Wifi-qcom local config: DHCP OFFER never reaches wireless client on second SSID/VLAN — "offered" never "bound"

RouterOS Wireless Networking
1

Hardware / Software:

  • Controller/Router: RB5009UG+S+, RouterOS 7.23.1 (stable), arm64

  • AP: wAP ax (wAPG-5HaxD2HaxD), RouterOS 7.23.1, wifi-qcom package, arm

  • Switch: Ubiquiti EdgeSwitch ES-8-150W (trunk configured and verified)

Goal: Two SSIDs via VLANs — "Home" (VLAN 10) and "IoT" (VLAN 20). Local forwarding. AP uplink is a tagged trunk.

Symptom: Clients associate fine (authorized, WPA3), but never get a DHCP lease on VLAN 20 (and, after switching the AP to local config with vlan-filtering, VLAN 10 is affected too). Clients fall back to 169.254.x.x.

What I have verified with /tool torch end-to-end:

  • Client DHCP Discover + Request are correctly tagged (VLAN 20) and travel all the way to the RB5009 — visible on the AP's wifi interface, on the AP's ether1 (trunk, tagged 20), and on the router's vlan20 interface.

  • RB5009 DHCP server receives the request. Log shows dhcpXX sending offer ... network only. Lease status becomes offered, never bound.

  • The DHCP OFFER (udp 67→68) never appears on the return path — not on the router's egress port, not on the AP's ether1, not on the AP's wireless interface. Only the client's own outbound traffic and MNDP discovery are visible on VLAN 20.

  • The client MAC is learned in the bridge FDB on VLAN 20 / correct port (/interface bridge host print confirms it).

What I have already ruled out:

  • Not a CAPsMAN slave-interface issue — problem persists with fully local AP config (no CAPsMAN).

  • Not the switch/path — identical behavior whether the AP is on the router's port directly or via the EdgeSwitch trunk.

  • Not 5 GHz/DFS — same result on 2.4 GHz.

  • Bridge VLAN table verified correct on both router and AP (tagged on uplink, untagged on the wifi interfaces, correct PVIDs).

  • add-arp=yes on the DHCP server — no effect.

  • No firewall filter rules present (empty filter table).

  • Already on latest stable (7.23.1), so not an update-fixable regression AFAIK.

AP local config (relevant parts):

/interface bridge set bridge vlan-filtering=yes
/interface bridge vlan
  add bridge=bridge vlan-ids=10 tagged=bridge,ether1 untagged=wifi1,wifi2
  add bridge=bridge vlan-ids=20 tagged=ether1 untagged=wifi-iot-24,wifi-iot-5
/interface bridge port
  set [find interface=wifi1] pvid=10
  set [find interface=wifi2] pvid=10
  # wifi-iot-24 / wifi-iot-5 pvid=20

(Master interfaces = Home/VLAN10, static slave interfaces = IoT/VLAN20.)

My question:
The OFFER is generated by the server (sending offer ... network only) but never egresses toward the client. Since the client MAC is in the FDB on the right VLAN/port, why would the unicast OFFER be dropped on the return path only for the wireless-side VLAN? Is network only (unicast to a not-yet-assigned IP) the culprit here, and is there a known workaround for wifi-qcom local-forwarding setups where the DHCP OFFER doesn't reach the wireless client on a tagged VLAN?

Any pointers appreciated — happy to post full /export and torch captures.

2

Since you didn't bother posting the DHCP config, you do have a DHCP server mapped to that VLAN, right?

3

Yes, DHCP server is correctly mapped to the VLAN. Server side works fine, the offer is generated; it just never reaches the wireless client. For comparison, VLAN10 (master SSID) completes offer→request→ack and binds normally on the same setup. Only the second SSID/VLAN fails.

Note: I've since switched the AP from CAPsMAN to a fully local wifi config to rule out CAPsMAN slave handling, same result. The RB5009 still has CAPsMAN config present but it's inactive for this test.

DHCP server (RB5009):

/ip pool add name=pool20 ranges=192.168.20.100-192.168.20.200
/ip dhcp-server add name=dhcp20 interface=vlan20 address-pool=pool20 lease-time=1d
/ip dhcp-server network add address=192.168.20.0/24 gateway=192.168.20.1 dns-server=192.168.20.1

DHCP debug log, VLAN20 (fails):

dhcp20 offering lease 192.168.20.200 for <client-mac> without success   (repeats endlessly)

DHCP debug log, VLAN10 (works, same client type):

dhcp10 sending offer ... to 192.168.10.198:68 (<client-mac>) (network only)
dhcp10 received request ... from <client-mac>
dhcp10 assigned 192.168.10.198 for <client-mac>
dhcp10 sending ack ...

So on VLAN20 the client's Discover+Request reach the server (verified via /tool torch on the router's vlan20 interface), the server logs the offer, but no OFFER is ever seen egressing back toward the client on any interface along the return path. Client falls back to 169.254.x.

AP config (local, hide-sensitive):

/interface bridge add name=bridge vlan-filtering=yes
/interface vlan add interface=bridge name=vlan10 vlan-id=10
/interface wifi datapath
add bridge=bridge name=dp-home vlan-id=10
add bridge=bridge name=dp-iot vlan-id=20
/interface wifi configuration
add datapath=dp-home name=cfg-home security=sec-home ssid=Home
add datapath=dp-iot name=cfg-iot security=sec-iot ssid=IoT
/interface wifi
set [find default-name=wifi1] configuration=cfg-home configuration.manager=local disabled=no
set [find default-name=wifi2] configuration=cfg-home configuration.manager=local disabled=no
add configuration=cfg-iot configuration.manager=local master-interface=wifi2 name=wifi-iot-5 disabled=no
add configuration=cfg-iot configuration.manager=local master-interface=wifi1 name=wifi-iot-24 disabled=no
/interface bridge port
add bridge=bridge interface=ether1
add bridge=bridge interface=wifi1 pvid=10
add bridge=bridge interface=wifi2 pvid=10
add bridge=bridge interface=wifi-iot-5 pvid=20
/interface bridge vlan
add bridge=bridge tagged=bridge,ether1 untagged=wifi1,wifi2 vlan-ids=10
add bridge=bridge tagged=ether1 untagged=wifi-iot-24,wifi-iot-5 vlan-ids=20

One thing I noticed in my own export: wifi-iot-24 is not listed as a static bridge port (only wifi-iot-5 is), yet both are referenced as untagged members of VLAN20. wifi-iot-24 only appears as a dynamic bridge port (it's a slave of wifi1), and it can't be added statically ("device already added as bridge port") nor have its PVID changed ("can not change dynamic port"). Could this asymmetry be the cause, i.e. does a slave wifi interface that's only a dynamic bridge port not get its VLAN20 return traffic delivered correctly? Persists across reboot.

Full /export hide-sensitive from both devices available on request.

4

SOLVED :white_check_mark:

Got it working, thanks to everyone here and especially to the thread by @akliouev: "7.18 CAPSMAN v2 VLAN provisioning problem to WAP ax" — same hardware, same symptom, and the fix there solved it for me too.

Root cause: I was fighting the wifi-qcom driver by trying to force the slave (IoT) interfaces into the bridge statically with manual PVIDs. That's exactly the wrong approach. With wifi-qcom + CAPsMAN local forwarding, the slave interfaces must be created and added to the bridge dynamically by CAPsMAN — any static slaves or manual wifi bridge-port entries break the VLAN tagging on the slave SSID.

What fixed it (key points):

On the CAP, the datapath must reference the local bridge and nothing else (no vlan-id on the CAP datapath), and the cap must set slaves-datapath:

/interface bridge add name=bridge vlan-filtering=yes
/interface bridge port add bridge=bridge interface=ether1
/interface bridge vlan
add bridge=bridge tagged=bridge,ether1 vlan-ids=10
add bridge=bridge tagged=bridge,ether1 vlan-ids=20
/interface wifi datapath add name=capdp bridge=bridge
/interface wifi cap set enabled=yes discovery-interfaces=vlan10 caps-man-addresses=192.168.10.1 slaves-datapath=capdp
/interface wifi
set [find default-name=wifi1] configuration.manager=capsman datapath=capdp disabled=no
set [find default-name=wifi2] configuration.manager=capsman datapath=capdp disabled=no

The slaves-datapath=capdp was the missing piece I never had.

VLAN IDs come from the controller side (datapaths attached to the CAPsMAN configurations), not from the CAP datapath.

Result: CAPsMAN now adds all wifi interfaces to the CAP bridge dynamically with the correct PVIDs:

# INTERFACE  PVID
  ether1      1
D wifi1      10   (Home master)
D wifi2      10   (Home master)
D wifi3      20   (IoT slave)   ← correct now!
D wifi4      20   (IoT slave)

DHCP OFFER now reaches clients on both VLANs, survives reboots, and a second wAP ax provisioned identically in minutes.

No static slaves, no manual wifi bridge ports — let CAPsMAN do it. Thanks again @akliouev :folded_hands: