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: <aAn6f9c-sck_pCTp@shredder>
Date: Thu, 24 Apr 2025 11:46:55 +0300
From: Ido Schimmel <idosch@...sch.org>
To: SIMON BABY <simonkbaby@...il.com>
Cc: netdev@...r.kernel.org
Subject: Re: query on EAPOL multicast packet with linux bridge interface

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@...a7g5ek-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@...a7g5ek-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.