[Battlemesh] Extending Eduroam over the community network

[Linus Lüssing]

On Fri, Jun 03, 2016 at 02:19:16PM +0200, Mitar wrote:
> Hi!
> 
>/ Getting back to this old thread. :-)

Me too :)

> [...]
> What I imagine is that one could really simply pass all packets further.
> That this new AP would really simply be a direct bridge.

I dug a little deeper into code and standards the last two days.
Yes, as EAP-Over-LAN claims to work over any LAN-like medium, bridging
should in theory be possible. Or even tunneling 802.1x over L2TP
over IP/UDP :P.


One caveat is, that EAPOL uses the supplicants (stations) and
access points MAC address for key generation (more precisely
for the Pairwise-Transient-Key and Group-Transient-Key) [0].

So the question is, which MAC address for the AP side of the key
generation should be used? An 802.11 AP has a BSSID, a Transmitter
Address and a Source Address to offer.

Source Address would be great, that would  work fine with
bridging, but... looks like IEEE 802.1X has something else in
mind...

-----
# 802.1x-2004, 7.8 EAPOL Adressing:

"In an 802.11 access point, the BSSID associated with the wireless
interface would be used in place of this MAC address."


# 802.1x-2010, 11.1.2 Source MAC address

"In an 802.11 access point, the BSSID associated with the wireless
interface is used."
-----

:-(


I also looked at the wpa-supplicant code. Which seems to have
some promising remarks, though:

wpa_supplicant.c
-> wpa_supplicant_rx_eapol():

-----
3122         wpa_s->last_eapol_matches_bssid =
3123                 os_memcmp(src_addr, wpa_s->bssid, ETH_ALEN) == 0;
3124
[...]
3192         /* Source address of the incoming EAPOL frame could be compared to the
3193          * current BSSID. However, it is possible that a centralized
3194          * Authenticator could be using another MAC address than the BSSID of
3195          * an AP, so just allow any address to be used for now. The replies are
3196          * still sent to the current BSSID (if available), though. */
3197
3198         os_memcpy(wpa_s->last_eapol_src, src_addr, ETH_ALEN);
3199         if (!wpa_key_mgmt_wpa_psk(wpa_s->key_mgmt) &&
3200             eapol_sm_rx_eapol(wpa_s->eapol, src_addr, buf, len) > 0)
3201                 return;
-----


So looks like we just have to try what addresses commonly used supplicants are
using exactly.


Also hostapd seems to have a driver=wired option. I will try
whether I can move hostapd from an AP to some other point in the LAN via bridging
and will report back whether that works or not, or only works for some
operating systems / supplicants / EAP Types.

Regards, Linus

[0]: http://www.hsc.fr/ressources/articles/hakin9_wifi/hakin9_wifi_EN.pdf
-> Figure 9+10

PS: Opened a pad here, if someone wants to add/organize some observations,
links etc.: https://pad.freifunk.net/p/WPA-over-IP