netdev - Re: query on EAPOL multicast packet with linux bridge interface

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250424102240.dxyk5uf6t6xfnd2k@skbuf>
Date: Thu, 24 Apr 2025 13:22:40 +0300
From: Vladimir Oltean <olteanv@...il.com>
To: SIMON BABY <simonkbaby@...il.com>
Cc: Ido Schimmel <idosch@...sch.org>, netdev@...r.kernel.org
Subject: Re: query on EAPOL multicast packet with linux bridge interface

Hello Simon,

On Wed, Apr 23, 2025 at 06:26:40AM -0700, SIMON BABY wrote:
> Thank you Ido.
> 
> Here is the details of my setup:
> 
> I have a microchip CPU connected to an 11 port marvell 88E6390 switch.
> I am using the marvel  linux DSA driver  so that all the switch ports
> (lan1, lan2, lan3 etc) are part of the linux kernel.
> 
> I am using hostapd as an authenticator.
> 
> An 802.1x client device is connected to port lan1 and binds this port
> (lan1) to hostapd daemon, I can see EAPOL packets are being forwarded
> to a radius server.
> 
> I have created a bridge with vlan filtering with below commands and
> bind the bridge (br0) with hostapd daemon. Now EAPOL packets are not
> forwarded.
> 
> ip link add name br0 type bridge vlan_filtering 1
> ip link set dev lan1 master br0
> ip link set dev lan2 master br0
> bridge vlan add dev lan1 vid 10 pvid untagged
> bridge vlan add dev lan2 vid 10 pvid untagged
> ip link set dev br0 up
> ip link set dev lan1 up
> ip link set dev lan2 up
> ip link add link br0 name br0.10 type vlan id 10
> ip link set dev br0.10 up
> ip addr add 192.168.2.1/24 dev br0.10
> bridge vlan add vid 10 dev br0 self
> 
> bridge vlan show
> port              vlan-id
> lan1              10 PVID Egress Untagged
> lan2              10 PVID Egress Untagged
> br0                10
> 
> echo 8 > /sys/class/net/br0/bridge/group_fwd_mask
> cat /sys/class/net/br0/bridge/group_fwd_mask
> 0x8
> 
> root@...a7g5ek-tdy-sd:~# cat /etc/hostapd.conf
> ##### hostapd configuration file ##############################################
> # Empty lines and lines starting with # are ignored
> 
> # Example configuration file for wired authenticator. See hostapd.conf for
> # more details.
> interface=br0
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>passing br0 as interface to
> hostapd.
> driver=wired

Could you please clarify what is the expected data path of EAPOL packets?
(I also have no experience with hostapd)
Is the forwarding to the RADIUS server something that is handled by
hostapd, through an IP socket, or is the kernel responsible for doing
that automatically somehow? Is the RADIUS server IP accessible? Does
hostapd log the reception of EAPOL packets? I'm trying to understand
whether the problem is that hostapd is not receiving or not sending
packets.

I think the hostapd.conf "interface" option can be overridden by '-i'
command line options. I'm wondering if there's any chance that is going
on, and hostapd is not listening on br0.

I don't understand the need for group_fwd_mask. In my image, you don't
need software forwarding of EAPOL packets among bridge ports (which that
option provides). You only need EAPOL frames to be received by a packet
socket, and routed using IP to the RADIUS server, correct? Can't you
just specify multiple '-i' options to hostapd, for the individual bridge
ports like lan1, lan2, and skip the bridge data path processing for
these packets, as happens by default when no group_fwd_mask is specified?

Are you also using some other bridge port options, like 'locked', which
you are not showing in the steps above?