CYW43012 chipset sending Null Data in unconnected channel

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
lock attach
Attachments are accessible only for community members.
rupesh_theatro
Level 3
Level 3
25 sign-ins 10 replies posted 5 replies posted

Hi All,

We are using CYW43012 chipset and here are our details:

Firmware version:
1.21 RC0.0
wl0: Feb 21 2022 07:19:28 version 13.10.271.283 (211da63 CY) FWID 01-18f4ac2
Driver Version:
Backported Linux Version v5.10.9-2022_0321-0-ga0971bc0b123

wl clmver:
API: 18.2
Data: 9.10.0
Compiler: 1.36.1
ClmImport: 1.34.1
Creation: 2019-12-13 03:26:37

We are using roam_off=0 option so that roaming decisions are taken by host and do post connection scan i.e. background scan from driver.

We have observed that firmware is trying to send Null Data packets in unconnected state and retries sending multiple times as no AP responds (as expected) causing intermittent packet loss as we are not in home channel.

Attached a pcap where the device is connected in Channel 36 but it tries to send Null data in channel 40 as well continuously. We are not seeing this issue in CYW43455 chipset product we have with the same driver and firmware.

Any help ASAP is deeply appreciated. @raks_99  @GauravS_31  @VinayakS_26 

Regards,

Rupesh.

0 Likes
11 Replies
raks_99
Moderator
Moderator
Moderator
First question asked 250 replies posted 250 sign-ins

Hi @rupesh_theatro ,

Is this only seen when roam_off=0?

To reproduce, do I just need to connect to an AP on channel 36 and sniff on channel 40?

 

 

0 Likes

Hi @raks_99 

Sorry for the confusion. The issue is seen with roam_off=1 and we haven't tested with roam_off=0 option.

Yes, connect to channel 36 and sniff on channel 40 and you can see the issue happening whenever scan happens. The capture I shared in my post has only two channels being scanned 36 and 40 for easier debugging.

We have found that the easiest way to trigger issue is by making the device connect to an AP and keep changing the channel of the AP and ensure background scan happens multiple times before changing the channel.

Regards,

Rupesh

0 Likes
rupesh_theatro
Level 3
Level 3
25 sign-ins 10 replies posted 5 replies posted

Hi @raks_99 

Any update on this issue? Are you able to replicate the issue and Do you need any other information or help to reproduce the issue

Regards,

Rupesh.

0 Likes

@rupesh_theatro , I will be getting a 43012 chip this week to test this.

Is there any previous version of the firmware where you are not seeing this issue? Do you know if this also happens in 2G channels?

0 Likes

Hi @raks_99 

Yes the issue happens in 2G channels as well. We have observed the issue with the following firmware and driver version as well:

Firmware version:
1.21 RC0.0
wl0: Sep 1 2021 22:33:32 version 13.10.271.273 (9278a67 CY) FWID 01-e6c8687a
Driver Version:
Backported Linux Version v4.14.77-kong-RTM-rc8-0-ged6fa18

Did you get the 43012 chip and were you able to replicate the issue?

 

Regards,

Rupesh

0 Likes
lock attach
Attachments are accessible only for community members.

hi @rupesh_theatro ,

I got the setup, I'm also using FW v13.10.271.283

It is connected to an AP on channel 36.

My sniffer is on channel 40 and I see only probe requests there sent from the 43012 device.

How long do you keep it running before you see the issue? I tried to ping and run iperf3 for about 10mins. I did not see any packets other than the Probe request in Ch40...

Is there anything else that I need to set up? Any wl commands that you run after loading the driver?

0 Likes

Hi @raks_99,

You should keep changing the channel of the connected AP for every 1min and keep monitoring the sniffer in the other channel.

For example we selected 36 and 40 channels for our testing and we keep changing the channel of the connected AP every 1min between 36 and 40. Whenever I am connected in Channel 36, I monitor sniffer in Channel 40 and when I am connected in Channel 40, I monitor sniffer in Channel 36 until the issue happens.

We have observed that the issue sometimes occur very fast and sometimes it take lot of time and we couldn't figure out why this happens.

So, I would suggest testing this for an hour and then give some time and test again.

Here is the config I use for my testing:

	insmod compat.ko
	insmod cfg80211.ko
	insmod brcmutil.ko
	insmod brcmfmac.ko roamoff=1 #debug=0x400

	wl -i wlan0 down
	wl vht_features 0
	wl band a;
	wl nmode 0;
	wl spect 0
	wl rrm 0
	wl wme 1
	wl -i wlan0 lrl 7
	wl -i wlan0 srl 7
	wl -i wlan0 PM 2
 	wl -i wlan0 rateset 6b 9 12b 18 24b 36
	wl -i wlan0 up
	wl pm2_sleep_ret 200

 Regards,

Rupesh

0 Likes

Hi @raks_99 

Did you get a chance to test with the configuration and in the way I suggested in my previous reply?

If yes, can you please let us know your observations.

Regards,

Rupesh.

0 Likes

Hi @raks_99 

Did you get a chance to test with the configuration and in the way I suggested in my previous reply?

If yes, can you please let us know your observations.

Regards,

Rupesh.

0 Likes
raks_99
Moderator
Moderator
Moderator
First question asked 250 replies posted 250 sign-ins

Hi @rupesh_theatro ,

We had had one of our other chips as a test AP. And to change the channel, we take down the AP, change the channel in the conf, then bring up the hostapd service. At this point, the CYW43012 reconnects to the AP, and we monitor the old channel. We do not observe any null function frames in the old channel.

Is this the right way? does your Access point also go down briefly and come back up, or does it offer a Channel switch announcement to the Client station? Also, can you set "wl PM 0" and "wl mpc 0" and still see the issue?

0 Likes

Hi @raks_99,

We didn't use any hostapd based AP but we directly tested with Cisco AP and also Aruba AP by changing the channel in the controller.

I didn't see any Channel Switch Indication to Client station and I am not sure if there is any dependency of Controller in the issue which will not be the case in your testing. 

We see the issue with "wl PM 0" and "wl mpc 0" configuration as well.

Regards,

Rupesh

0 Likes