MikroTik

• Can't automatically reconnect if connection is dropped.
  No traffic can passthrough the LTE connection then you have to disable the interface and enable it again. When this happens I can see the LTE interface got a IP address.

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

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

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.

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.

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...

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