:if ([/ping 8.8.8.8 count=10 size=64 interval=2s]=0) do={
:log error "LTE DOWN";
/interface disable <interface>
/delay 1s
/interface enable <interface>
} else={
:log info "LTE FINE";
}CCR1009-8G-S+S+PC | RB962UiGS-5HacT2HnT | RBOmniTikPG-5HacD | RB750Gr3 | RBwAPG-5HacT2HnD
Hello,Still troubleshooting this. I have implemented a script to ping 1.1.1.1 and cycle the LTE interface when the ping fails.
My cell provider assigns my STX a private IP from there CGNAT pool. I extended my ping script to also ping that CGNAT private IP when 1.1.1.1 fails.
When the 1.1.1.1 ping fails, the ping to the CGNAT IP still works. I still have an assigned IP in the CGNAT pool but it cannot access the web (ping 1.1.1.1 fail)
So is the disconnect issue on my cell providers end? I was looking to see if there was an AT command(s) to tell the GCNAT/Network "Hey, reconnect my IP to WAN"
I wonder does other sim card modems just have firmware that cycles there internal interfaces under the hood when they lose connectivity?
If it is my cell provider disconnecting me and I still have an assigned IP from the CGNAT, then its understandable that the STX thinks all is well
You might want to start a new thread.I'm facing the same issue on Chateau lte12 - interface doesn't lose cgnat IP, but public services are not available.
/system logging action add memory-lines=10000 name=mem10000 target=memory
/system logging add topics=lte,debug,!packet,!raw action=mem10000
Well, i believe you are true and like i've previously mentioned it automatically recovers. But delay when it happens is not constant and may be up to 5 minutes (haven't noticed more than that), which is not preferable for example for iptv. Router os build is 7.6 and lte modem has the latest firmware (viewtopic.php?p=974003#p974003). I've recently noticed this problem so haven't checked everything (i.e. does it happen on other bands or not), but "lte,debug" logging isn't helpful even with "packet". After i've configured remote logging i'll try to monitor this issue with "raw" enabled.The Chateau (or really any of the "modern LTE" devices) shouldn't need a script to recover. Now some builds to have bugs that would cause this.
Logs right now capture only dns failures, but it can't be a dns problem, because it happens not only with DOH, but with unsecure dns, too.I'm searching for a reliable way to automatically recover connection in a faster manner, so could you please, share your working solution.
Thank you, in advance.
I totally understand your point, thank you. I'm a bit skeptical about support, because, like you said, it's may be "not quick", but everyone at home wants to watch TV without visible hangs at least most of the time. I suppose most of us at least once in a life was in a situation when someone demanded smth and refused to hear any excuses, moreover when person is an expert in other field not connected to specific issue (i.e. mobile networks).For sure you'd want to make sure everything is upgraded to at least stable. And likely worth trying "testing" 7.7rcX too. But Mikrotik support is actually pretty good at looking at these LTE issue. Perhaps not quick. But they'd want similar to logging and supout.rif files (and that were running latest builds). Two supout.rif likely be more useful to them: from when it working and ideally one when it's in the hung state. That's why I was a little harsh on the script - it might help speed things recovery but someone else may run into same thing.
And you have a pretty new device... so LTE modems can have bugs, sometimes. Plus specific carrier sometimes do subtly different things, that can cause them. e.g I'd imagine this doesn't happen on LMT in Latvia. There are quite a few state transitions when LTE is initialized, so things can and do get stuck. Thus, disabling and enabling does get it out whatever LTE/MBIM state it was still waiting for and/or trying+failing.
Also, scripts are useful, but your long recovery time does seem more like a bug. So I didn't mean to imply you shouldn't have a script to check if something not hung, that's a good idea in fact . But saying I'd recommending if it's actually doing something / running, worth investigating at why in logs...
Excellent tips, thank you!It could very well be the signal you're getting, but normally the problem is the interface stays up with no data - but if your signal was very low, perhaps it would disconnect. To be clear: if the modem isn't actually disconnecting, and its only ping failures, that expected if congestions/low signal and be expected. If this happens at roughly the same time period everyday (e.g. early evening), that be another indicator it just the carrier's network that slow/congested.
So this may be help to know how to check signal:
https://www.youtube.com/watch?v=pRD0rzAiGxg
Another post explain some of the nitty-grity (although perhaps some info may be for V6):
viewtopic.php?t=178312
Since you seem relatively sophisticated (e.g. papertrail logging) and the problem is transitory, doesn't seem like a config issue but could be... If you think that it might be... for sure start a new thread with your config, see:
viewtopic.php?t=182601