Observed the problem while repeating https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240106#c28 A minimal script to repeat: ``` #!/bin/sh epa=$( ifconfig epair create ) epb=${epa%a}b lagg=$( ifconfig lagg create laggport $epa ) ifconfig $epa up ifconfig $lagg up j0=$( jail -ic vnet persist ) ifconfig $epb vnet $j0 jexec $j0 ifconfig $epb inet 192.168.1.2/24 tmp=$( mktemp ) nohup tcpdump -nvi $lagg --direction in > $tmp & jexec $j0 ping -t5 -c3 192.168.1.1 kill $! jail -R $j0 ifconfig $lagg destroy ifconfig $epa destroy cat $tmp rm $tmp ``` The output: ============== PING 192.168.1.1 (192.168.1.1): 56 data bytes --- 192.168.1.1 ping statistics --- 3 packets transmitted, 0 packets received, 100.0% packet loss tcpdump: listening on lagg0, link-type EN10MB (Ethernet), capture size 262144 bytes 0 packets captured 0 packets received by filter 0 packets dropped by kernel
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=5f3d0399e903573e9648385ea6585e54af4d573f commit 5f3d0399e903573e9648385ea6585e54af4d573f Author: Zhenlei Huang <zlei@FreeBSD.org> AuthorDate: 2023-04-02 17:01:51 +0000 Commit: Zhenlei Huang <zlei@FreeBSD.org> CommitDate: 2023-04-02 17:01:51 +0000 lagg(4): Tap traffic after protocol processing Different lagg protocols have different means and policies to process incoming traffic. For example, for failover protocol, by default received traffic is only accepted when they are received through the active port. For lacp protocol, LACP control messages are tapped off, also traffic will be dropped if they are received through the port which is not in collecting state or is not joined to the active aggregator. It confuses if user dump and see inbound traffic on lagg(4) interfaces but they are actually silently dropped and not passed into the net stack. Tap traffic after protocol processing so that user will have consistent view of the inbound traffic, meanwhile mbuf is set with correct receiving interface and bpf(4) will diagnose the right direction of inbound packets. PR: 270417 Reviewed by: melifaro (previous version) MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D39225 sys/net/if_lagg.c | 24 ++++++++++++++---------- 1 file changed, 14 insertions(+), 10 deletions(-)
A commit in branch stable/13 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=ed44ba413c544c0aa05b3456bc430c816a0e3168 commit ed44ba413c544c0aa05b3456bc430c816a0e3168 Author: Zhenlei Huang <zlei@FreeBSD.org> AuthorDate: 2023-04-02 17:01:51 +0000 Commit: Zhenlei Huang <zlei@FreeBSD.org> CommitDate: 2023-04-10 04:15:04 +0000 lagg(4): Tap traffic after protocol processing Different lagg protocols have different means and policies to process incoming traffic. For example, for failover protocol, by default received traffic is only accepted when they are received through the active port. For lacp protocol, LACP control messages are tapped off, also traffic will be dropped if they are received through the port which is not in collecting state or is not joined to the active aggregator. It confuses if user dump and see inbound traffic on lagg(4) interfaces but they are actually silently dropped and not passed into the net stack. Tap traffic after protocol processing so that user will have consistent view of the inbound traffic, meanwhile mbuf is set with correct receiving interface and bpf(4) will diagnose the right direction of inbound packets. PR: 270417 Reviewed by: melifaro (previous version) MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D39225 (cherry picked from commit 5f3d0399e903573e9648385ea6585e54af4d573f) sys/net/if_lagg.c | 24 ++++++++++++++---------- 1 file changed, 14 insertions(+), 10 deletions(-)
A commit in branch stable/12 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=11412682562925064591f0abaae63e2a9ff767e5 commit 11412682562925064591f0abaae63e2a9ff767e5 Author: Zhenlei Huang <zlei@FreeBSD.org> AuthorDate: 2023-04-02 17:01:51 +0000 Commit: Zhenlei Huang <zlei@FreeBSD.org> CommitDate: 2023-04-10 05:06:22 +0000 lagg(4): Tap traffic after protocol processing Different lagg protocols have different means and policies to process incoming traffic. For example, for failover protocol, by default received traffic is only accepted when they are received through the active port. For lacp protocol, LACP control messages are tapped off, also traffic will be dropped if they are received through the port which is not in collecting state or is not joined to the active aggregator. It confuses if user dump and see inbound traffic on lagg(4) interfaces but they are actually silently dropped and not passed into the net stack. Tap traffic after protocol processing so that user will have consistent view of the inbound traffic, meanwhile mbuf is set with correct receiving interface and bpf(4) will diagnose the right direction of inbound packets. PR: 270417 Reviewed by: melifaro (previous version) MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D39225 (cherry picked from commit 5f3d0399e903573e9648385ea6585e54af4d573f) (cherry picked from commit ed44ba413c544c0aa05b3456bc430c816a0e3168) sys/net/if_lagg.c | 24 ++++++++++++++---------- 1 file changed, 14 insertions(+), 10 deletions(-)