The kind folks at linux-wireless IRC suggested that I should probably bring this ugly topic over here.
I've been digging into this problem for the last few days, and am now in need of some guidance from you wireless guru's. I hope the you folks can follow my twisted path. Here's the scenario:
SYMPTOMS:
=========
Linux clients (and apparently *only* Linux clients) cannot associate with an AP running a brand new "flavor" of DD-WRT firmware. Myself and others have reported the same problem. The response from the chief DD-WRT person was basically, "tested and works on Windows and OSX, so it must be a Linux problem".
The Wicd network manager displays strange UTF-8 type characters for the SSID. This causes it to create an incorrect WPA PSK.
Also, two ESSIDs are returned for that MAC when running the "iwlist wlan0 scan" command using many different wireless devices. So far, I've found that ipw2200 and rta2870sta seem to be the only devices that don't report an "extra" ESSID with iwlist.
Not surprisingly, I can connect to the router by manually running wpa_supplicant.
The problem still exists when running compat-wireless-2010-04-26.
Here's an example of the "iwlist wlan0 scan" output with the router in it's "default" configuration:
Cell 02 - Address: 00:25:9C:XX:XX:XX
Channel:6
Frequency:2.437 GHz (Channel 6)
Quality=70/70 Signal level=-33 dBm
Encryption key:off
---> ESSID:"dd-wrt"
Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 6 Mb/s
9 Mb/s; 12 Mb/s; 18 Mb/s
Bit Rates:24 Mb/s; 36 Mb/s; 48 Mb/s; 54 Mb/s
---> ESSID:""
Mode:Unknown/bug
Extra:tsf=00000064b6ade4fb
Extra: Last beacon: 4120ms ago
IE: Unknown: 000664642D777274
IE: Unknown: 010882848B960C121824
IE: Unknown: 030106
IE: Unknown: 2A0100
IE: Unknown: 32043048606C
IE: Unknown: DD180050F2020101020003A4000027A4000042435E00623
IE: Unknown: 331A4C101BFFFF000000000000000000000000000000000
IE: Unknown: 2D1A4C101BFFFF000000000000000000000000000000000
>>>> IE: Unknown: 34160600190000000000000000000000000000000000000
IE: Unknown: 3D160600190000000000000000000000000000000000000
IE: Unknown: 4A0E14000A002C01C800140005001900
IE: Unknown: 7F0101
IE: Unknown: DD0900037F01010000FF7F
IE: Unknown: DD0A00037F04010000000000
PROBLEM:
========
I tried to narrow the problem by firing up the debugger against iwlist. After iwlist performs a SIOGIWSCAN, it then retreives the AP response, and this contains a second, bogus SSID (specifically a SIOCGIWESSID), with data matching one of the Information Elements above... actually two. But here's the data that I think causes the problem:
IE: Unknown: 34160600190000000000000000000000000000000000000
Both the Wireshark scan capture and my digging into the 802.11k-2008 specification show that line as being a "Neighbor Report" Information Element (0x34 = 52 decimal = Neighbor Report).
I noticed that decimal 52 is assigned to WLAN_EID_MESH_ID in the ieee80211.h file, and recently the same 52 was also assigned to WLAN_EID_NEIGHBOR_REPORT in the same enumerated ieee80211_eid{} structure.
BUT... before I go kernel diving, I have a question. I guess I'm trying to first determine if the problem may be in the router. From my reading of the 802.11k-2008 specification, I'm thinking that a Neighbor Report should not even be inside a scan response from the AP. Every reference to "Neighbor Report" that I can find in the specification *seems* to state that a Neighbor Report response should only arrive at the STA after the AP receives a "Neighbor Report Request" frame. And it should then be contained inside a "Neighbor Report Response" frame. Is my thinking correct??? Or am I off base (yet again ;)???
FYI: The router is configured as a simple AP acting as a gateway to a cable modem. No vlans, no hotspot, etc... i.e. nothing "exotic". In fact, no one has yet found a configuration setting that will make this problem disappear.
OBTW: All beacon frames coming from the router also contain this Neighbor Report.
Also, here is a snippet from a scan report using iw (notice that it's not confused by the Neighbor Report):
-------------------------- BEGIN NETLINK MESSAGE ---------------------------
[HEADER] 16 octets
.nlmsg_len = 312
.nlmsg_type = 24 <0x18>
.nlmsg_flags = 2 <MULTI>
.nlmsg_seq = 1273073208
.nlmsg_pid = 6127
[PAYLOAD] 296 octets
22 01 00 00 08 00 2e 00 c5 00 00 00 08 00 03 00 03 00 ".................
00 00 14 01 2f 00 0a 00 01 00 00 25 9c XX XX XX 00 00 ..../......%......
ce 00 06 00 00 06 64 64 2d 77 72 74 01 08 82 84 8b 96 ......dd-wrt......
0c 12 18 24 03 01 06 2a 01 00 32 04 30 48 60 6c dd 18 ...$...*..2.0H`l..
00 50 f2 02 01 01 02 00 03 a4 00 00 27 a4 00 00 42 43 .P..........'...BC
5e 00 62 32 2f 00 33 1a 4c 10 1b ff ff 00 00 00 00 00 ^.b2/.3.L.........
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 2d 1a ................-.
4c 10 1b ff ff 00 00 00 00 00 00 00 00 00 00 00 00 00 L.................
00 00 00 00 00 00 00 00 34 16 06 00 19 00 00 00 00 00 ........4.........
00 00 00 00 00 00 00 00 00 00 00 00 00 00 3d 16 06 00 ..............=...
19 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ..................
00 00 4a 0e 14 00 0a 00 2c 01 c8 00 14 00 05 00 19 00 ..J.....,.........
7f 01 01 dd 09 00 03 7f 01 01 00 00 ff 7f dd 0a 00 03 ..................
7f 04 01 00 00 00 00 00 00 00 0c 00 03 00 10 69 af ac ...............i..
77 00 00 00 06 00 04 00 64 00 00 00 06 00 05 00 21 04 w.......d.......!.
00 00 08 00 02 00 85 09 00 00 08 00 0a 00 e7 11 00 00 ..................
08 00 07 00 54 f2 ff ff ....T...
--------------------------- END NETLINK MESSAGE ---------------------------
BSS 00:25:9c:XX:XX:XX (on wlan0)
TSF: 513998285072 usec (5d, 22:46:38)
freq: 2437
beacon interval: 100
capability: ESS ShortPreamble ShortSlotTime (0x0421)
signal: -35.00 dBm
last seen: 4583 ms ago
SSID: dd-wrt
Supported rates: 1.0* 2.0* 5.5* 11.0* 6.0 9.0 12.0 18.0
DS Parameter set: channel 6
ERP: <no flags>
Extended supported rates: 24.0 36.0 48.0 54.0
WMM: * Parameter version 1
* BE: CW 15-1023, AIFSN 3
* BK: CW 15-1023, AIFSN 7
* VI: CW 7-15, AIFSN 2, TXOP 3008 usec
* VO: acm CW 3-7, AIFSN 2, TXOP 1504 usec
Unknown IE (51): 4c 10 1b ff ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
HT capabilities:
Capabilities: 0x104c
HT20
SM Power Save disabled
RX HT40 SGI
No RX STBC
Max AMSDU length: 7935 bytes
DSSS/CCK HT40
Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
Minimum RX AMPDU time spacing: 1/2 usec (0x02)
HT RX MCS rate indexes supported: 0-15
HT TX MCS rate indexes are undefined
Unknown IE (52): 06 00 19 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Unknown IE (61): 06 00 19 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Unknown IE (74): 14 00 0a 00 2c 01 c8 00 14 00 05 00 19 00
Extended capabilities: HT Information Exchange Supported
Vendor specific: OUI 00:03:7f, data: 01 01 00 00 ff 7f
Vendor specific: OUI 00:03:7f, data: 04 01 00 00 00 00 00
On Sat, May 08, 2010 at 09:34:45AM -0500, pigiron wrote:
> On Fri, 7 May 2010 09:29:18 -0700 Javier Cardona <[email protected]> wrote:
> > I don't know about the router, nor if the IE ID clash is causing your
> > problem, but moving the mesh codes somewhere else in the unassigned ID
> > space would be a "A Good Thing To Do (tm)".
> Really?
>
> Wouldn't that cause a problem for the kids running OLPC? For instance, where
> some of the laptops are running an old level of code where WLAN_EID_MESH_ID=52
> and others are running new code where WLAN_EID_MESH_ID=X.
If I'm not mistaken, the mesh done in OLPC is already incompatible w/
802.11s anyway.
John
--
John W. Linville Someday the world will need a hero, and you
[email protected] might be all we have. Be ready.
On Fri, 7 May 2010 09:29:18 -0700 Javier Cardona <[email protected]> wrote:
> Hi,
>
> On Thu, May 6, 2010 at 7:56 PM, pigiron <[email protected]> wrote:
> > On Thu, 6 May 2010 11:12:15 -0700 Steve deRosier <[email protected]> wrote:
> >
> >> On Wed, May 5, 2010 at 10:01 AM, pigiron <[email protected]> wrote:
> >> > I noticed that decimal 52 is assigned to WLAN_EID_MESH_ID in the
> >> > ieee80211.h file, and recently the same 52 was also assigned to
> >> > WLAN_EID_NEIGHBOR_REPORT in the same enumerated ieee80211_eid{}
> >> > structure.
> >> >
> >>
> >> I can't answer the rest of your question, but AFAIK, the element IDs
> >> for 802.11s mesh haven't been approved yet as the 802.11s draft
> >> contains a note to that effect. The current ANA database sheet I
> >> could find (Feb 2010) does have 52 assigned to Neighbor Report, and
> >> the mesh element IDs are nowhere to be found.
> >>
> > I agree. The 802.11k-2008 standard has already been approved with Element ID
> > 52 = Neighbor Report, so it's probably almost a guarantee that 802.11s
> > won't be assigning 52 to anything in the future.
> >
> > I'm kind of stuck on this problem. I could probably find out what's causing
> > the failure and create a patch... but the patch wouldn't be "The Right
> > Thing To Do(tm)" if the router isn't supposed to be spewing that data to
> > begin with.
>
> I don't know about the router, nor if the IE ID clash is causing your
> problem, but moving the mesh codes somewhere else in the unassigned ID
> space would be a "A Good Thing To Do (tm)".
>
> Cheers,
>
> Javier
Really?
Wouldn't that cause a problem for the kids running OLPC? For instance, where
some of the laptops are running an old level of code where WLAN_EID_MESH_ID=52
and others are running new code where WLAN_EID_MESH_ID=X.
Especially, since as far as I can tell with my untrained eye, this Neighbor
Report that I've been fretting about should only be coming over the air when
specifically asked for... and we don't have any code (yet) to do that?
peace,
Bob
On Thu, 6 May 2010 11:12:15 -0700 Steve deRosier <[email protected]> wrote:
> On Wed, May 5, 2010 at 10:01 AM, pigiron <[email protected]> wrote:
> > I noticed that decimal 52 is assigned to WLAN_EID_MESH_ID in the
> > ieee80211.h file, and recently the same 52 was also assigned to
> > WLAN_EID_NEIGHBOR_REPORT in the same enumerated ieee80211_eid{} structure.
> >
>
> I can't answer the rest of your question, but AFAIK, the element IDs
> for 802.11s mesh haven't been approved yet as the 802.11s draft
> contains a note to that effect. The current ANA database sheet I
> could find (Feb 2010) does have 52 assigned to Neighbor Report, and
> the mesh element IDs are nowhere to be found.
>
> - Steve
I agree. The 802.11k-2008 standard has already been approved with Element ID
52 = Neighbor Report, so it's probably almost a guarantee that 802.11s won't be
assigning 52 to anything in the future.
I'm kind of stuck on this problem. I could probably find out what's causing the
failure and create a patch... but the patch wouldn't be "The Right Thing To
Do(tm)" if the router isn't supposed to be spewing that data to begin with.
And at this point I've sort of convinced myself that the router is misbehaving.
When I combine Table 7-15 in the 802.11k-2008 standard with the same table in
the 802.11-2007 standard (Table 7-15 describes a "Probe Response frame body"), I
just can't find a way for it to contain a Neighbor Report.
I've had to code to a lot of standards/specifications over the years, but this
is my first trip into the 802.11 world... so I guess I'm just looking for some
confirmation from someone who has been living in the wireless world for awhile.
That, and I'd have to do a *bunch* of war driving to prove that no other routers
spew a Neighbor Report.
Hi,
On Thu, May 6, 2010 at 7:56 PM, pigiron <[email protected]> wrote:
> On Thu, 6 May 2010 11:12:15 -0700 Steve deRosier <[email protected]> wrote:
>
>> On Wed, May 5, 2010 at 10:01 AM, pigiron <[email protected]> wrote:
>> > I noticed that decimal 52 is assigned to WLAN_EID_MESH_ID in the
>> > ieee80211.h file, and recently the same 52 was also assigned to
>> > WLAN_EID_NEIGHBOR_REPORT in the same enumerated ieee80211_eid{} structure.
>> >
>>
>> I can't answer the rest of your question, but AFAIK, the element IDs
>> for 802.11s mesh haven't been approved yet as the 802.11s draft
>> contains a note to that effect. ?The current ANA database sheet I
>> could find (Feb 2010) does have 52 assigned to Neighbor Report, and
>> the mesh element IDs are nowhere to be found.
>>
> I agree. The 802.11k-2008 standard has already been approved with Element ID
> 52 = Neighbor Report, so it's probably almost a guarantee that 802.11s won't be
> assigning 52 to anything in the future.
>
> I'm kind of stuck on this problem. I could probably find out what's causing the
> failure and create a patch... but the patch wouldn't be "The Right Thing To
> Do(tm)" if the router isn't supposed to be spewing that data to begin with.
I don't know about the router, nor if the IE ID clash is causing your
problem, but moving the mesh codes somewhere else in the unassigned ID
space would be a "A Good Thing To Do (tm)".
Cheers,
Javier
On Wed, May 5, 2010 at 10:01 AM, pigiron <[email protected]> wrote:
> I noticed that decimal 52 is assigned to WLAN_EID_MESH_ID in the ieee80211.h file, and recently the same 52 was also assigned to WLAN_EID_NEIGHBOR_REPORT in the same enumerated ieee80211_eid{} structure.
>
I can't answer the rest of your question, but AFAIK, the element IDs
for 802.11s mesh haven't been approved yet as the 802.11s draft
contains a note to that effect. The current ANA database sheet I
could find (Feb 2010) does have 52 assigned to Neighbor Report, and
the mesh element IDs are nowhere to be found.
- Steve
John,
On Sat, May 8, 2010 at 5:40 PM, John W. Linville <[email protected]> wrote:
> On Sat, May 08, 2010 at 09:34:45AM -0500, pigiron wrote:
>> On Fri, 7 May 2010 09:29:18 -0700 Javier Cardona <[email protected]> wrote:
>
>> > I don't know about the router, nor if the IE ID clash is causing your
>> > problem, but moving the mesh codes somewhere else in the unassigned ID
>> > space would be a "A Good Thing To Do (tm)".
>
>> Really?
>>
>> Wouldn't that cause a problem for the kids running OLPC? For instance, where
>> some of the laptops are running an old level of code where WLAN_EID_MESH_ID=52
>> and others are running new code where WLAN_EID_MESH_ID=X.
>
> If I'm not mistaken, the mesh done in OLPC is already incompatible w/
> 802.11s anyway.
Yes, the currently deployed laptops implement an earlier version of
the 802.11s draft that's not compatible with what's in the kernel now.
Javier
--
Javier Cardona
cozybit Inc.
http://www.cozybit.com