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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 24 Mar 2021 20:15:52 +0100
From:   Pablo Neira Ayuso <pablo@...filter.org>
To:     DENG Qingfang <dqfext@...il.com>
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

Hi,

On Thu, Mar 25, 2021 at 12:07:02AM +0800, DENG Qingfang wrote:
> On Wed, Mar 24, 2021 at 11:03:54AM +0100, Pablo Neira Ayuso wrote:
> > 
> > For this scenario specifically, it should be possible extend the
> > existing flowtable netlink API to allow hostapd to flush entries in
> > the flowtable for the client changing AP.
> 
> The APs are external, are we going to install hostapd to them, and
> let them inform the gateway? They may not even run Linux.

This falls within the scenario that Jakub described already. These
limitations are described in patch 24/24.

> Roaming can happen in a wired LAN too, see Vladimir's commit message
> 90dc8fd36078 ("net: bridge: notify switchdev of disappearance of old FDB entry upon migration").
> I think the fastpath should monitor roaming (called "FDB migration" in
> that commit) events, and update/flush the flowtable accordingly.

Why does this need to happen in this batch? Is there anything that
makes you think dealing with roaming cannot be done incrementally on
top of this series?

This patchset is already useful for a good number of use-cases
regardless the roaming scenario you describe.

FDB hardware offload was added years ago and the roaming mitigation
that you refer to was added just a few months ago.