dynamic slave interfaces are never auto-added to the datapath bridge — is manual bridge-port-by-name the intended mechanism?

RouterOS Wireless Networking
1

Setup:

  • Controller: L009UiGS, RouterOS 7.23.2 (issue also present on 7.23.1)
  • CAPs: hAP ax² (wifi-qcom), hAP ax³ (wifi-qcom), hAP ax S ×2 (wifi-mediatek), hAP ax lite
  • Provisioning: two rules (2ghz-ax / 5ghz-ax), master + 2-3 slave configurations, action=create-dynamic-enabled (also tested create-enabled — no difference in behavior, slaves are always dynamic)
  • All configurations use a datapath with bridge=bridge-LAN
  • CAP-side: local forwarding ("traffic processing on CAP")

Behavior:

  1. On provision, slave virtual interfaces are created as dynamic (D flag) on the CAP, but they are not added to the bridge specified in the datapath. /interface bridge port print where dynamic on the CAP is empty. Master interfaces work only because they are static defconf bridge ports.
  2. Result: slave SSIDs beacon, clients associate, but no traffic passes.
  3. Workaround that works: manually adding static bridge ports by the current name of the dynamic interface (/interface bridge port add bridge=bridge-LAN interface=wifiXX). This succeeds and traffic flows.
  4. Fragility: dynamic interface names use an ever-increasing counter (observed wifi14 → 18 → 23 → 28 → 35 across re-provisions in one day). Every re-provision renames the slaves, the static bridge-port entries become orphaned (shown as *XX inactive), and the SSIDs silently stop passing traffic until the bridge ports are re-added with the new names.
  5. Note for anyone else debugging this: on DFS channels the slave interfaces only appear ~60-90s after provisioning (after the master completes CAC), which can make it look like 5GHz slaves are not being created at all.
  6. /interface/wifi find does not return dynamic interfaces, so scripted repair has to go through the generic /interface menu.

Questions:

  1. Is the CAP expected to automatically add dynamic slave interfaces to the datapath bridge in local-forwarding mode? If yes, under what conditions does this fail?
  2. Is manually adding bridge ports by name the intended mechanism? If so, is there a supported way to make it survive re-provisioning, given that interface names change every time?
  3. Should action=create-enabled produce static (non-dynamic) virtual interfaces on the CAP? In my case slaves are always dynamic regardless of the action setting, confirmed after forced re-provision.

Config exports (provisioning, datapath, configurations, bridge) available on request. supout.rif available.

2

Hi,

Lets start with this: Forum rules - #5 by gigabyte091

3

Why are you mark as a "fragility" and "complain" on the changing interface names if the configuration says so?

What AI was used to "compose" your post?

4

Re 3.: setting ```action=create-enabled``` will create dynamic interfaces. However, they will retain their properties across reboots (i.e. name, bridge association, etc.). Mind that that's true for reboot, not for "reprovision". In general, reprovision is pretty destructive operation which only happens when one is configuring CAPsMAN ... whatever CAPsMAN does automatically, it's not reprovisioning.

I'm using create-enabled in my wifi-qcom-ac installation where I'm using VLANs (wifi-qcom-ac doesn't do anything about VLANs). And there one has to add respective wifi interface(s) to bridge on CAP devices (and set appropriate VLAN-related properties, such as PVID). As I wrote, unless I (manually!) reprovision CAP, those settings survive reboots, ROS upgrades and what not.

Due to my use of mixed environment (both wifi-qcom and wifi-qcom-ac), I'm not sure exactly what is answer to your question #1 ... but judging from discussions on this forum, one has to have some basic datapath set on CAP devices (pointing at local bridge). Then CAP will use that datapath to dynamically add slave interfaces (with appropriately set VID according to CAPsMAN settings applicable to this particular slave interface).