Hello all, I’m trying to revive my cAP ac without luck and hope that someone can help.
Long story short, since I didn’t remember how to regain access to a cAP ac device, I decided to factory reset it (5 sec push on RESET button at boot).
Device reset, no access to it. Going quick to plan B: netinstall. Found and downloaded latest Netinstall and latest Router OS for ARM (7.13.1), procedure successfully ended (“Installation finished successfully” displayed on Netinstall application). Powered off, powered on, nothing happens. For some seconds different leds are blinking on a well determined sequence (meaning that something happens during boot process), but suddenly everything stop. Only Eth1 and Power LED lit, no IP address on new cAP ac, no way to access from any interface (no wifi SSIDs broadcasted, no response at dhcp requests on Eth1 or Eth2).
Going further, opened Wireshark on Eth1 and the only data sent from the cAP ac are LLDP packets sent every few seconds:
This should mean (beyond the fact that netinstall is telling that each procedure ends correctly) that the various firmwares are correctly loaded, but… why cAP ac is not working as expected?
Am I missing something? Having a serial boot console may help, but I’d like not to open the device only for this scope and hope that someone could point me out where I’m wrong…
Yes!!! Using MAC address on Winbox I’m able again to connect and manage the device!
That was as simple as undocumented! It’s weird that, on official Mikrotik guide on netinstall (https://wiki.mikrotik.com/wiki/Manual:Netinstall), they explain, step by step, how to assign IP address to an interface in Windows OS (!!!) and totally miss out this VERY CRUCIAL detail on how to access device after RouterOS upgrade…
Love Mikrotik devices for the granularity of configuration and features, but the documentation is far from exhaustive…
Thank you anyway, I’ll try to remember this behavior in case of future need
I celebrated victory too soon. Now I’m able to connect, via MAC address, to the cAP ac but many menus on Winbox are missing and simply pasting latest working configuration from CLI produces various errors and doesn’t restore the original configuration. Also noticed that resetting again device to factory defaults will prevent again the access to the device, even using MAC address in Winbox. In this situation the only way to proceed is to netinstall again latest routerOS image and connect, again, using eth1 MAC address on Winbox.
I’m facing this weird situation: the routerOS installation is ok (successfully checked on System->Packages) but it misses interfaces and parameters that I’m unable to add.
Just for example, I can’t see 2.4G and 5G wireless adapters on Interfaces menu and can’t find any master to associate to wifiX interface when creating it. It seems that my cAP ac, after all of these activities, transformed itself on a mere 2 ports router…
For sure it was working well before. Troubles came after my bad idea to try to factory reset its configuration…
Any hints? Thank you anyway.
For future reference below is the step by step description of how to Netinstall a cAP ac to RouterOS v7.13.1 (or newer). The first thing to do is to Netinstall (there is a Mikrotik YouTube video about it) the current stable RouterOS v7 version on your device. It is an ARM based equipment, therefore you’ll need the routeros-7.13.1-arm.npk and the wifi-qcom-ac-7.13.1-arm.npk packages from the extra packages (this one is to be uploaded via VinBox after the Netinstall). There are some hoops to jump trough tough during the process:
after downloading the required files (routeros-7.13.1-arm.npk ; all_packages-arm-7.13.1.zip ; netinstall64-7.13.1.zip or netinstall-7.13.1.tar.gz) connect your computer to a simple (not smart/managed aka dumb) switch, and the Eth1 port of the cAP ac to the same switch.
Make a photo of the label (containing its MAC address among other things) on the cAP ac as it may come handy down the road.
After the successful Netinstall if the cAP ac is powered with PoE than connect a second patch cable to its Eth2 port, otherwise remove the patch cable from Eth1 port of the cAP ac and connect it to its Eh2 port.
Log in to the cAP ac with WinBox. After that in the right side panel select System / RouterBOARD and click on the Upgrade button, than on the OK one.
In the right side panel select System / Reboot and click on the Yes button, than wait for the reboot of the cAP ac.
Log in to the cAP ac with WinBox. After that in the right side panel select Files, than click on the Upload button and find the wifi-qcom-ac-7.13.1-arm.npk file which you have extracted from the all_packages-arm-7.13.1.zip file and upload it.
In the right side panel select System / Reboot and click on the Yes button, than wait for the reboot of the cAP ac.
Log in to the cAP ac with WinBox. After that in the right side panel select System / Packages and make sure that you have two packages in the Package List namely: routeros and wifi-qcom-ac.
In the right side panel select System / Reset Configuration and tick the CAPS Mode and Do Not Backup checkboxes and make sure that the other two are not checked. Than click on the Reset Configuration button.
After the cAP ac restarted log in to the cAP ac with WinBox. Click OK to apply the default configuration and change the admin user’s password.
You may log out from the cAP ac, than disconnect it and also your computer from the simple switch. Connect your computer to the switch port it was connected previously and connect the Eth1 port of the cAP ac to the switch/router port where you will intend to use it on the long run.
Check in your DHCP server what address it has assigned to the cAP ac.
Read trough the new WiFi part of the documentation to have an overview about the basics of the configuration options.
If you have Netinstalled 7.13.1 than you may jump right to point #3.
Just a heads up, if you still have your hexS as you’ve posted earlier and want to use CAPsMAN to manage your shiny “new”(ly upgaded and performance increased) cAP ac with it (and also making use of the 802.11k 802.11v and 802.11r (fast)roaming feature), than it is strongly recommended to Netinstall it too 7.13.1 (as described above with the obvious difference that you have to only use the routeros-7.13.1-mmips.npk package and if you use User Manager to manage access to your Wi-Fi network than need to install the user-manager-7.13.1-mmips.npk (the same way as you did wifi-qcom-ac-7.13.1-arm.npk on your cAP ac) found in the all_packages-mmips-7.13.1.zip file) - just don’t forget to export (and save to a computer) your current configuration with the
in case of RouterOS v7 (using the Netinstall method to arrive to 7.13.1 (or newer) may save you from some configuration conversion glitches).
A few notes:
The configuration of the devices using the wifi-qcom-ac package in case of CAPsMAN - CAP VLAN configuration is different from devices using the wifi-qcom package, make sure you are following the documentation CAPs that support wifi-qcom-ac package section not the one before it which is for the 802.11ax (aka Wi-Fi 6) devices (using the wifi-qcom package).
The hexS got feature upgrade with the Bridge Hardware Offloading however because of the limitation of the RTL8367 switch chip if either IGMP (and MLD) snooping activated on the bridge, or DHCP Snooping with or without DHCP Option 82 activated on the bridge than it looses the above mentioned bridge hardware VLAN-filtering feature. Beside these also keep in mind that although
Bridge HW vlan-filtering > was added … [t]he switch does not support other ether-type 0x88a8 or 0x9100 (only 0x8100 is supported) and no tag-stacking. Using these features will disable HW offload.
There is possibility to increase your Wi-Fi network performance by using a single SSID and '[a]ssigning a different passphrase for a specific client [device] and also put it in a separate VLAN. For more details (on how to enhance the above mentioned example) see the Access List section of the documentation.
When setting up or tuning your Wi-Fi make good use of Apple’s disclosures on the roaming logic in its mobile devices, Macos ones and USA focused channel selection guide. For EU/EEA ETSI regulated countries the available non overlapping channels (and EIRP limits) are a bit different:
However the design ideas described in Get proper Wi-Fi coverage and Get proper Wi-Fi capacity sections are the same nevertheless, “just” in this regulatory domain one have one more (four instead three) non overlapping channels in the 2.4 GHz band, somewhat lower EIRP limits in certain parts of the 5 GHz band and lot less available non overlapping channels in the 6 GHz band.
Thank you un9edsda for your detailed reply! You saved my day! Now, with wifi package I can see again the two wifi interfaces! Again, THANK YOU.
After reading your second post (related to CAPSman enabling on hexS), I’m trying to find the best option between single managed APs or centrally CAPSman managed. I’ve read different opinions on whether to adopt CAPSman on not. Having only 2 cAP ac devices (maybe planning to add maximum 2 more) on my house, and playing with some VLANs with proper firewall rules on hexS to separate traffic between devices categories, do you think that CAPSman adoption could add improvements (like better roaming) that justifies its major complexity/overhead over each single managed cAP ac? I also know that the overhead added by CAPSman could lower performances. Have you got any suggestion for helping me to choose CAPSman or not
Thank you in advance!
My personal opinion ( being a scaredy cat regarding using capsman ) is that the time to use it is with MULTIPLE Access points that can make use of ROAMING standards only available on AXE3 products. In your case 2 or even 4 is easily managed as they are basically config and forget, they just keep working.
I have had two capacs hooked up in my house and two more would be easy peasy. The have the exact SAME configuration.
ETHER1 trunk port to managed switch or router
ETHER2 is an OFF BRIDGE port I use to config the router and reach it in an emergency ( always run a second ethernet cable from ether2 to a location where I can access the cable to plug into a laptop for example).
BRIDGE
TRUSTED VLAN is the only vlan created, rest are just passing through so tagged on ether1 and untagged on port or WLAN. Only trusted vlan is tagged on bridge
So the only difference between CAPACS is
a. different IP address on trusted vlans.
b. perhaps different selection of WIFI SSIDs…
c. Perhaps with B. a different VLAN or two.
