idk, /tool/sms/print:
status: off
receive-enabled: yes
port: lte1
channel: 0
secret:
allowed-number:
sim-pin:
last-ussd:
Can’t say anything about the status attribute.
I upgraded my hAP ax3 CAPsMAN APs (there are 8 of them) together with an RB5009 running CAPsMAN on Friday. I appear to be noticing that some wireless clients are having problem keeping their connection. Has anyone else noticed a degradation since 7.13.3, nothing in the change logs…
PS: 7.13.4 hardware offloaded bridges appear to have problems with certain VLANs dropping DHCP requests when DHCP snooping is enabled. As I understand it the DHCP snooping feature should possibly not filter requests but filter answers, right? If we for example have an uplink that is a trunk port for 7 VLANs, some work and then we have a system where DHCP requests are not forwarded upstream via that device, although the port has ‘trusted=yes’ set on it. If we then disable DHCP snooping the device immediately gets an IP.
Another issue with 7.13.X is that CRS354-48G-2S+2Q+ devices loose the ability to communicate with other devices (eg RADIUS stops working for 802.1X) shortly after rebooting. The device is able to acquire a DHCP lease for itself but is then unreachable from either the device or others on the network. The networking construct is a little different, in that we have ‘bridge’ as a tagged member of VLAN 1 and then have a dedicated ‘vlan1’ interface attached to the bridge. This works on other model devices with the same settings just perfectly, but not on CRS354-48G-2S±2Q+. Downgrading to 7.12.2 restored functionality only after also downgrading firmware as well (ie: RouterBOOT firmware from 7.13.4 does not work when only software has been downgraded to 7.12.2).
CRS354 is part of a MLAG:
/interface bonding
add lacp-rate=1sec mode=802.3ad name=bond-peer slaves=qsfpplus1-1,qsfpplus2-1 transmit-hash-policy=layer-3-and-4
/interface bridge
add admin-mac=DC:2C:DE:AD:BE:EF auto-mac=no name=bridge priority=0x5000 vlan-filtering=yes
/interface bridge mlag
set bridge=bridge peer-port=bond-peer
/interface bridge port
add bridge=bridge comment="MLAG Peer:" interface=bond-peer pvid=99 trusted=yes
add bridge=bridge edge=no-discover interface=bondsfp1 restricted-role=yes trusted=yes
/interface bridge vlan
add bridge=bridge comment=Core: tagged=bridge,bond-peer vlan-ids=1
/interface vlan
add interface=bridge name=vlan1 vlan-id=1
/ip dhcp-client
add interface=vlan1
Thanks! I did exactly what you suggested.
CCR1009-7G-1C-PC / Tile
Upgraded to 7.13.4. Immediately noticed that several interfaces did not recover and appeared as if no physical connectivity was present. Hard reboot seemed to clear the interface connectivity issue, but began noticing traffic dropping intermittently on those interfaces. Successfully downgraded and back to normal on 7.12
I’m definitely seeing the wireless client degradation issue since upgrading to 7.13.4 from 7.13.2, on my WapAC (non wave2). Clients which are only 10 meters away are now only getting a signal strength of -89/-90.
@ecylcje
The situation is similar with hAP ac3, but starting from version 7.13. And version 7.12 works fine with wifiwave2.
I was remotely upgrading a HAP Lite from 7.13.3 to 7.13.4 and it doesn’t come back 
I’m not using wifi on this Mikrotik, only ethernet cables. I didn’t install the wifi package when upgrading to 7.13.3
Maybe the missing wireless package has bricked the router when I upgraded to 7.13.4 ??
Crap, it’s too far away to go and check it on person. I shouldn’t have updated so early :((
You should not even have updated to v7. That kind of device is best left on v6.
Probably it is bricked due to lack of space. You can recover it with netinstall.
I’ve upgraded another HAP Lite just to make sure and it has also bricked (it’s located on another site, near my home, so I will be able to inspect it personally soon).
Be warned, guys: Two HAP lite upgraded from 7.13.3 to 7.13.4 (both of them were previously upgraded from 7.10.1 to 7.13.3 directly, without installing any wireless package)
I didn’t install the wireless package because I don’t use wifi in any of them. But it seems that it’s somehow necessary in 7.13.4.
Oh, and one important detail. The first phase of the upgrade to 7.13.4 was apparently correct in both (I could still connect with WinBox). But as soon as I upgraded the routerboard firmware (second phase of the upgrade), they both died and don’t respond anymore.
Found out that I can’t reboot my HEX without first deleting backup in storage because of lack of space. Space on 16mb devices is becoming a bit of a limiting factor.
Good news: one of the HAP lites (the one nearest to my house) wasn’t bricked after all. Just unresponsive. Turning it off, waiting a few seconds and turning it on again revived it!
The other HAP lite is quite far from where I live, I’ll try to visit it next week and will report back
I have not that problem on my hEX. Running 17.3.3 and still have not removed the not needed wireless package, I have 1388KiB free out of 16MiB.
But do agree 16 MiB are not sufficient in new hardware.
Fwiw, Hex running 7.14rc1 including wireless package (using it as test for dual capsman setup):
Just compare MIPSBE, MMIPS and SMIPS wireless package sizes with ARM on 7.14rc1. Also look at wifi-qcom-ac package size as well. Definitely progress on MIPSBE, MMIPS and SMIPS, but unfortunately still not enough for every single ARM based Mikrotik hardware with 16MB flash. Something still needs to be done with both with wireless package and wifi-qcom-ac package sizes on ARM because lots of people actually want wifi-qcom-ac and NOT wireless.
Upgrading from 7.13.3 to 7.13.4 on my GrooveA 52ac broke badly. The GrooveA 52ac is now stuck in a boot loop that’s so fast that it can’t be detected in Windows netinstall64.
Even if I hold down the hardware reset button it still boot loops rather than go into netboot mode.
I’ve had better luck with the 32bit binary for some reason
How can one run ROS 7 on a hAP lite? I’ve tried this several times and even just as a CPE (no firewall filter rules, a blank config in fact) it was barely unusable. Slow to unresponsive CLI. And basically hung up every 2 days and needed a power cycle. A real 
.
It is better not to do it. Just remain on v6.
A little while ago I updated two AX2 remotes from 7.13.2 to 7.13.4 and I agreed that I can no longer reach them but I know for a fact that they are working perfectly except for Wireguard… Just me?
hap lite running happily and rock stable on ROS 6.