Hi. I have a vendor branded Zyxel NR7101 (from Norwegian ISP Telenor) that I would like to use with OpenWRT. Unfortunately the ISP that resells them has crippled the firmware so that the web interface is inaccessible, so is SSH. It seems locked into bridge mode and I am unable to make it connect to any cellular network. Does anyone know how to flash stock FW from Zyxel on this device so that I can then flash OpenWRT? Thanks!
These procedures probably still work.
OK, and if I want to first go to stock I can use the stock image instead of the OpenWRT recovery image?
Next question; I have never used tools like Z-Loader. Can you shed some light?
thanks!
Yes. Console is required when local access has been locked down. The good news is that the device is easy to open and has a console header soldered.
Pardon my noobness here, but what do I need to make a console connection? I am assuming that the 4 pin connector is a serial (COM) interface that I need to bridge with a USB serial interface somehow? Where can I get the necessary connector or cable?
Thanks again
That should work. But make sure to set the DebugFlag as recommended first, to avoid locking yourself out in case something goes wrong.
I know about as much as I wrote on that page. But you don't need to use the x-loader. You can simply open for local ssh or web management in the stock firmware. It's just iptables blocking it. You can change those rules temporarily after getting a root shell on the console.
1 Like
The important part is to get one with matching voltages, 3.3V (the most common option) in this case. usb2serial adapters (e.g. cp2102) start around just over 1 USD/ EUR shipping on the slow ship from far east or around a fiver delivered from more local resellers within 2-3 business days.
Cool.
The goal is to get back to stock FW first, removing any restrictions that the ISP (Telenor) has put in place, so that the device behaves as a Zyxel NR7101.
So let me see if I understand:
- Get a USB Serial adapter and connect to the on-board connector.
- Connect with a terminal application as the device boots up(?)
- Temporarily enable http/https/ssh connectivity (iptables).
- Use Web GUI to flash stock Zyxel FW (?)
What happens to things like default admin password and SSID/PSK that usually is printed on a sticker on the back of the device, when I flash it like this? Is there some EEPROM/NVRAM storage that keeps these values?
Using the flash partition layout from OEM to illustrate:
[ 4.000000] Creating 10 MTD partitions on "MT7621-NAND":
[ 4.008000] 0x000000000000-0x000007f80000 : "ALL"
[ 4.020000] 0x000000000000-0x000000080000 : "Bootloader"
[ 4.032000] 0x000000080000-0x000000100000 : "Config"
[ 4.040000] 0x000000100000-0x000000140000 : "Factory"
[ 4.052000] 0x000000140000-0x000002000000 : "Kernel"
[ 4.064000] 0x000002140000-0x000004000000 : "Kernel2"
[ 4.076000] 0x000004000000-0x000004100000 : "wwan"
[ 4.084000] 0x000004100000-0x000005100000 : "data"
[ 4.096000] 0x000005100000-0x000005200000 : "rom-d"
[ 4.108000] 0x000005200000-0x000005280000 : "reserve"
Normal firmware upgrades will only write to the "Kernel" partition. All other partitions are left untouched on upgrades.
The bootloader will copy the image from "Kernel" to "Kernel2" if it decides this is required. Normally that won't happen, so you'll keep whatever initial firmware version the device had in "Kernel2" as a sort of backup. But don't trust this for anything. Booting from "Kernel2" is rarely considered by the bootloader, so it doesn't work as a generic failsafe solution.
nvram values are kept in the "Config" partition, so this is written whenever any of those variables are modified either by firmware or by bootloader. There isn't any device specific data here. There is a "serialnumber" variable, but the contents is not the real serial number (and it is the same for every device). This also goes for invalid "ethaddr" variable, which you'll have to work around to get tftp (or network at all) to work from the bootloader. Note: There are some variables here which are important to the bootloader. The DebugFlag is of special interest. If set to "0" (default), then the bootloader will not accept any input. I.e., you cannot upgrade firmware or boot from net or do anything else to fix a broken firmware. In other words: Any firmware failure while DebugFlag is set to "0" means a permanent BRICK!
To make this even worse: The OEM firmware will try to reset DebugFlag to default on every boot. So if you boot OEM once, then you have this dangerous setting. The idea is obviously to close down console access since these devices will be mounted outdoors without any physical access control. luckily for us, the OEM firmware tests DebugFlag against the string "1" before resetting it to "0". Writing "0x1" to the variable avoids the reset and is interpreted as "1" by the bootloader. But this hack depends on a bug in the OEM boot script, so it might stop working with any new OEM firmware version. Consider yourself warned: Always test that this hack still works (that you can type input to bootloader from the console) after any experiments with newer OEM firmwares. If it doesn't, then downgrade. If you can. But worst case is that they fix the bug and disable downgrades from OEM, while also disabling direct updates of the DebugFlag variable from OEM. But the latter will be very hard for them to do, so I don't think it is likely to happen.
The "data" partition has a UBIFS for userdata. The OEM firmware will mount it both under /data and every "<user home directory>/data". This partition is left untouched by firmware upgrades, so anything stored here is persistent over upgrades. The OEM firmware uses it for anything wanting persistent storage. I don't think there is ever anything critical here. Files will be created as required. But I suggest leaving this file system as is to allow smooth transitions between OEM and OpenWrt, or between different OEM versions.
The other partitions are never updated by anything, and I suggest you don't change any of them either. The "wwan", "rom-d" and "reserve" partitions are empty, so it probably doesn't matter much.
The real serialnumber and other device specific data like certificates etc are stored in the "Factory" partition. As long as you don't write to this partition (and DON'T do that) you should be able to restore the device to original. Note that there is no one who can help you recreate this partition. It is device specific and unique to your router. You should make a backup of if as soon as possible.
You''ll also have to make a backup copy of the original "Kernel" (and/or Kernel2") if you ever want to go back to the Telenor firmware. It isn't available for public download, and is required for Telenor to adopt the device it their management system. It's easiest not having to call Telenor to get a copy 
Last fun fact: Note the hole between "Kernel" and "Kernel2". You'd think it's empty. But it isn't (at least it wasn't on any of my devices). There's a jffs2 file system at 0x2100000 with lots of OpenWrt config files. That's where I found all the GPIO hints for this router. Needless to say, my suggestion is to leave this hole as-is too. Unless you know you'll never want to go back to the original
EDIT: One final warning: Remove any valid Telenor SIM while running the Telenor OEM firmware. Or the device might be captured by their management system. Using a Telenor SIM with OpenWrt is of course safe. And probably also with the generic ZyXEL OEM firmware.
EDIT2: Wasn't sure I should write this, but as required by personal integrity.... DISCLAIMER: I work for Telenor. All information provided above is based solely on a hobby project usiing a Telenor branded NR7101 I bought used on "finn" for my own money. But I do also have a Telenor provided NR7101 for work purposes. And I do use everything I learn from all my hobby projects in my daytime job. Just not the other way around.
4 Likes
Thanks Bjørn. That is a great write up. I think this should be part of the device page here on the forum. Thank you for your help and candour.
I did boot my device with one of my Telenor data SIMs inserted, as this seemed to be required per the Zyxel docs. My unit was never able to establish a connection though (the LED kept blinking green). Does this mean that the device has already been captured and will only work with a certain SIM or something like that? What does such a capture actually do? Does it grant some sort of management access? If so; how?
Regarding the boot loader debug flag. Is it correctly understood that a working firmware is the only way to change this flag in the config partition? And that it is the actual firmware that resets it to 0, and not the bootloader itself?
My serial adapters are in the mail. Once they arrive I will attempt the steps I outlined above and report on the result.
As you seem to have run both the OEM firmware and OpenWRT on this device, what is your recommendation on which to use?
Thanks again.
The FWA service is fully managed. This includes everything, such as firmware upgrades, user management and network configuration. Great for most users. But it might conflict with local management. Removing the SIM is a simple way to make sure the centralized management is disabled.
It's probably wrong to describe this as "capturing" the device. The management is part of what you subscribe to with a Telenor FWA service. It's not an addon. It's an integrated part of the service.
Correct as far as I know. But this is only based on my observations of the firmware and bootloader. I could easily have missed something.
That depends on what you want and what you expect. The OEM firmware is easy to configure and works really well. OpenWrt can do almost anything. But configuration of wwan devices is much harder. There still isn't and plug-and-play wwan "bridging" support in OpenWrt yet. Likewise for multiple APNs. Both can be done, but only with some effort.
1 Like
Hi. An update on this project. A PL2303TA USB cable arrived today. Following your PIN out documentation from the device page here at OpenWRT I connected it to the NR7101. However, the NR7101 does not boot when the adapter is connected and picocom does not provide any output. I have tried switching RX/TX and also connecting just RX or TX to the router. If I connect what the cable claims to be TX plus GND to either RX or TX on the router, it boots but no output is received. If I connect the adapter's RX connector to either RX or TX on the router it does not. Any ideas what might be going on?
Also, is it important what sequence things are connected in? I have unplugged the adapter cable and power to the router when I make connections to the PINs on it. I then connect the adapter to the computer, and finally power the router.
One final note. On the device page you write that the baud rate for the NR7101 is 57600, but in your terminal logs from the modem upgrade picocom seems to use 9600. What is the correct value?
Thanks again.
No idea. Didn't have any such issues with the adapters I used. Measure the voltage on all pins of your USB adapter if you have a multimeter. My experience is that many of these fake adapters are badly designed, using too high IO voltages for 3.3V devices.
No. It should be connected before either end is powered on. Then the order doesn't matter. I don't think there is a safe order if anything ispowered.
It's 57600 for the NR7101 console.
The picocom session connects to the RG502Q-EA modem from the NR7101 main SoC. That's something different. In fact,there isn't any serial connection involved at all in that case so the speed probably doesn't matter. It's a USB host (the NR7101) talking to a USB device (the RG502Q).
As a functionality test, short the RT and TX pins of the adapter, whatever you type in your terminal app (Putty ?) should be echoed back to you ...
1 Like
Thanks for the til @frollic. If I short RX and TX I do indeed get back my own input in picocom. If I type an A I get an A. I take this to do what you meant? I guess we can assume that the adapter is not broken outright.
Hi @bmork
The voltage between GND and RX (white on my adapter) is 3.25 V and between GND and TX (green on my adapter) it is 3.4 V. Between GND and the last lead (red) I have 5 V. According to https://openwrt.org/docs/techref/hardware/port.serial.cables anything above 3.3 is dangerous. What is within tolerance?
My fear now is that this adapted has fried something on the router. I measured the voltage between GND and TX on it and I get some fluctuation but 3.21 V max. Between GND and RX I get 3.24V stable. I am not going to connect this adapter again before I have more data 
Thanks
Those values sound good to me, and should be well within tolerance.
We don't know the precise specs of the console header, but 3.6V or Vcc +10% is often a good guess for the max value. Ref for example https://learn.sparkfun.com/tutorials/logic-levels/33-v-cmos-logic-levels
So everything is as expected, except that it doesn't work. Can't explain that...
The most likely issue is with the adapter. I also have a CP2102 adapter incoming. Will wait for that and see if it works then. In the meantime; can anyone recommend an adapter? Something that is confirmed to be working. Thanks.
Hello again. New CP2101 adapter has arrived and is working. Have successfully connected to the router and removed the iptables chains that were blocking local network http/https. I can now access the web GUI.
I would like to backup the old firmware (Kernel) and Factory partitions as you suggested @bmork How exactly can I do that and where is it safe to store them temporarily so I can download them with scp later?
I did a backup of the config in the web GUI. Is this a backup of the data partition?
I am also wondering about the steps needed to go back to stock. Should I first use the current firmware's 'Reset to factory defaults' before flashing OEM? What does factory default even mean when running the custom ISP FW? I did a factory reset using the button on the router, but that only reset it to whatever the custom FW has as default, how to go back to OEM defaults?
Thanks!