Hi Alessandro,

to use VLANs in batman-adv, you currently have to explicitly set up VLAN 
interfaces, as it was already explained. You can not just listen to bat0 and 
expected VLAN tagged frames to go through.

This is a limitation of the current code, which basically exists since we 
integrated VLANs into batman-adv. There were some ideas to register VLANs on 
the fly inside of batman-adv, but the current implementation relies on the 
setup of VLANs on top of bat0 provided by the system.

If you want to use those VLANs, you have to set up VLAN interfaces for each 
VLAN ID you want to use. This can get a bit messy if there are many VLANs, but 
it works. You can't just bridge bat0 to something else and expect VLAN tagged 
traffic to come out of bat0.

I can't say anything about OVS and to which extent bridges can be skipped, but 
you'll create VLAN devices in that case too.

We're open to patches to add VLANs on the fly without requiring explicit VLAN 
interfaces (maybe by snooping, similar to TT or BLA). I've also run into this 
scenario a couple of times, but the pain level wasn't high enough to change it 
yet. ;)

Cheers,
       Simon

On Friday, September 11, 2020 4:42:52 PM CEST Alessandro Bolletta wrote:
> Hi Sven,
> 
> I'm sorry for being not so clear in my statements. You can read my
> last "refactored" mail, which is easier to understand:
> 
> Should I must only rely to the related 802.1q interface (eg. bat0.1)
> or can I receive the whole traffic (untagged and tagged) from the
> plain bat0 interface, just listening for the incoming traffic on it?
> 
> If the answer is the first choice, is it possible to have an approach
> where I can receive coming from bat0 leveraging on a single interface
> anyway? Could a linux bridge br0 on the top of bat0 interface make it
> possible?
> 
> For example, if I connect an openvswitch port, configured as trunk port, to
> a linux bridge br0 that enslaves bat0, could I expect to see the whole
> traffic inside the batman-adv mesh network (so I mean, both tagged and
> untagged traffic) also "flowing" inside the other OvS switch ports that are
> attached to that vlans?
> Moreover, just out of curiosity, is there also another known way to
> get rid of the linux bridge br0 in order to get this done (attaching
> the bat0 directly to the OvS switch, for example)?
> 
> Il giorno ven 11 set 2020 alle ore 16:02 Sven Eckelmann
> 
> <sven@narfation.org> ha scritto:
> > On Friday, 11 September 2020 15:03:13 CEST Alessandro Bolletta wrote:
> > > I see. Ok for transmission purposes, but what if I have to receive a
> > > tagged
> > > frame?
> > 
> > It should not have been send to the other node when there is no TT entry
> > for this mac + VID from the receiver.
> > 
> > > Should I only rely to the 8021q interface (eg. bat0.1) or receive the
> > > whole
> > > traffic (untagged and tagged) from the plain bat0 interface?
> > 
> > Hm?
> > 
> > > If this is not feasible, is it possible to handle in someway this?
> > 
> > Hm?
> > 
> > > A linux
> > > bridge on the top of bat0 interface could make it possible?
> > 
> > No, the bridge must also enable the vlan for this bat0 interface.
> > 
> > See also
> > https://www.open-mesh.org/projects/batman-adv/wiki/Faq#BATMAN-Advanced-VLA
> > N-questions
> > 
> > Maybe Antonio wants to add more things to this discussion.
> > 
> > Kind regards,
> > 
> >         Sven