Flash on Zyxel NR7101

Gain access to GUI.

How?

Not so easy when the generated password is not working.

I just logged in as 'admin' using the password on the back of the router and was able to flash just fine that way.

1 Like

That's a bit unexpected, but obviously possible. They might have changed or removed the default password in newer units.

Sorry, I don't have any suggestions then. I was stuck until I discovered the password during the intiial exploration of this device. Almost gave up actually

The problem with the Norwegian Telenor branded units is that all local management is disabled by iptables rules. The ssh, telnet and web server ports are blocked on both LAN and WAN. And WiFi is disabled. This is the factory default settings on these units.

Since there is no user interface, there are no accounts available for end users either. Not even "admin" . The label on the Telenor units is a sign of this - it contains no passwords at all. But that's the official story. The default accounts have not been disabled. They exist and have valid passwords.

The bootloader is locked down, not accepting any input on serial. So there is no way to boot something different than the installed firmware without unlocking the bootloader console.

This is why it is necessary to gain access to a root shell in the Telenor firmware to be able to install OpenWrt on these units. There are no other ways in. But as you point out: This is not a generic NR7101 problem. It's specific to the Telenor version. Many firmwares allow LAN access to web and/or ssh management. The "consumer" variant obviously does. Installing OpenWrt on such units is a simple matter of flashing the OpenWrt initramfs from the OEM web GUI.

2 Likes

I have a hardware question about this device. Would you expect a software reset of the modem to power cycle it, and if this were to occur overly rapidly, could this in theory damage the device? Or does software reset just blank out memory such that software resets won't hurt it? I ask because of the exploration of options for reconnecting upon disconnect - one quick fix is simply to call call 'ifup' once netifd sees a disconnection, but perhaps in some cases this could result in repeated software resets, so not sure if that's an issue to worry about or not.

No, a software reset won't power cycle the modem. But a router reset might? Don't remember.

There are three(!) GPIOs controlling the modem from the host SoC. IThey control modem power and reset line. I have no idea what the third one is suppsoed to do, but I believe that's also power related. Any of these are capable of power cycling the modem. But I don't think we use them for anything by default. The one connected to the reset line is exposed to userspace as a "gpio_switch" named 'lte_reset'. The two others are declared as "gpio-hog" in the dts. Meaning that they are unconditionally enabled on boot and that's it.

Running ifup/ifdown or software resetting the modem is definitely safe.

Pulling the power, aka ethernet cable, or doing modem firmware upgrades is a slightly more risky. But I wouldn't worry too much. I haven't killed any of my two units yet. And I am not treating them nicely :slight_smile:

1 Like

@bmork I thank you sincerely once again for taking the trouble to respond to my many queries. I am still just using this device inside my house (where are electricians in the Scottish Highlands when you need them?), behind a 1-metre thick sandstone wall, and I still get fairly decent stats:

root@OpenWrt:~# mmcli -m any --signal-get
  ----------------------
  Signal | refresh rate: 5 seconds
  ----------------------
  LTE    |         rssi: -71.00 dBm
         |         rsrq: -8.00 dB
         |         rsrp: -97.00 dBm
         |          s/n: 20.00 dB

And it's certainly fun to have OpenWrt on the device itself to play with.

@bmork I wonder about your thoughts on the following.

The latest ModemManager includes a '10-report-down' script to report to netifd a modem disconnection. I hacked this to check whether the interface was originally up before reporting the interface as down, and after having reported the interface as down, then bring the interface back up again with 'ifup', as follows:

root@OpenWrt:/lib/netifd/proto# cat /usr/lib/ModemManager/connection.d/10-report-down-and-reconnect
#!/bin/sh

# Report modem disconnect to netifd and reconnect if the interface was up

# require program name and at least 4 arguments
[ $# -lt 4 ] && exit 1

MODEM_PATH="$1"
BEARER_PATH="$2"
INTERFACE="$3"
STATE="$4"

[ "${STATE}" = "disconnected" ] || exit 0

. /usr/share/ModemManager/modemmanager.common
. /lib/netifd/netifd-proto.sh
INCLUDE_ONLY=1 . /lib/netifd/proto/modemmanager.sh

MODEM_STATUS=$(mmcli --modem="${MODEM_PATH}" --output-keyvalue)
[ -n "${MODEM_STATUS}" ] || exit 1

MODEM_DEVICE=$(modemmanager_get_field "${MODEM_STATUS}" "modem.generic.device")
[ -n "${MODEM_DEVICE}" ] || exit 2

CFG=$(mm_get_modem_config "${MODEM_DEVICE}")
[ -n "${CFG}" ] || exit 3

IFUP=$(ifstatus ${CFG} | jsonfilter -e '@.up')

logger -t "modemmanager" "interface ${CFG} (network device ${INTERFACE}) ${STATE}"
proto_init_update $INTERFACE 0
proto_send_update $CFG

[ "${IFUP}" = "true" ] && ifup ${CFG}

exit 0

So I just added the ifup check and ifup call to sandwhich the report to netifd that the interface has gone down, as follows:

IFUP=$(ifstatus ${CFG} | jsonfilter -e '@.up')

logger -t "modemmanager" "interface ${CFG} (network device ${INTERFACE}) ${STATE}"
proto_init_update $INTERFACE 0
proto_send_update $CFG

[ "${IFUP}" = "true" ] && ifup ${CFG}

Please let me know if any obvious improvement is readily apparent to you.

This results in automatic reconnection, but it is somewhat slow in that on checking my logs I see that a disconnect event occurred at 11:18:08 and then wan got back up 11:18:13 (so around 5 to 6 seconds to fully reconnect). Here is the log:

Mon Nov  7 11:18:08 2022 daemon.info [2727]: <info>  [modem0/bearer27] verbose call end reason (6,36): [3gpp] regular-deactivation
Mon Nov  7 11:18:08 2022 daemon.info [2727]: <info>  [modem0] state changed (connected -> registered)
Mon Nov  7 11:18:08 2022 daemon.info [2727]: <info>  [modem0/bearer27] connection #1 finished: duration 172799s, tx: 3431975022 bytes, rx: 27023076800 bytes
Mon Nov  7 11:18:09 2022 user.notice modemmanager: interface wan (network device wwan0) disconnected
Mon Nov  7 11:18:09 2022 daemon.notice netifd: Interface 'wan' has lost the connection
Mon Nov  7 11:18:09 2022 daemon.notice netifd: Network device 'wwan0' link is down
Mon Nov  7 11:18:09 2022 daemon.warn dnsmasq[1]: no servers found in /tmp/resolv.conf.d/resolv.conf.auto, will retry
Mon Nov  7 11:18:09 2022 daemon.notice netifd: wan (13635): stopping network
Mon Nov  7 11:18:09 2022 daemon.notice netifd: wan (13635): running disconnection (common)
Mon Nov  7 11:18:09 2022 daemon.notice netifd: wan (13635): Command failed: ubus call network.interface notify_proto { "action": 0, "link-up": false, "keep": false, "interface": "wan" } (Permission denied)
Mon Nov  7 11:18:09 2022 daemon.notice netifd: wan (13635): successfully disconnected all bearers in the modem
Mon Nov  7 11:18:09 2022 daemon.info [2727]: <info>  [modem0] state changed (registered -> disabling)
Mon Nov  7 11:18:10 2022 daemon.info [2727]: <info>  [modem0] 3GPP registration state changed (home -> unknown)
Mon Nov  7 11:18:10 2022 daemon.info [2727]: <info>  [modem0] state changed (disabling -> disabled)
Mon Nov  7 11:18:10 2022 daemon.notice netifd: wan (13635): successfully disabled the modem
Mon Nov  7 11:18:10 2022 daemon.notice netifd: Interface 'wan' is now down
Mon Nov  7 11:18:10 2022 daemon.notice netifd: Interface 'wan' is setting up now
Mon Nov  7 11:18:10 2022 daemon.notice netifd: wan (13683): modem available at /org/freedesktop/ModemManager1/Modem/0
Mon Nov  7 11:18:10 2022 daemon.notice netifd: wan (13683): starting connection with apn 'wap.vodafone.co.uk'...
Mon Nov  7 11:18:10 2022 daemon.info [2727]: <info>  [modem0] simple connect started...
Mon Nov  7 11:18:10 2022 daemon.info [2727]: <info>  [modem0] simple connect state (3/8): enable
Mon Nov  7 11:18:10 2022 daemon.info [2727]: <info>  [modem0] state changed (disabled -> enabling)
Mon Nov  7 11:18:10 2022 daemon.info [2727]: <info>  [modem0] power state updated: on
Mon Nov  7 11:18:11 2022 daemon.info [2727]: <info>  [modem0] simple connect state (4/8): wait to get fully enabled
Mon Nov  7 11:18:12 2022 daemon.info [2727]: <info>  [modem0] state changed (enabling -> enabled)
Mon Nov  7 11:18:12 2022 daemon.info [2727]: <info>  [modem0] simple connect state (5/8): register
Mon Nov  7 11:18:12 2022 daemon.info [2727]: <info>  [modem0] 3GPP registration state changed (unknown -> registering)
Mon Nov  7 11:18:12 2022 daemon.info [2727]: <info>  [modem0] 3GPP registration state changed (registering -> home)
Mon Nov  7 11:18:12 2022 daemon.info [2727]: <info>  [modem0] state changed (enabled -> registered)
Mon Nov  7 11:18:12 2022 daemon.info [2727]: <info>  [modem0] simple connect state (6/8): bearer
Mon Nov  7 11:18:12 2022 daemon.info [2727]: <info>  [modem0] simple connect state (7/8): connect
Mon Nov  7 11:18:12 2022 daemon.info [2727]: <info>  [modem0] state changed (registered -> connecting)
Mon Nov  7 11:18:12 2022 daemon.info [2727]: <info>  [modem0/bearer29] QMI IPv4 Settings:
Mon Nov  7 11:18:12 2022 daemon.info [2727]: <info>  [modem0/bearer29]     address: 10.13.xx.yy/30
Mon Nov  7 11:18:12 2022 daemon.info [2727]: <info>  [modem0/bearer29]     gateway: 10.13.xx.zz
Mon Nov  7 11:18:12 2022 daemon.info [2727]: <info>  [modem0/bearer29]     DNS #1: 192.168.aa.1
Mon Nov  7 11:18:12 2022 daemon.info [2727]: <info>  [modem0/bearer29]     DNS #2: failed (Field 'Secondary IPv4 DNS Address' was not found in the message)
Mon Nov  7 11:18:12 2022 daemon.info [2727]: <info>  [modem0/bearer29]        MTU: 1500
Mon Nov  7 11:18:13 2022 daemon.info [2727]: <info>  [modem0/bearer29] couldn't start network: QMI protocol error (14): 'CallFailed'
Mon Nov  7 11:18:13 2022 daemon.info [2727]: <info>  [modem0/bearer29] verbose call end reason (2,210): [internal] pdn-ipv6-call-disallowed
Mon Nov  7 11:18:13 2022 daemon.info [2727]: <info>  [modem0] state changed (connecting -> connected)
Mon Nov  7 11:18:13 2022 daemon.info [2727]: <info>  [modem0] simple connect state (8/8): all done
Mon Nov  7 11:18:13 2022 daemon.notice netifd: wan (13683): successfully connected the modem
Mon Nov  7 11:18:13 2022 daemon.notice netifd: wan (13683): signal refresh rate is not set
Mon Nov  7 11:18:13 2022 daemon.notice netifd: wan (13683): network operator name: voda UK
Mon Nov  7 11:18:13 2022 daemon.notice netifd: wan (13683): network operator MCCMNC: 23415
Mon Nov  7 11:18:13 2022 daemon.notice netifd: wan (13683): registration type: home
Mon Nov  7 11:18:13 2022 daemon.notice netifd: wan (13683): access technology: lte
Mon Nov  7 11:18:13 2022 daemon.notice netifd: wan (13683): signal quality: 63%
Mon Nov  7 11:18:13 2022 daemon.notice netifd: wan (13683): IPv4 connection setup required in interface wan: static
Mon Nov  7 11:18:13 2022 daemon.notice netifd: wan (13683): adding IPv4 address 10.13.xx.yy, netmask 255.255.255.252
Mon Nov  7 11:18:13 2022 daemon.notice netifd: wan (13683): adding default IPv4 route via 10.13.xx.zz
Mon Nov  7 11:18:13 2022 daemon.notice netifd: wan (13683): adding primary DNS at 192.168.aa.1
Mon Nov  7 11:18:13 2022 daemon.notice netifd: Interface 'wan' is now up
Mon Nov  7 11:18:13 2022 daemon.info dnsmasq[1]: reading /tmp/resolv.conf.d/resolv.conf.auto
Mon Nov  7 11:18:13 2022 daemon.notice netifd: Network device 'wwan0' link is up
Mon Nov  7 11:18:13 2022 daemon.info dnsmasq[1]: using nameserver 192.168.aa.1#53
Mon Nov  7 11:18:13 2022 daemon.info dnsmasq[1]: using only locally-known addresses for test
Mon Nov  7 11:18:13 2022 daemon.info dnsmasq[1]: using only locally-known addresses for onion
Mon Nov  7 11:18:13 2022 daemon.info dnsmasq[1]: using only locally-known addresses for localhost
Mon Nov  7 11:18:13 2022 daemon.info dnsmasq[1]: using only locally-known addresses for local
Mon Nov  7 11:18:13 2022 daemon.info dnsmasq[1]: using only locally-known addresses for invalid
Mon Nov  7 11:18:13 2022 daemon.info dnsmasq[1]: using only locally-known addresses for bind
Mon Nov  7 11:18:13 2022 daemon.info dnsmasq[1]: using only locally-known addresses for lan
Mon Nov  7 11:18:14 2022 user.notice firewall: Reloading firewall due to ifup of wan (wwan0)

Do you think that this could be sped up at all?

Could it perhaps be sped up by trying to get the modem's built in '--set-autoconnect enabled' functionality to work?

Is there a way to have the modem just handle all the IP stuff so that we don't have to worry about IP settings and just let the modem itself reconnect and get treated as an ethernet device?

Do you know how the Zyxel firmware handles this reconnection issue?

Zyxel firmware use quectel-CM as connection manager, have qualcom multiplex over QMI, and use unsolicited message from the modem.
It's not the fastest way, but it works.
Chateau 5G, wich have the same modem, does a really better job on this point, too bad you can't flash RouterOS on zyxel :joy:

How long does the reconnect take with quectel-CM (from disconnect up to usable connection)?

like, 25/45 sec.
If you mean for changes etc, it restart a pretty long routine, can take up to 5 min lol, depends what you do.
but if you mean a normal reconnect, it averages 45 sec, if it is because of some bts changes.
What is your disconnect exactly? Band change? IP Renew?

Thanks for the info. Yikes - 45 seconds. That makes my 5 seconds seem pretty darn good. It seems Vodafone UK forcibly disconnect connections "[3gpp] regular-deactivation" at exactly the 48 hour mark, necessitating reconnection. I think even this 5 can be brought down a bit, but I don't entirely understand this sequence that I have hacked together:

IFUP=$(ifstatus ${CFG} | jsonfilter -e '@.up')

logger -t "modemmanager" "interface ${CFG} (network device ${INTERFACE}) ${STATE}"
proto_init_update $INTERFACE 0
proto_send_update $CFG

[ "${IFUP}" = "true" ] && ifup ${CFG}

And whether there is a way to speed the above up, either by modifying that or switching to the modem's autoconnect feature.

Lol are you bothering for 5 seconds?
Anyway don't think so, that's the way it works,to renew the ip on the interface, it have to get it down, then up again.
Also, if it is not a FWA contract, but a normal mobile contract, you are not supposed to be connected 24/7, and it can get you on lower priority, maybe it is just a way your mobile isp have, to check if your device is still alive.
Ask @bmork , he have done a good part of the work on QMI and MBIM, maybe he knows bettter.
Still, for 5 seconds, i would sleep tight overnight, there are worst scenario, 5 seconds is gold :stuck_out_tongue:

1 Like

What signal stats do you / others see? I have finally got this mounted on the outside of my house and see:

root@OpenWrt:~# mmcli -m any --signal-get
  ----------------------
  Signal | refresh rate: 5 seconds
  ----------------------
  LTE    |         rssi: -49.00 dBm
         |         rsrq: -11.00 dB
         |         rsrp: -72.00 dBm
         |          s/n: 22.00 dB

Those are pretty good, right?

Outside the usual congested periods I see bandwidth with bufferbloat (without cake-autorate) of circa 70-80 Mbit/s download and 20-30 Mbit/s upload.

I haven't tried to optimize the azimuth and elevation angles beyond having the electrician just generally point it at the cell tower. Might I get much benefit in doing so at this point I wonder?

I have the feeling that I am now maxing out what I can get from my local cell tower with its being limited to band 20 only and 10 Mhz bandwidth, with download and upload now just subject only to the load on the cell and perhaps its downlink connection. That was the goal in purchasing this device, anyway. And it runs OpenWrt too!

B20 only is a pretty nice result,even a waste, zyxel is a 5G Modem, it can reach 600 mbit on download easily.
You need a better BTS there, to use Zyxel @ full potential.

Hey,

What are the exact steps to return to stock firmware? I'd like to return my unit.

@bmork I'm trying to go back to stock firmware. But I get "-ash: can't create /dev/mtdX: Permission denied" for the following partitions:

  • mtd0 Bootloader
  • mtd2 Factory
  • mtd8 rom-d

Is it still okay?

I would normally not touch those partitions unless there was a good reason. You should only need to replace the "Kernel" and/or "Kernel2" to switch OS, including moving between OpenWrt and stock

@bmork how to check whether connected via 4G or 3G (and force 4G if that's a good idea)? I see 'mmcli -m any' shows up allowed modes, but I can't see how to see which mode is presently active.