OpenWrt support for Zyxel LTE5398-M904

in the meantime thanks for your work, :grinning:
now I have finally installed Openwrt on my router "Zyxel LTE5398-M904" :grinning:

Could you please explain to me why the mtu of the eth0 interface was set to 1504

ip link show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1504 qdisc mq state UP qlen 1000

I ask because if I run a tcpdump on the router I get (sometimes especially when I run a speedtest) something like this

tcpdump -n -i any icmp
wwan0 In  IP > IP ICMP IP unreachable - need to frag (mtu 1416), length 556

I believe the 4 extra bytes are for the DSA tag, it's like that on other MT7621 devices I have. The ICMP unreachables are normal part of PMTUD, you can see inside the ICMP packet where it's coming from and which packet triggered it. In case there are problems with PMTUD (which manifests as TCP connections stalling) you could configure MSS clamping, but I wouldn't expect that to be necessary - mobile networks are built for phones, so unless you have some custom VPN overlay you should be fine.

1 Like

thanks for the explanation of the mtu set to 1504

premise I'm currently doing (yes I know I'm doing double-nat and I'm also behind CGNAT)
ISP <-> Zyxel LTE5398-M904 <-> Fritzbox 4040 <-> Client

I noticed that if on the downstream router (Fritzbox 4040) I set mtu to 1416 the "unreachable - need to frag (mtu 1416)" packets disappear

but I can't understand why I should lower the mtu to fix this error/issue (if it is a problem) as I assume Openwrt does this -->

4 posts were split to a new topic: Setting up WireGuard on Zyxel LTE5398-M904

PMTUD is used by endpoints of the TCP connection. and the role of the routers on the path is only to send ICMP unreachable when packet is too big for the MTU and the DF bit is set (and it's always set for PMTUD). A special case is when routers themselves are initiating TCP connections (e.g. running auc).

As mentioned, I suggest not reducing MTU, or using MSS clamping because PMTUD should take care of that where needed, and leave it at max otherwise. If you do experience issues, then it makes sense. ICMP unreachable-needs-frag is a normal part of PMTUD and should be left alone and allowed.

If you reduce the MTU closer to an endpoint, then for example the Fritzbox will send the ICMP unreachable to the PC, and the PC will retry with smaller segments, so you won't see those ICMP unreachables on the next hop (OpenWRT).

2 Likes

Hello

With the new OpenWrt firmware is it possible to select and choose bands (e.g. B7 + B3 + B20 bands) like with the original Zyxel firmware? For me is important this function.

Thank you

If I may allow me to answer...

there are two ways the first is:

the second via at command:

1 Like

Is anyone using cake-autorate with this (I have for the most of the day sub-100mbps download)? How well would it functioning considering that you must disable hardware offload? I haven't made the jump to openwrt yet because I would have to reconfigure everything, but bufferbloat is killing the experience when 2-3 users are concurrent, so maybe it's time to do it.

Edit: made the jump to try cake-autorate. It works and speed seems reasonable

Hello everyone, I've been following you for a few years, and I've been tinkering with various devices, especially 4G modems and access points. I hope someone can help me, I think I have bricked the M904 modem. I did the following operations:

  1. Obtained the root password
  2. Set the Bypass and DebugFlag variables as per the procedure
  3. Flashed the Kernel partition with the firmware taken from the firmware selector
  4. Flashed the sysupgrade build from OpenWrt with the custom sysupgrade (I am trying to install luci on it) After step 4, the modem goes into a boot loop, meaning the LED blinks indefinitely, so I think I have soft-bricked it.

I tried resetting it but nothing happened.

I guess the only way to restore it is to use a TFTP server through the uboot console, which is only accessible by connecting to the serial port.

Could someone kindly help me? Could there be other ways to restore original firmware (or just the Openwrt Snapshot fw)? I am not very experienced with uboot.

I will reconstruct the next steps I should take:

  1. Connect to the console (I know how to do this)
  2. Interrupt the boot (I know how to do this)
  3. Set environment variables for IPServer and IPClient for scp/tftp transfers (I think I know how to do this)
  4. Make a copy of all partitions from uboot, so I have a backup in case of problems (I know how to do this)
  5. Write the kernel1 image of openwrt/stock image (I don't know how to do this)

Correct?

EDIT:
after i connected the TTL/Serial i was able too erase kernel1
after that the dualbooot system copied kernel2 to kernel1 and i was able to recover from bootloop

Thanks a lot

Great that you were able to unbrick it :slight_smile: I assume that when it recovered, it came back up with stock firmware? Do you have a boot log of the failed boot by any chance?

does anyone know when support for this router will make it to stable release of OpenWRT?

Next stable release.

3 Likes

Hello Merkle,

I was able to unbrick the modem.

When I attached the serial TTL, the modem was in the OpenWRT (so it was not 100% bricked) shell, so I used that shell to erase Kernel1.

Unfortunately, I don't have a copy of the bootlog, but I could see that the Kernel1 checksum did not pass. As a result, the bootloader started to copy Kernel2 to Kernel1 and rebooted again.

After that, it booted into the first version of the Zyxel original firmware.

1 Like

Are you guys using Modem Manager with this device? Could you please share your configuration?

MM will conflict with the useful apps like luci-app-3ginfo-lite and luci-app-modemband.
I suggest using the modem in MBIM mode and follow these instructions.

1 Like

I am currently more interested in the stability / reconnect features of MM, than those apps; but thanks for the suggestion.

Guys I'm having a few issues and I need help to debug, if possible. In the last two days I had frequent disconnections (but apparently not by ip change, because my ip should last 24h), and I needed to restart the wan interface every time when using uqmi. When using modemmanager instead it reattempted the connection.

Edit: with modemmanager these are the log on disconnection

Fri Jun 21 08:06:00 2024 daemon.warn [3227]: <wrn> [modem0] network reject indication received
Fri Jun 21 08:06:00 2024 daemon.warn [3227]: <wrn> [modem0]   service domain: ps
Fri Jun 21 08:06:00 2024 daemon.warn [3227]: <wrn> [modem0]   radio interface: lte
Fri Jun 21 08:06:00 2024 daemon.warn [3227]: <wrn> [modem0]   reject cause: implicitly-detached
Fri Jun 21 08:06:00 2024 daemon.warn [3227]: <wrn> [modem0]   mcc: 222
Fri Jun 21 08:06:00 2024 daemon.warn [3227]: <wrn> [modem0]   mnc: 88
Fri Jun 21 08:06:00 2024 daemon.notice [3227]: <msg> [modem0/bearer2] verbose call end reason (3,1009): [cm] implicitly-detached
Fri Jun 21 08:06:00 2024 daemon.notice [3227]: <msg> [modem0] state changed (connected -> registered)

So "network reject", I can't do nothing right? Does this happens when there is an ip change? Maybe even if the ip should change every 24h, pop maybe is saturated

Hello Guys, im new here in the Forum. First of all thanks for all the instructions, which helped me alot already! I've installed the actual snapshot on my zyxel and set it up with IceG's apps.

Speeds are same as stock firmware and for me the stability too. though the stability was never very good, it was changing between cell towers and lte/umts alot even when forcing it to use LTE only.

Right now ive v 13 on the modem and forced it with the sms tool to cell lock (nearby cell 200 meters). i found that i have a bad SINR with external and internal antenna of about -17 to -18 db.

do you think that might be the problem for the instability and do you have any suggestions for fixes?

Screenshot from 2024-06-21 12-59-08

Is the BTS you connect to 200 meters away?

try removing any external antennas and try without them

Hey there, thanks for the answer. yeah the bts is about 200 meters away. I have about the same sinr with the external and internal antennas. Just overall signal strength is less with the internal antennas. Also rsrq is a bit unstable going up and down every second. The external antenna is bidirectional and placed well without obstacles to the bts.