RE: Zigbee and net socket collision with Zephyr v2.6.0-rc1-ncs1

Marte Myrvold — Thu, 09 Sep 2021 13:38:44 GMT

Hi Milan,

I am happy to hear that!

Best regards,

Marte

RE: Zigbee and net socket collision with Zephyr v2.6.0-rc1-ncs1

mnvcsUDT — Thu, 09 Sep 2021 11:25:11 GMT

Hi Marte,

Thank you for this, I verified the fix was not issued branch we used but now using the master branch fixed it.

Regards,

Milan

RE: Zigbee and net socket collision with Zephyr v2.6.0-rc1-ncs1

Marte Myrvold — Wed, 08 Sep 2021 13:33:01 GMT

Hi,

Thank you for clarifying.

I asked our developers about this. A similar issue to this has been addressed by the following fix: https://github.com/rlubos/zephyr/commit/46efe3ed70c98d08701cd3e660875e409aaf7e03. This should already be available on the master branch of NCS. Can you try to either switch to the master branch or add these changes to your project and see if it fixes the issue? Please let me know if it does not.

Best regards,

Marte

RE: Zigbee and net socket collision with Zephyr v2.6.0-rc1-ncs1

mnvcsUDT — Tue, 07 Sep 2021 14:11:06 GMT

Hi Marte, Got further in narrowing down the issue,

CONFIG_NET_SOCKETS_PACKET is the problem here. This config option seems to be necessary with Memfault integration.

RE: Zigbee and net socket collision with Zephyr v2.6.0-rc1-ncs1

mnvcsUDT — Mon, 06 Sep 2021 15:11:45 GMT

Hi Marte, and thank you for your response.

I might formulated myself incorrectly.

[00:00:19.019,775] <err> ieee802154_nrf5: Packet dropped by NET stack

is triggered only when the network interface is disabled. Otherwise it is not possible to pair a Zigbee device. This only happens when CONFIG_NET_SOCKETS=y .I can see 802.15.4 frames being captured but nothing seems to be available for ZBOSS.

[00:00:00.013,763] <inf> zigbee: Start ZBOSS stack and init zigbee
[00:00:00.020,050] <inf> zigbee_app_utils: Production configuration is not present or invalid (status: -1)
[00:00:00.020,721] <inf> zigbee_app_utils: Zigbee stack initialized
[00:00:00.021,728] <dbg> ieee802154_nrf5.nrf5_filter: Applying filter 2
[00:00:00.021,759] <dbg> ieee802154_nrf5.nrf5_set_pan_id: 0xffff
[00:00:00.022,521] <dbg> ieee802154_nrf5.nrf5_filter: Applying filter 2
[00:00:00.022,521] <dbg> ieee802154_nrf5.nrf5_set_pan_id: 0x7d9d
[00:00:00.022,766] <dbg> ieee802154_nrf5.nrf5_filter: Applying filter 1
[00:00:00.022,766] <dbg> ieee802154_nrf5.nrf5_set_short_addr: 0x0
[00:00:00.023,010] <dbg> ieee802154_nrf5.nrf5_filter: Applying filter 0
[00:00:00.023,010] <dbg> ieee802154_nrf5.nrf5_set_ieee_addr: IEEE address f4:ce:36:c2:bd:56:5b:1a
[00:00:00.024,749] <dbg> ieee802154_nrf5.nrf5_filter: Applying filter 1
[00:00:00.024,749] <dbg> ieee802154_nrf5.nrf5_set_short_addr: 0x0
[00:00:00.024,993] <dbg> ieee802154_nrf5.nrf5_set_txpower: 20
[00:00:00.024,993] <dbg> ieee802154_nrf5.nrf5_set_channel: 12
[00:00:00.025,177] <dbg> ieee802154_nrf5.nrf5_start: nRF5 802154 radio started (channel: 12)
[00:00:00.025,177] <dbg> ieee802154_nrf5.nrf5_filter: Applying filter 0
[00:00:00.025,177] <dbg> ieee802154_nrf5.nrf5_set_ieee_addr: IEEE address f4:ce:36:c2:bd:56:5b:1a
[00:00:00.025,207] <dbg> ieee802154_nrf5.nrf5_filter: Applying filter 1
[00:00:00.025,207] <dbg> ieee802154_nrf5.nrf5_set_short_addr: 0x0
[00:00:00.025,207] <dbg> ieee802154_nrf5.nrf5_filter: Applying filter 2
[00:00:00.025,207] <dbg> ieee802154_nrf5.nrf5_set_pan_id: 0x7d9d
[00:00:00.025,726] <dbg> ieee802154_nrf5.nrf5_start: nRF5 802154 radio started (channel: 12)
[00:00:00.026,000] <dbg> ieee802154_nrf5.nrf5_start: nRF5 802154 radio started (channel: 12)
[00:00:00.057,556] <inf> zigbee: Start network steering
[00:00:00.094,299] <dbg> ieee802154_nrf5.nrf5_tx: 0x20009405 (54)
[00:00:00.094,390] <dbg> ieee802154_nrf5.nrf5_tx: Sending frame (ch:12, txpower:8)
[00:00:00.098,327] <dbg> ieee802154_nrf5.nrf5_tx: Result: 0
[00:00:00.531,402] <dbg> ieee802154_nrf5.nrf5_tx: 0x20009405 (54)
[00:00:00.531,524] <dbg> ieee802154_nrf5.nrf5_tx: Sending frame (ch:12, txpower:8)
[00:00:00.533,782] <dbg> ieee802154_nrf5.nrf5_tx: Result: 0
[00:00:00.537,567] <inf> zigbee: Allow pre 3.0 devices to join the network
[00:00:00.537,567] <wrn> zigbee: Network steering started, channel: 12
[00:00:15.309,387] <dbg> ieee802154_nrf5.nrf5_tx: 0x20009405 (45)
[00:00:15.309,448] <dbg> ieee802154_nrf5.nrf5_tx: Sending frame (ch:12, txpower:8)
[00:00:15.313,720] <dbg> ieee802154_nrf5.nrf5_tx: Result: 0
[00:00:30.564,331] <dbg> ieee802154_nrf5.nrf5_tx: 0x20009405 (45)
[00:00:30.564,392] <dbg> ieee802154_nrf5.nrf5_tx: Sending frame (ch:12, txpower:8)
[00:00:30.567,047] <dbg> ieee802154_nrf5.nrf5_tx: Result: 0
[00:00:45.788,543] <dbg> ieee802154_nrf5.nrf5_tx: 0x20009405 (45)
[00:00:45.788,604] <dbg> ieee802154_nrf5.nrf5_tx: Sending frame (ch:12, txpower:8)
[00:00:45.790,954] <dbg> ieee802154_nrf5.nrf5_tx: Result: 0
[00:01:01.028,137] <dbg> ieee802154_nrf5.nrf5_tx: 0x20009405 (45)
[00:01:01.028,198] <dbg> ieee802154_nrf5.nrf5_tx: Sending frame (ch:12, txpower:8)
[00:01:01.031,463] <dbg> ieee802154_nrf5.nrf5_tx: Result: 0
[00:01:15.890,930] <dbg> ieee802154_nrf5.nrf5_rx_thread: Frame received
[00:01:15.890,960] <dbg> ieee802154_nrf5.nrf5_rx_thread: Caught a packet (10) (LQI: 32)
[00:01:15.891,113] <dbg> ieee802154_nrf5.nrf5_rx_thread: Waiting for frame
[00:01:16.267,761] <dbg> ieee802154_nrf5.nrf5_tx: 0x20009405 (45)
[00:01:16.267,791] <dbg> ieee802154_nrf5.nrf5_tx: Sending frame (ch:12, txpower:8)
[00:01:16.270,782] <dbg> ieee802154_nrf5.nrf5_tx: Result: 0
[00:01:16.405,212] <dbg> ieee802154_nrf5.nrf5_rx_thread: Frame received
[00:01:16.405,273] <dbg> ieee802154_nrf5.nrf5_rx_thread: Caught a packet (10) (LQI: 188)
[00:01:16.405,395] <dbg> ieee802154_nrf5.nrf5_rx_thread: Waiting for frame
[00:01:26.204,681] <dbg> ieee802154_nrf5.nrf5_rx_thread: Frame received
[00:01:26.204,742] <dbg> ieee802154_nrf5.nrf5_rx_thread: Caught a packet (10) (LQI: 168)
[00:01:26.204,864] <dbg> ieee802154_nrf5.nrf5_rx_thread: Waiting for frame
[00:01:31.553,405] <dbg> ieee802154_nrf5.nrf5_tx: 0x20009405 (45)
[00:01:31.553,466] <dbg> ieee802154_nrf5.nrf5_tx: Sending frame (ch:12, txpower:8)
[00:01:31.557,403] <dbg> ieee802154_nrf5.nrf5_tx: Result: 0
[00:01:40.127,166] <dbg> ieee802154_nrf5.nrf5_rx_thread: Frame received
[00:01:40.127,227] <dbg> ieee802154_nrf5.nrf5_rx_thread: Caught a packet (10) (LQI: 180)
[00:01:40.127,349] <dbg> ieee802154_nrf5.nrf5_rx_thread: Waiting for frame
[00:01:46.839,080] <dbg> ieee802154_nrf5.nrf5_tx: 0x20009405 (45)
[00:01:46.839,141] <dbg> ieee802154_nrf5.nrf5_tx: Sending frame (ch:12, txpower:8)
[00:01:46.842,773] <dbg> ieee802154_nrf5.nrf5_tx: Result: 0
[00:02:02.094,055] <dbg> ieee802154_nrf5.nrf5_tx: 0x20009405 (45)
[00:02:02.094,207] <dbg> ieee802154_nrf5.nrf5_tx: Sending frame (ch:12, txpower:8)
[00:02:02.096,160] <dbg> ieee802154_nrf5.nrf5_tx: Result: 0
[00:02:17.318,206] <dbg> ieee802154_nrf5.nrf5_tx: 0x20009405 (45)
[00:02:17.318,267] <dbg> ieee802154_nrf5.nrf5_tx: Sending frame (ch:12, txpower:8)
[00:02:17.322,540] <dbg> ieee802154_nrf5.nrf5_tx: Result: 0
rtt:~$ net iface



Interface 0x20001c9c (<unknown type>) [1]
=========================================
Link addr : F4:CE:36:C2:BD:56:5B:1A
MTU       : 127
Flags     : AUTO_START,IPv4
IPv4 unicast addresses (max 1):
	<none>
IPv4 multicast addresses (max 1):
	<none>

As you can see there is only one interface enabled (that is the zigbee one) but it is the same error when we add more. Looks like Zigbee network starts up correctly, even there are incoming frames that indicates the device tries to join the network.

Thank you.

RE: Zigbee and net socket collision with Zephyr v2.6.0-rc1-ncs1

Marte Myrvold — Fri, 03 Sep 2021 09:29:42 GMT

Hi Milan,

I have not heard of this before, but I do not see why Zephyr's network stack is processing the incoming Zigbee packets instead of the ZBOSS stack.

In your log it states that the packet was dropped by the NET stack. Are you certain that this is related to Zephyr's network stack? As is stated in the log, that error is from the function nrf5_rx_thread() in the nRF5 802.15.4 driver (zephyr/drivers/ieee802154/ieee802154_nrf5.c), so the packet is received and handled by the nRF5 802.15.4 driver, and not Zephyr's network stack. Something is causing net_recv_data() to return an error, so something is going wrong when pushing the packet up in the network for further processing, but in addition to the packet itself, this function also takes in the network interface where the packet was received. In this case, this network interface is set to be the interface of a nrf5_802154 device.

Do you know what is failing in net_recv_data()? This function returns different error codes depending on what the error is, so knowing which error code is being returned could help with finding out what fails. You can find this function in zephyr/subsys/net/ip/net_core.c.

Is this the case for all Zigbee packets, or does it only happen with certain packets? What packets are you sending that is not processed by the ZBOSS stack?

Are you able to share code or steps I can take to reproduce this issue on my side?

Best regards,

Marte