bridge(4) learning

[Lloyd Parkes]

Hi all,
I’ve started reworking the bridge(4) code a bit in order to do a better job of handling multicast and broadcast packets. It’s not a big rework, it’s mostly limited to bridge_input(). While looking at bridge_input(), I noticed the following code:

if (bif->bif_flags & IFBIF_LEARNING)
bridge_rtupdate(sc, eh->ether_shost, ifp, 0, IFBAF_DYNAMIC);

It fairly obviously does the learning needed to actually do the bridging. It’s only run when we successfully unicast a packet through the bridge. i.e. we only learn source host addresses from packets when we already know where the destination host is.

Surely we should (or could) be learning source host address from all incoming packets?

Cheers,
Lloyd
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Lloyd Parkes]

Post by Lloyd Parkes
Hi all,
if (bif->bif_flags & IFBIF_LEARNING)
bridge_rtupdate(sc, eh->ether_shost, ifp, 0, IFBAF_DYNAMIC);
It fairly obviously does the learning needed to actually do the bridging. It’s only run when we successfully unicast a packet through the bridge. i.e. we only learn source host addresses from packets when we already know where the destination host is.
Surely we should (or could) be learning source host address from all incoming packets?

And I’ve found the answer to my question. What matters is the state the bridge port is in, blocking vs. learning vs. listening vs. forwarding. This probably also explains the amount of repeated code in bridge_input().

Cheers,
Lloyd


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de