This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

[closed] TFTP windowing not working

0

Hi

I'm using TFTP to transfer a 300mb boot file over a wan link as part of an Operating System Deployment solution.

The file is hosted on a Windows 2012 server. It takes about 20 minutes to transfer the file. A packet trace revealed that the client was ACK'ing every block. Whilst I know that this use to be normal for TFTP since Windows Server 08 the default value for Windowing is 4.

Does anyone have any idea why this might be happening or suggest any troubleshooting ideas?

Cheers

Alex

asked 01 Jul '14, 01:55

troubleshootist's gravatar image

troubleshootist
11●2●2●5
accept rate: 0%

closed 01 Jul '14, 06:31

Jaap's gravatar image

Jaap ♦
11.7k●16●101

Some questions:

  • what is your TFTP client (OS and OS version)
  • what is the RTT of the WAN link
  • what is the available bandwidth of the WAN link
  • can you post a sample capture file on google drive, dropbox or cloudshark.org, including the first 100 frames of the session
(01 Jul '14, 04:08) Kurt Knochner ♦

Hi

the client is PXE booting so it has no meaningful OS at the time of the download. All the TFTP setting are dictated by the BSD on the server.

The RTT is about 12ms

I can't post a capture file but here is a screen shot. As you can see every block is being Ack'ed

alt text

(01 Jul '14, 06:12) troubleshootist

The question has been closed for the following reason “Question is off-topic or not relevant” by Jaap 01 Jul ‘14, 06:31

One Answer:

0

A packet trace revealed that the client was ACK'ing every block.

As you said, TFTP requires every data block to be ACKed before the next block can be sent.

http://tools.ietf.org/html/rfc1350

2. Overview of the Protocol
   ....
   length blocks of 512 bytes.  Each data packet contains one block of
   data, and must be acknowledged by an acknowledgment packet before the
   next packet can be sent.

There are TFTP Extension options to change the block size, which will have an effect on the number of ACKs as well.

http://tools.ietf.org/html/rfc2348

However, that's an option the client requests and which the server must accept. In your example the blocksize is 1456 bytes. There are speed tests in the RFC mentioned above, that show tremendous performance gains by using larger block sizes (8K). This will especially help on a WAN link.

So, this is a config issue of the TFTP client in your PXE implementation on the client system and not related to the network.

Regards
Kurt

answered 01 Jul '14, 06:28

Kurt%20Knochner's gravatar image

Kurt Knochner ♦
24.8k●10●39●237
accept rate: 15%

Hi Kurt

you're right that the original implementation of TFTP reacquired every block to be ACK'ed before another was sent. However from Windows server 08 you can set a Window size so that not every block has to be ACK'ed immediately. The default is now set to 4, so that 4 blocks can be set before the client has to ACK them all. The windowing size is set in the BCD on te server and when I query it, it tells me the block size is 4.

We tried up'ing the block size but it made it grind to a halt. There's obviously a bit of network kit that doens't like alrge blocks and stops them ,so the Windowing issue seems to be the way to attach this problem.

Cheers

Alex

(01 Jul '14, 07:28) troubleshootist