wpa_supplicant: Work around Linux packet socket regression

[Jouni Malinen]

On Wed, Feb 18, 2015 at 04:35:44PM +0100, r.sperling at avm.de wrote:
> I've been taking a closer look at the workaround for WDS interfaces in a
> bridge that respects RFC2863 operational states and found an issue with
> this patch. The problem is that the workaround gets disabled by EAPOLs
> forwarded by the linux bridge while the interface is not in dormant state.
> This is primary the case during group rekeying. In addition, there is a
> possible race condition until the netdevice entirely arrived in dormant
> state and the first reception of an EAPOL of the 4-way handshake by the
> kernel/supplicant. This may happen e.g. in loaded condition if the WLAN
> driver has already connected to the AP but the dormant state is yet not
> fully set. Hence, in both cases the workaround gets disabled although it is
> still needed later on e.g. in case of a reconnection.

Have you been able to trigger that latter case? I can reproduce the
former through any reauthentication/rekeying sequence, but I'm not sure
how the dormant state would not be set for the first EAPOL frame.
wpa_supplicant puts the interface in dormant state at startup (i.e.,
before even trying an association) and similarly, dormant state is set
on disconnection.

> This faulty deactivation of the workaround may be prevented by additionally
> checking the the current interface status flags for dormant state. Only if
> the latter one is really set the workaround should be disabled.

This sounds like something that would have risks for race conditions..
Or well, I guess wpa_supplicant could do this based on internal
knowledge of what was the last successfully completed operstate change.
That said, I don't think I really want l2_packet*.c to have to be able
to track this state.

> Nevertheless, as already discussed on the list, this workaround is not a
> really nice one including possible drawbacks like performance regression.
> Hence I would like to add two other solutions as basis for discussion.

Well, I'd recommend fixing the kernel side issue if the performance loss
from use of Linux socket filter is considered an issue. This could be
done either by applying something like the patch used in OpenWrt (*) or
coming up with a new design for EAPOL frame delivery (e.g., through
netlink).

(*)
http://git.openwrt.org/?p=openwrt.git;a=blob_plain;f=target/linux/generic/patches-3.19/120-bridge_allow_receiption_on_disabled_port.patch;h=bd24fdb1efe9956b389d4846d6f7a9cfc0ed52ca;hb=HEAD

> 1. Most of the WLAN drivers stop all traffic if the connection is not
> authorized. In addition, with older kernel version the dormant state was
> ignored anyway. So we could completely remove setting dormant state in the
> supplicant for the drivers.

I don't think I would be willing to do this. There is a good reason for
wpa_supplicant to manage operstate to avoid other programs like DHCP
client from starting to transmit packets too early and time out or slow
down their operations.

> 2. If we stay with the workaround we can also consider just to enabled it
> if the devices is currently in dormant state. As a result, there would be
> not influence if the connection is successfully established.

I think this workaround will need to remain until someone uses enough
time to get an upstream kernel change to either restore the old behavior
for EAPOL ethertype or a new mechanism for delivering EAPOL frames to
user space.

I modified the disable-workaround trigger to happen only for the initial
EAPOL frame RX to avoid disabling the workaround on reauthentication or
rekeying. This comes with some additional complexity and CPU use in
wpa_supplicant (need to avoid duplicate processing), but since this is
only applicable to EAPOL frames and only for the corner case of
wpa_supplicant being used on a netdev that is in a bridge, this seems
justifiable.

-- 
Jouni Malinen                                            PGP id EFC895FA