wAP AC. Wireless station(s). VLANs?

RouterOS General
1

I’ve got a wAP AC. It has two radios and two ethernet ports.

I want to use it to do one main thing: Use a radio (or really, both) as a station-pseudobridge, and communicate whatever untagged traffic happens on that station-pseudobridge via a VLAN (200, say) via the ethernet ports. I have reasons for this*.

I’ve tried a lot of different methods. I’ve watched a lot of videos. I’ve read the manual and searched the forum. I went down a long and dark road with ChatGPT 4, and a darker road with ChatGPT 4o. I’ve done other simple stuff with VLANs before, including with RouterOS.

This doesn’t seem like it should be a hard problem to solve, but it isn’t clicking for me. The best I could do was to get traffic tagged as VLAN 200 to appear at the radio interfaces, but that’s not functional for me; the radio interfaces must only deal with untagged traffic because the devices that associate with that radio interface are very dumb.

Most of my attempts (far too many to list) behaved even worse.

(I also want to leave the default/blank VLAN traffic as-is, so I can do other stuff with it. And the VLAN 200-destined traffic and the default traffic should not ever see eachother.)

Any ideas, anyone? All I really want to do is tag/untag traffic from/to wlan1 and wlan2, and have that tagged traffic show on both ethernet ports, and also do the opposite.

*: OK, so the reasons. I want to use the wAP AC as a station-pseudobridge for a singular wifi hotspot or something, which I’ve done before (and it works for me), as a backup or alternative for when hardwired ethernet has failed us. I also want to use the wAP AC as a dual-band access point using virtual wireless interfaces (which I’ve done before, and it works for me). New to the scenario: I also want the layer-3 routing and NAT to happen on a different device entirely, and have this device connected with a singular Ethernet cable, which means using VLAN.

More context: This is for camping. Some friends and I do a very gear-centric kind of “camping” every year, with a load of stuff including a PA system in an environment where that is appreciated, and having good internet is key to making what we do actually-work, and that’s a lot of fun for people. I’ve done it all internal to the wAP AC before, including NAT, but that had limitations. I’ve got a hEX S with OpenWRT for the routing and packet mangling and QoS and whatnot, and I’d like to use that (because I prefer OpenWRT for these things at this end-user level, and the hEX S has a convenient pass-through port for passive PoE).

And sure, I could throw more/different gear at the problem, but the idea is to be running this stuff off-grid with a small solar power system to minimize use of the noisy generator and its fuel. Power efficiency, cabling simplicity, and configuration flexibility (including flexibility for things like physically broken ports without reconfiguration) are keys to having success here, to avoid having to dive in deep when something goes wrong instead of having fun. And I already own the wAP AC and the hEX S, so…

2

I would just make the wireless interface in station-pseudobridge mode a member port of a bridge with vlan-filtering=yes where the /interface bridge port row linking it to the bridge would say pvid=200. And the ethernet ports would be trunk (tagged) ports of the same bridge for VLAN 200:
/interface bridge port
add interface=ether2 bridge=bridge pvid=1
…
add interface=wlan1 bridge=bridge pvid=200
/interface bridge vlan
add bridge=bridge vlan-ids=200 tagged=ether2,… untagged=wlan1

What may be the actual problem is the behavior of the DHCP server behind the AP. If it properly assigns the IP configurations based on the client-id field inside the DHCP datagram, which is normally unique for each client, and doesn’t care about the source MAC address of the Ethernet frame inside which the DHCP datagram has arrived, everything is fine; if it takes the source mac address into account, things go wrong since all frames that arrive over the air from the wAP ac have the same MAC address.

3

Thank you for the response.

I erased my previous efforts, made a new bridge, and did exactly what you suggested (except with only one radio, and only one physical ethernet interface).

Afterwards, in packet dumps of the wlan1 interface, I see DHCP discover requests tagged with VLAN 200. I expect to instead see DHCP requests that aren’t tagged with VLAN at all.

Thus, it still does not work – nothing on wlan1 knows what to do with these VLAN-tagged DHCP requests, so nothing can ever reply to them.

What other ideas do you have?

Good eye catching on the potential complications of DHCP and MAC addresses with station-pseudobridge.

I don’t anticipate this will be a problem for me: The station-psuedobridge interface can only associate with one AP at one time, and on my little network there is only one device (the singular hEX S gateway device) that will be issuing DHCP requests via the station-psuedobridge interface.

(There’s a vaguely-related issue in this kind of application when using multiple station-psuedobridge interfaces bridged together, but I’ll add some logic somewhere so that only one station-psuedobridge is active at one time after I get this VLAN business sorted. Or maybe I’ll just avoid bridging those, and/or skip the idea of using multiple station-pseudobridge interfaces altogether. There’s a lot of ways to deal with this, but none of them matter until the VLAN problem is resolved.)

4

I expect the same as you, hence there must be a mistake in the actual configuration you’ve set. Please post an export of it. The wireless interface must not be on the tagged list on the row of /interface bridge vlan for vlan-ids=200, and vlan-filtering on the bridge must be set to yes, otherwise tagging/untagging does not take place at all and the bridge just forwards the frames without changing them (the name is slightly misleading, it should rather read vlan-aware than vlan-filtering).


Even for a single device, a mere station-pseudobridge means that the MAC address of the hEX will be substituted by the MAC address of the hAP ac on the way from the hAP ac to the AP. Since the hEX will be the only DHCP client, I’d suggest to use the station-pseudobridge**-clone** mode instead.


If you plan on using multiple hAP ac simultaneously anyway, what prevents you from using one as the main AP and having an all-Mikrotik setup where you could use a true wireless bridge that doesn’t overwrite MAC addresses, so the pseudobridge workaround would not be necessary?