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