Bug 250913
| Summary: | [PATCH] iwl3945 improperly combines 802.11a and 802.11bg networks and fails to find the a net | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Derek Atkins <warlord> |
| Component: | kernel | Assignee: | John W. Linville <linville> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | high | Docs Contact: | |
| Priority: | medium | ||
| Version: | 7 | CC: | cebbert, chris.brown, davej |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | 2.6.22.9-91.fc7 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2007-10-04 00:14:17 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Attachments: | |||
|
Description
Derek Atkins
2007-08-05 05:31:13 UTC
Just to clarify, the problem is that you can't associate to "SSID-a", but you can associate to "SSID-g". The theory you are offering (which seems plausible enough) is that because "SSID-a" and "SSID-g" both use the same BSSID they must be conflicting with one another in the kernel's internal data structures used for storing scan results. Is this a correct characterization? I'll have to look at the scanning code to see if I can find such a problem. I just want to make sure I understand your report. John, Yes, that is the correct characterization. The scan results presented via "iwlist eth1 scan" don't even show the SSID-a network in the list; network-manager never sees it, either, and I can't seem to get the driver even to manually swap over to the SSID-a. At the IETF two weeks ago, however, I WAS able to connect to ietf-a because they were different BSSIDs than "ietf-g". I'm only guessing at the cause, but it seems reasonable. I'm happy to test kernel RPMs for you. As suspected, mac80211 collects scan results based solely on BSSID. So, I surmise that your scan results cover both your .11a network and your .11g network, with your .11g results overwriting the .11a stuff almost immediately. I'm not sure what (if anything) IEEE802.11 says about using the same BSSID on different channels or modulations. But it may not matter anyway if there is equipment in the field doing it already. I'll look at a patch and see about getting you a test kernel... Thanks. I don't know specifically what the 802.11 docs say about this, but I'll just add that the win32 driver, the ipw3945 driver, and previous a/b/g drivers have all worked just fine in this particular environment. I look forward to your patch and a test kernel. FWIW I've since upgraded to 2.6.22.1-41.fc7 but obviously it still has this issue. Thank you for looking at it! Created attachment 161683 [details]
0001-mac80211-store-freq-info-in-sta_bss_list.patch
I'm building RPMs now (may be a while before they're done): http://koji.fedoraproject.org/koji/taskinfo?taskID=105621 Just click on the build for your arch, then look for the right RPM in the "output" secion at the bottom of the page. Do these kernels show both the a and b/g BSSIDs? Also, what is the AP you are using? It's a D-Link DWL-7100AP I'll try the new kernel once it finishes. Created attachment 161736 [details]
Scan results
I'm running with the new kernel now. The good news: the scan results show
both my 802.11a and 802.11b/g networks. The bad news: it's showing too many
entries. For example, there are multiple entries for the same AP on the same
BSSID/Frequency pairs.
So, I would say that this patch isn't quite right, yet.
I'm happy to test your next attempt! Thanks!
Yeah, something definitely looks busted there... :-) I'll look at it again. BTW, I think the meaning of ON_DEV is non-obvious (and it may not actually be used anymore in our process). Also, it makes this bug drop off my default list! Let's stick to ASSIGNED or maybe NEEDINFO with the field set to Assignee...FWIW, I think it will put it back to ASSIGNED automatically when you are the NEEDINFO person and you add a comment. Yeah, I just didn't add a comment directly; I commented by adding an attachment. That didn't automatically convert it from NEEDINFO to ASSIGNED, and I didn't see "ASSIGNED" in the list when I tried to convert it directly. I'll be more careful next time around. :) Oh, something else I noticed.. Even with this new kernel in place, networkmanager still didn't list both devices, but I think that's a NM issue, not a driver issue. Once we get the driver working then I'll file a bug with NM. (Mumbling to myself...) Can't replicate here, might be related to actually having same BSSIDs on multiple freqs. Maybe that situations screws-up the hash table so that is never right afterwards (causing later BSSID lookups to fail)? Hmm.. Yeah, it might be making an assumption that there's only one entry per BSSID and as a result screwing up the hash table.. And if you never actually HAVE that situation in your environment then you'll never see it. Hmm.. So how would you like me to help you debug this? Hash table looks pretty simple -- still, I observe that your scan results look fine until the first not-quite-duplicate bssid. After that every entry is either a duplicate or the first in a series of duplicates. Still, might be coincidental since only one bssid is un-duplicated in that list anyway (two if you count "ihtfp-a" as distinct from "ihtfp"). Does the scan result list grow longer over time? Any idea of the rate at which it gets longer? I'm guessing it relates to beacon intervals, but that should make it grow pretty darned fast up to limit of 256 or so... Hmmm...scratch that -- it probably has one entry for each beacon it sees _during_the_scan_ (after list entry duplication starts). So, it might be naturally limited by the channel dwell time during the scan. You might try manipulating the beacon interval on any AP you control, to see if you can make it show more duplicates? It probably doesn't help find the problem, but it might be fun... :-) Along those lines, do "ihtfp-a" and "ihtfp" have different beacon intervals? If so, that might account for why "ihtfp-a" doesn't get duplicated... 802.11a (ihtfp-a) is configured with beacon interval 100, DTIM 1, Fragment Length 2346, PTS Length 2346. 802.11g (ihtfp) is configured exactly the same. So many what I'm seeing is the sum of all beacons, where it's never actually detecting any duplicates so it never culls the list? Or when a beacon comes in it doesn't check if it's in the list before adding it? Check for an existing entry seems to be failing in some cases. It looks like there is some funny business with the freq values in the bss list entries. I'd like to try using channel instead -- still not sure if I really should check mode either in addition or instead. But, lets see if this works as a start... Created attachment 161770 [details] 0001-mac80211-store-channel-info-in-sta_bss_list.patch http://koji.fedoraproject.org/koji/taskinfo?taskID=107553 Build in comment 20 will likely take a while -- anyway, let me know if it works any differently (hopefully better)...thanks! I just updated to 2.6.22.2-57.bz250913.1.fc7 and it does indeed fix the problem. Thanks! Now I get to file a bug report against NM. Nice work. I take it this patch didn't make it into 2.6.22.4-65.fc7 that was just released? Any chance this patch will make it into a new kernel anytime soon? If not, any chance you could build be a new kernel based on kernel-2.6.22.5-76.fc7 ? Thanks Hello Derek, I'm reviewing this bug as part of the kernel bug triage project, an attempt to isolate current bugs in the fedora kernel. http://fedoraproject.org/wiki/KernelBugTriage I am CC'ing myself to this bug and will try and assist you in resolving it if I can. (In reply to comment #24) > Any chance this patch will make it into a new kernel anytime soon? If not, any > chance you could build be a new kernel based on kernel-2.6.22.5-76.fc7 ? I'm building one now and will run one in Koji if it goes okay. Attaching updated patch - this should be in 2.6.23 - can you test a kernel from the development repository to see whether this issue is resolved for you? Cheers Chris Created attachment 203631 [details]
J. Linville's patch updated to apply against 2.6.22.5
(In reply to comment #24) > Any chance this patch will make it into a new kernel anytime soon? If not, any > chance you could build be a new kernel based on kernel-2.6.22.5-76.fc7 ? > > Thanks http://koji.fedoraproject.org/koji/taskinfo?taskID=171488 I can verify that kernel-2.6.22.5-76.bz250913.fc7.i686.rpm works for me. FYI, I'm also tracking another iwl3945 bug #293701 but I cannot test both simultaneously. See my latest comment in that bug for an explanation. Hopefully both fixes will make it into an updated kernel. Thanks. Patch is in kernel 2.6.22.9-91 |