On Fri, Mar 13, 2015 at 11:29:34AM -0500, Dan Williams wrote: > On Fri, 2015-03-13 at 16:53 +0100, voncken wrote: > > > > Below, a tcpdump capture from sta. > > > > 17:43:12.964096 EAPOL key (3) v2, len 95 > > > > 17:43:12.998439 EAPOL key (3) v1, len 117 > > > > 17:43:13.062409 ARP, Request who-has 10.32.61.100 tell 10.32.0.1, > > > > length 28 > > > > 17:43:13.079989 EAPOL key (3) v2, len 151 > > > > 17:43:13.082764 EAPOL key (3) v1, len 95 > > > > 17:43:14.062381 ARP, Request who-has 10.32.61.100 tell 10.32.0.1, > > > > length 28 > > > > 17:43:14.127101 ARP, Reply 10.32.61.100 is-at b8:88:e3:45:1d:c6 (oui > > > > Unknown), length 46 > > > > 17:43:14.127123 IP 10.69.1.201.41690 > 10.32.61.100.5001: UDP, length > > > > 1470 > > > > 17:43:14.127136 IP 10.69.1.201.41690 > 10.32.61.100.5001: UDP, length > > > > 1470 > > > > > > > > You can see the ARP request during the WPA Handshake. > > > > > > During the initial WPA handshake the connection is not fully set up, and so > > > no general traffic can (nor should) pass between the STA and AP. > > > That includes ARP and any L2/L3+ protocols, except for EAP and wifi > > > management packets. > > > > > > The interface itself must be IFF_UP before it can pass traffic, including the > > > WPA handshake traffic. IFF_UP only means that the interface can be > > > configured at the L2 level and the hardware is active, it does *not* mean the > > > interface can pass traffic. > > > > > > Whatever is causing the ARPs shouldn't be doing that yet, and should be fixed > > > to use the interface's "operstate" or IFF_LOWER_UP instead of IFF_UP. Only > > > when the supplicant changes the interface's operstate to IF_OPER_UP is the > > > interface *actually* ready to pass traffic. IFF_UP is not sufficient. > > > > > > > Thanks for your reply. > > > > It seems wpa_supplicant set the operstate to IF_OPER_DORMANT when he received the ASSOCIATED Event from the driver (through netlink). And set the operstate to IF_OPER_UP in case of wpa handshake success. > > > > Is it normal the local ip stack send arp when netdev it is on IF_OPER_DORMANT state? > > I'm not sure the kernel stack cares much as long as the device is up. > It is requesting the ARP because some application is attempting to > communicate with that IP address. That application should probably be > waiting until the interface is actually ready to communicate, which > means IF_OPER_UP. > > But if this is the first WPA handshake with the AP during the initial > connection, the wifi device shouldn't even have an IP address yet, so > nothing should be doing ARP on the interface yet. I thought that ARP was a means to get an IP address before an interface had an IP address, so the interface spends some time without an IP address yet generating ARP. > Perhaps whatever is assigning the IP address to the interface is > doing it too early, before the interface is IF_OPER_UP? > > Dan > > > > > > > > > > > > > Any suggestion will be appreciate. > > > > > > > > Cedric. > > > > > > > > > > > Thanks for your help. > > > > > > > > > > > > Cedric Voncken > > > > > > > > > > > > > > > > > > -- > > > > > > 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 > > > > > > > > -- > > > > 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 > > > > > > > > > > -- > 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 -- James Cameron http://quozl.linux.org.au/ -- 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
