search

zephyrproject-rtos / zephyr

Primary Git Repository for the Zephyr Project. Zephyr is a new generation, scalable, optimized, secure RTOS for multiple hardware architectures.
https://docs.zephyrproject.org
Apache License 2.0
10.71k stars 6.54k forks source link

net: l2: ieee802154: bringing up the interface should be possible w/o bringing up the receiver #76178

Closed gumulka closed 1 week ago

gumulka commented 2 months ago

Describe the bug

When issuing an active scan of 802.15.4 on the shell, all response packages are dropped by the network stack.

To Reproduce

Have something, that answers to 802.15.4 active network scans, like a zigbee coordinator (here, you could use the out of scope nRF sample nrf/samples/zigbee/network_coordinator)

Compile Zephyr with:

CONFIG_SHELL=y
CONFIG_NETWORKING=y
CONFIG_NET_SHELL=y
CONFIG_NET_L2_IEEE802154=y
CONFIG_NET_L2_IEEE802154_SHELL=y
CONFIG_NET_L2_IEEE802154_RFD=y

Do an active scan on the commandline (see snippet below)

Expected behavior

The scan response packages are received and given to the network stack for further processing

Impact

Showstopper. I have to force the network interface up before I can scan.

Logs and console output

The log from my shell:

uart:~$ net iface show 

Interface ieee0 (0x20000b30) (IEEE 802.15.4) [1]
========================================
Interface is down.
uart:~$ net iface up 1
Cannot take interface 1 up (-115)
uart:~$ ieee802154 scan active all 100
Active Scanning (channel set: 0xffffffff, duration 100 ms)...
Done
[00:02:23.907,348] <wrn> net_ieee802154_mgmt: Could not remove PAN ID filter
[00:02:25.347,076] <err> ieee802154_nrf5: Packet dropped by NET stack
[00:02:25.348,358] <err> ieee802154_nrf5: Packet dropped by NET stack
[00:02:25.360,168] <err> ieee802154_nrf5: Packet dropped by NET stack
[00:02:25.546,966] <wrn> net_ieee802154_mgmt: Could not remove PAN ID filter
uart:~$

The "Packet dropped by NET stack" messages are produced, because the network interface is not up. I don't want to set the interface up, because I'm currently scanning for the network.

Environment (please complete the following information):

Additional context

The error starts here: https://github.com/zephyrproject-rtos/zephyr/blob/f2b6490dee30b38dfb0ee31902177491c35ebacb/drivers/ieee802154/ieee802154_nrf5.c#L215-L218

Because: https://github.com/zephyrproject-rtos/zephyr/blob/f2b6490dee30b38dfb0ee31902177491c35ebacb/subsys/net/ip/net_core.c#L499-L501

aescolar commented 2 months ago

CC @rlubos @jukkar

fgrandel commented 2 months ago

@gumulka By the current standard (section 6.3.1), only beacons should be received during active or passive scan. Are you saying that currently no beacons can be received?

If we're not talking about beacons then please help me with some additional context re your expectation. What kinds of packets does the Zigbee co-ordinator send back (frame type, payload, purpose)?

fgrandel commented 2 months ago

@gumulka I further debugged the issue and I cannot yet reproduce it. We have a unit test on this. The interface should be brought up during initialization which in turn would set the NET_IF_UP flag and any beacons received should then be allowed in.

But I can see that you cannot bring the interface up manually in your case. I'll dig deeper because that seems to be the actual cause.

fgrandel commented 2 months ago

@gumulka Can you please try to scan from the echo sample instead, e.g.

west build samples/net/sockets/echo_server --pristine --board nrf52840dk/nrf52840 -DEXTRA_CONF_FILE=overlay-802154.conf

The shell is exposed through UART in that sample. In my case this provides me with a properly set up interface that is automatically "UP". Can you properly scan with this sample?

UPDATE: I digged into the zigbee sample that you reference - this requires a different L2 (ZIGBEE_L2) so it shouldn't be expected to work with CONFIG_NET_L2_IEEE802154=y. If you can confirm that you can properly scan with the echo sample I propose that we close this bug as "invalid".

gumulka commented 2 months ago

Are you saying that currently no beacons can be received?

yes, as seen in the logs.

@gumulka I further debugged the issue and I cannot yet reproduce it. We have a unit test on this. The interface should be brought up during initialization which in turn would set the NET_IF_UP flag and any beacons received should then be allowed in.

But I can see that you cannot bring the interface up manually in your case. I'll dig deeper because that seems to be the actual cause.

I have just seen, that I forgot the CONFIG_LOG=y parameter

How to reproduce on my side:

mkdir zephyr_76178 
cd zephyr_76178
west init -m https://github.com/zephyrproject-rtos/zephyr --mr main
west update
cd zephyr
cat 76178.patch | git am
cd ..
west build -p -b nrf52840dk_nrf52840 zephyr/samples/basic/blinky
west flash

Using the nrf52840dk, obviously.

for the patch, use this git diff 76178.txt

results in:

[00:00:00.448,913] <inf> ieee802154_nrf5: nRF5 802154 radio initialized
*** Booting Zephyr OS build v3.7.0-rc3-102-g099209b7d563 ***
uart:~$ ieee802154 scan active all 500
Active Scanning (channel set: 0xffffffff, duration 500 ms)...
Done
[00:00:08.975,860] <err> ieee802154_nrf5: Packet dropped by NET stack
[00:00:13.372,528] <err> ieee802154_nrf5: Packet dropped by NET stack
[00:00:13.373,809] <err> ieee802154_nrf5: Packet dropped by NET stack
[00:00:13.377,990] <err> ieee802154_nrf5: Packet dropped by NET stack
uart:~$
gumulka commented 2 months ago

@gumulka Can you please try to scan from the echo sample instead, e.g.

west build samples/net/sockets/echo_server --pristine --board nrf52840dk/nrf52840 -DEXTRA_CONF_FILE=overlay-802154.conf

The shell is exposed through UART in that sample. In my case this provides me with a properly set up interface that is automatically "UP". Can you properly scan with this sample?

Yes, I can do with this example. But here the example does the heavy lifting of putting up the network. I don't need a network that is up to scan for beacons.

fgrandel commented 2 months ago

I don't need a network that is up to scan for beacons.

net_if_up() brings up the link layer (MAC) - not a full network. Scanning is a link layer activity, so I'd say you need L2 up to scan. You don't need anything above L2 of course (IP, UDP, etc.).

When enabling the interface we currently switch on the receiver so you have to configure at least a channel before you can call net_if_up() (which should be optional - see below). Conceptually enabling the interface could be anything, though, therefore a disabled interface should not allow you to scan. So what you're seeing is expected behavior IMHO.

I do see, though, where the confusion might come from:

Both issues are unrelated to your issue, though, and should be easy to work around by setting a channel before trying to bring up the interface. @gumulka Can you confirm, please?

fgrandel commented 2 months ago

See https://github.com/zephyrproject-rtos/zephyr/pull/76265 (RFC that discusses how macRxOnWhenIdle can be reached from application level). This would make it possible to bring up the interface without also bringing up the receiver, i.e. an initial channel would no longer have to be configured to bring the interface up and scan for networks.

github-actions[bot] commented 3 weeks ago

This issue has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time.