> Ah, vlan support can be tricky, hardware switch in tl-mr3220 for example
> > doesn't play properly. We should confirm the buffalo's do.
> >
> Mmm, I'm not sure if we are speaking about the same kind of VLAN. I'm not
> referring to layer1 (port switching) but to layer2 (VLAN tags in MAC
> header). So in theory the physical switch from the routers have nothing to
> do with it.
> To make it clear, we will have:
> - wlan0.1
> - wlan0.2
> - eth0.1
> - eth0.2
> The first protocol will run in .1 devices, the second in .2, and so on.
There are some devices which have troubles with VLAN on Ethernet, because VLAN
is also used internally for port switching - so if you have a "real" VLAN on
a specific port, in hardware you'd end up with VLAN in VLAN, which is not
supported by some hardware.
...
Pau said: But in such case you can disable the port switchuing and that's it, no?
Simon said: If the hardware is still usable then, yes. Have to test. :)
> The VLAN approach can be very interesting because we are layer-2 isolating
> the protocols.
> We have more control over what are we sending through the protocols. We can
> see, for instance, the amount of data sent by protocol X just looking the
> interface description.
> They are actual virtual interfaces, also from the kernel point of view!
> adhoc + vlan works fine. We are using it in qMp.