OpenWrt support for Zyxel LTE5398-M904

It doesn't look easily doable as far as my limited understanding of netifd goes. There is setup and teardown which take care of full modem setup/teardown and not just bearer. So in my mind even if the "watcher" script is implemented (which looks doable) the process would still go through setup/teardown which takes time with MM, so we could get automatic reconnect but it would be "slow".

There is support for implementing a topology change renew handler, but that's meant to trigger dhcp renew when bridge topology changes and I think it would be super ugly to hook into there.

I think the general problem that the bearer/connection state itself is not really tracked/visible in Linux/netifd outside of MM, and thus handling things like this, but also for example controlling a LED based on packet connection status is really difficult. An example - PPPoE interface is bound to the ethernet interface, so it's normal for the ethernet to be up while PPPoE interface can go down at any point; for QMI the interface is always up, even if you don't have a SIM card inserted, and the only way to get the bearer state is to interact with MM or uqmi etc.

I'm just speaking out of ignorance here, but is it not possible to issue the mmcli connect command, followed by a DHCP renew?

question:

you can also tell us if you preferred to use "uqmi" or "modemmanagager" and how you feel about it

and

given that with the original firmware and the LTE module updated to version 13 the cell-lock does not work (connection to a specific BTS)

you have the possibility to test the cell-lock with Openwrt and the LTE module updated to version 13

example by connecting with picocom /dev/ttyUSB3 (commands taken from various sites so there may be errors):

detects the cells that the modem manages to hook:
'AT+QENG="neighborcell"'
+QENG: "neighborcell intra","LTE",1650,65,etc

set a cell lock
'AT+QNWLOCK="common/4g",1,1650,65'

It really seems to work. The only thing is that after executing the celllock command you must give a restart to the WWAN0 interface for the modem to reconnect with the main band selected.
So I locked on the main band B1 and then B7 and obtained as per the attached screens.
chrome_y7nh8DnIRS
chrome_6120oC7MY9
chrome_BlVXq9QVHD

EDIT
Then I've disabled cell locking with this command:

AT+QNWLOCK="common/4g",0

And restarted WWAN0

1 Like

It's great to know that cell-lock errors
do not depend on the LTE module firmware
but on the original OEM firmware.

regarding the second question:

prefer wan management with the package:
"uqmi" or "modemmanagager"

I've uninstalled modemmanager because I use these apps (that conflict with modemmanager): https://github.com/4IceG
I use all of them, they work great. Many thanks to @IceG
So in the end for WAN configuration I've "uqmi" and "luci-proto-qmi"

2 Likes

What did you do to detect and/or automatically reconnect?

script, watchcat, other ?

Connection of course is configured to autoconnect (this is default uqmi settings on openwrt) then I use the watchdog monitor by @IceG, part of the apps I posted before:

I ask for further information without the package
"luci-app-lite-watchdog"
does not the uqmi module automatically reconnect
in the event of disconnection?

I would like to avoid using sources other than Openwrt ones...

Sure it will keep connection active and reconnect it in case of drop. Autoconnect is by default 1 in uqmi:

1 Like

really excellent

Can you give me feedback on the LTE connection compared to the original firmware (latency, download, upload, other)

can you give me feedback on the WIFI connection compared to the OEM firmware

In summary, you don't need install modem-manager to have an automatic re-connection

And execute at commands and mange SMS messages can also use picocom

But that doesn't handle wan IP change, right? So modem reconnects, but change in wan IP renders connection unusable, or?

Have you perhaps noticed and/or understood where the LTE module update files that you updated from version 8 to 13 are written (in which partition/device)?

The modem has its own flash storage it doesn't use the host router partitions. The OEM firmware is probably using its tmp space for manual modem upgrade. I haven't fully tested "offline" upgrade but it should be doable with picocom.

thanks for the timely response

another question if I created a custom image starting from:

OpenWrt Firmware Selector

adding the following software packages I would have some problems (I would like to test both modem-manager and uqmi):

htop wget-ssl sed luci-app-ksmbd curl picocom coreutils-base64
usbutils block-mount at e2fsprogs fdisk kmod-fs-ext4 kmod-usb-storage-uas mount-utils smartmontools irqbalance kmod-button-hotplug openssh-client openssh-client-utils openssh-keygen coreutils-stty socat minicom luci-proto-qmi luci-app-nft-qos luci-app-watchcat luci-app-wireguard luci-app-mwan3 luci-app-ledtrig-usbport luci-app-ledtrig-switch luci-app-ledtrig-rssi qrencode tcpdump luci-app-uhttpd luci-proto-modemmanager luci-app-firewall luci-app-attendedsysupgrade

1 Like

I don't expect you would have problems with both packages installed as long as you don't try using both at the same time.

1 Like

Thanks again

Those who own this device and have used it for some time, would you recommend it? would you purchase it again? Thanks!

with the original Zyxel firmware no, as it presents problems of disconnections in which the only way to restore connectivity is by restarting, technical support is lacking.

regarding the hardware of the device for me it gets 10/10

I would still buy it again, as I have high hopes from the Openwrt firmware as it is customizable.

1 Like

How are you flashing the router? Do you use the "zycast" tool? Can it be done without a console? Thanks!