Bug in getting the origin of UDP packets ?

thospel@mail.dma.be
Sun, 5 Oct 1997 00:57:52 +0200 (CEST)


Hi,

while developing some code for an asynchronous DNS library, I came across
the followin problem:

basically, the application sends packets to a nameserver and reacts to
returning packets. It tries to look at the origin of the packet it gets
back to match the answer with the question that caused it (i'm trying
to use for each nameserver a different message ID counter). This works
just fine for the first packet, but fails completely for the second one.

I'll show you some strace output:

# Setting up the socket
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 17
# Doing a query to my local nameserver (it's on localhost, but you get exactly
# the same results when running it on any other interface)
sendto(17, "\375\'\1\0\0\1\0\0\0\0\0\0\3www\6"..., 32, 0, {sin_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("127.0.0.1")}, 16) = 32
# Wait for an answer (is the only thing happening in this test)
oldselect(18, [17], [], [], NULL) = 1 (in [17])
# As expected, I get an answer from 127.0.0.1, port 53
recvfrom(17, "\375\'\201\200\0\1\0\2\0\4\0\5\3"..., 4096, 0, {sin_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("127.0.0.1")}, [16]) = 273
# Send a another, simular query
sendto(17, "\375(\1\0\0\1\0\0\0\0\0\0\3www\6"..., 42, 0, {sin_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("127.0.0.1")}, 16) = 42
# Wait for the answer again
oldselect(18, [17], [], [], NULL) = 1 (in [17])
# The contents of the returned packet are fine, but the struct sockaddr
# is completely zero :-(
recvfrom(17, "\375(\205\203\0\1\0\0\0\1\0\0\3w"..., 4096, 0, {sa_family=0, sa_data="\0\0\0\0\0\0\0\0\0\0\0\0\0\0"}, [16]) = 101

I tested this on my very non standard system at home (kernel 2.1.57), and
on a very standard debian installation on a notebook (kernel 2.0.29), both
giving the same results.

I can provide you with code, but it's a small part of a very big program
(I definitely should split out that library) that is at the moment
very much in a development state (no neat closed package). Contact me
if you want it.

Ton