On Tue, 2015-03-17 at 16:02 +0100, voncken wrote: > > > > > 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? > > > It is not the initial connection. My sta is connected on AP1 and the communication is established (in my test the communication it is iperf from STA to computer behind the APs). > > I looking for a solution to enable the communication for wpa_supplicant, but block the L3 communication while the WPA handshake is not finished. Yeah, I saw your mail to netdev. In my opinion (which may not count for much) I don't think the kernel should be doing any ARP when the interface is not IF_OPER_UP. wpa_supplicant is doing the right thing if it is setting the interface IF_OPER_DORMANT when doing the rekeying and then setting the interface to IF_OPER_UP when it has successfully installed the new keys. There's only a few places where ARPs get triggered in the kernel, and perhaps those need to be modified to defer the ARP until IF_OPER_UP or something like that. In any case, I think this is best followed up on netdev since I don't think the supplicant is doing anything wrong here. Dan -- 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
