recvfrom() не работает

Question

я был открытым исходным кодом трески (это это ссылка) Визит https://github.com/jtRIPper/dns-tcp-socks-proxy/blob/master/dns_proxy.c в этой части трески

while(1) 
    { 
     // receive a dns request from the client 
     printf("wait for a dns request from the client\n"); 
     len = recvfrom(sock, buffer->buffer, 2048, 0, (struct sockaddr *)&dns_client, &dns_client_size); 
     printf("dns request received\n"); 


     // fork so we can keep receiving requests 
     if (fork() != 0) { continue; } 

     // the tcp query requires the length to precede the packet, so we put the length there 
     query = malloc(len + 3); 
     query[0] = 0; 
     query[1] = len; 
     memcpy(query + 2, buffer->buffer, len); 

     // forward the packet to the tcp dns server 
     fprintf(LOG_FILE, "tcp query call\n"); 
     tcp_query(query, buffer, len + 2); 

     // send the reply back to the client (minus the length at the beginning) 
     sendto(sock, buffer->buffer + 2, buffer->length - 2, 0, (struct sockaddr *)&dns_client, sizeof(dns_client)); 

     free(buffer->buffer); 
     free(buffer); 
     free(query); 

     exit(0); 

, recvfrom() функция не работает, и я не могу continiu и show "dns request received \ n" в чем проблема? а затем, когда я использую NETSTAT команду -upan трактир лин я вижу это

Активные подключения к Интернету (серверы и установленные) Прото Recv-Q Send-Q Локальный имя адрес Внешний адрес Состояние PID/Program УДП 0 0 127,0 .0.1: 951 0.0.0.0:* 1623/rpc.statd
udp 0 0 0.0.0.0:54721 0.0.0.0:* 2214/avahi-daemon: udp 0 0 0.0.0.0:45085 0.0.0.0:* 1623 /rpc.statd
0 UDP 127.0.0.1:53 0 0.0.0.0:* 4084/dns_proxy
0 UDP 0.0.0.0:68 0 0.0.0.0:* 1628/dhclient
UDP 0 0 0.0.0.0:111 0.0.0.0:* 1582/rpcbind
udp 0 0 0.0.0.0:631 0.0.0.0:* 2323/cupsd
udp 0 0 0.0.0.0:5353 0.0.0.0:* 2214/Avahi-демон: UDP 0 0 0.0.0.0:42756 0.0.0.0:* 1628/dhclient
0 UDP 0.0.0.0:1900 0 0.0.0.0:* 3306/minissdpd
0 0 UDP 0.0.0.0:908 0.0 .0.0: * 1582/RPCbind
udp6 0 0 ::: 111 ::: * 1582/RPCbind
udp6 0 0 ::: 34443 ::: * 1623/rpc.statd
udp6 0 0 ::: 5353 ::: * 2214/avahi-daemon: udp6 0 0 ::: 62844 ::: * 1628/dhclient
udp6 0 0 ::: 54654 ::: * 2214/Avahi-демон: udp6 0 0 ::: 908 ::: * 1582/RPCbind

Answer 1

Аналогичная модификация (добавление printf после recvfrom()) отлично подходит для меня. Вы внесли какие-либо другие изменения в программу, помимо печати?

Эти шаги, которые я сделал, чтобы проверить это:

1. мерзавец клонировать репозиторий
2. добавить printfs к источнику
3. сделать
4. редактировать dns_proxy.conf войти куда-нибудь, чем/DEV/нуль
5. В другом терминале, SSH someuser@a.box.somewhere -D локальный: 9050
6. sudo ./dns_proxy
7. Тест с: хост ftp.funet.fi

BTW. Добавление printf(), где вы предлагаете производить много вывода на рабочем столе, где у вас есть другие приложения, такие как веб-браузер или клиент электронной почты, поэтому будьте осторожны. Возможно, вы можете использовать соглашение о протоколировании, которое использует остальная часть источника, например.

if (LOG == 1) { fprintf(LOG_FILE, "Using DNS server: %s\n", inet_ntoa(*(struct in_addr *)&remote_dns)); } 

BTW2. Не забудьте взять резервную копию вашего /etc/resolv.conf перед запуском dns_proxy, если вы создали или отредактировали его вручную. Используйте tailf "your_dns_proxy_logfile.log", чтобы узнать, что происходит.

BTW3. Эта программа не очень надежна. Он утечки fds, есть один за другим в string_value(), а udp_listener() делает malloc() и memcpy() без проверки возвращаемого значения recvfrom(). На моей машине это очень много. Кажется, только едва функционирует.

EDIT Вот некоторые изменения, которые я внес в оригинал. https://github.com/thuovila/dns-tcp-socks-proxy/ После этих изменений не прерывается для каждого прерывания recvfrom(). Изменения были объединены с восходящим репо.

Answer 2

Может быть нет данных получать в первую очередь. Тот факт, что вы не видите «полученный DNS-запрос», означает, что вызов recvfrom() находится в состоянии блокировки, ожидающем приема данных. Вам нужно будет исследовать, отправляет ли отправитель hte данные или нет. Затем вам, вероятно, придется перепроверять, если носок связан с правильным портом. Возможно, вам захочется разделить код отправителя, а также код recvfrom, где происходит связывание.