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. 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
