Leandro Santi
lesanti@uolsinectis.com.ar
Sat Jul 19 07:59:12 UTC 2003
Hi list, Vernon, Some DCC clients here have been reporting recv() errors: Jul 19 04:24:27 dcc2 postfix/smtpd[24853]: recv(216.244.192.2,53)=28 < 40 Jul 19 04:28:45 dcc2 postfix/smtpd[25367]: recv(216.244.192.3,53)=36 < 40 Jul 19 04:31:28 dcc2 postfix/smtpd[25600]: recv(216.244.192.130,53)=28 < 40 Jul 19 04:31:28 dcc2 postfix/smtpd[25600]: recv(216.244.192.2,53)=28 < 40 I've been tracing the problem a bit and I think its a false alarm. These machines are running ancient Linux-2.2, so the default port range is quite small (about ~4k as reported by /proc/sys/net/ipv4/ip_local_port_range). This increases de likelihood of port reutilization. The DCC uses a single UDP socket to talk to possibly multiple DCCD's, so the socket can sometimes be disconnected (ie it can receive datagrams from anywhere if the destination port is the socket's local port). Some of these DNS datagrams will be picked up by the DCC socket, hence an alarm will be triggered. Of course, the problem is emphasized if I shrink the local port range even more (actually my first workaround was just to expand the local port range by 10x so as to keep the noc people happy :-). The patch just checks the datagram's source port before the sanity checking, to see if it comes from a valid DCCd port. If it doesn't, it simply discards it. If it does, the usual checks will be done. http://webs.sinectis.com.ar/lesanti/dcc/dcc-dccd-1.1.43-disconnected_socket.patch Maybe its better to actually use a dedicated, connected socket for each DCCd descriptor, but I guess it will be a more invasive hack. Regards, Leandro
More information about the DCC
mailing list