Hi all,
I know that the kernel forbids sending UDP packets to port 0. Is there a
specific reason for this?
I'm asking because I regularly need to access a device that asks for
tftp files using port 0 as source. To use these devices I'm using a
kernel with removed port 0 checks.
I read RFC 768, and it does not explicitly forbid the use of port 0 as
far as I can see. It only says that if unused, 0 is to be inserted.
RFC 1350 (TFTP) even states explicitly:
The transfer identifiers (TID's) used by TFTP are passed to the Datagram
layer to be used as ports; therefore they must be between 0 and 65,535.
In my understanding, and apparently that of the authors of the
appliance's tftp client implementation, this marks port 0 as valid.
Please CC: me on any replies as I am not subscribed to the list.
Regards,
Chris
On Sunday 2008-06-22 10:19, Christian P. Schmidt wrote:
>
> RFC 1350 (TFTP) even states explicitly:
> The transfer identifiers (TID's) used by TFTP are passed to the Datagram layer
> to be used as ports; therefore they must be between 0 and 65,535.
One could interpret "between" as 0 > x < 65535 and not
0 >= x <= 65535 (that could be "between (inclusive)").
Christian P. Schmidt wrote:
> Hi all,
>
> I know that the kernel forbids sending UDP packets to port 0. Is there a
> specific reason for this?
_Source_ port 0 is treated specially in the sockets implementation,
though I'm not sure whether this is an intended feature of the API
(manpages don't mention it). If you say "bind to port 0", you get an
arbitrary unused port instead, which is potentially useful.
> I'm asking because I regularly need to access a device that asks for
> tftp files using port 0 as source. To use these devices I'm using a
> kernel with removed port 0 checks.
>
> I read RFC 768, and it does not explicitly forbid the use of port 0 as
> far as I can see. It only says that if unused, 0 is to be inserted.
1. No, it only says that about the source port.
2. The only way to tell whether the field is "unused" is to check for
a 0 value.
> RFC 1350 (TFTP) even states explicitly:
> The transfer identifiers (TID's) used by TFTP are passed to the Datagram
> layer to be used as ports; therefore they must be between 0 and 65,535.
>
> In my understanding, and apparently that of the authors of the
> appliance's tftp client implementation, this marks port 0 as valid.
They're a bit mad then. RFC1700 marks port 0 as "reserved" (other
unused ports are marked "unassigned").
I hope that explains why most sane people would avoid using port 0. I
can't think of a specific reason for forbidding port 0 as a
destination; it's just generally not expected (and there was no reason
to allow it). I think you need to be more specific if you hope to
have this check removed in mainline though.
Which TCP/IP stacks is the device tested/supported against? Are you
saying Windows or some other OS lets you send to port 0?