Date: Fri, 12 Jan 2007 22:13:12 +0000 From: "Bruce M. Simpson" <bms@FreeBSD.org> To: Ricardo Nabinger Sanchez <rnsanchez@wait4.org> Cc: freebsd-net@freebsd.org, hugme@hugme.org Subject: Re: Problem with port 0 Message-ID: <45A807F8.7080603@FreeBSD.org> In-Reply-To: <20070112163057.2a3ec8f0.rnsanchez@wait4.org> References: <f9876c510701120903r65543ef4nafc7eeead2becb42@mail.gmail.com> <20070112163057.2a3ec8f0.rnsanchez@wait4.org>
index | next in thread | previous in thread | raw e-mail
Ricardo Nabinger Sanchez wrote: > On Fri, 12 Jan 2007 12:03:17 -0500 > "Hug Me" <hugme@hugme.org> wrote: > > >> We believe FreeBSD is not allowing a UDP source port of 0 and the kernel is >> dropping the packet before it ever reaches the tftp server but are unable to >> verify this hypothesis. I was hoping someone here could help shed some light >> on the problem. >> > > But port 0 has special meaning to the kernel (ie, "give me some random > port"). Also, it is a reserved one. Please check IANA: > > http://www.iana.org/assignments/port-numbers > > I'm afraid you'll have to select another port number. > Nope. A source port of 0 is perfectly legal for UDP. I did an experiment with rpcbind whereby I performed a UDP based rpcinfo query from one FreeBSD machine to another, captured the traffic, and used tcpreplay to inject it from source port 0. At first I thought the INPCB hash lookup was doing the wrong thing, then I ktrace'd rpcbind and it was apparent that it was in fact being delivered to rpcbind from udp_input(). rpcbind tries to reply to destination port 0. This was verified with kdump and rpcbind -d. This quite rightly fails, and, indeed, we reject this from the socket code. So, FreeBSD appears to handle a UDP source port of 0 ok based on these tests. The most likely explanation for the failure in this case, without looking further, is that inetd or the tftpd implementations can't handle source port 0. BMShome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?45A807F8.7080603>