Re: ARP dropped during WPA handshake

[Dan Williams <dcbw@redhat.com>]

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