Wi-Fi: Shell Firmware example with nrf7002

[BarnesToby]

Hi There

I have implemented the nrf firmware example "Wi-Fi Shell" on the nrf7002 development kit.
But I noticed a strange behaviour, after a while I cannot ping any server and it disconnects and reconnects from the access point.

It always gives the error reason=4 for the disconnection:
CTRL-EVENT-DISCONNECTED bssid=a4:6c:f1:fd:82:82 reason=4

Now as I understand it, reason 4 means "disconnected due to inactivity".

Is this conclusion correct is there any documentation about the error and how can I fix this problem so that it does not happen again?

Thanks for your Answer

[BarnesToby]

1) I am using nRF Connect SDK v2.4.1 version.
2) I have the same problem with different types of access points (mobile hotspot, router, etc).
3) It does not matter which address I want to ping, it always happens after about a minute of doing nothing on the console.

Regards
Toby

[runsiv]

Thanks for the quick reply. 

I would highly recommend to update to NCS 2.5.x (2.5.2 is the newest ) if possible to do the improvements for the 7002 done on the driver side. 

I will see if I can replicate the behavior on my side as I have not seen this error  with that sample before. 

Regards

Runar

[BarnesToby]

Thank you for your reply. .
I have updated to nRF Connect SDK v2.5.2, which has successfully resolved the issue.  
It would still be interesting what the error meant. Do you have any insight into the meaning of the error?

Regards

Toby

[BarnesToby]

I would like to revise my statement, it just happened again with the new updated sdk, although much later.

[runsiv]

There was a issue where Zephr did not allow for zero payload packages for non IPv4/6 frameshttps://github.com/zephyrproject-rtos/zephyr/pull/54277 So if you don't send any "normal" packages the NWm will try to send keep alive to the access point, and since this was not allowed at the time it would disconnect the device. But then i would expect some error earlier in the log

There were also an issue at some point where memory allocation could lead to the same disconnect event. So it could be something related to either of them. 

Edit: with the new update my reply is no longer valid. 

Would it be possible to get a log from wireshark? If not could you build your application with optimized for debug and run it again and post the log?

Regards

Runar

[BarnesToby]

Is there a quick way to connect Wireshark to the nrf board?
Otherwise I will write again next week as I will have a wifi sniffer for it.

[runsiv]

you could try the following:

The very first thing to check is if your computer supports monitor mode.

Windows:

This is done by going to cmd prompt and entering "netsh wlan show wirelesscapabilities"

If this prints "Network monitor mode                        : Not supported" then it will not work.

AX201 is confirmed not working in windows, but will work in linux.

1. 1. Install wireshark: https://www.wireshark.org/
   2. Install npcap: https://npcap.com/
   3. Follow the guide from npcap to enable monitor mode (again; requires support in your chipset!): https://npcap.com/guide/npcap-devguide.html#npcap-feature-dot11

This is a bit hit or miss depending if your computer 

linux:

In Ubuntu, NetworkManager claims all network interfaces by default. This is problematic, as we want to change the wifi mode from "managed" to "monitor".

As a workaround, you can manually set the $DEVICE as unmanaged for your current session:

sudo nmcli device set $DEVICE managed no

More detailed guide for always marking a device as unmanaged can be found here:

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/configuring_and_managing_networking/configuring-networkmanager-to-ignore-certain-devices_configuring-and-managing-networking

$DEVICE here can be for instance "wlp2s0".

You can see this by issuing "iw dev" or "iwconfig".

1. Open a terminal and install wireshark: 

   sudo apt get install wireshark-qt -y

2. make sure your user has proper permissions to sniff using wireshark by adding your user to the wireshark group (reboot required afterwards): 

   sudo usermod -a -G wireshark $USER

3. Take your wireless device down: 

   sudo ip link set dev $DEVICE down

4. set your chipset into monitor mode: 

   sudo iw dev $DEVICE set type monitor

5. Start up the wifi chipset again: 

   sudo ip link set dev $DEVICE up

6. Start Wireshark (you might need to start with sudo) and select your wlan device.

Here is a properly configured device, wlp2s0, set to monitor:

In Wireshark, to select the channel and bandwidth, you need to check "View → Wireless toolbar":

in short, I will not say it is a quick way and if it will work depends on your HW and operating system. So i would suggest to try the wifi shell with optimize for debug to see if there is some more information to be had

Regards

Runar

[BarnesToby]

So finally I have captured it

The deauthentication happens at Packet Number 47, and it reconnects at the Packet Number 314.

capture_reason4_detail.pcapng

Best Regards
Toby

[runsiv]

Thank you

From the looks of it you get client expired. So the Ap does not hear anything from the device and disassociate it. It could also be the other way around, I'm not to sure. 

It looks like the the device is connecting to a Samsung hotspot? Could you describe your AP and try to test with another one? 

Regards

Runar

[BarnesToby]

Hi Runar

Thanks for your reply.
So the Samsung hotspot is an old mobile phone that I use as a hotspot access point for wifi.
I have tried to get the same error on different types of access points, but to no avail.

So you can close this case, I think the SDK update fixed most of the problems here.

Regards, Toby