Hi, I've managed to install openwrt on ZTE MF289F. I am using it with QMI protocol without modemmanager. I've read on the forum about issues with random LTE disconnection so i've made a script that every 30 seconds check if there's internet connection otherwise it restarts the LTE interface with ifup LTE.
My ISP forcibly change IP every 4 hours. When 4 hours lease ends, the connection go down, and this is the last line i see in the log: netifd: LTE_4 (20553): udhcpc: sending renew to server 10.12.228.153.
After some time my script detect the disconnection and restart the interface, so it gets a new IP and it starts working again. If i disable my script, the connection go down and nothing happens forever.
Is this intended? I think udhcpc should get the new IP automatically at the end of the lease time.
OpenWrt complies with the standard DHCP renewal process... that is, it will attempt to renew the lease at 50%, 87.5% and then 100% of the lease time. If the upstream DHCP server does not respond, or does not allow a renewal or new lease, there is nothing OpenWrt can do about that. And this is true of really any DHCP client. At that point, the typical 'fix' is to bounce the network connection in the hopes that it will result in a DHCP lease issuance.
The root of the problem in these cases is really the DHCP server -- such as:
it is not working as expected (for any number of reasons)
the lease pool is exhausted
it has policies to specifically only allow DHCP leases under specific circumstances and/or to not allow renewals.
My guess is that the DHCP server changes its address. This server is running on the modem, and it uses an address the modem firmware derived from the one assigned by the network. So when the modem reconnects and gets a new address, then the DHCP server stops responding on the old address. Which means that unicast DHCP renewals fail. It's the way this "works". Or not.
My opinion has always been that it's best to ignore all these modem firmware hacks, if possible. Don't let the modem autoconnect. Reconnect yourself if the session goes down. Don't use DHCP for address configuration. Use a management protocol with some idea about the pont-to-pont link and a way to notify the client about changes. E.g MBIM or QMI. And don't let the modem add ethernet headers to your IP packets. That is only OK if the modem firmware has no bugs. In the real world, no modem vendor has been able to consistently add ethernet headers. They are an infinite source of very hard-to-debug issues.
Or just ignore that rant and restart the DHCP session from DISCOVER whenever a ping probe fails. Or something like that.
Connection monitoring is not a part of QMI or MBIM connection scripts used by OpenWrt, I don't think that was ever considered as a bug so no fix should be expected. The tool like watchcat is a known good workaround for this kind of issue.
As far as I understand, without ModemManager, the QMI protocol in OpenWrt is configured such that an action is submitted, and a response is received. So a disconnection event is not even handled in any sense. It is therefore necessary to poll the modem to work out when a disconnection has occurred, and then react appropriately. That does not facilitate minimizing downtime.
Right now i am using a script to check if there is internet connection and restarting the interface in case the internet is down. My ISP forces disconnection and new IP every 4 hours. I will try switching to modemmanager when it will handle the reconnection automatically. The problem is that i think i will have to disable all other packages that use qmi protocol (for example sms_tools, uqmi, 4iceG packages).