Asymetric VLAN behavior in a Ubiquity Unfi AP

I've been trying to debug VLAN handling on a Ubiquity Unfi AP. It looks like the AP is removing the 802.1q header on the way out, but not adding it back on the way in.

I can created a VLAN interface on the device (eth0.100). When I send a packet from the AP, an 802.1q packet shows up at the server. When I send a packet from the server, no packet shows up on eth0 or eth0.100. When I send an 802.1ad packet from the server (eth0.1.100), the packet arrives on eth0 as an 802.1q tagged packet and is delivered to eth0.100.

My best guess is the AR71xx is using the 802.1q header to determine the destination port (even though this AP only has one physical Ethernet port) so under the hood it's adding an 802.1q header which gets stripped off by the chip. I suspect that the chip is supposed to automatically add an 802.1q header on the way back in but is failing to do so. That would explain why the 802.1ad tagged packets are arriving at the interface as 802.1q.

eth0.100->eth0(802.1q vlan 100)-> NET ->eth0(802.1q vlan100)->eth0.100
eth0(No Packets) <- NET <-eth0(802.1q vlan100)<-eth0.100
eth0.100<-eth0(802.1q vlan 100)<- NET <-eth0(802.1ad vlan 1.100)<-eth0.100(802.1q vlan 100)<-eth0.1.100

Obviously, I could do some iptables mangle magic to add the extra 802.1q header, but this seems hackish and hard to maintain.

Any thoughts?

Don't have plain eth0 in any of your configs. Once you start tagging VLANs, tag everything.

If the device has a switch you have to configure the switch to actually get the packet from the CPU port to outside. Many of the models with a single 10/100 port still use the built in switch in the SoC (AR7241, AR9341 etc) because there is no way to bypass it. This switch hardware is limited to 16 VLANs. If you want VLAN numbers higher than 16 you need both option vlan and option vid in the configuration. Option vlan is the index in the switch's hardware table, it must be less than 16. Option vid is the tag number, it can be any 802.1q number.

1 Like