query on EAPOL multicast packet with linux bridge interface

query on EAPOL multicast packet with linux bridge interface

[SIMON BABY]

Hello,

I have a difficulty with making EAPOL packet forwarding with the Linux
bridge interface.

 I have configured the group_fwd_mask parameter with the below value.

 echo 8 > /sys/class/net/br0/bridge/group_fwd_mask

I still could not see the EAPOL packets being forwarded  from the
linux bridge interface . However I can see the EAPOL packets are
forwarded if I use it as a regular interface.

Do we have any more settings?


Regards
Simon

Re: query on EAPOL multicast packet with linux bridge interface

[Ido Schimmel]

On Tue, Apr 22, 2025 at 06:42:58PM -0700, SIMON BABY wrote:
> Hello,
> 
> I have a difficulty with making EAPOL packet forwarding with the Linux
> bridge interface.
> 
>  I have configured the group_fwd_mask parameter with the below value.
> 
>  echo 8 > /sys/class/net/br0/bridge/group_fwd_mask
> 
> I still could not see the EAPOL packets being forwarded  from the
> linux bridge interface . However I can see the EAPOL packets are
> forwarded if I use it as a regular interface.
> 
> Do we have any more settings?

What do you mean by "linux bridge interface"? The bridge device itself
or a bridge port? Also, what is "regular interface"?

The following script [1] seems to work fine for me:

EAPOL packets on h2 without group_fwd_mask: 0
EAPOL packets on h2 with group_fwd_mask: 1

Can you adjust it to show the problem you are referring to?

Thanks

[1]
#!/bin/bash

# Setup
#
for ns in h1 h2 br; do
	ip netns add $ns
	ip -n $ns link set dev lo up
done

ip -n h1 link add name veth0 type veth peer name veth1 netns br
ip -n h2 link add name veth2 type veth peer name veth3 netns br

ip -n h1 link set dev veth0 up
ip -n h2 link set dev veth2 up

ip -n br link add name br0 up type bridge
ip -n br link set dev veth1 up master br0
ip -n br link set dev veth3 up master br0

tc -n h2 qdisc add dev veth2 clsact
tc -n h2 filter add dev veth2 ingress pref 1 proto all \
	flower dst_mac 01:80:c2:00:00:03 action pass

# Without group_fwd_mask
#
ip netns exec h1 mausezahn veth0 -a own -b 01:80:c2:00:00:03 -c 1 -q
sleep 1
pkt=$(tc -n h2 -s -j -p filter show dev veth2 ingress | \
	jq ".[] | select(.options.handle == 1) | .options.actions[0].stats.packets")

echo "EAPOL packets on h2 without group_fwd_mask: $pkt"

# With group_fwd_mask
#
ip -n br link set dev br0 type bridge group_fwd_mask 0x0008
ip netns exec h1 mausezahn veth0 -a own -b 01:80:c2:00:00:03 -c 1 -q
sleep 1
pkt=$(tc -n h2 -s -j -p filter show dev veth2 ingress | \
	jq ".[] | select(.options.handle == 1) | .options.actions[0].stats.packets")
echo "EAPOL packets on h2 with group_fwd_mask: $pkt"

# Cleanup
#
for ns in h1 h2 br; do
	ip netns del $ns
done

Re: query on EAPOL multicast packet with linux bridge interface

[SIMON BABY]

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@sama7g5ek-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



Regards
Simon


On Wed, Apr 23, 2025 at 4:42 AM Ido Schimmel <idosch@idosch.org> wrote:
>
> On Tue, Apr 22, 2025 at 06:42:58PM -0700, SIMON BABY wrote:
> > Hello,
> >
> > I have a difficulty with making EAPOL packet forwarding with the Linux
> > bridge interface.
> >
> >  I have configured the group_fwd_mask parameter with the below value.
> >
> >  echo 8 > /sys/class/net/br0/bridge/group_fwd_mask
> >
> > I still could not see the EAPOL packets being forwarded  from the
> > linux bridge interface . However I can see the EAPOL packets are
> > forwarded if I use it as a regular interface.
> >
> > Do we have any more settings?
>
> What do you mean by "linux bridge interface"? The bridge device itself
> or a bridge port? Also, what is "regular interface"?
>
> The following script [1] seems to work fine for me:
>
> EAPOL packets on h2 without group_fwd_mask: 0
> EAPOL packets on h2 with group_fwd_mask: 1
>
> Can you adjust it to show the problem you are referring to?
>
> Thanks
>
> [1]
> #!/bin/bash
>
> # Setup
> #
> for ns in h1 h2 br; do
>         ip netns add $ns
>         ip -n $ns link set dev lo up
> done
>
> ip -n h1 link add name veth0 type veth peer name veth1 netns br
> ip -n h2 link add name veth2 type veth peer name veth3 netns br
>
> ip -n h1 link set dev veth0 up
> ip -n h2 link set dev veth2 up
>
> ip -n br link add name br0 up type bridge
> ip -n br link set dev veth1 up master br0
> ip -n br link set dev veth3 up master br0
>
> tc -n h2 qdisc add dev veth2 clsact
> tc -n h2 filter add dev veth2 ingress pref 1 proto all \
>         flower dst_mac 01:80:c2:00:00:03 action pass
>
> # Without group_fwd_mask
> #
> ip netns exec h1 mausezahn veth0 -a own -b 01:80:c2:00:00:03 -c 1 -q
> sleep 1
> pkt=$(tc -n h2 -s -j -p filter show dev veth2 ingress | \
>         jq ".[] | select(.options.handle == 1) | .options.actions[0].stats.packets")
>
> echo "EAPOL packets on h2 without group_fwd_mask: $pkt"
>
> # With group_fwd_mask
> #
> ip -n br link set dev br0 type bridge group_fwd_mask 0x0008
> ip netns exec h1 mausezahn veth0 -a own -b 01:80:c2:00:00:03 -c 1 -q
> sleep 1
> pkt=$(tc -n h2 -s -j -p filter show dev veth2 ingress | \
>         jq ".[] | select(.options.handle == 1) | .options.actions[0].stats.packets")
> echo "EAPOL packets on h2 with group_fwd_mask: $pkt"
>
> # Cleanup
> #
> for ns in h1 h2 br; do
>         ip netns del $ns
> done

Re: query on EAPOL multicast packet with linux bridge interface

[Ido Schimmel]

(Please avoid top posting)

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.

Do you see the EAPOL packets when running tcpdump on 'lan1' and 'br0'?
Does the result change if you pass '-p' to tcpdump?

> 
> 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@sama7g5ek-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

I have zero experience with hostapd, but I assume it opens a packet
socket on the specified interface to receive the EAPOL packets. When
listening on 'br0' you should see the EAPOL packets with a VLAN tag
which could be a problem for hostapd. When you told it to listen on
'lan1' it received the EAPOL packets without a VLAN. I would try to
specify 'br0.10' and see if it helps. hostapd should observe the packets
without a VLAN tag in this case.

> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>passing br0 as interface to
> hostapd.
> driver=wired
> 
> 
> 
> Regards
> Simon

Re: query on EAPOL multicast packet with linux bridge interface

[SIMON BABY]

On Wed, Apr 23, 2025 at 8:51 AM Ido Schimmel <idosch@idosch.org> wrote:
>
> (Please avoid top posting)
>
> 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.
>
> Do you see the EAPOL packets when running tcpdump on 'lan1' and 'br0'?
> Does the result change if you pass '-p' to tcpdump?
>
> >
> > 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@sama7g5ek-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
>
> I have zero experience with hostapd, but I assume it opens a packet
> socket on the specified interface to receive the EAPOL packets. When
> listening on 'br0' you should see the EAPOL packets with a VLAN tag
> which could be a problem for hostapd. When you told it to listen on
> 'lan1' it received the EAPOL packets without a VLAN. I would try to
> specify 'br0.10' and see if it helps. hostapd should observe the packets
> without a VLAN tag in this case.
>
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>passing br0 as interface to
> > hostapd.
> > driver=wired
> >
> >
> >
> > Regards
> > Simon


Hello Ido,

I tried with br0.10 and still did not see EAPOL packets are
forwarding. Below are the tcpdump logs with lan5 and br0.10.


root@sama7g5ek-tdy-sd:~# tcpdump -i br0.10 ether proto 0x888e -p
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on br0.10, link-type EN10MB (Ethernet), snapshot length 262144 bytes

br0: port 5(lan5) entered disabled state
mv88e6085 e2800000.ethernet-ffffffff:10 lan5: Link is Down
mv88e6085 e2800000.ethernet-ffffffff:10 lan5: Link is Up -
100Mbps/Full - flow control rx/tx
br0: port 5(lan5) entered blocking state
br0: port 5(lan5) entered forwarding state
18:15:59.243997 EAP packet (0) v2, len 5
18:16:02.245922 EAP packet (0) v2, len 5
18:16:08.252660 EAP packet (0) v2, len 5



root@sama7g5ek-tdy-sd:~# tcpdump -i lan5 ether proto 0x888e -p
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on lan5, link-type EN10MB (Ethernet), snapshot length 262144 bytes


br0: port 5(lan5) entered disabled state
mv88e6085 e2800000.ethernet-ffffffff:10 lan5: Link is Down
mv88e6085 e2800000.ethernet-ffffffff:10 lan5: Link is Up -
100Mbps/Full - flow control rx/tx
br0: port 5(lan5) entered blocking state
br0: port 5(lan5) entered forwarding state
18:18:00.558929 EAPOL start (1) v1, len 0
18:18:00.566422 EAP packet (0) v2, len 5
18:18:00.580678 EAP packet (0) v1, len 28
18:18:00.688667 EAP packet (0) v2, len 6
18:18:00.711016 EAP packet (0) v1, len 172
18:18:00.866300 EAP packet (0) v2, len 1004
18:18:00.867310 EAP packet (0) v1, len 6
18:18:00.871946 EAP packet (0) v2, len 1004
18:18:00.872795 EAP packet (0) v1, len 6
18:18:00.877155 EAP packet (0) v2, len 1004
18:18:00.878087 EAP packet (0) v1, len 6
18:18:00.882673 EAP packet (0) v2, len 866
18:18:00.893136 EAP packet (0) v1, len 1492
18:18:00.898185 EAP packet (0) v2, len 6
18:18:00.899091 EAP packet (0) v1, len 903
18:18:01.912476 EAP packet (0) v2, len 4


Regards
Simon

Re: query on EAPOL multicast packet with linux bridge interface

[Ido Schimmel]

On Wed, Apr 23, 2025 at 10:59:35PM -0700, SIMON BABY wrote:
> I tried with br0.10 and still did not see EAPOL packets are
> forwarding. Below are the tcpdump logs with lan5 and br0.10.
> 
> 
> root@sama7g5ek-tdy-sd:~# tcpdump -i br0.10 ether proto 0x888e -p
> tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
> listening on br0.10, link-type EN10MB (Ethernet), snapshot length 262144 bytes
> 
> br0: port 5(lan5) entered disabled state
> mv88e6085 e2800000.ethernet-ffffffff:10 lan5: Link is Down
> mv88e6085 e2800000.ethernet-ffffffff:10 lan5: Link is Up -
> 100Mbps/Full - flow control rx/tx
> br0: port 5(lan5) entered blocking state
> br0: port 5(lan5) entered forwarding state
> 18:15:59.243997 EAP packet (0) v2, len 5
> 18:16:02.245922 EAP packet (0) v2, len 5
> 18:16:08.252660 EAP packet (0) v2, len 5
> 
> 
> 
> root@sama7g5ek-tdy-sd:~# tcpdump -i lan5 ether proto 0x888e -p
> tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
> listening on lan5, link-type EN10MB (Ethernet), snapshot length 262144 bytes
> 
> 
> br0: port 5(lan5) entered disabled state
> mv88e6085 e2800000.ethernet-ffffffff:10 lan5: Link is Down
> mv88e6085 e2800000.ethernet-ffffffff:10 lan5: Link is Up -
> 100Mbps/Full - flow control rx/tx
> br0: port 5(lan5) entered blocking state
> br0: port 5(lan5) entered forwarding state
> 18:18:00.558929 EAPOL start (1) v1, len 0
> 18:18:00.566422 EAP packet (0) v2, len 5
> 18:18:00.580678 EAP packet (0) v1, len 28
> 18:18:00.688667 EAP packet (0) v2, len 6
> 18:18:00.711016 EAP packet (0) v1, len 172
> 18:18:00.866300 EAP packet (0) v2, len 1004
> 18:18:00.867310 EAP packet (0) v1, len 6
> 18:18:00.871946 EAP packet (0) v2, len 1004
> 18:18:00.872795 EAP packet (0) v1, len 6
> 18:18:00.877155 EAP packet (0) v2, len 1004
> 18:18:00.878087 EAP packet (0) v1, len 6
> 18:18:00.882673 EAP packet (0) v2, len 866
> 18:18:00.893136 EAP packet (0) v1, len 1492
> 18:18:00.898185 EAP packet (0) v2, len 6
> 18:18:00.899091 EAP packet (0) v1, len 903
> 18:18:01.912476 EAP packet (0) v2, len 4

The captures were taken at different times, but it seems that only a few
packets reach br0.10 compared to lan5. You can put the bridge in
promiscuous mode to make sure that everything that is received by lan5
is also received by the bridge interface:

ip link set dev br0 promisc on

If this helps, you will need to look at the destination address of the
packets and the bridge FDB ("bridge fdb show") to understand why the
packets don't reach the bridge interface.

Re: query on EAPOL multicast packet with linux bridge interface

[Vladimir Oltean]

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@sama7g5ek-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?

Re: query on EAPOL multicast packet with linux bridge interface

[SIMON BABY]

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@gmail.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@sama7g5ek-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?

Re: query on EAPOL multicast packet with linux bridge interface

[SIMON BABY]

On Sun, Apr 27, 2025 at 11:55 PM SIMON BABY <simonkbaby@gmail.com> wrote:
>
> 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@gmail.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@sama7g5ek-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?

Hello,

I have some improvement with my 802.1x testing.
I have enabled the "locked port" feature and it stopped all traffic
except "EAPOL".
I am using hostapd_cli tool for monitoring the 802.1x traffic.
 I see that after the authentication success, the fdb is added with a
new STA mac address. Is it done automatically  with the latest 802.1x
package?
I see below logs with hostapd_cli tool.
root@sama7g5ek-tdy-sd:~# hostapd_cli -i br0.50

<3>CTRL-EVENT-EAP-STARTED 00:0e:c6:88:75:e7

<3>CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=1

<3>CTRL-EVENT-EAP-SUCCESS2 00:0e:c6:88:75:e7

<3>AP-STA-CONNECTED 00:0e:c6:88:75:e7

root@sama7g5ek-tdy-sd:~# bridge fdb show | grep 00:0e:c6:88:75:e7

00:0e:c6:88:75:e7 dev lan1 vlan 50 master br0
                          >>>>>>>>>>>>>>>> got this entry in the FDB.

root@sama7g5ek-tdy-sd:~#

 Once I make the interface down, I don’t see any event with
hostapd_cli and the fdb entry got removed automatically.

I thought I would see the event AP-STA-DISCONNECTED with hostapd_cli.
Can you please suggest if I am supposed to see AP-STA-DISCONNECTED
when the interface goes down after the successful authentication ?

 Do I need to do anything from the user space for the FDB entries when
we see the events AP-STA-CONNECTED and AP-STA-DISCONNECTED ?

 Regards
Simon