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>
next in thread | previous in thread | raw e-mail | index | archive | help
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. BMS
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?45A807F8.7080603>