use bound listen port(s) to respond to client

[robertpenz]

Currently the TFTPy Server does use a random Source Port with the Source Port of the request of the client as destination port for sending files. This seems to make problems with some PXE BIOSes. With other TFTP Server which use source Port 69 there are no problems.

[robertpenz]

I've just tested it with a second notebook from an other vendor. It hangs always at the bbl.c32 file, all files before work. I've done a network trace: http://robert.penz.name/files/tftp_test_1.pcap

I don't see any difference to a working pxe boot just the source port. Can you help me please? I don't know what to look further, why does the client not answer that packets? Thx!

ps: both notebooks use as src port for that file request (bbl.c32) always 57100 .. don't know why.

[msoulier]

So the client is in the notebook bios while you're using tftpy on the server?

No idea. I don't see anything wrong with the traffic sent. The client even acked the oack, and then didn't bother acking any of the dat packets.

It's asking for odd blocksizes though. Why 1408? The DAT packets appear to be the right length though.

[robertpenz]

Yes

Here is a link to the pxe boot from the same notebook to the original server. I only see the source port as difference. http://robert.penz.name/files/tftp_working.pcap

how easy is it to make a quick and dirty patch for tftpy to use 69 as source port? just for testing.

[msoulier]

Note that tftpy's behaviour is rfc compliant. From RFC 1350:

In order to create a connection, each end of the connection chooses a
TID for itself, to be used for the duration of that connection. The
TID's chosen for a connection should be randomly chosen, so that the
probability that the same number is chosen twice in immediate
succession is very low. Every packet has associated with it the two
TID's of the ends of the connection, the source TID and the
destination TID. These TID's are handed to the supporting UDP (or
other datagram protocol) as the source and destination ports. A
requesting host chooses its source TID as described above, and sends
its initial request to the known TID 69 decimal (105 octal) on the
serving host. The response to the request, under normal operation,
uses a TID chosen by the server as its source TID and the TID chosen
for the previous message by the requestor as its destination TID.
The two chosen TID's are then used for the remainder of the transfer.

Port 69 is only used for the initial request.

[msoulier]

At the moment the TftpServer owns the socket bound to udp port 69. For a context object to send from that port, it would have to be passed through the server class and out that socket, instead of using the currently used emphemeral ports.

[robertpenz]

I believe you that tftpy is RFC compliant ... still the BIOS of some major vendors (HP and Dell in that case) hang.

[msoulier]

This is also important for NAT traversal through firewalls.