 | 1 | initial version |
Logically, the higher the packet size the less number of packets required to send a file. This is true when I try 128, 512, 1024 and 1428 bytes options. However, when I go for 2048, 4096, till 32768 bytes options, this logic is no longer applicable and I observe the following in WireShark:
TFTP runs over UDP, and a single UDP packet is sent as a single IP packet.
If the IP packet is too big to be sent in a single link-layer packet, the sending IP layer "fragments" it into smaller packets, each of which can be sent in a single link-layer packet, and the receiving IP layer must reassemble all the fragments of the original IP packet and provide that to the receiving UDP layer. UDP has no mechanism to handle this itself, unlike TCP, which divides the stream of data provided to it into "segments", each of which can be made small enough to fit in a single link-layer packet.
The maximum size of a raw Ethernet packet, without counting the FCS (which is usually not captured by Wireshark, so it won't show up in the packet or in the frame length) is 1514 bytes; that's 14 bytes of Ethernet header (destination address, source address, type/length), and 1500 bytes of payload.
A TFTP data packet sending 1024 bytes of data, sent as an IPv4 packet over Ethernet, and with no IP options, will have 14 bytes of Ethernet header, 20 bytes of IPv4 header, 8 bytes of UDP header, 4 bytes of TFTP header, and 1024 bytes of data, for a total of 1070 bytes, which is <= 151, so that can be sent in an un-fragmented IPv4 packet.
A TFTP data packet sending 1428 bytes of data, sent as an IPv4 packet over Ethernet, and with no IP options, will have 14 bytes of Ethernet header, 20 bytes of IPv4 header, 8 bytes of UDP header, 4 bytes of TFTP header, and 1428 bytes of data, for a total of 1474 bytes, which is <= 1514, so that can be sent in an un-fragmented IPv4 packet.
A TFTP data packet containing 2048 bytes of data, sent as an IPv4 packet over Ethernet, and with no IP options, will have 14 bytes of Ethernet header, 20 bytes of IPv4 header, 8 bytes of UDP header, 4 bytes of TFTP header, and 2048 bytes of data, for a total of 2094 bytes, which is > 1514, and which thus would have to be sent as more than one fragment of a fragmented IPv4 packet.
Packets size is not equal to the specified option. for example: for 2048 bytes option, packet size= 614 bytes !!
The first fragment will probably be the maximum size, with 14 bytes of Ethernet header, 20 bytes of IPv4 header, 8 bytes of UDP header, 4 bytes of TFTP header, and 1468 bytes of data and the second fragment will contain the remaining 2048 - 1468 = 580 bytes of data; it does not need to included the UDP or TFTP headers, as those were sent in the first fragment, it only needs an Ethernet header, an IPv4 header, and an FCS, so that's 14 bytes of Ethernet header, 20 bytes of IPv4 header, and 580 bytes of data, for a total of 614 bytes.
Wireshark can also reassemble fragmented IPv4 packets, and does so, by default; it will show the last fragment in the capture as the fully reassembled packet, and will show earlier fragments as fragments of a larger IPv4 packet, so, for example, in the capture you uploaded, frame 3764 is the first fragment of the first TFTP packet with 2048 bytes of data, and shows up as a "Fragmented IP packet", and frame 3765 is the second fragment of that TFTP packet, and shows up as a TFTP packet that's "Data packet, block 1".
Less number of packets required to send a file even though packet size is much less.
If you use "tftp" as a filter, you'll see only the last fragment; you won't see the other fragments.
Try a filter of "tftp || ip.flags.mf == 1"; that will show all packets that Wireshark dissects as TFTP and all packets other than the last fragment. That way, you'll see all the packets involved in the TFTP transfer.
The file transferring is much faster.
The numbers in your screen shot are "0 second" and "1 second"; does the TFTP program bother to keep track of fractional seconds, or even just to round up to the next integral number of seconds?
If not, then "0 second" could be 0.999999999 seconds and "1 second" could be 1.00000001 seconds, which isn't a big difference.
And, even if it just rounds up, "0 second" could be 0.49999999 seconds and "1 second" could be 0.500000001 second, which, again, isn't a big difference.
If the program isn't keeping track of fractional seconds, then, to get meaningful results, you'd need to transfer much larger files, so that it takes, say, 10 or more seconds.
File sent is complete and no corruption on file.
TFTP runs on top of UDP, and UDP does no detection and retransmission of packets not received by the host on the other end, so TFTP does that itself.
| | 2 | No.2 Revision |
Logically, the higher the packet size the less number of packets required to send a file. This is true when I try 128, 512, 1024 and 1428 bytes options. However, when I go for 2048, 4096, till 32768 bytes options, this logic is no longer applicable and I observe the following in WireShark:
TFTP runs over UDP, and a single UDP packet is sent as a single IP packet.
If the IP packet is too big to be sent in a single link-layer packet, the sending IP layer "fragments" it into smaller packets, each of which can be sent in a single link-layer packet, and the receiving IP layer must reassemble all the fragments of the original IP packet and provide that to the receiving UDP layer. UDP has no mechanism to handle this itself, unlike TCP, which divides the stream of data provided to it into "segments", each of which can be made small enough to fit in a single link-layer packet.
The maximum size of a raw Ethernet packet, without counting the FCS (which is usually not captured by Wireshark, so it won't show up in the packet or in the frame length) is 1514 bytes; that's 14 bytes of Ethernet header (destination address, source address, type/length), and 1500 bytes of payload.
A TFTP data packet sending 1024 bytes of data, sent as an IPv4 packet over Ethernet, and with no IP options, will have 14 bytes of Ethernet header, 20 bytes of IPv4 header, 8 bytes of UDP header, 4 bytes of TFTP header, and 1024 bytes of data, for a total of 1070 bytes, which is <= 151, 1514, so that can be sent in an un-fragmented IPv4 packet.
A TFTP data packet sending 1428 bytes of data, sent as an IPv4 packet over Ethernet, and with no IP options, will have 14 bytes of Ethernet header, 20 bytes of IPv4 header, 8 bytes of UDP header, 4 bytes of TFTP header, and 1428 bytes of data, for a total of 1474 bytes, which is <= 1514, so that can be sent in an un-fragmented IPv4 packet.
A TFTP data packet containing 2048 bytes of data, sent as an IPv4 packet over Ethernet, and with no IP options, will have 14 bytes of Ethernet header, 20 bytes of IPv4 header, 8 bytes of UDP header, 4 bytes of TFTP header, and 2048 bytes of data, for a total of 2094 bytes, which is > 1514, and which thus would have to be sent as more than one fragment of a fragmented IPv4 packet.
Packets size is not equal to the specified option. for example: for 2048 bytes option, packet size= 614 bytes !!
The first fragment will probably be the maximum size, with 14 bytes of Ethernet header, 20 bytes of IPv4 header, 8 bytes of UDP header, 4 bytes of TFTP header, and 1468 bytes of data and the second fragment will contain the remaining 2048 - 1468 = 580 bytes of data; it does not need to included the UDP or TFTP headers, as those were sent in the first fragment, it only needs an Ethernet header, an IPv4 header, and an FCS, so that's 14 bytes of Ethernet header, 20 bytes of IPv4 header, and 580 bytes of data, for a total of 614 bytes.
Wireshark can also reassemble fragmented IPv4 packets, and does so, by default; it will show the last fragment in the capture as the fully reassembled packet, and will show earlier fragments as fragments of a larger IPv4 packet, so, for example, in the capture you uploaded, frame 3764 is the first fragment of the first TFTP packet with 2048 bytes of data, and shows up as a "Fragmented IP packet", and frame 3765 is the second fragment of that TFTP packet, and shows up as a TFTP packet that's "Data packet, block 1".
Less number of packets required to send a file even though packet size is much less.
If you use "tftp" as a filter, you'll see only the last fragment; you won't see the other fragments.
Try a filter of "tftp || ip.flags.mf == 1"; that will show all packets that Wireshark dissects as TFTP and all packets other than the last fragment. That way, you'll see all the packets involved in the TFTP transfer.
The file transferring is much faster.
The numbers in your screen shot are "0 second" and "1 second"; does the TFTP program bother to keep track of fractional seconds, or even just to round up to the next integral number of seconds?
If not, then "0 second" could be 0.999999999 seconds and "1 second" could be 1.00000001 seconds, which isn't a big difference.
And, even if it just rounds up, "0 second" could be 0.49999999 seconds and "1 second" could be 0.500000001 second, which, again, isn't a big difference.
If the program isn't keeping track of fractional seconds, then, to get meaningful results, you'd need to transfer much larger files, so that it takes, say, 10 or more seconds.
File sent is complete and no corruption on file.
TFTP runs on top of UDP, and UDP does no detection and retransmission of packets not received by the host on the other end, so TFTP does that itself.
