[OpenWrt-Devel] [LEDE-DEV] [PATCH] kernel: drop patch hacking bridge to accept EAP only locally

Etienne Champetier champetier.etienne at gmail.com
Fri Jul 26 03:05:35 EDT 2019


Hi Felix,

Le mar. 13 mars 2018 à 00:41, Felix Fietkau <nbd at nbd.name> a écrit :
>
> On 2018-03-12 14:56, Rafał Miłecki wrote:
> > From: Rafał Miłecki <rafal at milecki.pl>
> >
> > EAPOL frames have wireless interface address specified as destination.
> > That makes "dst->is_local" condition true for them and results in
> > upstream code processing frames the same way as OpenWrt/LEDE's hack.
> >
> > This code could be needed years ago but currently it seems redundant.
> >
> > Signed-off-by: Rafał Miłecki <rafal at milecki.pl>
> I think I remember now why I added this years ago. The failure case
> involved a client roaming between multiple access points.
> I think in some of these cases, the bridge considered the client MAC to
> be reachable via LAN instead of the WLAN interface, because that's where
> the packets were coming from earlier.

I'm reviving this old thread because I was trying to let EAP frame go
through a bridge
with 2 wired connection (setting group_fwd_mask), and this old hack blocks me

If the client just sent an EAP frame via WLAN, why wouldn't the bridge learn
that the address is now WLAN side and send response back on the WLAN ?
And why is it an issue just for EAP ?
Say the client is roaming for A to B, maybe the problem was that the client was
sending EAP frame with A mac address as destination instead of B ?

In any case I need a way to disable this hack, would you accept a
patch to drop it
(and maybe reintroduce a bug) or would you prefer a patch to make it
configurable ?

Etienne

>
> - Felix

_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


More information about the openwrt-devel mailing list