Help testing patch that may help diagnosing the PR 240106

Hi,

I write here so that the original PR 240106 is not polluted.

Can you please test the attached patch with bridge / lagg setup?

For long:

In https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240106#c28 you encountered
problem and I said:

> The IF_BRIDGE(4) seems to hide some thing to protect itself get confused.
Actually IF_BRIDGE(4) has a learning mode. You can `man ifconfig` and refer the
`Bridge Interface Parameters` section.

By default the learning mode of all bridge members is on, and the bridge will
insert or update an entry to its (internal) forwarding table. When unicast packets
come to the bridge member, the bridge will check if it is for itself, if not then
the packets will be forwarded to one bridge member if a forwarding entry is found.
While the magic is, if the bridge member to be forwarded is the receiving one, then
the packets are silently discarded.

That's perfect fine, but will be hard to diagnose if user has wrong network setup,
bridge loops e.g., or some other ones set duplicated ether address for their nic,
or some bad guys / virus / trojans send spoofed packets on the wire. Those are common
and I think it will be good if IF_BRIDGE(4) can emit logs so that the symptoms will
be obvious and it will be easy to diagnose.

> If you can confirm, then please config you switch properly. The two ports cc0 and cc1 connected should be in same link aggregation group.

If two ports (on physical switch), say 1 and 2, are not in same link aggregation group,
then packets (typically broadcast ones) received on 1 will be forwarded to 2, and
the lagg interface will be bounce-backed (from port 2) the packets it send (to port 1).
If the lagg happenly be the member of IF_BRIDGE(4), then the bridge will update
its forwarding entry as it learn mac address from lagg interface.

Here is a simple diagram, the arrow shows the flow of ARP request from epair0a.

11:22:33:44:55:66         [1]                  -> cc0 ->  port 1 -> 
       epair0a -> epair0b -> bridge0 -> lagg0                        physical-switch <-> host0
                                     <-        <- cc1 <-  port 2 <-  
                                     [2]                          

On [1] bridge0 will learn MAC 11:22:33:44:55:66 on port member epair0b and add entry,
after [2] it will learn same MAC on port member lagg0 and update the entry. Then
subsequent ARP reply (to 11:22:33:44:55:66, epair0a i.e.) sent from host0 reach bridge0
via lagg0.

Apparently bridge0 will dropped the ARP reply as it believes 11:22:33:44:55:66 (epair0a) is
within segment of lagg0.

> I'll see if I can teach IF_BRIDGE(4) to emit warnings in case it get ARP request packet sent from it self.

Attached patch will enable IF_BRIDGE(4) to emit logs about MAC address port flapping.
Various hardware vendors have similar facilities.


Best regards,
Zhenlei