hAP ax S - Strange networking behavior

[XQV]

Hi Community,

Being relatively new to the mikrotik world, I have trouble understanding if I got some faulty device or am just too stupid for a good configuration.

There seems to be sth. strange going on with one of my hAP ax S access points:

• The wifi interface names of the default config seem to be different (wifi1 = 5GHz, wifi2 = 2GHz).
• Some clients refuse to connect to that particular device, or prefer APs with much weaker signal. Logs show a “handshake timeout”

In total I got three hAP ax S, and wonder if it is normal that sometimes default interface names are different, or if I got some type of faulty device. Two out of three work fine with the config, one of them is a troublemaker…

Any opinion/ direction about what may be wrong is much appreciated.

Thanks already,
Chris

Situation:

• **Setup: **
  RB5009 with CAPsMAN, 3 hAP ax S as access points, one per floor (reinforced concrete walls in my house), wired connection to router.
• RouterOS/ Firmware version: V7.22.2
• **Configuration: **
  Same config on all APs (reset to factory, removed default config, used the same script for configuration), wifi part below
• Unexpected behavior:
  • Some clients completely refuse to connect to the AP in question (2VAX),
  • other clients do connect when nothing else is around, but prefer APs with much lower signal,
  • other clients drop after some time and need reconnect, including password.
• What I tried so far for remediation without success:
  • Rule out interference
    Switched off all but one interface 2VAX (2GHz), the most stubborn clients don’t connect at all, others will connect. As soon as another (weaker) AP from a different floor comes up, connection is transferred
  • Switch off FT
  • Switch off WPA3
    This gave trouble in combination with FT
  • reduce TX power
  • manually configure channels, to prevent overlap
  • Reinstall from scratch

logs, config, details,…

Wireless debug log from CAPsMAN (2G_2VAX gives trouble, 2G_1VAX connects well, client stubbornly refuses to connect, even if there is no other signal around)
2026-04-29 22:29:55 wireless,debug AA:AA:AA:AA:AA:AA@2G_2VAX(SSID) associated, signal strength -60
2026-04-29 22:29:56 wireless,debug AA:AA:AA:AA:AA:AA@2G_2VAX(SSID) reauthenticating
2026-04-29 22:29:56 wireless,debug AA:AA:AA:AA:AA:AA@2G_2VAX(SSID) associated, but was associated already
2026-04-29 22:29:58 wireless,debug AA:AA:AA:AA:AA:AA@2G_1VAX(SSID) associated, signal strength -73
2026-04-29 22:29:58 wireless,info AA:AA:AA:AA:AA:AA@2G_1VAX(SSID) connected, signal strength -73
2026-04-29 22:30:03 wireless,debug AA:AA:AA:AA:AA:AA@2G_2VAX(SSID) disassociated, key handshake timeout, signal strength -59

/interface/wifi/radio/print detail (on 2VAX)
Flags: L - LOCAL
0 L radio-mac=AA:AA:AA:AA:AA:AA tx-chains=0,1 rx-chains=0,1 bands=2ghz-g:20mhz,2ghz-n:20mhz,20/40mhz,2ghz-ax:20mhz,20/40mhz ciphers=tkip,ccmp,gcmp,ccmp-256,gcmp-256,cmac,gmac,cmac-256,gmac-256 min-antenna-gain=6
countries=all 2g-channels=2412,2417,2422,2427,2432,2437,2442,2447,2452,2457,2462,2467,2472 max-vlans=4095 max-interfaces=16 max-station-interfaces=19 max-peers=120 hw-type="mt7916"
hw-caps=sniffer,qos-classifier-dscp,channel-switch,6 interface=wifi2

1 L radio-mac=BB:BB:BB:BB:BB:BB tx-chains=0,1,2 rx-chains=0,1,2 bands=5ghz-a:20mhz,5ghz-n:20mhz,20/40mhz,5ghz-ac:20mhz,20/40mhz,20/40/80mhz,20/40/80/160mhz,5ghz-ax:20mhz,20/40mhz,20/40/80mhz,20/40/80/160mhz
ciphers=tkip,ccmp,gcmp,ccmp-256,gcmp-256,cmac,gmac,cmac-256,gmac-256 min-antenna-gain=6 countries=all
5g-channels=5180,5200,5220,5240,5260,5280,5300,5320,5340,5360,5380,5400,5420,5440,5460,5480,5500,5520,5540,5560,5580,5600,5620,5640,5660,5680,5700,5720,5745,5765,5785,5805,5825,5845,5865,5885,4920,4940,4960,
4980
max-vlans=4095 max-interfaces=16 max-station-interfaces=19 max-peers=120 hw-type="mt7916" hw-caps=sniffer,qos-classifier-dscp,channel-switch,6 interface=wifi1

/interface/wifi/configuration/print detail (on CAPsMAN)
name="2G" country=Netherlands installation=indoor ssid="SSID" mode=ap station-roaming=no
security.authentication-types=wpa2-psk .encryption=ccmp,gcmp,ccmp-256,gcmp-256 .wps=disable
datapath=datapath_vlan20
datapath.bridge=bridge .client-isolation=yes .vlan-id=20
channel=2GHZ::AUTO
channel.frequency=2412,2437,2462 .band=2ghz-ax .width=20mhz

[jaclaz]

You should post the FULL configurations of two of those AP (one of the two working ones and the one that creates the issue), instructions here:

Forum rules

Hello and welcome to the Mikrotik forum For all new users that uses RouterOS for the first time and have some questions regarding their config here is short tutorial on how to access RouterOS configuration using "WinBox" and how to export their configuration and posting it properly in their topic. So after you unpack your new device and connect it to the power supply you need to connect it to the PC. Be careful when connecting because to access your new router you need to use one of…

At first sight, from the snippets you posted, you have a more complex configuration than usual with a number of settings that are not commonly explicitly set, but from a print output cannot really say.
Since you are using CAPSMAN, there could be some kind of conflict between settings on the CAPSMAN and on the specific CAP, so you should post the /wifi export of the CAPSMAN device.

Is the problem the same on 2.4 GHz radio and on 5 GHz one?

What is the "story" of the three hAP Ax S (like they came together at the same time, have they been repeatedly updated, etc.)?

It may happen that some update procedures (from version x to version z) have created differences when compared to a similar device upgraded differently (from version x to version y and later to version z), but they are not very common.

You can still netinstall, but it is far from easy-peasy, so if it can be resolved by modifying something in config it would be easier/better.

The "associated, but was associated already" has been reported in the past but you should be already running newer/fixed version of Ros, if I recall correctly the issues were in some beta versions of 7.18 or 7.19.

[XQV]

Hi @jaclaz,

Thank you for looking at this.

Attached below the info you were asking for. There is indeed a bit more ongoing, wrt. wireless; I use the ACL to force clients into a certain VLAN. I indicated in the comments which devices are giving trouble.

Re history: I ordered the devices from different stores. 2VAX was offered as “tested and undamaged return”, a discount that may be biting me now. 1VAX was purchased as regular “new” device.

Maybe interesting as well: Factory firmware on 2VAX was 7.20.6, 1VAX was 7.20.4.

Thanks again for looking at this,
Chris

260429_1VAX.rsc (4.6 KB)

CAPsMAN.rsc (4.8 KB)

260429_2VAX.rsc (4.6 KB)

[jaclaz]

The configuration of 1VAX and 2VAX are identical (there is only a difference in system leds).
I don't think this latter is relevant though it is strange that the interfaces have a different order.
What is "suspect" is that the OID (from the radio-mac) of the two working ones (1VAX and BGAZ) is 04:F4:1C while the OID of the 2VAX is D0:EA:11.
While both are "routerboard" or "Mikrotik":
https://maclookup.app/search/result?mac=d0ea11
https://maclookup.app/search/result?mac=04f41c
they point definitely to two different batches (and probably also board revisions), which would explain the different factory firmware.

Nothing of the above should be meaningful (for the issue you are having) BUT the “tested and undamaged return” nature of the 2VAX might well mean that the device has been used (and abused) in tests (or whatever) and it wouldn't be the first time that something remains "sticky" after upgrades/downgrades/whatever.

It could also be that there is something "default" in 7.20.4 that has been changed in 7.20.6 and that is "carried over" notwithstanding the ROS update.

In any case a "used" device should be netinstalled anywyay (to make sure that there are no leftover, accidental or malicious).

I see that you have everything on 7.22.2 (good).

What I would do is trying to netinstall 7.22.2 to the 2VAX and then manually re-create the configuration from the export (do not use a backup as it may carry over the whatever is causing the problem).

BTW check that firmware is "aligned" to ROS version on all devices.

Even if I cannot find anything "wrong", it does seem to me a configuration issue (as opposed to a hardware fault) so it is IMHO worth it to attempt the netinstall, even if it is a PITA.

Are you a Windows or a Linux kind of guy?

JFYI, the only "surely working" netinstall approach is this one (seemingly complex, but doable and avoiding the usual complications when attempting direct use of an OS):
https://tangentsoft.com/mikrotik/wiki?name=Run%20NetInstall%20in%20a%20VM

[XQV]

Hi @jaclaz,

Netinstall did do the trick. Device names are back to normal (wifi1 = 2GHz), and clients stick to where they are supposed to, no more “handshake timeout” in the logs.

The procedure below worked for me, I leave it here for reference and others. It omits the virtual machine approach.

Thank you very much for your guidance, the result speaks for itself.

Regards,
Chris

My procedure on an XUbuntu machine:

Prepare computer (=netinstall server)

• Download netinstall, wifi-mediatek, routeros from mikrotik website (all the way down on the device home page)
• unzip netinstall-cli into separate folder
• copy packages in the same folder
• copy my own install script in the same folder (260429_2VAX.rsc)

Prepare mikrotik:

/system/device-mode/update routerboard=yes

press reset button to reboot

Prepare internet connection on computer:

• Set fixed IP and route on my ethernet device
• (for me: 192.168.88.10, netmask 255.255.255.0, gateway 192.168.88.1)
• Set autoconnect priority to 20.
  When rebooting the mikrotik the connection goes down briefly, and other connection may take over from the set values
• Write down device name (for me enp37s0)

Connect computer ethernet to port1 of mikrotik with cable.

Start netinstall server

• I ran the following command in terminal window

  sudo ./netinstall-cli -r -s 260429_2VAX.rsc -i enp37s0 -a 192.168.88.1 routeros-7.22.2-arm.npk wifi-mediatek-7.22.2-arm.npk

• Enter sudo password, then the server will show:
  "waiting for link-up", and "waiting for RouterBoard"1

Restart mikrotik in netinstall (etherboot) mode:

• /system/routerboard/settings/set boot-device=try-ethernet-once-then-nand
• /system/reboot

This kicked off the netinstall, and ran the custom configuration script to load my own configuration, ethernet and wireless settings. LEDs on hAP ax S need to be set manually after reset, it seems to be a strange quirk for this device. (@jaclaz, you gave guidance there last time, as well)

References used:

• mikrotik netinstall manual
• mikrotik device-mode manual
• mikrotik router-board manual
• Mikrotik solutions website linked by you earlier (manual install section)

[jaclaz]

Very good.

Experiences with netinstall vary so much (from people like you that got it fine at first or second try to people desperately trying it on different PC's with different OSes, with a dumb switch in the middle, etc., and still failing) that I suspect there is some kind of magic involved in its use.

I think we can flag "Xubuntu" as "compatible" with netinstall, good to know.

The curiosity to know what (the heck) the issue was remains, but if it works, it works.