netdev - Re: [PATCH net-next,v2 01/24] net: resolve forwarding path from virtual netdevice and HW destination address

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: <20210324072711.2835969-1-dqfext@gmail.com>
Date:   Wed, 24 Mar 2021 15:27:11 +0800
From:   DENG Qingfang <dqfext@...il.com>
To:     Pablo Neira Ayuso <pablo@...filter.org>
Cc:     netfilter-devel@...r.kernel.org,
        "David S. Miller" <davem@...emloft.net>, netdev@...r.kernel.org,
        Jakub Kicinski <kuba@...nel.org>, Andrew Lunn <andrew@...n.ch>,
        Vladimir Oltean <olteanv@...il.com>,
        Tobias Waldekranz <tobias@...dekranz.com>,
        Felix Fietkau <nbd@....name>
Subject: Re: [PATCH net-next,v2 01/24] net: resolve forwarding path from virtual netdevice and HW destination address

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@...filter.org>