[U-Boot-Users] Multicast TFTP problems
Dave,
I'm having problems with tftp transfer with current U-Boot running on MPC5121 (FEC controller); since your mcast tftp implementation we first attempt to transfer using some bigger blocksize: #define TFTP_MTU_BLOCKSIZE 1468, and it seems my problems are related to this size.
When running current code (ET_DEBUG enabled) it fails like the following:
=> run load Using FEC ETHERNET device TFTP from server 192.168.1.1; our IP address is 192.168.160.77 Filename '/tftpboot/ads5121/u-boot.bin'. Load address: 0x100000 Loading: send option "timeout 5" Got OACK: timeout 5 Blocksize ack: 1468, 1468 T T T T T T T T T T Retry count exceeded; starting again Using FEC ETHERNET device TFTP from server 192.168.1.1; our IP address is 192.168.160.77 Filename '/tftpboot/ads5121/u-boot.bin'. Load address: 0x100000 Loading: send option "timeout 5" Got OACK: timeout 5 Blocksize ack: 1468, 1468
Abort =>
It fails with TFTP_MTU_BLOCKSIZE values above 1454, but it's ok with anything up to this (including 1454):
=> run load Using FEC ETHERNET device TFTP from server 192.168.1.1; our IP address is 192.168.160.77 Filename '/tftpboot/ads5121/u-boot.bin'. Load address: 0x100000 Loading: send option "timeout 5" Got OACK: timeout 5 Blocksize ack: 1454, 1454 ########### done Bytes transferred = 157720 (26818 hex) =>
Any hints on these observations? What might be going wrong here?
kind regards, Rafal
Rafal,
Rafal Jaworowski wrote:
Dave,
I'm having problems with tftp transfer with current U-Boot running on MPC5121 (FEC controller); since your mcast tftp implementation we first attempt to transfer using some bigger blocksize: #define TFTP_MTU_BLOCKSIZE 1468, and it seems my problems are related to this size.
When running current code (ET_DEBUG enabled) it fails like the following:
=> run load Using FEC ETHERNET device TFTP from server 192.168.1.1; our IP address is 192.168.160.77 Filename '/tftpboot/ads5121/u-boot.bin'. Load address: 0x100000 Loading: send option "timeout 5" Got OACK: timeout 5 Blocksize ack: 1468, 1468 T T T T T T T T T T Retry count exceeded; starting again Using FEC ETHERNET device TFTP from server 192.168.1.1; our IP address is 192.168.160.77 Filename '/tftpboot/ads5121/u-boot.bin'. Load address: 0x100000 Loading: send option "timeout 5" Got OACK: timeout 5 Blocksize ack: 1468, 1468
Abort =>
It fails with TFTP_MTU_BLOCKSIZE values above 1454, but it's ok with anything up to this (including 1454):
=> run load Using FEC ETHERNET device TFTP from server 192.168.1.1; our IP address is 192.168.160.77 Filename '/tftpboot/ads5121/u-boot.bin'. Load address: 0x100000 Loading: send option "timeout 5" Got OACK: timeout 5 Blocksize ack: 1454, 1454 ########### done Bytes transferred = 157720 (26818 hex) =>
Any hints on these observations? What might be going wrong here?
kind regards, Rafal
TFTP packets are structured as follows:
| Eth header (14 bytes) | IP header (20 bytes) | UDP header (8 bytes) | TFTP message | Eth FCS (4 bytes) |
You can see that the total overhead is 46 bytes. If your network port's maximum MTU size is 1500 bytes (the default), the math works out for a maximum TFTP PDU size of 1454 bytes.
However... the Ethernet header/trailer is not supposed to be included in the MTU. I suspect we have a terminology problem here. Let me dig a bit further to find out what's going on.
regards, Ben
Sorry all; I've lost access to my testbed hardware, so for now am out of the loop.
Rafal Jaworowski wrote:
Dave,
I'm having problems with tftp transfer with current U-Boot running on MPC5121 (FEC controller); since your mcast tftp implementation we first attempt to transfer using some bigger blocksize: #define TFTP_MTU_BLOCKSIZE 1468, and it seems my problems are related to this size.
When running current code (ET_DEBUG enabled) it fails like the following:
=> run load Using FEC ETHERNET device TFTP from server 192.168.1.1; our IP address is 192.168.160.77 Filename '/tftpboot/ads5121/u-boot.bin'. Load address: 0x100000 Loading: send option "timeout 5" Got OACK: timeout 5 Blocksize ack: 1468, 1468 T T T T T T T T T T Retry count exceeded; starting again Using FEC ETHERNET device TFTP from server 192.168.1.1; our IP address is 192.168.160.77 Filename '/tftpboot/ads5121/u-boot.bin'. Load address: 0x100000 Loading: send option "timeout 5" Got OACK: timeout 5 Blocksize ack: 1468, 1468
Abort =>
It fails with TFTP_MTU_BLOCKSIZE values above 1454, but it's ok with anything up to this (including 1454):
=> run load Using FEC ETHERNET device TFTP from server 192.168.1.1; our IP address is 192.168.160.77 Filename '/tftpboot/ads5121/u-boot.bin'. Load address: 0x100000 Loading: send option "timeout 5" Got OACK: timeout 5 Blocksize ack: 1454, 1454 ########### done Bytes transferred = 157720 (26818 hex) =>
Any hints on these observations? What might be going wrong here?
kind regards, Rafal
TFTP packets are structured as follows:
| Eth header (14 bytes) | IP header (20 bytes) | UDP header (8 bytes) | TFTP message | Eth FCS (4 bytes) |
You can see that the total overhead is 46 bytes. If your network port's maximum MTU size is 1500 bytes (the default), the math works out for a maximum TFTP PDU size of 1454 bytes.
However... the Ethernet header/trailer is not supposed to be included in the MTU. I suspect we have a terminology problem here. Let me dig a bit further to find out what's going on.
regards, Ben
This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
Ben Warren wrote: [...]
TFTP packets are structured as follows:
| Eth header (14 bytes) | IP header (20 bytes) | UDP header (8 bytes) | TFTP message | Eth FCS (4 bytes) |
You can see that the total overhead is 46 bytes. If your network port's maximum MTU size is 1500 bytes (the default), the math works out for a maximum TFTP PDU size of 1454 bytes.
However... the Ethernet header/trailer is not supposed to be included in the MTU. I suspect we have a terminology problem here. Let me dig a bit further to find out what's going on.
Hi Ben,
Did you manage to look at this any further?
kind regards, Rafal
Rafal,
Rafal Jaworowski wrote:
Ben Warren wrote: [...]
TFTP packets are structured as follows:
| Eth header (14 bytes) | IP header (20 bytes) | UDP header (8 bytes) | TFTP message | Eth FCS (4 bytes) |
You can see that the total overhead is 46 bytes. If your network port's maximum MTU size is 1500 bytes (the default), the math works out for a maximum TFTP PDU size of 1454 bytes.
However... the Ethernet header/trailer is not supposed to be included in the MTU. I suspect we have a terminology problem here. Let me dig a bit further to find out what's going on.
Hi Ben,
Did you manage to look at this any further?
The size of 1468 works fine for me on an MPC8349EMDS board. I captured the transfer using Wireshark (Ethereal) and the numbers match exactly as I've shown above. Here are the first few transfers.
----------------------------------------------------------------------------------------------- No. Time Source Destination Protocol Info 1 0.000000 10.69.69.201 10.69.69.23 TFTP Read Request, File: zImage, Transfer type: octet
Frame 1 (80 bytes on wire, 80 bytes captured) Ethernet II, Src: Motorola_00:7d:20 (00:e0:0c:00:7d:20), Dst: WwPcbaTe_a3:fc:9c (00:0f:1f:a3:fc:9c) Internet Protocol, Src: 10.69.69.201 (10.69.69.201), Dst: 10.69.69.23 (10.69.69.23) User Datagram Protocol, Src Port: 2714 (2714), Dst Port: tftp (69) Trivial File Transfer Protocol Opcode: Read Request (1) Source File: zImage Type: octet Option: timeout = 5 Option: blksize = 1468
***** ***** You can see we've requested a block size of 1468 bytes *****
No. Time Source Destination Protocol Info 2 0.000891 10.69.69.23 10.69.69.201 TFTP Option Acknowledgement
Frame 2 (67 bytes on wire, 67 bytes captured) Ethernet II, Src: WwPcbaTe_a3:fc:9c (00:0f:1f:a3:fc:9c), Dst: Motorola_00:7d:20 (00:e0:0c:00:7d:20) Internet Protocol, Src: 10.69.69.23 (10.69.69.23), Dst: 10.69.69.201 (10.69.69.201) User Datagram Protocol, Src Port: 33454 (33454), Dst Port: 2714 (2714) Trivial File Transfer Protocol Opcode: Option Acknowledgement (6) Option: timeout = 5 Option: blksize = 1468
***** ***** The server acknowledges this option *****
No. Time Source Destination Protocol Info 3 0.000945 10.69.69.201 10.69.69.23 TFTP Acknowledgement, Block: 0
Frame 3 (60 bytes on wire, 60 bytes captured) Ethernet II, Src: Motorola_00:7d:20 (00:e0:0c:00:7d:20), Dst: WwPcbaTe_a3:fc:9c (00:0f:1f:a3:fc:9c) Internet Protocol, Src: 10.69.69.201 (10.69.69.201), Dst: 10.69.69.23 (10.69.69.23) User Datagram Protocol, Src Port: 2714 (2714), Dst Port: 33454 (33454) Trivial File Transfer Protocol Opcode: Acknowledgement (4) Block: 0
No. Time Source Destination Protocol Info 4 0.001605 10.69.69.23 10.69.69.201 TFTP Data Packet, Block: 1
Frame 4 (1514 bytes on wire, 1514 bytes captured) Ethernet II, Src: WwPcbaTe_a3:fc:9c (00:0f:1f:a3:fc:9c), Dst: Motorola_00:7d:20 (00:e0:0c:00:7d:20) Internet Protocol, Src: 10.69.69.23 (10.69.69.23), Dst: 10.69.69.201 (10.69.69.201) User Datagram Protocol, Src Port: 33454 (33454), Dst Port: 2714 (2714) Trivial File Transfer Protocol Opcode: Data Packet (3) Block: 1 Data (1468 bytes)
***** ***** The first block transfer. Notice the total size is 1514, indicating that this fits in an Ethernet MTU of 1500 bytes. *****
-----------------------------------------------------------------------------------------------
The only thing I can think of is that something on your network is limiting the MTU size to less than 1500 bytes. Are you using VLANs or PPPoE? Maybe your server has its MTU limited to 1486?
Please repeat what I've done here and let me know what you see.
regards, Ben
Ben Warren wrote:
The size of 1468 works fine for me on an MPC8349EMDS board. I captured the transfer using Wireshark (Ethereal) and the numbers match exactly as I've shown above. Here are the first few transfers.
[...]
The only thing I can think of is that something on your network is limiting the MTU size to less than 1500 bytes. Are you using VLANs or PPPoE? Maybe your server has its MTU limited to 1486?
Hi Ben,
Thanks for your help. It turned there was a bug in the MPC5121 FEC driver which occured only upon some bigger frames, so it wasn't anything MTU-related or the TFTP code. Strangely enough, the frame size offset it would or not corrupt coincided with the 46 bytes that are overhead for the TFTP...
kind regards, Rafal
Rafal,
Rafal Jaworowski wrote:
Hi Ben,
Thanks for your help. It turned there was a bug in the MPC5121 FEC driver which occured only upon some bigger frames, so it wasn't anything MTU-related or the TFTP code. Strangely enough, the frame size offset it would or not corrupt coincided with the 46 bytes that are overhead for the TFTP...
kind regards, Rafal
That's great news! Glad to see you're up and running.
regards, Ben
participants (3)
-
Ben Warren -
David Updegraff -
Rafal Jaworowski