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] [day] [month] [year] [list]
Message-ID: <CAEFUPH1uvr1O1RNk6Ru953cs4bbXbudma7hyZyYnWdbkqD8b6Q@mail.gmail.com>
Date: Sun, 27 Apr 2025 23:55:41 -0700
From: SIMON BABY <simonkbaby@...il.com>
To: Vladimir Oltean <olteanv@...il.com>
Cc: Ido Schimmel <idosch@...sch.org>, netdev@...r.kernel.org
Subject: Re: query on EAPOL multicast packet with linux bridge interface

Hi,

Can someone please suggest if we need all the patches in the link
below for 802.1x to work on a  bridge interface with DSA  marvel ports
?
https://lore.kernel.org/lkml/20221022115505.nlnkfy2xrgrq74li@skbuf/T/

I also noticed that the iproute2 package in my kernel version does not
include the "locked" port option. Is that the cause for the EAPOL
packets forwarding issue on the bridge interface ?

Regards
Simon





On Thu, Apr 24, 2025 at 3:22 AM Vladimir Oltean <olteanv@...il.com> wrote:
>
> 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?

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ