"Uncontiguous data cannot be linearized" error in nRF7002 Wi-Fi Connection

[funkySanrits]

I am encountering the error message "<err> net_pkt: Uncontiguous data cannot be linearized" when already connected with nRF7002-DK to a Wi-Fi network using the EAP-TLS authentication method over FreeRADIUS server. The error appears periodically after the successful handshake and connection processes. The `net ping 8.8.8.8.` further confirms that the connection is OK. However under the same conditions and configuration, this error message DOES NOT appear on the Zephyr master branch, commit [2879607](github.com/.../28796076d84056d085e5a4ebf213dafbfe56202a)

Setup Details
- Hardware: nRF7002-DK
- Firmware: NCS v2.8.0
- Development OS: Ubuntu 22.04 LTS
- Wi-Fi Setup: EAP-TLS authentication over FreeRADIUS
- Sample Used: `/samples/net/wifi`

Test case steps

1. Set up the Wi-Fi AP with WPA2-Enterprise and FreeRADIUS for EAP-TLS authentication.
2. Generated valid CA, certificates, and keys on the FreeRADIUS, then transferred them to the sample's /test_certs folder. Two sets of certificates were created since the sample requires them for both authentication phases. In this case, I've created the same certificates for both phases to simplify things. Therefore:

ca.pem = ca2.pem
client-key.pem = client-key2.pem
client.pem = client2.pem

3. Edited overlay-enterprise.conf :

CONFIG_NET_PKT_TX_COUNT=36
CONFIG_NET_PKT_RX_COUNT=36
CONFIG_NET_BUF_TX_COUNT=72
CONFIG_NET_BUF_RX_COUNT=36

CONFIG_MBEDTLS_ENABLE_HEAP=y
CONFIG_MBEDTLS_HEAP_SIZE=70000

CONFIG_WIFI_NM_WPA_SUPPLICANT_LOG_LEVEL_DBG=y
CONFIG_LOG_BUFFER_SIZE=16384

CONFIG_WIFI_NM_WPA_SUPPLICANT_CRYPTO_ENTERPRISE=y
CONFIG_WIFI_NM_WPA_SUPPLICANT_EAPOL=y
CONFIG_EAP_TLS=y


4. Built and flashed the `samples/net/wifi` sample from the NCS 2.8.0, configured with valid client certificates and keys.

west build -b nrf7002dk/nrf5340/cpuapp -- -DEXTRA_CONF_FILE=overlay-enterprise.conf
west flash

5. Entered `wifi connect` command (use your arguments):

wifi connect -s "MikroTikChateau-WLAN-2" -k 7 -a "user-tls" -K "sanri"


Logs
I have attached logs captured during the connection attempt with Minicom, showing the full error trace and related context. The logs are available in the attached ncs_2_8_0_wifi_shell_tls.txt file:
ncs_2_8_0_wifi_shell_tls.txt

[Håkon Alseth]

Hi funkySanrits,

 

My deepest apologies for the late response.

Q1: Are you seeing the same issue in v2.9.0?

Q2: Could this issue be due to multicast/broadcast data in the test-network? Do you see the same on other APs as well?

 

Kind regards,

Håkon

[Saxman58]

Hi Håkon,

I have also been seeing this with the nRF7002DK board lately.  My experience may provide some more clues about what is going on:

• Our app is build with NCS v2.6.2, development is on the MacOS
• App was built on the Wi-Fi BLE coex sample (the BT code and network processor is currently not part of the project)
• SSID and password is currently hardwired
• No special server, just attaching to the local home network with WPA2.  So no certificates, etc.
• Like funkySanrits, the errors appear sometime after a successful connection, sometimes minutes, but usually hours later.  Our app is idling at the time, waiting for a request on the TFTP server we've implemented, but no app initiated or solicited network messages

Our app never saw this error in a couple of months of operating on my home network.  It started appearing as soon as I moved my development to Florida for the winter, and thus a different home network.  On the other network I never saw the "Uncontiguous data" error, but I often saw a "net_icmpv6" error instead and haven't seen that error in Florida.

In this DevZone thread I see that some people see both errors at the same time: devzone.nordicsemi.com/.../516272

Nothing has changed with the Wi-Fi code in our app since the move.  I've been working on sensor interfaces and hardware designs, completely unrelated to the network code.  So I am convinced that the errors are being triggered by some unsolicited packets from the network, or unsupported or improperly handled background handshaking.

I let the app run idling overnight and almost always see a few of these errors in the morning.  Here are some from when I took a several hour break from development.  The relative timing of the errors might be of interest:

[Håkon Alseth]

Hi,

 

This error is printed when there's a buffering issue, ie. where the net_buf isn't able to fully fit the incoming packet. If we look at the sources:

https://github.com/nrfconnect/sdk-zephyr/blob/main/subsys/net/ip/net_pkt.c#L2174-L2175

Its a generic printout and effectively does not tell us where it originated from, but there has been issues, especially with regards to ipv6:

https://github.com/zephyrproject-rtos/zephyr/issues/66639

 

Which was addressed with this commit (included in NCS v2.7 and newer):

https://github.com/zephyrproject-rtos/zephyr/pull/66532

 

As you mention v2.6.2, it could be this issue that you're seeing.

 

Kind regards,

Håkon

[Saxman58]

Thanks Håkon,

These seem to be benign error messages.  Is that true?  I was told that it is best to stick with the same NCS version through a development project.  In your opinion, which would be best?

- Ignore the "Uncontiguous" and IPv6 error messages
- Upgrade to a newer NCS
- Patch v2.6.2 code to match the fixes in v2.7

[Håkon Alseth]

Hi,

 

To be able to determine how to fix the issue, it is crucial to know where the error comes from.

In your case, I can only guess where the error message came from, but to be certain, you should test and set a breakpoint on the line that prints this to see if the callstack is then similar to what is shown in the below linked issue.

If you still see issues, I would recommend creating a dedicated thread on the matter, as it is highly likely that the issue is not the same as the original issue here, due to the generic nature of the printed error.

 

Kind regards,

Håkon