Vlan problem with Dumb/Bridge AP on openwrt 19.07 & Meraki-MR33

Installing and Using OpenWrt Network and Wireless Configuration
1

No matter what I seem to do, if I set up vlans on this device and send packets out of those vlans, it appears as though they're going into the switch as vlan1, but tcpdump on the device show it leaving the correct vlan. The only way I can seem to use it in dumb-ap mode is to have it bridge to a single vlan based on the switch config, which is way less useful than I'd like. I need at least 3 separate networks and I don't really want to NAT them on all of the APs. At some point I'll be turning on roaming if I can make these work.

00:00.0 PCI bridge: Qualcomm Device 1001
01:00.0 Network controller: Qualcomm Atheros QCA9887 802.11ac Wireless Network Adapter

This has a IPQ4029 in it, which doesn't seem to have a switch, but it certainly may. swconfig doesn't list one.

Does anybody know how to get this to Do The Right Thing, or some good troubleshooting steps?

Thanks

2

If it doesn't have a switch then you can create subinterfaces on the eth0 interface and bridge them with the desired Wifi.
https://openwrt.org/docs/guide-user/network/vlan/switch_configuration#creating_driver-level_vlans
The last example of the lan with ifname eth0.106 is exactly what you need.

3

Yes, and I've done that.

Screen Shot 2020-02-22 at 7.26.34 PM
Screen Shot 2020-02-22 at 7.26.34 PM1070×746 59.6 KB

The packets show via tcpdump to be leaving on vlan20, but those packets arrive on a vlan10 interface instead of the vlan20 interface.

From the AP:

01:32:47.360570 de:16:80:97:10:fa > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 332: vlan 20, p 0, ethertype IPv4, 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from de:16:80:97:10:fa, length 286
01:32:47.362398 00:90:0b:38:eb:5c > de:16:80:97:10:fa, ethertype IPv4 (0x0800), length 397: 10.42.0.1.67 > 10.42.0.193.68: BOOTP/DHCP, Reply, length 355

From the router:

01:32:47.373821 de:16:80:97:10:fa > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 332: vlan 10, p 0, ethertype IPv4, 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from de:16:80:97:10:fa, length 286
01:32:47.374506 00:90:0b:38:eb:5c > de:16:80:97:10:fa, ethertype 802.1Q (0x8100), length 401: vlan 10, p 0, ethertype IPv4, 10.42.0.1.67 > 10.42.0.193.68: BOOTP/DHCP, Reply, length 355

They're plugged into 23 and 26 respectively on a cisco sg350 switch.

interface GigabitEthernet23
 description "office jack"
 switchport mode trunk
 switchport trunk native vlan 10
!
solie-csg350-r01#sh run int gi26
interface GigabitEthernet26
 description router-port1
 switchport mode trunk
!
4

I am not sure about the sg350, but any other cisco switch needs the switchport trunk allowed vlan x

5

Don't quote me on Cisco stuff but I think when trunk is set, all vlans are allowed by default. Then there are ways to deny some of them.

But if you set a native VLAN, those packets go in/out untagged. You don't want that, keep it a pure trunk.

6

The router is on gi26 and it's trunking just fine on all those vlans to my other openwrt AP.

Forgive the timestamp mismatches, the AP can't get an address and can't sync its time. I'm copying the tcpdump output from the serial console.

interface GigabitEthernet23
 description "office jack"
 switchport mode trunk
!
interface GigabitEthernet26
 description router-port1
 switchport mode trunk

From the AP for it's own DHCP request on vlan10 and a wireless device on vlan20:

03:06:01.723259 de:16:80:97:10:fa > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 332: vlan 20, p 0, ethertype IPv4, 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from de:16:80:97:10:fa, length 286
03:06:02.360074 e0:cb:bc:32:65:91 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 346: vlan 10, p 0, ethertype IPv4, 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from e0:cb:bc:32:65:91, length 300
03:06:04.838602 00:90:0b:38:eb:5c > de:16:80:97:10:fa, ethertype IPv4 (0x0800), length 397: 192.168.192.1.67 > 192.168.192.193.68: BOOTP/DHCP, Reply, length 355
03:06:04.839471 00:90:0b:38:eb:5c > e0:cb:bc:32:65:91, ethertype IPv4 (0x0800), length 403: 192.168.192.1.67 > 192.168.192.95.68: BOOTP/DHCP, Reply, length 361

From the router.

03:06:29.911419 de:16:80:97:10:fa > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 328: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from de:16:80:97:10:fa, length 286
03:06:30.548322 e0:cb:bc:32:65:91 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 342: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from e0:cb:bc:32:65:91, length 300
03:06:33.026086 00:90:0b:38:eb:5c > de:16:80:97:10:fa, ethertype IPv4 (0x0800), length 397: 192.168.192.1.67 > 192.168.192.193.68: BOOTP/DHCP, Reply, length 355
03:06:33.026841 00:90:0b:38:eb:5c > e0:cb:bc:32:65:91, ethertype IPv4 (0x0800), length 403: 192.168.192.1.67 > 192.168.192.95.68: BOOTP/DHCP, Reply, length 361

It's like there's something there that's flattening everything down to vlan1? The lengths of the DHCP requests are 4 bytes longer in the AP than in the router, so the vlan header is definitely getting stripped.

7

Then connect the Meraki that has problem on the port of the other AP and verify if the problem lies on the switch or the Openwrt.

8

It seems to lie in the openwrt on this unit.

I just upgraded with openwrt-19.07.1-ipq40xx-generic-meraki_mr33-squashfs-sysupgrade.bin as well, to check to see if it'd somehow gotten fixed already. I didn't see anything directly related in the changelog however.

9

Turns out the hidden switch in this unit is definitely mangling the packets down to vlan1.