This was done with spatch using the following semantic patch and minor
manual edits to clean up coding style and avoid compiler warnings in
driver_wext.c:
@@
expression a,b;
@@
- os_memcmp(a, b, ETH_ALEN) == 0
+ ether_addr_equal(a, b)
@@
expression a,b;
@@
- os_memcmp(a, b, ETH_ALEN) != 0
+ !ether_addr_equal(a, b)
@@
expression a,b;
@@
- !os_memcmp(a, b, ETH_ALEN)
+ ether_addr_equal(a, b)
Signed-off-by: Jouni Malinen <j@w1.fi>
In repeater configuration, both AP and STA wireless interfaces may be
included into the same bridge. In this case the following race condition
may occur: wpa_supplicant and hostapd are started, then hostapd clients
are connected before wpa_supplicant connects to remote AP. EAPOL packets
between hostapd and its clients are detected by wpa_supplicant on bridge
interface, prematurely disabling the workaround.
One possible option to fix this issue is to check EAPOL destination MAC
in wpa_supplicant and disable workaround only if EAPOL packet on bridge
interface is indeed intended for wpa_supplicant.
Signed-off-by: Sergey Matyukevich <sergey.matyukevich.os@quantenna.com>
When wpa_supplicant is running on a Linux interface that is configured in
promiscuous mode, and it is not a member of a bridge, incoming EAPOL
packets are processed regardless of the Destination Address in the frame.
As a consequence, there are situations where wpa_supplicant replies to
EAPOL packets that are not destined for it.
This behavior seems undesired (see IEEE Std 802.1X-2010, 11.4.a), and can
be avoided by attaching a BPF filter that lets the kernel discard packets
having pkt_type equal to PACKET_OTHERHOST.
Signed-off-by: Davide Caratti <davide.caratti@gmail.com>
There was a race condition in how the l2_packet sockets got read that
could result in the same socket (e.g., non-bridge) to process both the
EAP-Success and the immediately following EAPOL-Key msg 1/4 instead of
each frame going in alternative order between the bridge and non-bridge
sockets. This could be hit, e.g., if the wpa_supplicant process did not
have enough CPU to process all the incoming frames without them getting
buffered and both sockets reporting frames simultaneously.
This resulted in the duplicated EAP-Success frame getting delivered
twice for processing and likely also the EAPOL-Key msg 1/4 getting
processed twice. While the latter does not do much harm, the former did
clear the EAP authentication state and could result in issues.
Fix this by extended the l2_packet Linux packet socket workaround for
bridge to check for duplicates against the last two received frames
instead of just the last one.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
It was possible for the packet socket on the bridge interface to receive
own transmitted frames between the bridge and non-bridge sockets
receiving the same incoming frame from a foreign host. This resulted in
the hash checksum validation step failing to notice a duplicate RX due
to the own frame updating the store hash value.
The own frame did get dropping in RX EAPOL processing, but that was too
late to address the issue with duplicate RX. Fix this by dropping own
frames already in l2_packet layer before checking and updating the last
RX hash value.
Signed-off-by: Jouni Malinen <j@w1.fi>
Linux packet socket workaround(*) has an impact in performance when the
workaround socket needs to be kept open to receive EAPOL frames. While
this is normally avoided with a kernel that has the issue addressed by
closing the workaround packet socket when detecting a frame through the
main socket, it is possible for that mechanism to not be sufficient,
e.g., when an open network connection (no EAPOL frames) is used.
Add a build option (CONFIG_NO_LINUX_PACKET_SOCKET_WAR=y) to disable the
workaround. This build option is disabled by default and can be enabled
explicitly on distributions which have an older kernel or a fix for the
kernel regression.
Also remove the unused variable num_rx.
(*) Linux kernel commit 576eb62598f10c8c7fd75703fe89010cdcfff596
('bridge: respect RFC2863 operational state') from 2012 introduced a
regression for using wpa_supplicant with EAPOL frames and a station
interface in a bridge.
Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
Commit e6dd8196e5 ('Work around Linux
packet socket regression') closed the workaround socket on the first
received EAPOL frame from the main packet socket. This can result in
closing the socket in cases where the kernel does not really work in the
expected way during the following initial association since
reauthentication/rekeying using EAPOL frames happens while operstate is
not dormant and as such, the frames can get delivered through the main
packet socket.
Fix this by closing the workaround socket only in case the first EAPOL
frame is received through the main packet socket. This case happens
while the interface is in dormant state and as such, is more likely to
show the more restricted case of kernel functionality.
In order to avoid processing the received EAPOL frames twice, verify a
checksum of the frame contents when receiving frames alternatively from
the main packet socket and the workaround socket.
Signed-off-by: Jouni Malinen <j@w1.fi>
Commit e6dd8196e5 ('Work around Linux
packet socket regression') added a mechanism to close the workaround
bridge socket in l2_packet_receive(). However, it did not take into
account the possibility of the l2->rx_callback() closing the l2_packet
socket altogether. This could result in use of freed memory when usin
RSN pre-authentication. Fix this by reordering the calls to clear the
workaround socket before calling the rx_callback.
Signed-off-by: Jouni Malinen <j@w1.fi>
Linux kernel commit 576eb62598f10c8c7fd75703fe89010cdcfff596 ('bridge:
respect RFC2863 operational state') from 2012 introduced a regression
for using wpa_supplicant with EAPOL frames and a station interface in a
bridge. Since it does not look like this regression is going to get
fixed any time soon (it is already two years from that commit and over
1.5 from a discussion pointing out the regression), add a workaround in
wpa_supplicant to avoid this issue.
The wpa_supplicant workaround uses a secondary packet socket to capture
all frames (ETH_P_ALL) from the netdev that is in a bridge. This is
needed to avoid the kernel regression. However, this comes at the price
of more CPU load. Some of this is avoided with use of Linux socket
filter, but still, this is less efficient than a packet socket bound to
the specific EAPOL ethertype. The workaround gets disabled
automatically, if the main packet socket interface on the bridge
interface turns out to be working for RX (e.g., due to an old kernel
version being used or a new kernel version having a fix for the
regression). In addition, this workaround is only taken into use for the
special case of running wpa_supplicant with an interface in a bridge.
Signed-off-by: Jouni Malinen <j@w1.fi>
The RA, NS, and NA packets may be longer, so do not arbitrarily limit
the packet socket capture size to 150 bytes in the socket filter.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
gcc 4.4 ends up generating strict-aliasing warnings about some very common
networking socket uses that do not really result in a real problem and
cannot be easily avoided with union-based type-punning due to struct
definitions including another struct in system header files. To avoid having
to fully disable strict-aliasing warnings, provide a mechanism to hide the
typecast from aliasing for now. A cleaner solution will hopefully be found
in the future to handle these cases.
