My test plateforme is very simple, One sta (with openwrt), one AP and a
computer connected to the AP.
I launch iperf on the sta and power up the AP.
With wireshark I can observe 1 s delay between the frame EAPOL 4/4 and
the arp request sent by the sta. I can observe the delay only if my sta
uses architecture with more 1 cpu.
When the sta received the Authentication response, mac80211 sets the
iface on UP state. This state allows wpa_supplicant to send the EAPOL
frame for WPA handshake but other frames are dropped.
If an arp request is sent by the local ip stack during the WPA handshake
this arp will be dropped and we need to wait the end of arp timeout (1
s).
Have you any suggestion / pointer to fix this issue?
Thanks for your help.
Cedric Voncken
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
>
>
> On 03/13/2015 12:36 PM, Cedric VONCKEN wrote:
> > My test plateforme is very simple, One sta (with openwrt), one AP and
> > a computer connected to the AP.
> > I launch iperf on the sta and power up the AP.
> >
> > With wireshark I can observe 1 s delay between the frame EAPOL 4/4 and
> > the arp request sent by the sta. I can observe the delay only if my
> > sta uses architecture with more 1 cpu.
> >
> > When the sta received the Authentication response, mac80211 sets the
> > iface on UP state. This state allows wpa_supplicant to send the EAPOL
> > frame for WPA handshake but other frames are dropped.
> >
> > If an arp request is sent by the local ip stack during the WPA
> > handshake this arp will be dropped and we need to wait the end of arp
> > timeout (1 s).
> >
> > Have you any suggestion / pointer to fix this issue?
> >
>
> I had a situation where ARP requests were sent and responses were replied,
> but the requester did not accept the responses and therefore was
continuously
> sending request. However, this was in an IBSS and WPA encryption, which is
> not really supported if I understand well. RSN worked like a charm,
though.
> The issue was related to the type of encryption. This could also be an
issue
> in your case, however, AP is well supported, so hard to tell. I'm not
really
> a security expert.
>
> My point being, you will get better and faster support if you could
specify
> which encryption protocol you use, the specific parameters, etc.
>
> br,
> Wim.
>
My platform is very simple. I use 2 equipment. Both equipment are based on
mips64 processor, use ATH9K driver and openwrt.
One equipment is configured in AP mode with WPA2-PSK, another equipment is
configured in station mode.
I can access to the sta through ssh.
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.
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 [email protected]
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
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
> > > > > > [email protected] 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 [email protected]
> > > > 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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
James Cameron
http://quozl.linux.org.au/
On 03/13/15 19:34, James Cameron wrote:
> 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.
ARP is an Address Resolution Protocol to obtain the ethernet or MAC
address for a destination ip address by sending a broadcast message. One
common application involving arp queries is 'ping'.
Regards,
Arend
>> 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
>>>>>>> [email protected] 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 [email protected]
>>>>> 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 [email protected]
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
> > 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?
>
>
> > 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
> > > > [email protected] 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 [email protected]
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
>
On Fri, 2015-03-13 at 14:41 +0100, voncken wrote:
> >
> >
> > On 03/13/2015 12:36 PM, Cedric VONCKEN wrote:
> > > My test plateforme is very simple, One sta (with openwrt), one AP and
> > > a computer connected to the AP.
> > > I launch iperf on the sta and power up the AP.
> > >
> > > With wireshark I can observe 1 s delay between the frame EAPOL 4/4 and
> > > the arp request sent by the sta. I can observe the delay only if my
> > > sta uses architecture with more 1 cpu.
> > >
> > > When the sta received the Authentication response, mac80211 sets the
> > > iface on UP state. This state allows wpa_supplicant to send the EAPOL
> > > frame for WPA handshake but other frames are dropped.
> > >
> > > If an arp request is sent by the local ip stack during the WPA
> > > handshake this arp will be dropped and we need to wait the end of arp
> > > timeout (1 s).
> > >
> > > Have you any suggestion / pointer to fix this issue?
> > >
> >
> > I had a situation where ARP requests were sent and responses were replied,
> > but the requester did not accept the responses and therefore was
> continuously
> > sending request. However, this was in an IBSS and WPA encryption, which is
> > not really supported if I understand well. RSN worked like a charm,
> though.
> > The issue was related to the type of encryption. This could also be an
> issue
> > in your case, however, AP is well supported, so hard to tell. I'm not
> really
> > a security expert.
> >
> > My point being, you will get better and faster support if you could
> specify
> > which encryption protocol you use, the specific parameters, etc.
> >
> > br,
> > Wim.
> >
>
> My platform is very simple. I use 2 equipment. Both equipment are based on
> mips64 processor, use ATH9K driver and openwrt.
> One equipment is configured in AP mode with WPA2-PSK, another equipment is
> configured in station mode.
> I can access to the sta through ssh.
>
> 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.
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 [email protected]
> > > 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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> > > 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.
Have you any idea?
Cedric.
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
> > > > > [email protected] 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 [email protected]
> > > More majordomo info at http://vger.kernel.org/majordomo-info.html
> >
>
>
On 03/13/2015 12:36 PM, Cedric VONCKEN wrote:
> My test plateforme is very simple, One sta (with openwrt), one AP and a
> computer connected to the AP.
> I launch iperf on the sta and power up the AP.
>
> With wireshark I can observe 1 s delay between the frame EAPOL 4/4 and
> the arp request sent by the sta. I can observe the delay only if my sta
> uses architecture with more 1 cpu.
>
> When the sta received the Authentication response, mac80211 sets the
> iface on UP state. This state allows wpa_supplicant to send the EAPOL
> frame for WPA handshake but other frames are dropped.
>
> If an arp request is sent by the local ip stack during the WPA handshake
> this arp will be dropped and we need to wait the end of arp timeout (1
> s).
>
> Have you any suggestion / pointer to fix this issue?
>
I had a situation where ARP requests were sent and responses were
replied, but the requester did not accept the responses and therefore
was continuously sending request. However, this was in an IBSS and WPA
encryption, which is not really supported if I understand well. RSN
worked like a charm, though. The issue was related to the type of
encryption. This could also be an issue in your case, however, AP is
well supported, so hard to tell. I'm not really a security expert.
My point being, you will get better and faster support if you could
specify which encryption protocol you use, the specific parameters, etc.
br,
Wim.
> Thanks for your help.
>
> Cedric Voncken
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html