(My first post to this group, hopefully I'm doing it right) I am trying to add a TFTP client to a project using FreeRTOS and LwIPs netconn API. I seem to have run into a pretty fundamental-looking conflict between the TFTP protocol and how LwIPs netconn interface normally works. I'm hoping someone out there either points out some newbie assumption error or at least confirms my "Plan B" is a roughly correct direction. The fundamental disconnect is that for TFTP, when the server responds to the clients initial packet, it doesn't respond from its well-known port address but a random "higher address" port. The problem is the netconn API only passes packets back to the caller if that return packet comes from the same port address it sent packets to. If a packet from that server comes back with a random source port it assumes that packet is for some other session. There isn't, so it drops the packet. That seems like the right action to take! On this "disagreement", I'm kind siding with LwIP: it is doing what I think should be done, but it breaks TFTP. I'm sure there is a reason TFTP does this, but I have no idea why.
My cheesy work-around for now is to tell the TFTP server to not choose a random port, but a specific port. Then on my client side right after sending the TFTP request packet I quickly change the listening port in the PCB structure to the fixed port I set the server (pcb.udp->remote_port=30000). This works for now and seeing it work gives me comfort I have the issue well understood. The stock answer to wanting to see all packets is to use the raw API. For the 5+ other tasks already using LwIPs netconn I'm pretty committed to the netconn API, so don't want to do that. My glimmer of hope is the official docs for LWIP's netconn_bind() call state that for the port parameter it has the note "(not used for RAW)". This is a netconn function, so shouldn't be referencing the raw API, so maybe it is referring to the NETCONN_RAW option for netconn_new()? I can't find any human examples of using NETCONN_RAW and the AI generated ones are either obviously wrong or sketchy at best. I've fumbled around with NETCONN_RAW and callbacks, but even they only call back after the port filtering. It's also not lost on me that for something as fundamental as a TFTP client using LWIPs netconn interface doesn't exist anywhere on "the internet"-at least not that I can find. That seems a bit scary. TFTP server examples abound, just not clients. I am using an STM32H750 with STs libraries. Yes, STs libraries are a challenge to bring up but I feel pretty confident this is an issue with LwIP vs TFTP, not a driver issue of some kind. Hence my questions: - Do I have the problem well-understood, is the issue what I think it is? TFTP seems weird. - Would NETCONN_RAW mode address it if I could figure it out (and not mess up all my other netconn interfaces)? - Does anyone know of a decent example use of this mode? All the Google searching I have done (including this forum) comes up not applicable. Some concluding notes: - This is for an open-source project if that is any motivator. A ham radio VOIP-like project, so the answer will be published. https://github.com/beals5/Voter2-2K has the current state with the workaround. Code is in src/Tftp.c - One suggestion I found was to *not* call netconn_bind(). Alas binding binds the source IP as well as port. I still need to bind the source IP. When I tried it anyway it broke all my other IP traffic, so guessing it grabbed all traffic from all other IP addresses, not just my TFTP server. Thanks in advance! will _______________________________________________ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
