[wpa_supplicant/WPA] request for clarification
Lukasz Majewski
l.majewski
Tue Jul 20 01:25:04 PDT 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