netdev - Re: VLAN/bridge "compression" in wifi (was: Re: [PATCH 3/8] qtnfmac: implement AP

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] [day] [month] [year] [list]

Message-ID: <1504766720.23905.25.camel@sipsolutions.net>
Date:   Thu, 07 Sep 2017 08:45:20 +0200
From:   Johannes Berg <johannes@...solutions.net>
To:     Sergey Matyukevich <sergey.matyukevich.os@...ntenna.com>
Cc:     linux-wireless@...r.kernel.org, netdev <netdev@...r.kernel.org>,
        Igor Mitsyanko <igor.mitsyanko.os@...ntenna.com>,
        Avinash Patil <avinashp@...ntenna.com>
Subject: Re: VLAN/bridge "compression" in wifi (was: Re: [PATCH 3/8]
 qtnfmac: implement AP_VLAN iftype support)

Hi,

> > To clarify, I think what you - conceptually - want is the following
> > topology:
> > 
> >         +--- eth0.1  ---  br.1  ---  wlan0.1
> >         |
> > eth0 ---+--- eth0.2  ---  br.2  ---  wlan0.2
> >         |
> >         +--- eth0.3  ---  br.3  ---  wlan0.3
[...]
> That's right. In fact, hostapd is able to create this kind of network
> bridge infrastructure automatically when it is built
> with CONFIG_FULL_DYNAMIC_VLAN option enabled.

Cool, I was unaware of the exact functionality of this build-time
option. :)

> > Now, you seem to want to compress this to
> > 
> >                   +---  wlan0.1
> >                   |
> > eth0  ---  br  ---+---  wlan0.2
> >                   |
> >                   +---  wlan0.3

[...]

> Exactly. And yes, the only purpose of this 'non-conventional' mode
> was to have 802.1Q acceleration on the ethernet port.

Right. You can still have acceleration in the top picture by placing
the feature into the Ethernet hardware, so that tagging/untagging
doesn't have to touch the packet data but just touches (skb) metadata.
But obviously that's something that happens on the other side and you
don't have control over it.

Anyway, I'm happy we cleared up what was going on and also that you
decided to leave it for now and work with the regular Linux topology
model.

Thanks,
johannes