[wpa_supplicant/WPA] request for clarification

Lukasz Majewski l.majewski at samsung.com
Tue Jul 20 04:25:04 EDT 2010


Hi Holger,

Thank you for the response.

> cross-compiled sounds like your on some embedded device. Which WLAN
> driver do you use, which CPU type?

I'm using the bcm4329 driver available from
http://android.git.kernel.org/?p=platform/system/wlan/broadcom.git;a=tree;h=f427424c414886903e4ad654c143c8ce6ec10e3c;hb=f427424c414886903e4ad654c143c8ce6ec10e3c

It is used on an ARM based CPU, running ordinary Linux.

> Can you *really* understand why it times out?  I can't. If you have
> one client and only one AP, then it shouldn't time out.

To be honest I don't have any clue why it is timed out. It shouldn't
happen since there is only one target and AP. There shouldn't be time
out anyway.

> You can shed more light into this issue if you take a third computer,
> put it on the channel of the AP and monitor all packets via wireshark.

I did this and the result is quite strange. On the beginning of the
communication the STA (target machine) is sending the "Null function
(No data)" frame :

158     1.475488        Netgear_23:5c:02        Epigram_c5:00:34
IEEE 802.11     Probe Response, SN=3619, FN=0, Flags=........, BI=100,
SSID="linksys-g"
159     1.478116        Netgear_23:5c:02        Epigram_c5:00:34
IEEE 802.11     Probe Response, SN=3619, FN=0, Flags=....R..., BI=100,
SSID="linksys-g"


164     1.515540        Epigram_c5:00:34        Netgear_23:5c:02
IEEE 802.11     Null function (No data), SN=1094, FN=0, Flags=.......T
165     1.515909        Epigram_c5:00:34        Netgear_23:5c:02
IEEE 802.11     Null function (No data), SN=1094, FN=0, Flags=....R..T
166     1.515925                Epigram_c5:00:34 (RA)   IEEE 802.11
Acknowledgement, Flags=........

169     1.561414        Epigram_c5:00:34        Netgear_23:5c:02
IEEE 802.11     Null function (No data), SN=1095, FN=0, Flags=...P...T
170     1.561446                Epigram_c5:00:34 (RA)   IEEE 802.11
Acknowledgement, Flags=........


178     1.592608        Epigram_c5:00:34        Netgear_23:5c:02
IEEE 802.11     Null function (No data), SN=1098, FN=0, Flags=.......T
179     1.592614                Epigram_c5:00:34 (RA)   IEEE 802.11
Acknowledgement, Flags=........
180     1.593170        Epigram_c5:00:34        Netgear_23:5c:02
IEEE 802.11     Disassociate, SN=1099, FN=0, Flags=........


809     8.019347        Netgear_23:5c:02        Epigram_c5:00:34
IEEE 802.11     Probe Response, SN=3734, FN=0, Flags=........, BI=100,
SSID="linksys-g"
810     8.019655                Netgear_23:5c:02 (RA)   IEEE 802.11
Acknowledgement, Flags=........
811     8.021956        Netgear_23:5c:02        Epigram_c5:00:34
IEEE 802.11     Probe Response, SN=3734, FN=0, Flags=....R..., BI=100,
SSID="linksys-g"
812     8.022273                Netgear_23:5c:02 (RA)   IEEE 802.11
Acknowledgement, Flags=........


816     8.100390        Epigram_c5:00:34        Netgear_23:5c:02
IEEE 802.11     Authentication, SN=1179, FN=0, Flags=........
817     8.100713                Epigram_c5:00:34 (RA)   IEEE 802.11
Acknowledgement, Flags=........
818     8.101306        Netgear_23:5c:02        Epigram_c5:00:34
IEEE 802.11     Authentication, SN=3736, FN=0, Flags=........
819     8.101620                Netgear_23:5c:02 (RA)   IEEE 802.11
Acknowledgement, Flags=........
820     8.102710        Epigram_c5:00:34        Netgear_23:5c:02
IEEE 802.11     Association Request, SN=1180, FN=0, Flags=........,
SSID="linksys-g"
821     8.103034                Epigram_c5:00:34 (RA)   IEEE 802.11
Acknowledgement, Flags=........

824     8.108839        Netgear_23:5c:02        Epigram_c5:00:34
EAPOL   Key
825     8.109163                Netgear_23:5c:02 (RA)   IEEE 802.11
Acknowledgement, Flags=........

840     8.274929        Epigram_c5:00:34        Netgear_23:5c:02
EAPOL   Key
841     8.275221                Epigram_c5:00:34 (RA)   IEEE 802.11
Acknowledgement, Flags=........
842     8.279074        Netgear_23:5c:02        Epigram_c5:00:34
EAPOL   Key
843     8.279387                Netgear_23:5c:02 (RA)   IEEE 802.11
Acknowledgement, Flags=........
844     8.289174        Epigram_c5:00:34        Netgear_23:5c:02
EAPOL   Key
845     8.289531                Epigram_c5:00:34 (RA)   IEEE 802.11
Acknowledgement, Flags=........

847     8.299322        Netgear_23:5c:02        Epigram_c5:00:34
IEEE 802.11     QoS Data, SN=2, FN=0, Flags=.p....F.
848     8.299631                Netgear_23:5c:02 (RA)   IEEE 802.11
Acknowledgement, Flags=........

Please pay attention to the following issues:
1. The STA on the beginning of the communication is indicating that it
will go for a sleep (Flags=...P...T). Why? 

2. Several ACK frames are send without source, only with destination,
which is the same as the source which is sending data. Why it is like
that? Shouldn't the source for ACK frames be the AP/STA, which has
received the data?

3. The delay between first appearance of the Epigram_c5:00:34 (target)
and the first association negotiation (approximately 6.5 seconds). What
might cause the delay?

> I see that you still use WEXT (side note: it's outdated, don't make
> new development with  WEXT technology, use NL80211 instead).
 
Yes, WEXT are used in this driver. Unfortunately there isn't any
possibility to use the nl80211/cfg80211 framework.

BTW. Could you explain in a short way, how the driver written to
comply with nl80211 framework is fully compatible with utilities, which
are using wext (e.g. iwconfig)?

> wpa_supplicant tried to associate to this AP. But this AP didn't
> answer. So for now, wpa_supplicant assumes that this AP is broken.

It's strange. The AP is working as it should. Other Linux running
laptops (e.g. Ubintu 10.04) are able to seamlessly connect to it. I
doubt, that it is the fault of AP. It might be the driver. 

> 1279286521.499003: Wireless event: new AP: 00:00:00:00:00:00

I guess that the AP: 00:00:00:00:00:00, which has been found by the
driver is wrong. And it indicates some kind of driver error. I don't
know where to look to solve the problem. Any hint to look into is
welcome.

The most strange thing is that the STA is connected with the proper
AP, then AP with MAC 00:00:00:00:00:00 is found as the better one to
connect therefore the driver disconnect and tries to connect the new AP.
This of course must fail and thereafter reconnection is done with the
old (proper) AP. How to explain this?

Thanks for help.

Lukasz Majewski 

On Mon, 19 Jul 2010 15:21:36 +0200
Holger Schurig <holgerschurig at gmail.com> wrote:

> > I'm using the wpa_supplicant 0.6.10, the source code cross compiled
> > from Debian sources. 
> 
> cross-compiled sounds like your on some embedded device. Which WLAN
> driver do you use, which CPU type?
> 
> I'm asking this because it might be the case that your WLAN driver
> isn't totally little-endian/big-endian clean. Proper source
> annotation and "sparse" can help you in discovering this kind of
> errors.
> 
> > One is the "blacklist". Please consider the following snippet:
> > 
> > 1279286521.334725: Authentication with c0:3f:0e:49:6a:ca timed out.
> > 1279286521.334790: CTRL_IFACE monitor send - hexdump(len=21): 2f 74
> > 6d 70 2f 77 70 61 5f 63 74 72 6c 5f 32 39 32 36 2d 31 00
> > 1279286521.334926: CTRL_IFACE monitor[0]: 111 - Connection refused
> > 1279286521.334984: Added BSSID c0:3f:0e:49:6a:ca into blacklist
> > 1279286521.335034: wpa_driver_wext_disassociate
> > 1279286521.497794: No keys have been configured - skip key clearing
> > 1279286521.497841: State: 4WAY_HANDSHAKE -> DISCONNECTED
> > 
> > I can understand that the authentication has timed out.
> 
> Can you *really* understand why it times out?  I can't. If you have
> one client and only one AP, then it shouldn't time out.
> 
> You can shed more light into this issue if you take a third computer,
> put it on the channel of the AP and monitor all packets via wireshark.
> 
> I see that you still use WEXT (side note: it's outdated, don't make
> new development with  WEXT technology, use NL80211 instead). So it
> might even be the case that you have a WLAN card where the card
> itself does the association part of 802.11. You could even have
> something like a lost interrupt.
> 
> 
> 
> > But from the other hand I don't know why the connection is refused
> 
> Some upper layer assumes that a timed out association (client sent
> the 802.11 association request packet, but did not receive the 802.11
> association response packet) equals to a "connection refused" error.
> That's a follow-up error. The first error is more important here.
> 
> 
> > and then wpa_supplicant is putting the AP to the "blacklist". 
> 
> wpa_supplicant tried to associate to this AP. But this AP didn't
> answer. So for now, wpa_supplicant assumes that this AP is broken.
> Therefore the AP ends up on the blacklist. This makes sure that on
> the next try (if you have more than one AP), it won't be tried again,
> but a another one instead.
> 
> > I'm using 4WAY_HANDSHAKE EAP authentication.
> 
> This is here irrelevant, as 802.11 association request / association
> response and 802.11 authentication request / authentication response
> must happen before that. Only then can the 4-way handshake start.
> 
> 
> > 1279286521.499053: BSSID 00:00:00:00:00:00 blacklist count
> > incremented to 2 
> > 1279286521.499108: CTRL-EVENT-DISCONNECTED - Disconnect event -
> > remove keys 
> 
> That's quite wacky. Maybe your driver sends strange WEXT events.
> 
> What does "iwevent" say during this?
> 
> Maybe you need to call "iwevent" with some arguments to see all the
> gory details, I forgot as I abandoned iwconfig and other WEXT friends
> nine months ago.
> 
> 



-- 
Best regards,

Lukasz Majewski

Samsung Poland R&D Center
Platform Group


More information about the HostAP mailing list