On Wed, Mar 24, 2021 at 02:30:32AM +0100, Pablo Neira Ayuso wrote: > This patch adds dev_fill_forward_path() which resolves the path to reach > the real netdevice from the IP forwarding side. This function takes as > input the netdevice and the destination hardware address and it walks > down the devices calling .ndo_fill_forward_path() for each device until > the real device is found. > > For instance, assuming the following topology: > > IP forwarding > / \ > br0 eth0 > / \ > eth1 eth2 > . > . > . > ethX > ab:cd:ef:ab:cd:ef > > where eth1 and eth2 are bridge ports and eth0 provides WAN connectivity. > ethX is the interface in another box which is connected to the eth1 > bridge port. > > For packets going through IP forwarding to br0 whose destination MAC > address is ab:cd:ef:ab:cd:ef, dev_fill_forward_path() provides the > following path: > > br0 -> eth1 > > .ndo_fill_forward_path for br0 looks up at the FDB for the bridge port > from the destination MAC address to get the bridge port eth1. > > This information allows to create a fast path that bypasses the classic > bridge and IP forwarding paths, so packets go directly from the bridge > port eth1 to eth0 (wan interface) and vice versa. > > fast path > .------------------------. > / \ > | IP forwarding | > | / \ \/ > | br0 eth0 > . / \ > -> eth1 eth2 > . > . > . > ethX > ab:cd:ef:ab:cd:ef Have you tested if roaming breaks existing TCP/UDP connections? For example, eth1 and eth2 are connected to 2 WiFi APs, and the client ab:cd:ef:ab:cd:ef roams between these APs. > > Signed-off-by: Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx>
