I will preface this, by saying I have used multiple platforms, different devices, and different quectel modems, and always had the same persistent firmware bugs. You can look at the prior posts I’ve made on the subject.
I would post a link to the discussion on the Openwrt forums, about all the quectel modem’s having the same issue, but this forum software is set-up so poorly, that adding links, gets all your posts, even previous ones, up for months, auto-banned. You’ll just have to search the Openwrt forum posts out, yourself.
Suffice to say: whether it’s the GLINET GL-X750 with the EC06-AF, or NETGEAR ORBI LBR20 with the EG18-NA, if the router device is configured to set MTU on the cell connection, after 2 minutes of up-time of the cell link, the modem locks-up. Only a hard reboot of the entire router, will reboot the modem and make it available again.
Only a plain QMI setup works [but you cannot set MTU], because the QMI protocol, by itself, without ModemManager, does not require or try to detect/set the MTU. If you use ModemManager, transitioning the modem interface from QMI, to adding the ModemManager layer (which can use either QMI or MBIM), either MM or the underlying library, will try to detect the MTU, and will correctly set it (1428). Although the MTU is correct, and as a result, sites like test-ipv6.com and others come up quickly and have zero issues: inevitably, after about 2 minutes, precisely, of uptime, of the quectel cell device -the quectel chip locks-up.
If you try to use plain MBIM, which by default autodetects the MTU (to 1428), the same issue happens: works for 2 minutes and locks up. Doesn’t matter what firmware it is on the quectel, what revision of openwrt it is, or the hardware platform or quectel device, but the only correlating factor is setting the MTU. Plain MBIM protocol, probes and autodetects and sets the MTU. QMI does not.
If the connection runs into difficulty, and it’s only using the plain QMI with no settings of the MTU, the occasional cell connection failure occurs, as is normal, and when there is no throughput, an ‘ifdown qmippp’ followed by a pause of 5 seconds, and then ‘ifup qmippp’, followed by waiting 30 seconds, almost always works to get the cell device running again. I have a script running on the openwrt device, that runs after a delay on startup, and then every 30 seconds afterwards, checking known good sites, that can detect connection problems. It logs failed attempts, and so I can see when ifdown/up has worked, versus when it has to go to the next level -a reboot- which is also logged (search the Openwrt Wiki for ‘Wireguard Extras’). I mention that information, because this is how it’s supposed to normally work. Whereas specifying the MTU causes a hard lock condition of the quectel device itself, and it becomes totally unresponsive. Not even a ‘picocom /dev/ttyUSB2’ is able to communicate with the AT/serial interface channel on the quectel device anymore, until the entire router is rebooted.