[U-Boot-Users] Multicast TFTP problems

[U-Boot-Users] Multicast TFTP problems

[Rafal Jaworowski]

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

[U-Boot-Users] Multicast TFTP problems

[Ben Warren]

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

[U-Boot-Users] Multicast TFTP problems

[David Updegraff]

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/

[U-Boot-Users] Multicast TFTP problems

[Rafal Jaworowski]

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

[U-Boot-Users] Multicast TFTP problems

[Ben Warren]

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

[U-Boot-Users] Multicast TFTP problems

[Rafal Jaworowski]

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

[U-Boot-Users] Multicast TFTP problems

[Ben Warren]

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