Solutions to make LTE stable(ish) on the MF286R?

Installing and Using OpenWrt
1

Hi,

I’ve recently installed OpenWRT (24.10) on a MF286R (did not pay enough attention when I bought it…) and I’ve been able to configure the LTE modem and make it work with the operator fot he SIM card. The issue, as already been reported here, is the lte connection is not very stable. It randomly fails after a few hours.

I’ve been thinking about using some watchdog (using watchcat or some custom script executed by cronjobs), but it’s unclear to me if there is a solution to do this reliably on this device.

The big catch is that in addition to being unstable, the reset circuitry of the modem seems to be connected to the device one: when I send the modem reset AT command (AT+CFUN=1,1 IIRC) the whole device is rebooting. (I think I also read something about this in a forum post…)

So my question is: hos anyone found a way of running this device more or less reliably (aka automatically restoring the lte connection when necessary, if possible without rebooting the device, it’s very slow to boot which can be an issue for my use case)?

Are there “happy users” of this device around?

Should I continue to fight it or is it a lost cause (and buy something else (if so, is a WE826T2 clone from aliexpress with an NL678-E modem a suitable solution – no need for performance, just decent stability and ability to deploy a few extras like wireguard and 3g/lte luci packages))?

Thanks,

David

2

A few additional notes here.

The model is a Marvell, revision BD_PKTPLMF286R1MODULEV1.0.0B03

The issue reported with the serial port showing garbage at startup (in uboot) is because the baudrate is pretty unstable; I had to estimate the baudrate with an oscilloscope and use this to get a usable uboot prompt (then revert to 115200 when booting the kernel).

Then it seems the RX line is loaded (or level shifted with a pair of resistors or something) because the first usb-serial I used (not sure which chip it was) could not maintain a TX signal high enough for the mf286r to register it (high level was about 1,2v or something). I did want to risk using the 5V setting of the usb-ttl converter so I tried a different one (ch340 based) which could deliver a high enough voltage for the H level. Maybe the schematic of the mf286r has some level shifters on the serial interface.

I am currently trying to use watchcat but not sure how the make the interface restarting properly. Just had the interface down (after a few hours of uptime) but watchcat could not restart the interface to make it up again. In the end the connection got restored after I executed a service network restart .

3
4

Thanks, I’ve read quite a number of discussions but I probably missed this one (hard part being that it’s not a QMI model so hard to tell how much can be used in my case).

As I mentioned, I tried using watchcat (using a restart-interface rule) but it does seem to work: the connection is not resumed after it’s triggered (nor it is so if I do a “restart interface” on luci’s Inteface page.)

But weirdly it did work (last time at least) when I executed the service netword restartcommand (not sure what this later command does more than restarting all the interfaces; need to check that). This is however not ideal either because it will disconnect everything (especially the wifi clients) which I’d prefer not to do.

Also the issue is triggering a modem reset (with the AT+CFUN=1,1 at command) on thids device makes the whole router reboot (again, not ideal, I’d like to have a lower down time if possible).

So my first goal is to find a reasonably robust solution to restore the lte connection (without rebooting the router) then use it in a watchdog script of some sort. But it’s a slow feedback loop since the lte connection does not “crash” so often :slight_smile:

5

The same way as with any other USB peripheral, e.g. any modem in any mode.
Try using usbreset and see if it can restart your modem only.

1 Like
6

yes I know that (but thanks).

Will try with usbreset. There are also a AT*MODEMRESET listed by the model (as provided by AT+CLAC) I want to try. I event think about trying a reboot command on the modem since this is accessible via adb shell. We’ll see.

2 Likes
7

Yes, AT*MODEMRESET and/or AT+ZRESET needs to be tested as well.
adb shell should also help if available.

1 Like
8

ok so the LTE interface got stuck again (after almost exactly 12h of uptime, so the “operator kills the connection” hypothesis seems reasonable), and a usbresetdid restore the connection!

The interface went up again (I could ping from there). But for some reason mwan3 could not recover the status for the interface; it was considered as “disabled“ (not what the interface view in luci was telling). A service restart mwan3 did the trick.

[edit] a mwan3 ifup lte seems to also be enough to restore mwan3’s state

9

Do you use NCM?

10

yes

config interface 'lte'
	option proto 'ncm'
	option pdptype 'IP'
	option apn 'free'
	option pincode 'xxxx'
	option ipv6 'auto'
	option device '/dev/ttyACM0'
	option metric '10'
11

FTR I have deployed a temporary solution using watchcat monitoring the lte link with a “Run script” policy which seems to be running (with a downtime of 30/45s every 12h).

The script is currently very naive:

#!/bin/sh

IFACE=$1

case "$IFACE" in 
  usb0)
    usbreset 19d2:1489
    sleep 20
    mwan3 ifup lte
    ;;
esac

But I want to try also @mrhaav solution based on his atc scripts (see https://github.com/mrhaav/openwrt-packages/tree/main/atc-zte-mf286r). Might be a better solution.

FYI when the connection is shut (by the operator) I see this in the modem’s logs (via adb shell reading /logfs/syslog):

Jan  4 14:55:46 OpenWrt daemon.notice netifd: Network device 'ccinet0' link is down
Jan  4 14:55:46 OpenWrt daemon.notice netifd: Interface 'wan60' has link connectivity loss
Jan  4 14:55:46 OpenWrt daemon.notice netifd: Interface 'wan0' has link connectivity loss
Jan  4 14:55:46 OpenWrt daemon.notice netifd: Interface 'lan' is now down
Jan  4 14:55:46 OpenWrt daemon.notice netifd: Interface 'lan' is disabled
Jan  4 14:55:46 OpenWrt daemon.notice netifd: Interface 'lan' has link connectivity loss
Jan  4 14:55:46 OpenWrt daemon.notice netifd: Interface 'lan' has link connectivity 
Jan  4 14:55:46 OpenWrt daemon.notice netifd: Interface 'lan' is enabled
Jan  4 14:55:46 OpenWrt daemon.notice netifd: Interface 'lan' is setting up now
Jan  4 14:55:46 OpenWrt daemon.notice netifd: Interface 'lan' is now up
Jan  4 14:55:46 OpenWrt daemon.notice netifd: Bridge 'br-lan' link is down
Jan  4 14:55:46 OpenWrt daemon.notice netifd: Interface 'lan' has link connectivity loss
Jan  4 14:55:46 OpenWrt daemon.notice netifd: Network device 'usbnet0' link is down
Jan  4 14:55:46 OpenWrt daemon.notice netifd: Network device 'usbnet0' link is up
Jan  4 14:55:46 OpenWrt daemon.notice netifd: Bridge 'br-lan' link is up
Jan  4 14:55:46 OpenWrt daemon.notice netifd: Interface 'lan' has link connectivity 
Jan  4 14:55:46 OpenWrt daemon.notice netifd: Interface 'lan' is setting up now
Jan  4 14:55:46 OpenWrt daemon.notice netifd: Interface 'lan' is now up
Jan  4 14:55:47 OpenWrt user.notice firewall: Reloading firewall due to ifup of lan (br-lan)
Jan  4 14:55:47 OpenWrt daemon.warn dnsmasq[4255]: failed to create listening socket for fe80::a897:fbff:fe2f:e8a5: No such device
Jan  4 14:55:47 OpenWrt daemon.warn dnsmasq[4255]: failed to create listening socket for fe80::a897:fbff:fe2f:e8a5: No such device
Jan  4 14:55:48 OpenWrt daemon.warn dnsmasq[28502]: no servers found in /tmp/resolv.conf.auto, will retry

yes there is OpenWrt in the modem itself!

/ # cat /etc/openwrt_release 
DISTRIB_ID="OpenWrt"
DISTRIB_RELEASE="Barrier Breaker"
DISTRIB_REVISION="unknown"
DISTRIB_CODENAME="barrier_breaker"
DISTRIB_TARGET="mmp/generic"
DISTRIB_DESCRIPTION="OpenWrt Barrier Breaker 14.07"
DISTRIB_TAINTS="no-all busybox"