Hi, When I connect my USB wireless card (Linksys WUSB54GS, rndis_wlan module) and after configuring it with iwconfig + dhclient, I see a warning on the kernel output. The device seems to work correctly afterwards, though. If I use network-manager I see no warning at all being printed on the syslog. I see this behaviour both on 2.6.32.24 as well as 2.6.36-rc7. I haven't tested other kernel versions. This is the card: Bus 002 Device 003: ID 13b1:000e Linksys WUSB54GS v1 802.11g Adapter [Broadcom 4320 USB] I'm attaching said output. Best regards, Luís Picciochi
Created attachment 33362 [details] Warning caught under 2.6.36-rc7
Created attachment 33372 [details] Warning caught under 2.6.32.24
Problem most likely is that rndis_wlan_do_link_up_work() assumes that "Internal bss list in device always contains at least the currently connected bss" at the time of 'media connect' indication. This is true for BCM4320b device that I have, but your device is BCM4320a type. So problem is that cfg80211 doesn't have bss for access point, device is already connected to, thus warning (bss == null). Maybe BCM4320a needs full scan to get bss information, or maybe rndis_wlan should try just fake/construct bss information for cfg80211 with a-type device.
I'm not sure that I understand your description but probably this is related: - It can take a long time (sometimes 20 to 30 minutes) for the device to show my SSID with 'iwlist scan' after starting from a cold boot. Other devices on my network (one of them is usually placed near this one) don't have this problem. - I notice that I can connect to my network even when 'iwlist scan' doesn't show my AP on the scan results. After I run iwconfig / dhclient and the connection is established, 'iwlist scan' always shows my AP from that point on. - The time to detect the AP's beacon is particularly noticeable when I use network-manager. n-m seems to connect only after it detects a beacon with a scan. - If I have n-m running, after I use iwconfig/dhclient and am connected to the network, n-m will re-connect afterwards. I suppose this is because scans show my AP's beacon after the connection is established. n-m then sees the network and will then connect to it. Please tell me if there are any tests I can do to help you triage this.
(In reply to comment #4) > I'm not sure that I understand your description but probably this is related: > - It can take a long time (sometimes 20 to 30 minutes) for the device to show > my SSID with 'iwlist scan' after starting from a cold boot. Other devices on > my > network (one of them is usually placed near this one) don't have this > problem. Ok, this means that scanning doesn't seem to work with BCM4320a and is mostlikely separate issue from the warning. > - I notice that I can connect to my network even when 'iwlist scan' doesn't > show my AP on the scan results. After I run iwconfig / dhclient and the > connection is established, 'iwlist scan' always shows my AP from that point > on. But since we get the warning, currently AP doesn't show up as fast as with BCM4320b. But it's good to know that it will show up quickly after some time. Maybe older firmware requires some extra tricks (like issueing scan before reading scan results in 'media connect' handler). > - The time to detect the AP's beacon is particularly noticeable when I use > network-manager. n-m seems to connect only after it detects a beacon with a > scan. > > - If I have n-m running, after I use iwconfig/dhclient and am connected to > the > network, n-m will re-connect afterwards. I suppose this is because scans show > my AP's beacon after the connection is established. n-m then sees the network > and will then connect to it. I'd say this is expected as n-m will keep scanning and when it sees AP, it will (re)connect even if its the same AP we are already manually connected. This because n-m doesn't monitor manual use of network devices and expects to be sole user. > > Please tell me if there are any tests I can do to help you triage this. I'll attach patch for 2.6.36 to enable debugging in rndis_wlan, it might show more info on the scanning issue and about the warning.
Created attachment 33922 [details] Enable debugging output for rndis_wlan.
(In reply to comment #5) > (In reply to comment #4) > > I'm not sure that I understand your description but probably this is > related: > > - It can take a long time (sometimes 20 to 30 minutes) for the device to > show > > my SSID with 'iwlist scan' after starting from a cold boot. Other devices > on my > > network (one of them is usually placed near this one) don't have this > problem. > > Ok, this means that scanning doesn't seem to work with BCM4320a and is > mostlikely separate issue from the warning. I forgot to mention that other SSIDs appear when I scan. My SSID always ends up showing, eventually. It just takes time. Sometimes it is not long, others it is. Scanning looks like it's working, just not very well. I'm attaching the output I got with debugging enabled: two logs are with network-manager disabled, where I tested scanning and connecting without having done any previous scan. The third is just letting n-m do it's thing.
Created attachment 34062 [details] Scan tests without network-manager running
Created attachment 34072 [details] Connection test without network-manager running
Created attachment 34082 [details] network-manager connecting
Created attachment 34112 [details] Try to get device return bssid by issuing explicit scan on connect I read more of the NDIS spec and indeed device should return currectly associated BSSID when retrieving BSSID scan list. So this patch pokes device/firmware little more in hopes that it will update internal bssid list.
Above patch might work, but on the other hand, debug output with n-m shows that scans after connect do not always get current bssid. So device might not be following NDIS spec correctly. Please test with debug enabled.
It doesn't seem to have changed much.
Created attachment 34132 [details] Connection test w/ patch and without n-m
Created attachment 34142 [details] Workaround warning by manually crafting bss when not otherwise available Add workaround but only in case device internal BSS list doesn't have the BSS for currently associated AP.
Created attachment 34152 [details] Longer scan delay might fix the scanning issue. NDIS spec says scan must be ready after 6 seconds. Now this might not be true for real devices, so lets relax scan delay (6 sec to 9 sec) a little bit so we hopefully catch more APs.
With these patches the warning doesn't seem to appear anymore. It still takes a long time until I see my beacon. About 20 minutes on my latest test. Should I file a new bug for this?
(In reply to comment #17) > With these patches the warning doesn't seem to appear anymore. > > It still takes a long time until I see my beacon. About 20 minutes on my > latest > test. Should I file a new bug for this? Please do. I have few ideas to test.
'Workaround warning by manually crafting bss when not otherwise available' is going to 2.6.38 and workarounds the hardware bug. Marking bug resolved.