Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 Apollo 11/21/85; site apollo.uucp
Path: utzoo!utcsri!ubc-vision!uw-beaver!apollo!mishkin
From: mishkin@apollo.uucp (Nathaniel Mishkin)
Newsgroups: net.unix-wizards,net.bugs.4bsd
Subject: TFTP/UDP/IP on 4.2bsd
Message-ID: <2ba5fe22.3166@apollo.uucp>
Date: Thu, 30-Jan-86 15:23:27 EST
Article-I.D.: apollo.2ba5fe22.3166
Posted: Thu Jan 30 15:23:27 1986
Date-Received: Fri, 31-Jan-86 07:25:47 EST
Reply-To: mishkin@apollo.UUCP (Nathaniel Mishkin)
Organization: Apollo Computer Inc., Chelmsford MA
Lines: 23
Summary: 

I am implementing a new socket domain.  This domain supports only datagram
style sockets.  So, I figured, what better way to test my new sockets
than by hacking up "tftp" and "tftpd" a bit (just enough to remove the
IP addressing dependencies).  Unfortunately, when I looked through the
code, I saw that once the daemon gets a "request" packet on the "tftp"
well-known port, it forks.  The child continues to read on the same file
descriptor (port).  The parent goes back to the top of its listen loop,
creates a new socket, and binds its end to the "tftp" well-known port
again.  Well, I said, someone's understanding of how UDP works is different
from mine because if the implementation is correct, then "tftp/tftpd"
could never work since both the parent and the child would be reading
packets from the same port -- it would be random which were gotten by
the parent and which were gotten by the child.  The apparent reason things
work on 4.2 is because the kernel demultiplexes incoming UDP packets
based on BOTH the packet's local AND foreign port.  If I understand the
UDP/IP spec, this is a bug -- you're supposed to demultiplex incoming
packets by looking ONLY at the local port.

Comments?

            -- Nat Mishkin
               Apollo Computer Inc.
               {wangins,yale,uw-beaver}!apollo!mishkin