Wi-Fi example fails if Ethernet is present in device tree

[ShahinHaque97-CT]

Using the Wi-Fi example on NPX RT1040 through UART to an ESP32-C3 running ESP-AT, This example works fine, provided that the device tree does not contain Ethernet (&enet).

Wifi Scan Fails.
Wifi Status results in:
`
uart:~$ wifi status
[00:00:12.234,000] os: ***** USAGE FAULT *****
[00:00:12.234,000] os:   Illegal use of the EPSR
[00:00:12.234,000] os: r0/a1:  0x6001c8a0  r1/a2:  0x80003b50  r2/a3:  0x80003b50
[00:00:12.234,000] os: r3/a4:  0x60022334 r12/ip:  0x600212d3 r14/lr:  0x6000b9cf
[00:00:12.234,000] os:  xpsr:  0x60000000
[00:00:12.234,000] os: Faulting instruction address (r15/pc): 0x60022334
[00:00:12.234,000] os: >>> ZEPHYR FATAL ERROR 35: Unknown error on CPU 0
[00:00:12.234,000] os: Current thread: 0x800012c0 (shell_uart)
[00:00:12.289,000] os: Halting system

 `
I believe the issue could be that it is trying to use wifi commands with an ethernet iface.

[ShahinHaque97-CT]

Solution, If both are present on the board, change ethernet priority to be after Wi-Fi. If net default is set to ethernet, change it to the Wi-Fi module as follows
net_if_set_default(net_if_lookup_by_dev(DEVICE_DT_GET(DT_NODELABEL(esp32c3))));

[rlubos]

This is a known limitation of the Wi-Fi shell, which uses net_if_get_default() to obtain interface to work with (https://github.com/zephyrproject-rtos/zephyr/blob/main/subsys/net/l2/wifi/wifi_shell.c#L1018). The proposed workaround is what we also use for now.

[ShahinHaque97-CT]

@rlubos @carlescufi
Update,

"wifi scan" works fine, however "wifi connect ssid password" causes the device to restart.

I put a switch on the power to the ethernet so that I am able to kill power to it and "wifi connect" works with ethernet power killed during that command

My question is, even though net_if_get_default is set to the ESP32C3, Ethernet functions must still be being used in the Wifi functions, I am just unsure where.

Can this thread be re-opened to discuss this or shall I make a new one?

[rlubos]

@krish2718 Did you experience any problems with wifi connect when running in multi-interface environment?

@ShahinHaque97-Corintech It's really hard to find the answer out of thin air, especially that you run a custom hardware configuration. Would be good if you could debug the issue a bit and provide more specific information.

I'll convert the issue into a discussion for now.

[krish2718]

@krish2718 Did you experience any problems with wifi connect when running in multi-interface environment?

We had to do the same workaround as above to make Wi-Fi as the default interface, but if scan is working I don't see why connect should fail. I have never seen this issue. And I guess this Ethernet is a netusb based Ethernet? Best starting point would be to get a callstack using a debugger (gdb/ozone/vscode).

[ShahinHaque97-CT]

@krish2718

The Ethernet is built into the MIMRT1040 through an IC KSZ8081RNA to the Ethernet Cable.

Here is the link to the development board - https://www.nxp.com/design/development-boards/i-mx-evaluation-and-development-boards/i-mx-rt1040-evaluation-kit:MIMXRT1040-EVK

The ethernet driver used is https://github.com/zephyrproject-rtos/zephyr/blob/main/drivers/ethernet/eth_mcux.c

[ShahinHaque97-CT]

Although Ethernet is not being used in the Wi-Fi example "eth_mcux.c" is still active as the device tree contains "&enet" and board Kconfig contains "ETH_MCUX_PHY_RESET" When the Wifi is used, the PHY is set to reset allowing the ethernet to be inactive. After probing the rest connection on the board, I have found that is not is being reset a resistor issue.

I have both Wi-Fi and Ethernet working on this board (with changing set default)

This discussion can be closed.

Thanks.

[matt-wood-ct]

Hi All,
this net_if_get_default() usage for access to capability specific usage (i.e. wifi actions) seems pretty wide spread, is there any good macros to get the first iface with wifi capabilities?
I know in applications you would get the iface by the device tree but in a library you need to keep the code more agnostic, is there a neat trick to achieve this?

At the moment you need to force the wifi iface to be default or a swath of library code simply ceases to work.

I just ran into the wifi BLE provisioning system which also uses net_if_get_default() for all iface actions, so if you have any other network interface set as default it all falls apart.

[matt-wood-ct]

Yes you are correct, that would certainly be a better. It would make the existing API function work
net_if_get_first_by_type(&NET_L2_GET_NAME(WIFI))

[rlubos]

I'd rather avoid polluting Ethernet L2 codebase with Wi-Fi-specific tweaks. Defining Wi-Fi L2 sounds like an option, although it does sound like a massive endeavor?

Anyways, I think that Wi-Fi commands should simply accept an optional parameter for the interface index to work with, it would be unavoidable if there are multiple Wi-Fi interfaces, regardless of the workaround we provide to identify Wi-Fi interface.

[krish2718]

it would be unavoidable if there are multiple Wi-Fi interfaces, regardless of the workaround we provide to identify Wi-Fi interface.

Sure, but currently, sending packets over non-Wi-Fi links e.g., 802.15.4 can lead to crashes, so, knowing its Wi-Fi even if its not the right interface will help.

[matt-wood-ct]

How do we progress this further (I'm relatively new to Zephyr) I think it is clear this is worthwhile

[rlubos]

Defining Wi-Fi L2 sounds like an option, although it does sound like a massive endeavor.

Actually, on second thought, yet again offloaded devices would be a problem as they don't implement any specific L2. So identifying by L2 is not really a good option. Maybe we need some kind of interface type field in the net_if structure to be able to identify the device type regardless of the L2 used.

The question is what do you want to achieve here. If you want to add a better protection against calling Wi-Fi mgmt APIs on non-Wi-Fi interfaces, then I think the above suggestion would be the way to go. Extend struct net_if, list all network device types supported in Zephyr and update respective L2s/offloaded implementations to set the device type accordingly.

If it's just about adding more flexibility when selecting the target interface for the command, then an extra (optional) argument for all commands is the way to go.

[krish2718]

Actually, on second thought, yet again offloaded devices would be a problem as they don't implement any specific L2. So identifying by L2 is not really a good option.

I was thinking more of below flags, so, either native or offloaded we can always identify use L2_WIFI || L2_WIFI_OFFLOADED, the flags can be used in the registration to convey the type of device.

• L2_ETHERNET
• • L2_ETHERNET_OFFLOADED
• L2_WIFI
• L2_WIFI_OFFLOADED

[rlubos]

I just don't think (but I'm open for discussion/arguments) that Zephyr's L2 concept is a good way to identify offloaded device types. The only thing that allows to identify what L2 is net_if working with is the L2 API pointer, which means, every offloaded device type would need to provide a unique, dummy L2 API definition. Basically meaning multiple copies of https://github.com/zephyrproject-rtos/zephyr/blob/main/subsys/net/l2/offloaded_netdev/offloaded_netdev.c

[krish2718]

Can't we add flags to *_NET_DEVICE_INIT that has a L2 type (including offloaded dev)? Of course, this itself is a invasive change, but should be simpler.

[rlubos]

What do you mean by flags? Not sure I follow.

[krish2718]

What do you mean by flags? Not sure I follow.

I guess we both are aligned, I am referring to below as adding a new field in net_if structure as flags, where devices can communicate their features, similar to hw_caps in Ethernet L2.

Extend struct net_if, list all network device types supported in Zephyr and update respective L2s/offloaded implementations to set the device type accordingly.

[krish2718]

FYI, I took a stab here #58869 changed the approach a bit.