Re: ARP dropped during WPA handshake
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: ARP dropped during 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? > 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. -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ARP dropped during WPA handshake
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 majord...@vger.kernel.org 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 majord...@vger.kernel.org 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 majord...@vger.kernel.org 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ARP dropped during WPA handshake
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 > > > > > > majord...@vger.kernel.org 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 majord...@vger.kernel.org > > > > 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 majord...@vger.kernel.org > 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ARP dropped during WPA handshake
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 > > > > > majord...@vger.kernel.org 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 majord...@vger.kernel.org > > > 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: ARP dropped during WPA handshake
> > 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 > > > > majord...@vger.kernel.org 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 majord...@vger.kernel.org > > 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ARP dropped during WPA handshake
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 majord...@vger.kernel.org > > > 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 majord...@vger.kernel.org > 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: ARP dropped during WPA handshake
> > > 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 majord...@vger.kernel.org > > 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ARP dropped during WPA handshake
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 majord...@vger.kernel.org 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
