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.
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).
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.
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:
Obtained the root password
Set the Bypass and DebugFlag variables as per the procedure
Flashed the Kernel partition with the firmware taken from the firmware selector
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:
Connect to the console (I know how to do this)
Interrupt the boot (I know how to do this)
Set environment variables for IPServer and IPClient for scp/tftp transfers (I think I know how to do this)
Make a copy of all partitions from uboot, so I have a backup in case of problems (I know how to do this)
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
Great that you were able to unbrick it 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?
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.
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.
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?
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.
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?