Skip to main content
jowakar122
Senior
Apr 9, 2025 4:52 AM UTC
Solved

STM32H7 as TFTP Client

Earlier I implemented file transfer using TFTP in which my stm32 module was working as a server. But now I want to make it work as a TFTP client. Is there any example regarding TFTP client.

This topic has been closed for replies.
jowakar122Best answer
Senior
Apr 23, 2025 12:29 PM UTC

@Will5 I have gone through your post and I think you might be using udp_connect or some other function to connect to the TFTP server, where you have define the server IP address and the default port 69. If you are doing this in that case only you will find yourself where you are. 

So the solution is to, create a pcb for you TFTP client, bind to it and set a receive callback. For the TFTP server you need one thing which is its IP address. Don't bind or connect to the TFTP serve using any function, about the port it is already defined as TFTP_PORT in tftp_opts.h file so you can use that. 

jowakar122_0-1745411234396.png

Then just send the read request to the server. When the server replies back using a different port the receive callback will be called from there you will get the port of server and use it for further communication or file transfer.

jowakar122_1-1745411381272.png

 

View in thread

4 replies

jowakar122Author
Senior
Apr 9, 2025 8:38 AM UTC

Does anyone have any reference documents related to TFTP client in STM32.

Will5
Associate II
Apr 22, 2025 10:25 PM UTC

Hi jowakar122!

I posted something similar, then your thread came up after I hit submit!  I'm also trying to get a TFTP client going.  I am having trouble with how the TFTP protocol send back replies to a read request from a different port than the request was sent to and that confuses LwIP.  I'm using netconn. I posted my question here

https://community.st.com/t5/stm32-mcus-embedded-software/lwip-and-a-tftp-client/td-p/795573

If I cheat a bit I can get it to work (see the post), but that isn't a real solution, just one that confirms the issue is what I am thinking it is.  Letting you know in case I get a reply.

will

jowakar122AuthorBest answer
Senior
Apr 23, 2025 12:29 PM UTC

@Will5 I have gone through your post and I think you might be using udp_connect or some other function to connect to the TFTP server, where you have define the server IP address and the default port 69. If you are doing this in that case only you will find yourself where you are. 

So the solution is to, create a pcb for you TFTP client, bind to it and set a receive callback. For the TFTP server you need one thing which is its IP address. Don't bind or connect to the TFTP serve using any function, about the port it is already defined as TFTP_PORT in tftp_opts.h file so you can use that. 

jowakar122_0-1745411234396.png

Then just send the read request to the server. When the server replies back using a different port the receive callback will be called from there you will get the port of server and use it for further communication or file transfer.

jowakar122_1-1745411381272.png

 

Will5
Associate II
Apr 23, 2025 7:39 PM UTC

Jowakar122:

 

Alas the calls you are referring to are the native (callback) API.  All the rest of my code is based on the netconn (blocking) API.  While I haven't seen it said explicitly, I'm 99% sure you can't mix the two APIs simultaneously.

My other concern is just making the assumption that any packet coming back no matter the server port ID is a TFTP packet.  Maybe its a packet for another connection?  While not required, I'd like the server I'm talking to for the rest of my project to also be the TFTP server too.  Now I'm making weird assumptions about what port numbers go to which connection.  That seems awful messy.

I have trouble believing the problem is this bad.  This isn't an LwIP issue directly, it is the way TFTP works goes against how normal IP traffic is supposed to be routed.  The LwIP effort is basically how to work around it.  Now that it is more about "the internet" vs LwIP I'm going to poll some Unix/Linux gurus and see if there is something I'm missing.

I appreciate the replies!  I'll keep you posted. 

will

Terms & ConditionsAccessibility statement