On Sat, Feb 16, 2008 at 12:40:03PM +0100, Michael Buesch wrote:
> On Saturday 16 February 2008 12:33:57 Rafał Miłecki wrote:
> > 2008/2/16, Michael Buesch <mb@xxxxxxxxx>:
> > > On Saturday 16 February 2008 12:01:34 Rafał Miłecki wrote:
> > > > I use 4318/02 and 2.6.24 kernel. Usually everything works fine but in
> > > > some moments iwlist shows my AP a few time in the output. The problem
> > > > is that as long as iwlist do that, KNetworkManager doesn't display my
> > > > AP. I wonder if this can be b43 bug?
> > >
> > > This seems to be channel interference.
> > > KNetworkManager should be fixed in any case.
> >
> > But as far as I know channels 6 and 11should be out of interference,
> > or am I wrong? I'm not a genius in this sphere, everying I can do is
> > just to comapre that 2426-2448 (ch6) and 2451-2473 (ch1) have another
> > values.
>
> If there is an AP on channel 6, you can also get most of its beacons on channel 7
> and 5. So if the AP sends a beacon while you scan channel 7 you might get the
> AP from channel 6. Note that the TSF timers are different for the two APs.
> The Channel:X value from iwlist is most likely from the beacon-embedded channel
> identifier IE. So you'll also get Channel:6, if the packet was actually received
> on channel 7 or 5 or whatever.
Here is a pertinent fragment of the code in question from
ieee80211_rx_bss_info (called for both beacons and probe responses):
if (elems.ds_params && elems.ds_params_len == 1)
freq = ieee80211_channel_to_frequency(elems.ds_params[0]);
else
freq = rx_status->freq;
bss = ieee80211_rx_bss_get(dev, mgmt->bssid, freq,
elems.ssid, elems.ssid_len);
if (!bss) {
bss = ieee80211_rx_bss_add(dev, mgmt->bssid, freq,
elems.ssid, elems.ssid_len);
if (!bss)
return;
} else {
.
.
.
So the frequency info can come from either the beacon or from the
Rx status. But in either case, the info that comes from iwlist is
taken from the same linked list used by ieee80211_rx_bss_get and
ieee80211_rx_bss_add. Since the frequency (i.e. channel) information
is the same for both instances of the BSSID, that implies that the
same freq value was passed to ieee80211_rx_bss_add for each entry.
The ieee80211_rx_bss_get compares BSSID, SSID, and frequency when
matching a BSS. This accounts for some strange AP implementations
that use the same BSSID either on different frequencies or in
different SSIDs. Anyway, the BSSID and SSID information also
matches in both BSSID instances from the posted iwlist output.
To me this implies that we have some linked list management problem.
Since ieee80211_rx_bss_add only gets called after a failed match in
ieee80211_rx_bss_get, I have to guess that there is a hole in our
matching algorithm?
Here is the ieee80211_rx_bss_get implementation, in case someone else
sees the problem:
static struct ieee80211_sta_bss *
ieee80211_rx_bss_get(struct net_device *dev, u8 *bssid, int freq,
u8 *ssid, u8 ssid_len)
{
struct ieee80211_local *local = wdev_priv(dev->ieee80211_ptr);
struct ieee80211_sta_bss *bss;
spin_lock_bh(&local->sta_bss_lock);
bss = local->sta_bss_hash[STA_HASH(bssid)];
while (bss) {
if (!memcmp(bss->bssid, bssid, ETH_ALEN) &&
bss->freq == freq &&
bss->ssid_len == ssid_len &&
(ssid_len == 0 || !memcmp(bss->ssid, ssid, ssid_len))) {
atomic_inc(&bss->users);
break;
}
bss = bss->hnext;
}
spin_unlock_bh(&local->sta_bss_lock);
return bss;
}
Any ideas on what might be happening? It seems like it would have
to be linked to matching the SSID...?
John
P.S. Here is the iwlist info in question, for those just joining the thread:
wlan0 Scan completed :
Cell 01 - Address: 00:18:39:DD:EE:78
ESSID:"zajec_linksys"
Mode:Master
Channel:6
Frequency:2.437 GHz (Channel 6)
Quality=63/100 Signal level=-51 dBm Noise level=-72 dBm
Encryption key:on
IE: Unknown: 300130
Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 6 Mb/s
12 Mb/s; 24 Mb/s; 36 Mb/s; 9 Mb/s; 18 Mb/s
48 Mb/s; 54 Mb/s
Extra:tsf=00000014481e851a
Cell 02 - Address: 00:14:78:EB:FF:6C
ESSID:"NTC_03"
Mode:Master
Channel:11
Frequency:2.462 GHz (Channel 11)
Quality=31/100 Signal level=-86 dBm Noise level=-72 dBm
Encryption key:on
Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s
Extra:tsf=000000c4357e0181
Cell 03 - Address: 00:18:39:DD:EE:78
ESSID:""
Mode:Master
Channel:6
Frequency:2.437 GHz (Channel 6)
Quality=65/100 Signal level=-50 dBm Noise level=-72 dBm
Encryption key:on
IE: IEEE 802.11i/WPA2 Version 1
Group Cipher : CCMP
Pairwise Ciphers (1) : CCMP
Authentication Suites (1) : PSK
Preauthentication Supported
Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 6 Mb/s
12 Mb/s; 24 Mb/s; 36 Mb/s; 9 Mb/s; 18 Mb/s
48 Mb/s; 54 Mb/s
Extra:tsf=0000001447c32e34
Cell 04 - Address: 00:18:39:DD:EE:78
ESSID:""
Mode:Master
Channel:6
Frequency:2.437 GHz (Channel 6)
Quality=65/100 Signal level=-50 dBm Noise level=-72 dBm
Encryption key:on
IE: IEEE 802.11i/WPA2 Version 1
Group Cipher : CCMP
Pairwise Ciphers (1) : CCMP
Authentication Suites (1) : PSK
Preauthentication Supported
Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 6 Mb/s
12 Mb/s; 24 Mb/s; 36 Mb/s; 9 Mb/s; 18 Mb/s
48 Mb/s; 54 Mb/s
Extra:tsf=0000001447c239ef
--
John W. Linville
linville@xxxxxxxxxxxxx
-
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
