No additional records in log (with debug topic enabled) related to this issue. I guess this is related to SMS offstatus, there is no indication why is switched into that status:
/tool/sms> print
status: off
receive-enabled: yes
port: lte1
channel: 0
secret: xxxxxx
allowed-number: ###########,###########,###########,###########
auto-erase: no
sim-pin:
last-ussd:
The issue is the same on my side as well. “After upgrading from ROS 7.7 to 7.8 I’m unable to delete received SMS message in inbox.”
Device: MikroTik LHG LTE6 kit
Certnaly there is a bug in SMS tool on ROS 7.8. Probably SMS is not widely used on MT devices or at least not on ROS 7.8, so there are no reports from ohers regarding this.
In my case I need to manually remove message after is sent to email so I can’t have auto-erase enabled. After upgrading to 7.8 I had to disable scheduler which event triggers script that process SMS inbox because it is not functioning as expected and feature can’t be workarounded.
Addition:
After reboot SMS is again in off status and it is not possible to delete messages again
Well, at least it can be workarounded with startup scheduler which puts status in running:
It doesn’t matter if the app works or not, some users never use the app and have constant problems with “this feature”,
they better know whether to choose the app to work or their connection to work…
But why internet detect actually uses DHCP to check internet status? It is used to detect WAN status? Can checking that status be disabled so that only LAN and Internet statuses can be obtained?
By documentation https://help.mikrotik.com/docs/display/ROS/Detect+Internet - Internet status is when: WAN interfaces that can reach cloud.mikrotik.com using UDP protocol port 30000 can obtain this state. Reachability is checked every minute. If a cloud is not reached for 3 minutes, the state falls back to WAN.
…so by this statement UDP connection to cloud.mikrotik.com:30000 is used to obtain Internet status.
It ain't the user's fault - the idea of the app is it's a friendly way to access a router for someone not familar with RouterOS. But @rextended ain't wrong, it's a dangerous feature. And it only looks innocent.
/interface/detect-internet is too aggressive will modify your configuration to add DHCP client on any interface covered by detect-internet list, if it can't ping 8.8.8.8. But "detect" doesn't imply that – docs are right on what it does. This, in some cases, may be totally fine. But adding a dhcp client can have a lot of side-effects. Another one being adding a route with a distance=1, and so your routing can get messed up, depending on what DHCP is doing and/or if your using recursive routing.
Further you have to grant "write" access if you want an end-user to be able to update Wi-Fi password. And since internet-detect is NOT protected by a policy, an end-user can change this in the app.
I actually filed a feature request (SUP-108814) a little bit ago, since it annoying catch-22. There should be some option to stop the "add a dhcp client" logic IMO. They did respond:
We will consider adding an option for detect internet, not to create or adjust DHCP client.
If a DHCP client getting added of an interface in the detect-internet list cannot ping 8.8.8.8 isn't a problem for your ISP or cause a break in routing table, it's fine. But yeah that's a bit to unpack to know if "safe".
I guess alternative is to use https://github.com/IgorKha/Grafana-Mikrotik - which I actually did setup while ago on MT container but my device doesn’t have enough RAM to run this continuously along with other containers and ROS ram usage
BTW It’s the subtle clause in docs “an interface can obtain (or has obtained) an address from DHCP (does not apply if DHCP server is also running Detect Internet on the DHCP server interface).” – so the “can obtain” part is tested by adding a /ip/dhcp-client.
Thx detailed for explanations, I assumed it is for WAN check, that’s why I asked can WAN check be disabled, obviously not.
For router security I’m not concerned, this is on home router and I’m end-user, if there is no potential safety concern from wan, no problem.
Regarding routing, I did not setup any custom routes, all my IP routes are dynamic, per IP address list, subnets with distance 0 and with dynamic routes for Wan lte1 interface with subnets 0.0.0.0/0 with distance 2 and <public_ip>/32 with distance 0.
Yeah it adds a nice chart in the app – which is exactly what an end-user wants to see . Similar with LTE, the app is pretty useful since it has graphs for that too.
So if the dhcp client logic doesn’t break things, it’s harmless. So it won’t add anything if 8.8.8.8 is ping-able from all addresses in WAN list. And even then only if there wasn’t already a dhcp-client (or it’s LTE).
And “detect-interface-list=WAN” means it does all of the Internet, WAN, LAN, etc detection using the interfaces listed in WAN in /interface/list/members. It does NOT mean only do WAN detection in docs, rather it will do all detection ONLY using the WAN interface list. But that setting should actually pretty safe. It defaults to “all” which tests ALL interfaces, so that includes tunnels, VPN, dynamic interfaces, etc…
In the esoteric features, you might also want to look at /system/watchdog. I’d recommend setting the email stuff for supout notification. That way you’d know if it ever crashes.
You can enable ping check there, that will reboot router if x minutes of failure to ping (on top of the CPU hang detection). Similar to netwatch, just no code.
