Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

net: regression on native IP stack when an offload driver is present #61173

Closed
RomainPelletant opened this issue Aug 4, 2023 · 3 comments · Fixed by #61215
Closed

net: regression on native IP stack when an offload driver is present #61173

RomainPelletant opened this issue Aug 4, 2023 · 3 comments · Fixed by #61215
Assignees
Labels
area: Networking bug The issue is a bug, or the PR is fixing a bug

Comments

@RomainPelletant
Copy link
Contributor

Describe the bug
In case we include ethernet driver (enc424j600) and wifi offload driver (esp-at), the ethernet interface is no more usable and go into hard fault.
We are only using one interface at a time (exchangeable).
But, surprisingly, Wi-Fi interface is working well when selected.

Please also mention any information which could help others to understand
the problem you're facing:

  • The target network interface is always set as default interface

To Reproduce
Steps to reproduce the behavior:

  1. include enc424j600 or another native driver
  2. include an offloaded driver or esp-at
  3. Make something on network (UDP or TCP)
  4. See error

Expected behavior
Connect succesfull

** Workaround **
Revert PR #58232

Impact
showstopper

Additional context
Duplicate of issue #58435

@RomainPelletant RomainPelletant added the bug The issue is a bug, or the PR is fixing a bug label Aug 4, 2023
@rlubos
Copy link
Contributor

rlubos commented Aug 7, 2023

How do you switch between native/offloaded interfaces? I'm asking, because NET_OFFLOAD offloading is known of not being well prepared to work with multiple interfaces in the system (https://github.com/zephyrproject-rtos/zephyr/blob/main/subsys/net/ip/net_context.c#L258, https://github.com/zephyrproject-rtos/zephyr/blob/main/subsys/net/ip/net_context.c#L330) - it will always assume the default interface should be used. Are you switching the default interface before allocating socket/net_context?

Anyway, I can see one possible issue with native interfaces when NET_OFFLOAD is enabled - after the change which installs the recv handler before connect, this line might be an issue: https://github.com/zephyrproject-rtos/zephyr/blob/main/subsys/net/ip/net_context.c#L2114. In case of native interface, the iface pointer on the context may still not be set, which would lead to an assert/crash net_if_is_ip_offloaded().

Given that we now assign the interface to the context during context creation for offloaded cases (see #59851) I think we could update net_if_is_ip_offloaded() to handle NULL pointer more gracefully (as it would indicate we deal with native interface). Could you check if changing the function as follows helps in your case:

 static inline bool net_if_is_ip_offloaded(struct net_if *iface)
 {
 #if defined(CONFIG_NET_OFFLOAD)
-       NET_ASSERT(iface);
-       NET_ASSERT(iface->if_dev);
-
-       return (iface->if_dev->offload != NULL);
+       return (iface != NULL && iface->if_dev != NULL &&
+               iface->if_dev->offload != NULL);
 #else
        ARG_UNUSED(iface);

@RomainPelletant
Copy link
Contributor Author

RomainPelletant commented Aug 7, 2023

Hi @rlubos,

Thank you for your answer.
Before loading drivers, network interface is known is EEPROM and only the right driver is loaded.
It works even when two interfaces drivers are loaded, but before doing network things, I always call net_if_set_default();

Impressive : I rebased from current 3.4 and apply your patch : it works like a charm.
I looked into socket.c and issue always came around net_if_is_ip_offloaded but I didn't see the inline function in header.

I can do PR or can leave you do so as you want.
Thank you for your help

@rlubos
Copy link
Contributor

rlubos commented Aug 7, 2023

@RomainPelletant I've opened #61215 with the fix.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: Networking bug The issue is a bug, or the PR is fixing a bug
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants