2024-12-19 11:37 PM - last edited on 2024-12-20 02:50 AM by Andrew Neil
Hello everyone,
I'm using Netconn snmp over freertos on my project and I found an issue when using 2 netif interfaces. The problem is that when I receive udp messages, the response is always routed to the default netif despite having the LWIP_HOOK_IP4_ROUTE_SRC defined. Seems like in udp, the ip destination of the message received is not saved so we always answer on the default interface, that doesn't happen in tcp communication, where the message received destination ip is saved so in the LWIP_HOOK_IP4_ROUTE_SRC we can check that ip and select the correct the netif interface.
Does anybody know if there is any option that can be activated using a DEFINE or defining a function for that scope?
Solved! Go to Solution.
2025-01-07 05:48 AM
Hello @RPC
You can periodically check if one or either of the links is up and change the states using if-else in the
void ethernet_link_status_updated(struct netif *netif) for example.But since it is working and helping your needs it can stay as you stated.
Regards
2024-12-25 08:27 AM
Hello @RPC ,
There are no defines that can be activated to solve such an issue as far as I recall, but my recommendation for you is to insure proper implementation of the callback functions and memory allocation for handling of multiple networking interfaces and also to make sure that you are working with the latest version of CubeFirmware which is known to solve a lot of issues related to the ethernet driver and containing the updated version of LWIP middleware it is also good to look for some reference implementation similar to your usecase to gain some time as well a good place to Seach for information about lwIP middleware is lwIP - A Lightweight TCP/IP stack - Summary [Savannah]
Regards
2024-12-30 06:35 AM
Hello @RPC ,
any updates on this issue?
Regards
2025-01-03 02:53 AM - edited 2025-01-03 02:56 AM
Hello @STea ,
First of all I wanted to thank you for the response.
I checked the lwip files and seems like the only file that I had tu update was the auth.c from middlewares/ppp and I updated it.
Seems like udp works properly if both interfaces are up. However, when the first interface is not up because the ethernet is unplugged, and I try to perform an udp request on the ppp interface, the ip stack gets stucked somewhere because any other service that was working before on the ppp interface isn't working anymore.
Afterwards, even if I plug the ethernet I cannot perform any connection to neither of the 2 interfaces.
I'll be looking more into it to provide more details.
2025-01-07 03:28 AM - edited 2025-01-07 04:49 AM
Hi again,
After some debugging, I changed 1 thing that made udp working even when I only have the second interface pppos working.
On the LWIP_HOOK_IP4_ROUTE_SRC function, in addition to check if the ip matches one of the interfaces. In case of not being the pppos ip, because a lot of times the argument passed to this function is NULL, I check if the default interface is up, if its not up I return the ppp_netif instead of the netif_default which is the ethernet one.
I feel like this is not the best approach possible but it works.
2025-01-07 05:48 AM
Hello @RPC
You can periodically check if one or either of the links is up and change the states using if-else in the
void ethernet_link_status_updated(struct netif *netif) for example.But since it is working and helping your needs it can stay as you stated.
Regards