I switched all our ac devices (cap ac, hap ac) to a regular wireless some times ago after months of kernel and OOM failures and reboots.
I have tried all recent ROS versions, (up to and including 7.16.1) with one of ours hAP ac2 and wifi-qcom-ac and there is maybe a slight improvement but nothing to be called stable (kernel failure do inevitably occur after couple of days) so I will continue to use old wireless package for production for now…
Unfortunately there is no user-level tool to show that (like there is for processor usage).
MikroTik claim that they can see it in a supout.rif. Of course you can upload a supout.rif to your account at mikrotik.com to show the content of a supout.rif so you could try that.
Or else you could make a support ticket and include the supout.rif and hope for a quick response.
That would have the advantage that they become aware of the failure scenario and can fix it in the software.
Hello,
I own a CRS317 and this release seams to have some CRS317 related fixes. However in the change log also the remark:
CRS317 devices (“/system routerboard upgrade” required)! What is that!?
So can any body explain:
- what is mend by ^routerboard upgrade^ and
- what exact procedure I should follow during the upgrade process not to lose / kill my CRS317
Thanks,
Louis
Winbox
System routerboard upgrade.
Cli: same path
Simple as that.
Yep I found a description
https://help.mikrotik.com/docs/spaces/ROS/pages/328142/Upgrading+and+installation
No problem, I never did that, and I was perhaps a bit to afraid, since I one’s lost a CRS317 perhaps due to a unsuccessful update
Mikrotik devices, just like many others, have actually two pieces of software: firmware (think “BIOS”) and the operating system itself. So what this remark says is, that you have to update the “BIOS” too. So in Winbox, go to System → Routerboard, click the Upgrade button and then reboot. (You can update the firmware only to the one matching the running system; this is a bit annoying, that when you want update both operating system and firmware, you have to reboot twice).
Why do I see positive signal values in registration table for one client only?
Damn thats some superb wifi 
hmmm… we probably have here the first clues about subspace communications?. =)
Next stop, Alpha Centauri?
Maybe the value is truncated and it is -104, which is not very realistic either but still more believable.
No idea what it is. Sometimes it shows “-74” or some realistic value. But most of the time it is a positive value. It goes up to 149 I have seen. Today it shows strength in interval of -83…-80. As it is realistic. But I did not reboot capsman nor did I reboot cap and not even the client was rebooted. It just “healed itself” somehow. I mean, it did not heal itself actually. It must be some kind of “edge-case” that is not handled correctly - not appearing today.
Could it be Winbox 4 related issue with displaying these values? Can you check them with Winbox 3 or some other way?
The log entry also states +159
I had this nonesense a while back. can’t recall what version now (7.15/7.16 ish), but it isn’t specific to wAP ax I don’t thnk!
I don’t have it now I am on 7.17beta4
Same here, Completely a mess after the update, mostly with the new AX devices. The old HAPAC2 have not been affected. By luck? i dont know…
The strange thing here is that despite i tried to allocate a static IP to the AP from the RB4011 router, this was not possible with the first 2-3 trials… anyway now seems ok but you never know after a reboot…
Eventually, it seems that in these 2 HAPAX2 that the problem occurred, i had not set admin MAC address like the other devices. I do not know what does it mean but i set them. Hope that helps me. Until now the static IP survives the reboot.
You should always set admin MAC address on the bridge (best practice is to use MAC of the first ethernet interface that is part of the bridge), otherwise during the boot process, depending on interface statuses (up, down …), bridge could get MAC other than the one that is used for DHCP static lease…
While this might be one of best approaches, it’s not flawless … if one removes “first ethernet interface” from bridge and forgets to change bridge MAC address, it’s possible that some problems arise (in certain scenarios). IMO it’s better to construct LAA MAC (based on MAC of first ethernet interface part of bridge) … which makes possibility to have two interfaces with same MAC lower.
Trying to upgrade a CCR1009 working as a wifiwave2 capsman from ROS 7.12 (has routeros and wifiwave2 packages)
I get an error:
wifi-qccom-ac-7.16.1-tile.npk missing, use ignore-missing or disable package(s)
Will I loose the capsman configuration ?
It is a possibility. As far as I remember wifiwave2 config structure is pretty close (if not the same) as the (new) wifi config structure. So even if you’ll have to manually upgrade configuration after you upgrade ROS, it shouldn’t be a big problem.
Export (at least) contents of /interface/wifiwave2 to ASCII file (execute /interface/wifiwave2/export file=wave2config show-sensitive) and fetch it off CCR before performing upgrade. After upgrade you’ll probably have to copy-paste config, replacing /interface/wifiwave2/xxx with /interface/wifi/xxx …
You’ll probably have to disable and remove the (optional) wifiwave2 package as there is no “successor” for tile architecture. However, the base functionality (which includes CAPsMAN) is included in basic (routeros) package.