TFTP Server Downloads (remote GET) Reliability

[davefilip]

I understand that the TFTP server included in /addons/ was primarily designed to permit uploading (remote PUT) a new kernel image to the root of the SD card. This is very useful, and means that replacing / testing a new kernel image does not require physically removing the SD card from the Raspberry Pi, inserting it into another system (where the new kernel was built), copying the new kernel to the card, removing, re-inserting, and then rebooting. With the TFTP server, it is a simple network copy and reboot. Uploading files, large and small, to the SD card appears to work reliably, even if a bit slow. Brilliant feature.

However, I see that the TFTP server also provides a download (remote GET) as well, to download files. For that functionality, it appears to only work with small (perhaps 30K or less?) files. From the Circle perspective, it logs the READ connection, and logs the completion, but always in about a second even for larger (1 - 2 MB) files. On the remote side, the GET usually receives around 30K - 50K or so, and then eventually times out (it looks like it is still waiting to receive long after Circle logs completion).

I have a theory as to why this is happening, but first wanted to confirm whether this should work? I have tried a few different TFTP clients with the same result.

Or is the TFTP server in /addon/ really not designed for downloads (remote GETs) from the SD card.

BTW - I am using the FAT FS version in /addon/ (tftpfatfsfileserver.cpp).

I can provide additional details if this is something that should work / is tested. But if it is something that was included with the price of the dinner, but not really used, then it is probably not a priority to fix?

Cheers,

Dave.

[davefilip]

Update on file size: I did some more testing, and it appears ... at least for a RPi 3 on WiFi ... that the limit is around 250K to download (remote GET) from Circle running the TFTP server.

The larger the file is over that limit, the less is actually received (e.g., downloading a 300K file will download around 260K before disconnecting, a 1 MB file will download around 30K before disconnecting).

And since TFTP is using UDP, the network transport does not ACK the packets, and the application must handle that.

[rsta2]

This is odd and should be sorted out. But I'm using the TFTP server frequently to upload and download kernel images and configuration files of different sizes (about 1 KByte to 1 MByte) to a remote RPi Zero W running an app using circle- stdlib. I did not notice any problems with it. I have to stop the local firewall on my Linux desktop, before using TFTP. Have your tested this with the Circle example addon/tftpfileserver/sample?

[davefilip]

I will test further - seems to work on downloads of 1 to 1.5 MB kernel images on Ethernet but not WiFi.  WiFi downloads limited to around 150K.  Uploads are always successful.Let me test further and provide more results.  Downloads always complete - from Circle perspective - in about 1 second or less regardless of size of file.  It appears as though Circle downloads might not be waiting for ACK for each numbered data packet?  Just a guess based on what I am seeing.I will provide more info now that know this should work.  But give me a couple days as I have some other - non-related - work to catch up on.  More by the end of the week.

[rsta2]

I'm also using WiFi with the mentioned app for TFTP. Circle checks for ACK and block number here. Oops, the if-condition should be AND'ed together, not OR'ed. Can you change this to

if (   nResult == sizeof AckPacket
     && AckPacket.OpCode == BE (OP_CODE_ACK)
     && AckPacket.BlockNumber == le2be16 (usBlockNumber))

and test again? Thanks.

[davefilip]

Perfect! That fixes it!

I think before in only worked if the network was able to keep up with the UDP stream, and now it works even if it can’t. So your WiFi network must be faster than mine … ;-)

[Actually, for my Circle testing, I think I’m still connecting to a very old 2.4 GHz router in my basement, since WPA handshakes better there when I am testing WiFi on the RPi4 … the Circle + RPi4 combination seems to WPA handshake faster on 2.4 GHz than 5 GHz, at least in my environment ...]

Nonetheless, I very much appreciate the quick fix!

Cheers,

Dave.

On Nov 12, 2024, at 2:46 PM, Rene Stange @.***> wrote:

I'm also using WiFi with the mentioned app for TFTP. Circle checks for ACK and block number here https://github.com/rsta2/circle/blob/c243194670720c8a13e6a553654b6d26ec7845a0/lib/net/tftpdaemon.cpp#L315. Oops, the if-condition should be AND'ed together, not OR'ed. Can you change this to

if ( nResult == sizeof AckPacket && AckPacket.OpCode == BE (OP_CODE_ACK) && AckPacket.BlockNumber == le2be16 (usBlockNumber)) and test again? Thanks.

— Reply to this email directly, view it on GitHub https://github.com/rsta2/circle/issues/498#issuecomment-2471426982, or unsubscribe https://github.com/notifications/unsubscribe-auth/BA2V5KXARUPZBZAP7PVI6Q32AJLKDAVCNFSM6AAAAABRUAZ4CWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINZRGQZDMOJYGI. You are receiving this because you authored the thread.

[rsta2]

Fine! Yes, I was obviously lucky, that it was working here before. I will fix it soon on the develop branch. Thanks for reporting and testing!

Rene