*FIXED* hapAX3: why do devices coming via wifi1 appear "unknown" at the bridge, DHCP level etc?

I’m used to a hapAC2, but new to WiFi Wave2 on a hAPax3. I’m experiencing something which makes no sense and feels like a bug, but might just be my unfamiliarity. Both Wifi1 and Wifi2 are bound to the bridge, but the hosts table shows devices on Wifi1 as an unknown port, but Wifi2 is correct!

To eliminate configurations errors, I went back to basics, accepted the default configuration, but changed country to UK and followed the various firewall stages. Everything worked pretty much out the box. Wifi Settings are:

set [ find default-name=wifi1 ] channel.band=5ghz-ax .skip-dfs-channels=10min-cac .width=20/40/80mhz configuration.mode=ap .ssid=Made_UP_1 .country="United Kingdom" disabled=no security.authentication-types=wpa2-psk .passphrase=Made_UP_2
set [ find default-name=wifi2 ] channel.band=2ghz-ax .skip-dfs-channels=10min-cac .width=20mhz configuration.mode=ap .ssid=Made_UP_1 .country="United Kingdom" disabled=no security.authentication-types=wpa2-psk .passphrase=Made_UP_2

I notice after I’ve run both commands, when I check the configuration, WiFi1 has datapath.bridge=bridge automagically added, but WifI2 does not(!). I don’t know why this is different, but it’s repeatable:

 0 name="wifi1" mac-address=xx:xx:xx:xx:xx:xx arp-timeout=auto radio-mac=xx:xx:xx:xx:xx:xx 
   configuration.mode=ap .ssid="Made_UP_1" .country=United Kingdom 
   security.authentication-types=wpa2-psk .passphrase="Made_UP_2" 
   datapath.bridge=bridge 
   channel.band=5ghz-ax .width=20/40/80mhz .skip-dfs-channels=10min-cac 
 1 name="wifi2" mac-address=xx:xx:xx:xx:xx:xx arp-timeout=auto radio-mac=xx:xx:xx:xx:xx:xx 
   configuration.mode=ap .ssid="Made_UP_1" .country=United Kingdom 
   security.authentication-types=wpa2-psk .passphrase="Made_UP_2" 
   channel.band=2ghz-ax .width=20mhz .skip-dfs-channels=10min-cac

Here’s the bridge hosts table. All the the devices without an assigned interface are on Wifi1:

/interface/bridge/host> print
Flags: I - INVALID; D - DYNAMIC; L - LOCAL
Columns: MAC-ADDRESS, ON-INTERFACE, BRIDGE
 #     MAC-ADDRESS        ON-INTERFACE  BRIDGE
 0  D  xx:xx:xx:xx:xx:01  ether2        bridge
 1 ID  xx:xx:xx:xx:xx:02                bridge
 2  D  xx:xx:xx:xx:xx:03  ether3        bridge
 3 ID  xx:xx:xx:xx:xx:04                bridge
 4  D  xx:xx:xx:xx:xx:05  ether5        bridge
 5  DL xx:xx:xx:xx:xx:06  bridge        bridge
 6  DL xx:xx:xx:xx:xx:07  ether3        bridge
 7 IDL xx:xx:xx:xx:xx:08                bridge
 8  DL xx:xx:xx:xx:xx:09  wifi2         bridge
 9 ID  xx:xx:xx:xx:xx:10                bridge
10 ID  xx:xx:xx:xx:xx:11                bridge
11  D  xx:xx:xx:xx:xx:12  wifi2         bridge
12 ID  xx:xx:xx:xx:xx:13                bridge
13  D  xx:xx:xx:xx:xx:14  ether5        bridge

Has anyone else seen this? Is there a fix? It’s not just cosmetic, it makes firewall rules “interesting”

It’s naughty to reply to my post, but it looks like a bridge or Wifiwave2 bug (or perhaps a hardware fault on a batch), rather than something I’m doing wrong, because a refined search shows up other users with this issue all without a resolution.

Bridge Port unknownhttp://forum.mikrotik.com/t/bridge-port-unknown/169514/1
Wifiwave2 bridge interface unknown V7.7http://forum.mikrotik.com/t/wifiwave2-bridge-interface-unknown-v7-7/163639/1
wifiwave2 bridge interface “unknown” in hosts tablehttp://forum.mikrotik.com/t/wifiwave2-bridge-interface-unknown-in-hosts-table/167994/1

BTW my hAPax3 is on 7.11.2 and Winbox GUI and the terminal show the same thing:

Already contacted support about it with supout.rif ?
Because if nobody does, they might still not know about it.

And FWIW, I’m not seeing that problem. No unknowns on wifi clients on my AX3.

PS cleaned up other post. Let’s not cross-post too much in older threads or nobody can follow anymore.

[xyz@AX3-Living] > interface/bridge/host print
Flags: D - DYNAMIC; L - LOCAL
Columns: MAC-ADDRESS, VID, ON-INTERFACE, BRIDGE
 #    MAC-ADDRESS        VID  ON-INTERFACE  BRIDGE
 0 DL xx:A9:8A:vv:yy:7C       ether1        bridge
 1 DL 48:A9:8A:vv:yy:7D       bridge        bridge
 2 DL 48:A9:8A:vv:yy:82       wifi2         bridge
 3 DL 4A:A9:8A:vv:yy:82       wifi3         bridge
 4 DL 48:A9:8A:vv:yy:7C    1  ether1        bridge
 5 DL 48:A9:8A:vv:yy:7D    1  bridge        bridge
 6 D  zz:11:ww:v:yy:0F    2  ether1        bridge
 7 D  zz:E0:ww:vv:yy:B3    2  ether1        bridge
 8 DL 48:A9:8A:vv:yy:7C    2  ether1        bridge
 9 DL 48:A9:8A:vv:yy:7D    2  bridge        bridge
10 D  48:A9:8A:vv:yy:D0    2  ether1        bridge
11 D  48:A9:8A:vv:yy:C8    2  ether1        bridge
12 D  zz:E2:ww:vv:yy:76    2  ether1        bridge
13 D  zz:AB:ww:vv:yy:1D   10  wifi2         bridge
14 DL 48:A9:8A:vv:yy:7C   10  ether1        bridge
15 DL 48:A9:8A:vv:yy:7D   10  bridge        bridge
16 DL 48:A9:8A:vv:yy:82   10  wifi2         bridge
17 D  48:A9:8A:vv:yy:D0   10  ether1        bridge
18 D  zz:3A:88:vv:yy:92   20  wifi3         bridge
19 D  zz:39:ww:vv:yy:1C   20  wifi3         bridge
20 D  zz:39:ww:vv:yy:46   20  ether1        bridge
21 DL 48:A9:ww:vv:yy:7C   20  ether1        bridge
22 DL 48:A9:8A:vv:yy:7D   20  bridge        bridge
23 D  48:A9:8A:vv:yy:D0   20  ether1        bridge
24 DL 4A:A9:8A:vv:yy:82   20  wifi3         bridge
25 DL 48:A9:8A:vv:yy:7C   30  ether1        bridge
26 DL 48:A9:8A:vv:yy:7D   30  bridge        bridge
27 D  48:A9:8A:vv:yy:D0   30  ether1        bridge
[xyz@AX3-Living] >

Thanks holvoetn. I’ve not contacted support yet, because I started with the assumption it was my ignorance causing the issue. The fact you don’t experience this makes me think it is something obscure in my settings, so I’ll go back over them and start from default again. If I reproduce the effect I’ll log a support call. It might be (e.g.) a hardware issue.

What I do find strange is that using identical SET commands (adjusted obviously for the different channels) produces a different outcome - namely the “datapath.bridge=bridge” setting that appears in Wifi1 that’s not there in Wifi2. The GUI confirms there is a different outcome…

I’ve asked about this before but got no response so I just assumed I did something Dumb.

interface/bridge/host/print detail
Flags: X - disabled; I - invalid; D - dynamic; L - local; E - external 
 0   D   mac-address=18:D6:C7:XX:XX:XX interface=ether5 bridge=bridge on-interface=ether5 

 1   DL  mac-address=18:FD:74:XX:XX:XX interface=bridge bridge=bridge on-interface=bridge 

 2   DL  mac-address=18:FD:74:XX:XX:XX interface=ether5 bridge=bridge on-interface=ether5 

 3  IDL  mac-address=18:FD:74:XX:XX:XX interface=*FFFFFFFF bridge=bridge 

 4   DL  mac-address=18:FD:74:XX:XX:XX interface=wifi2 bridge=bridge on-interface=wifi2 

 5   D   mac-address=1C:1B:0D:XX:XX:XX interface=ether5 bridge=bridge on-interface=ether5 

 6   D   mac-address=1C:56:FE:XX:XX:XX interface=wifi2 bridge=bridge on-interface=wifi2 

 7  ID   mac-address=2A:1D:D0:XX:XX:XX interface=*FFFFFFFF bridge=bridge 

 8   D   mac-address=48:A9:8A:XX:XX:XX interface=ether5 bridge=bridge on-interface=ether5 

 9  ID   mac-address=60:6B:FFXX:XX:XX: interface=*FFFFFFFF bridge=bridge 

10   D   mac-address=9E:A9:FA:XX:XX:XX interface=ether5 bridge=bridge on-interface=ether5 

11  ID   mac-address=A0:80:69:XX:XX:XX interface=*FFFFFFFF bridge=bridge 

12   D   mac-address=AE:6B:97:XX:XX:XX interface=ether5 bridge=bridge on-interface=ether5 

13   D   mac-address=C0:4A:00:XX:XX:XX interface=wifi2 bridge=bridge on-interface=wifi2 

14   D   mac-address=DC:A6:32:XX:XX:XX interface=ether5 bridge=bridge on-interface=ether5

Hi ToTheFull - thanks this is helpful. I’d not run the print detail command, so had not seen the *FFFFFFFF identifier before, but now I’ve run it I get the same as you. I’m planning to reinstall via netinstall, build the simplest working config possible and check. If I’ve still the issue I’ll log a call, but even more likely I’ll just return the hAPax3 and live with the hAPac2, since the former has been a lot more bother than benefit.

> interface/bridge/host/print detail
Flags: X - disabled; I - invalid; D - dynamic; L - local; E - external 
 0   D   mac-address=xx:xx:xx:xx:xx:01 interface=ether2 bridge=bridge on-interface=ether2 

 1   D   mac-address=xx:xx:xx:xx:xx:02 interface=ether3 bridge=bridge on-interface=ether3 

 2  ID   mac-address=xx:xx:xx:xx:xx:03 interface=*FFFFFFFF bridge=bridge 

 3   D   mac-address=xx:xx:xx:xx:xx:04 interface=ether5 bridge=bridge on-interface=ether5 

 4   DL  mac-address=xx:xx:xx:xx:xx:05 interface=bridge bridge=bridge on-interface=bridge 

 5   DL  mac-address=xx:xx:xx:xx:xx:06 interface=ether3 bridge=bridge on-interface=ether3 

 6  IDL  mac-address=xx:xx:xx:xx:xx:07 interface=*FFFFFFFF bridge=bridge 

 7   DL  mac-address=xx:xx:xx:xx:xx:08 interface=wifi2 bridge=bridge on-interface=wifi2 

 8  ID   mac-address=xx:xx:xx:xx:xx:09 interface=*FFFFFFFF bridge=bridge 

 9   D   mac-address=xx:xx:xx:xx:xx:10 interface=wifi2 bridge=bridge on-interface=wifi2 

10  ID   mac-address=xx:xx:xx:xx:xx:11 interface=*FFFFFFFF bridge=bridge 

11  ID   mac-address=xx:xx:xx:xx:xx:12 interface=*FFFFFFFF bridge=bridge 

12   D   mac-address=xx:xx:xx:xx:xx:13 interface=ether5 bridge=bridge on-interface=ether5 

13  ID   mac-address=xx:xx:xx:xx:xx:14 interface=*FFFFFFFF bridge=bridge

Hi @holvoetn and @ToTheFull

I have used Netinstall to re-install the routeros and wifiwave2 packages and now the bridge tables and interfaces are correct. So it’s not a bug or hardware but perhaps something in the initial install or something I mistyped that caused the issue. When I did the first install, I renamed the bridge, but later changed it back. I don’t know if there is something strange in the way wifiwave2 talks to the routeros bridge code and expects the name to never change…

Thanks for letting us know thats very useful, would be nice to know what caused the problem but I’ll take the fix, but I see it more of an irritation so not that worried about it. Did you try an old config or just go straight for a fresh one ?

I accepted the default config and used Quick Set to set it up as a “home dual AP” (out of laziness). I then copy and pasted some useful stuff from the old config (such as DHCP leases). Finally I added a few firewall basics and logs. I was keen not to get too far away from default, since I can’t tell if it’s something I did wrong.

For my first installation (which caused the interface=*FFFFFFFF issue) I naively took a gamble on importing an ac2 export, but it didn’t work for the WiFi stuff because WifiWave2 is a different syntax. This might have set something wrong somewhere, but manually checking through a verbose export (of the ax3) showed nothing suspicious.

Has anything happened in this topic? My devices connected to wifi1 (5GHz) also show “Bridge port” unknown - wifi2 (2,4GHz) show correct.

I also have the same problem with AC2 and ROS 7.15.3 but with legacy wireless drivers, if it can be useful I use CAPSMAN

I am also using qcom+caps and have this problem every time after rebooting the router.