pre-authentication problem

[Bryan Kadzban]

On Fri, Nov 30, 2007 at 02:27:43PM +0100, IO te wrote:
> State: GROUP_HANDSHAKE -> COMPLETED
> CTRL-EVENT-CONNECTED - Connection to <mac_ap_1> completed (auth)
> EAPOL: External notification - portValid=1
> RSN: processing PMKSA candidate list
> RSN: PMKSA candidate <mac_ap_1> does not need pre-authentication anymore
> RSN: PMKSA candidate <mac_ap_2> selected for pre-authentication
> RSN: starting pre-authentication with <mac_ap_2>

So far so good (I assume)...

> EAPOL: SUPP_PAE entering state DISCONNECTED
> EAPOL: KEY_RX entering state NO_KEY_RECEIVE
> EAPOL: SUPP_BE entering state INITIALIZE
> EAP: EAP entering state DISABLED
> EAPOL: External notification - portValid=1
> EAPOL: External notification - portEnabled=1
> EAPOL: SUPP_PAE entering state CONNECTING
> EAPOL: SUPP_BE entering state IDLE
> EAP: EAP entering state INITIALIZE
> EAP: EAP entering state IDLE
> EAPOL: startWhen --> 0
> EAPOL: startWhen --> 0
> EAPOL: SUPP_PAE entering state CONNECTING

That also looks (fairly) normal...

> EAPOL: txStart
> TX EAPOL (preauth) - hexdump(len=4): 01 01 00 00
> EAPOL: startWhen --> 0
> EAPOL: SUPP_PAE entering state CONNECTING
> EAPOL: txStart
> TX EAPOL (preauth) - hexdump(len=4): 01 01 00 00
> EAPOL: startWhen --> 0
> EAPOL: SUPP_PAE entering state CONNECTING
> EAPOL: txStart

Etc., etc.  It looks like wpa_supplicant is just re-sending the
EAPOL-Start frame over and over again, probably because it never gets an
EAP-Request-Identity from the second AP.

If you fire up tcpdump on eth1 on the second AP, do you see the incoming
EAPOL frames?  I think they'll have an Ethertype of 0x88c7 (which is not
the same as normal EAPOL, and is also different from IP -- I don't think
that will cause the issue you're seeing, but it will affect any filter
that you set up in tcpdump).  Do you also see the outgoing EAPOL frames?

Also, if you start up tcpdump on eth1 on the first AP, which destination
MAC address do the EAPOL frames have?  Are they using the BSSID of the
second AP, or the second AP's wired MAC?  (Or is it something else?)

I think the only address that wpa_supplicant knows is the BSSID, so I
suspect the destination MAC will match the BSSID.  But then the kernel
on the second AP will (probably) drop the frame when it sees it, because
it isn't coming in on the correct interface.  Unless hostapd has already
configured the kernel to accept these frames; I'm not sure whether it
does that or not.  It probably should, if the kernel can be configured
to do that.  (Promiscuous mode?  See also:
http://lists.shmoo.com/pipermail/hostap/2005-November/011840.html )

It's also possible that your switch is dropping the frame because it
hasn't learned the destination MAC.  But I'm pretty sure that switches
will broadcast the frame if that happens (i.e. they'll act like a hub).

Anyway, see what tcpdump shows first.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.shmoo.com/pipermail/hostap/attachments/20071130/594a0969/attachment.pgp