Hi Jonas, On 8/14/19, Jonas Bonn wrote: >> I logged link status every 10 minutes. > > How? Not clear from what you posted earliest how you can tell that the > link has gone down. The default route is set to go over WiFi so a > generic ping isn't sufficient. What exactly are you monitoring? I have a cron job to check LTE link IP, if the IP is gone that the link is down. I also connect the device and monitor it by serial port connection. I don't think that is important, let's move on. >> >>> Cloud messages are as good as a ping... a packet's a packet. >>> The link is configured by connman, not ofono. ofono just publishes the >>> address details so that connman can set it up. >> >> So, it is back to connman? > > Well, the log _seemed_ to indicate that connman does an NTP request to a > server that isn't available and thereby decides to take the link down... > off the top of my head I can't say whether that's something connman > actually does so hopefully somebody else will jump in here. Did ofono > indicate the context as still established after that? That seems critical, every time when the link down, connman called: connmand[213]: Time request for server 10.114.52.97 failed (101/Network is unreachable) Then deleted the link IP address to cause the link down: connmand[213]: wwan0 {del} address 10.114.52.98/30 label wwan0 connmand[213]: Skipping disconnect of /ubloxqmi_0/context1, network is connecting. connmand[213]: ipconfig state 2 ipconfig method 1 > Seeing the issue with complete logs would be useful. I thought your > previous logs indicated connman trying to deactivate the context when it > took the link down, but the ofono logs didn't show any of that... what's > going on there? The full connman log file attached, there was no information for ofono log files. I don't think that ofono was aware of that connman deleted the IP address from the LTE link, I cannot understand why the connman did it. Anyway, I'll try to debug and to generate ofono log again. Thank you Jonas, - jh