Hostapd daemons receive each other's EAPOL frames

[Johan Almbladh]

Hi,

I have a setup with where several hostapd/nl80211 daemons run on
different interfaces. The interfaces are really different PHYs, not
virtual APs, so a single hostapd instance won't cut it. All interfaces
are also bridged to the same bridge interface.

The nl80211 driver receives EAPOL frames on an EAPOL socket with
PF_PACKET/SOCK_DGRAM/ETH_P_PAE
(src/drivers/driver_nl80211.c:handle_eapol). It then compares the
destination ifindex from the sockaddr_ll struct to the list of
ifindices it owns. If the ifindex is found the EAPOL frame is passed
on for further processing. Unfortunately the destination ifindex in
sockaddr_ll is the bridge ifindex. This is true for all hostapd
daemons running on interfaces bridged to that bridge. It seems that
they will see each others EAPOL frames.

I am not 100 per cent sure this is harmful, but to me it seems very
dangerous to send arbitrary EAPOL frames deep into the hostapd EAPOL
state machine. For example, the receive handler
hostapd_event_eapol_rx() in src/ap/drv_callbacks.c doesn't even check
that the source MAC is an associated STA. I have seen the error
"invalid MIC in msg 2/4 of 4-Way Handshake" that may be caused by
this, see the log at the end.

I think we need the true destination BSSID for the EAPOL frame in
order to correctly determine if it is meant for us or not. The bridge
ifindex is not enough to resolve that. Also, filtering the source MAC
with the list of associated STAs is not sufficient either. There may
be a STA entry for a STA that has already associated with another AP,
e.g. if the STA start scanning and then changes association it may not
send DEAUTH to the first AP.

The correct way to do this would be to get hold of the destination
BSSID of the EAPOL frames. I propose that we use SOCK_RAW instead of
SOCK_DGRAM on the EAPOL socket. Then we can get the destination MAC
from the ethernet header and only accept EAPOL frames where this MAC
matches a BSSID that we own. I have not done any long-term testing
yet, but it works seem to work in that sense that EAPOL frames get
filtered correctly on BSSID, even if they are on the same bridge.

Any comments or feedback on this is much appreciated!

Thanks,
/Johan


WPA: 00:26:08:f7:33:8f WPA_PTK entering state AUTHENTICATION
WPA: 00:26:08:f7:33:8f WPA_PTK entering state AUTHENTICATION2
WPA: 00:26:08:f7:33:8f WPA_PTK entering state INITPSK
WPA: 00:26:08:f7:33:8f WPA_PTK entering state PTKSTART
wlan0: STA 00:26:08:f7:33:8f WPA: sending 1/4 msg of 4-Way Handshake
WPA: Send EAPOL(version=2 secure=0 mic=0 ack=1 install=0 pairwise=8
kde_len=0 keyidx=0 encr=0)
nl80211: Event message available
nl80211: Ignored unknown event (cmd=19)
IEEE 802.1X: 00:26:08:f7:33:8f TX status - version=2 type=3 length=95 - ack=1
mgmt::action cb
IEEE 802.1X: 121 bytes from 00:26:08:f7:33:8f
   IEEE 802.1X: version=1 type=3 length=117
wlan0: STA 00:26:08:f7:33:8f WPA: received EAPOL-Key frame (2/4 Pairwise)
WPA: 00:26:08:f7:33:8f WPA_PTK entering state PTKCALCNEGOTIATING
WPA: PTK derivation - A1=00:25:86:d9:62:cf A2=00:26:08:f7:33:8f
wlan0: STA 00:26:08:f7:33:8f WPA: invalid MIC in msg 2/4 of 4-Way Handshake
wlan0: STA 00:26:08:f7:33:8f WPA: EAPOL-Key timeout
WPA: 00:26:08:f7:33:8f WPA_PTK entering state PTKSTART
wlan0: STA 00:26:08:f7:33:8f WPA: sending 1/4 msg of 4-Way Handshake
WPA: Send EAPOL(version=2 secure=0 mic=0 ack=1 install=0 pairwise=8
kde_len=0 keyidx=0 encr=0)
IEEE 802.1X: 00:26:08:f7:33:8f TX status - version=2 type=3 length=95 - ack=1
IEEE 802.1X: 121 bytes from 00:26:08:f7:33:8f
   IEEE 802.1X: version=1 type=3 length=117
wlan0: STA 00:26:08:f7:33:8f WPA: received EAPOL-Key frame (2/4 Pairwise)
WPA: 00:26:08:f7:33:8f WPA_PTK entering state PTKCALCNEGOTIATING
WPA: PTK derivation - A1=00:25:86:d9:62:cf A2=00:26:08:f7:33:8f
wlan0: STA 00:26:08:f7:33:8f WPA: invalid MIC in msg 2/4 of 4-Way Handshake
wlan0: STA 00:26:08:f7:33:8f WPA: EAPOL-Key timeout
WPA: 00:26:08:f7:33:8f WPA_PTK entering state PTKSTART
wlan0: STA 00:26:08:f7:33:8f WPA: sending 1/4 msg of 4-Way Handshake
WPA: Send EAPOL(version=2 secure=0 mic=0 ack=1 install=0 pairwise=8
kde_len=0 keyidx=0 encr=0)
IEEE 802.1X: 00:26:08:f7:33:8f TX status - version=2 type=3 length=95 - ack=1
IEEE 802.1X: 121 bytes from 00:26:08:f7:33:8f
   IEEE 802.1X: version=1 type=3 length=117
wlan0: STA 00:26:08:f7:33:8f WPA: received EAPOL-Key frame (2/4 Pairwise)
WPA: 00:26:08:f7:33:8f WPA_PTK entering state PTKCALCNEGOTIATING
WPA: PTK derivation - A1=00:25:86:d9:62:cf A2=00:26:08:f7:33:8f
wlan0: STA 00:26:08:f7:33:8f WPA: invalid MIC in msg 2/4 of 4-Way Handshake
wlan0: STA 00:26:08:f7:33:8f WPA: EAPOL-Key timeout
WPA: 00:26:08:f7:33:8f WPA_PTK entering state PTKSTART
wlan0: STA 00:26:08:f7:33:8f WPA: sending 1/4 msg of 4-Way Handshake
WPA: Send EAPOL(version=2 secure=0 mic=0 ack=1 install=0 pairwise=8
kde_len=0 keyidx=0 encr=0)
IEEE 802.1X: 00:26:08:f7:33:8f TX status - version=2 type=3 length=95 - ack=1
mgmt::deauth
deauthentication: STA=00:26:08:f7:33:8f reason_code=2
AP-STA-DISCONNECTED 00:26:08:f7:33:8f
wlan0: STA 00:26:08:f7:33:8f WPA: event 3 notification
wpa_driver_nl80211_set_key: ifindex=13 alg=0 addr=0x452fd8 key_idx=0
set_tx=1 seq_len=0 key_len=0
    addr=00:26:08:f7:33:8f
WPA: 00:26:08:f7:33:8f WPA_PTK entering state DISCONNECTED