SSH in to the router and run the following for each partition (X is the partition number) -
Example backup : cat /dev/mtdX > /tmp/X.bin
cat /dev/mtd0 > /tmp/0.bin
Example restore : cat /tmp/X.bin > /dev/mtdX
cat /tmp/0.bin > /dev/mtd0
The mtd files are saved in /tmp
Using LuCI -
System > Backup/Flash Firmware
The mtd files are saved to your local hardrive.
Backing up the config does not save packages you've added after upgrading.
They will need to be re-installed.
I've neveru used the GUI backup tool so I don't know. But I assume it's just backing up the config file. Which is completely useless. The Telenor firmware always boots from factory default.
You'll need to do what @anon89577378 suggests: Read and save each /dev/mtdX device, and then copy it out to a safe storage outside the router. There is no USB port so network the only option. I suggest using scp from a connected PC.
Temporarily storing the copies in /tmp is fine since this is a ramdisk. Note that you might need to do one-by-one partition and delete the /tmp copies after transferring to avoid running out of space (i.e. ram). It might also help compressing the images before transfer, using something like
cat /dev/mtd0ro | gzip -9c >/tmp/mtd0.bak.gz
and then retrieve it from the connected PC:
scp root@nt7101.ip.address:/tmp/mtd0.bak.gz /some/where/safe
Run
cat /proc/mtd
to get the full list of partitions and the size of each. Observe that mtd0 ("ALL") is special, covering all the flash including all the other partitions. It's still useful to have a copy of it as there are some holes with content, as I've documented.
New update!
Did a backup of all the partitions, including "ALL". What is the difference between mtd0 and mtd0ro?
Flashed ZyXEL's latest FW. This went fine and the device seemed mostly to revert to stock settings. There are a couple of things hanging around, even after I perform a reset to defaults on the zyxel FW:
I get no Internet for any clients connected to the Wifi of the router, but clients connected to the ethernet port do. Can't really find anything that can account for that. Anyone know if this is by design, or how this can be fixed?
EDIT: Found out that this is actually by design. Zyxel considers the wifi to only be for management: https://support.zyxel.eu/hc/en-us/articles/4403445339026-NR7101-No-internet-though-the-built-in-WIFI
I have been using @bmork's tool to get the supervisor password, but I also wanted to find the password for the admin user, and I found a trick to do that:
Download the /data/zcfg_config.json and find the encrypted string of the default password for the admin user. It starts with encrypted and includes what looks like base64 (but is not). If you then enter this encrypted string into the Dynamic DNS password of the Web GUI, the FW will decrypt it to the cleartext value. This is not my discovery. All credit goes to Thomas Rinsma (https://th0mas.nl/2020/03/26/getting-root-on-a-zyxel-vmg8825-t50-router/). This apparently works for all encrypted stings.
SSH in to the router and run cat /proc/mtd
A description of each partition is included in the list.
Thanks, I have done that. But in /dev there are both mtd0 and mtd0ro eg. All the mtd partitions exist in pairs. I was wondering what was the difference between them.
M
Post the output of cat /proc/mtd
I suspect @bmork explained it here...
Here's my output:
root@NR7101:~# cat /proc/mtd
dev: size erasesize name
mtd0: 07f80000 00020000 "ALL"
mtd1: 00080000 00020000 "Bootloader"
mtd2: 00080000 00020000 "Config"
mtd3: 00040000 00020000 "Factory"
mtd4: 01ec0000 00020000 "Kernel"
mtd5: 01ec0000 00020000 "Kernel2"
mtd6: 00100000 00020000 "wwan"
mtd7: 01000000 00020000 "data"
mtd8: 00100000 00020000 "rom-d"
mtd9: 00080000 00020000 "reserve"
But then there's:
root@NR7101:~# ls -laX /dev/mtd*
crw-r--r-- 1 root root 90, 0 Jan 1 1970 /dev/mtd0
crw-r--r-- 1 root root 90, 1 Jan 1 1970 /dev/mtd0ro
crw-r--r-- 1 root root 90, 2 Jan 1 1970 /dev/mtd1
crw-r--r-- 1 root root 90, 3 Jan 1 1970 /dev/mtd1ro
crw-r--r-- 1 root root 90, 4 Jan 1 1970 /dev/mtd2
crw-r--r-- 1 root root 90, 5 Jan 1 1970 /dev/mtd2ro
crw-r--r-- 1 root root 90, 6 Jan 1 1970 /dev/mtd3
crw-r--r-- 1 root root 90, 7 Jan 1 1970 /dev/mtd3ro
crw-r--r-- 1 root root 90, 8 Jan 1 1970 /dev/mtd4
crw-r--r-- 1 root root 90, 9 Jan 1 1970 /dev/mtd4ro
crw-r--r-- 1 root root 90, 10 Jan 1 1970 /dev/mtd5
crw-r--r-- 1 root root 90, 11 Jan 1 1970 /dev/mtd5ro
crw-r--r-- 1 root root 90, 12 Jan 1 1970 /dev/mtd6
crw-r--r-- 1 root root 90, 13 Jan 1 1970 /dev/mtd6ro
crw-r--r-- 1 root root 90, 14 Jan 1 1970 /dev/mtd7
crw-r--r-- 1 root root 90, 15 Jan 1 1970 /dev/mtd7ro
crw-r--r-- 1 root root 90, 16 Jan 1 1970 /dev/mtd8
crw-r--r-- 1 root root 90, 17 Jan 1 1970 /dev/mtd8ro
crw-r--r-- 1 root root 90, 18 Jan 1 1970 /dev/mtd9
crw-r--r-- 1 root root 90, 19 Jan 1 1970 /dev/mtd9ro
brw-r--r-- 1 root root 31, 0 Jan 1 1970 /dev/mtdblock0
brw-r--r-- 1 root root 31, 1 Jan 1 1970 /dev/mtdblock1
brw-r--r-- 1 root root 31, 2 Jan 1 1970 /dev/mtdblock2
brw-r--r-- 1 root root 31, 3 Jan 1 1970 /dev/mtdblock3
brw-r--r-- 1 root root 31, 4 Jan 1 1970 /dev/mtdblock4
brw-r--r-- 1 root root 31, 5 Jan 1 1970 /dev/mtdblock5
brw-r--r-- 1 root root 31, 6 Jan 1 1970 /dev/mtdblock6
brw-r--r-- 1 root root 31, 7 Jan 1 1970 /dev/mtdblock7
brw-r--r-- 1 root root 31, 8 Jan 1 1970 /dev/mtdblock8
brw-r--r-- 1 root root 31, 9 Jan 1 1970 /dev/mtdblock9
So for every mtdn there is a mtdnro and mtdblockn-1. These might all be different names for the same thing, but I noticed that @bmork used the mtd0ro in his example on how to back up all the partitions, but neither you nor him used that when backing up individual partitions.
I've got those as well.
mtdro are read-only devices mapping to the same partitions as their mtd counterparts. Extra safe-guard against accidents.
The unique device certificate and private key is stored in the "Factory" partition. If you delete this certificate then you'll have to restore it from backup if you ever want to make the device work with Telenor again. And if you mess up this partition then you'll probably have a brick. I don't see any reason to risk that. Is there any harm in having the certificate available?
Yes, the wifi is not meant for normal use. I wouldn't bother with it. Use a second indoor router for wifi.
Hi
I agree; it does no harm. I am more concerned if there are things left in iptables etc. that might either compromise the device or allow it to be managed or accessed remotely. If you know of anything in particular to check, please let me know.
I did set the DebugFlag to 0x1 as you suggested, and this seems to persist across boots with the stock V4 firmware. Can you explain what the CheckBypass flag does?
I have verified connectivity with one of my data SIMs so the time is fast approaching to install this device in its intended location. I am also considering painting it to match the building it will be mounted on.
Thanks for all your help so far. I will keep you updated on progress 
The persistent state surviving firmware upgrades is the bootloader variables stored in "Config", the factory programmed device specific settings in"Factory" and whatever is stored in "data". The last one is the only place where OS config stuff could be saved. But I don't think there is anything there since Telenor always boots it from factory default.
Yes, and then there is all the stuff stored on the modem module. But except for some APNs etc, I don't think you'll find anything operator specific there.
A warning about the DebugFlag trick if you keep running the ZyXEL firmware: This is abusing a pretty obvious bug in the ZyXEL init scripts. They could fix that with any new release, disabling your access to the bootloader.
I believe CheckBypass tells the bootloader to skip image validation. Optimizing boot by only validating the firmware images when they've been updated. Note that the ZyXEL firmware never writes anything to the "Kernel" or "Kernel2" partitions, except for firmware upgrades-
Sorry, how do you modify this value? you need to do it by serial console, or can you set it whit standard ssh?
Sorry to get inside this thread all of a sudden. im gonna use a ROOter version of openwrt, and im trying to understand how to use openwrt in a safe way.
I have a Normal Zyxel NR7101 no brand, so whit normal stock firmware. Actually i have
100ABUV5C0 firmware version. Upgraded module whit RG502QEAAAR01A04-R11A03.
A friend did a try whit RG502QEAAAR11A03-A06 module firmware, but was having problems.
Can i know best way to set it up to openwrt, either by ssh or gui, and how i can actually go back to stock firmware in a safe way?
Also the only module firmware i can use is those given by zyxel, or i could use those provided by Quectel?
Is anyone running Openwrt as a daily driver on Zyxel NR7101 already? or did you just boot from ram and backup the partitions?
@bmork After flashing to OpenWrt successfully, I've got two questions.
How can I revert to stock? As soon the initramfs booted, I took copies of all mtd[0-9]ro blocks to my computer.
I see the following network interfaces:
root@OpenWrt:~# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1504 qdisc fq_codel state UP qlen 1000
link/ether d8:ec:e5:08:90:9c brd ff:ff:ff:ff:ff:ff
inet6 fe80::daec:e5ff:fe08:909c/64 scope link
valid_lft forever preferred_lft forever
3: lan@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-lan state UP qlen 1000
link/ether d8:ec:e5:08:90:9c brd ff:ff:ff:ff:ff:ff
4: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
link/ether d8:ec:e5:08:90:9d brd ff:ff:ff:ff:ff:ff
5: wwan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN qlen 1000
link/ether 76:a2:b2:4d:64:7a brd ff:ff:ff:ff:ff:ff
inet6 fe80::74a2:b2ff:fe4d:647a/64 scope link
valid_lft forever preferred_lft forever
6: br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
link/ether d8:ec:e5:08:90:9c brd ff:ff:ff:ff:ff:ff
inet 192.168.1.1/24 brd 192.168.1.255 scope global br-lan
valid_lft forever preferred_lft forever
inet6 fdba:727a:8cef::1/60 scope global noprefixroute
valid_lft forever preferred_lft forever
inet6 fe80::daec:e5ff:fe08:909c/64 scope link
valid_lft forever preferred_lft forever
I've configured "wan" in /etc/config/network to use the device "wwan0". But it doesn't get an IP address via DHCP.
The device /dev/cdc-wdm0 is there, but this command never finishes (no output, waiting forever).
uqmi -d /dev/cdc-wdm0 --get-data-status
I'd appreciate your help on this.
Kind regards.
P.S. Those devices are present:
root@OpenWrt:~# cat /sys/kernel/debug/usb/devices
+
T: Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=480 MxCh= 2
B: Alloc= 0/800 us ( 0%), #Int= 0, #Iso= 0
D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=1d6b ProdID=0002 Rev= 5.10
S: Manufacturer=Linux 5.10.100 xhci-hcd
S: Product=xHCI Host Controller
S: SerialNumber=1e1c0000.xhci
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub
E: Ad=81(I) Atr=03(Int.) MxPS= 4 Ivl=256ms
T: Bus=02 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=5000 MxCh= 1
B: Alloc= 0/800 us ( 0%), #Int= 0, #Iso= 0
D: Ver= 3.00 Cls=09(hub ) Sub=00 Prot=03 MxPS= 9 #Cfgs= 1
P: Vendor=1d6b ProdID=0003 Rev= 5.10
S: Manufacturer=Linux 5.10.100 xhci-hcd
S: Product=xHCI Host Controller
S: SerialNumber=1e1c0000.xhci
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub
E: Ad=81(I) Atr=03(Int.) MxPS= 4 Ivl=256ms
T: Bus=02 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=5000 MxCh= 0
D: Ver= 3.20 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 9 #Cfgs= 1
P: Vendor=2c7c ProdID=0800 Rev= 4.14
S: Manufacturer=Quectel
S: Product=RG502Q-EA
S: SerialNumber=af5741f8
C:* #Ifs= 5 Cfg#= 1 Atr=a0 MxPwr=896mA
I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option
E: Ad=81(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
E: Ad=01(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
E: Ad=83(I) Atr=03(Int.) MxPS= 10 Ivl=32ms
E: Ad=82(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
E: Ad=02(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
E: Ad=85(I) Atr=03(Int.) MxPS= 10 Ivl=32ms
E: Ad=84(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
E: Ad=03(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
E: Ad=87(I) Atr=03(Int.) MxPS= 10 Ivl=32ms
E: Ad=86(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
E: Ad=04(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
I:* If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan
E: Ad=88(I) Atr=03(Int.) MxPS= 8 Ivl=32ms
E: Ad=8e(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
E: Ad=0f(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
Uh oh, what does that mean in "logread -f"?
Wed Feb 16 21:03:20 2022 kern.warn kernel: [ 948.223590] ------------[ cut here ]------------
Wed Feb 16 21:03:20 2022 kern.warn kernel: [ 948.232838] WARNING: CPU: 0 PID: 0 at net/sched/sch_generic.c:467 dev_watchdog+0x2f4/0x2fc
Wed Feb 16 21:03:20 2022 kern.info kernel: [ 948.249310] NETDEV WATCHDOG: wwan0 (qmi_wwan): transmit queue 0 timed out
Wed Feb 16 21:03:20 2022 kern.warn kernel: [ 948.262820] Modules linked in: pppoe ppp_async option nft_fib_inet nf_flow_table_ipv6 nf_flow_table_ipv4 nf_flow_table_inet usb_wwan qmi_wwan pppox ppp_generic nft_reject_ipv6 nft_reject_ipv4 nft_reject_inet nft_reject nft_redir nft_quota nft_objref nft_numgen nft_nat nft_masq nft_log nft_limit nft_hash nft_flow_offload nft_fib_ipv6 nft_fib_ipv4 nft_fib nft_ct nft_counter nft_chain_nat nf_tables nf_nat nf_flow_table nf_conntrack mt7603e mt76 mac80211 cfg80211 usbserial usbnet slhc nfnetlink nf_reject_ipv6 nf_reject_ipv4 nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c crc_ccitt compat cdc_wdm sha256_generic libsha256 seqiv jitterentropy_rng drbg hmac cmac leds_gpio xhci_plat_hcd xhci_pci xhci_mtk xhci_hcd gpio_button_hotplug usbcore nls_base usb_common mii crc32c_generic
Wed Feb 16 21:03:20 2022 kern.warn kernel: [ 948.397499] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.10.100 #0
Wed Feb 16 21:03:20 2022 kern.warn kernel: [ 948.409617] Stack : 80a30000 807757d8 00000001 80083400 808c0000 807b0250 00000000 00000000
Wed Feb 16 21:03:20 2022 kern.warn kernel: [ 948.426259] 8140bd8c 80a10000 8077e370 8084d368 8084ce87 00000001 8140bd30 59e5f575
Wed Feb 16 21:03:20 2022 kern.warn kernel: [ 948.442896] 00000000 00000000 8077e370 8140bbd0 ffffefff 00000000 ffffffea 00000000
Wed Feb 16 21:03:20 2022 kern.warn kernel: [ 948.459532] 8140bbdc 0000012e 80852858 ffffffff 00000000 00000001 00000000 80780000
Wed Feb 16 21:03:20 2022 kern.warn kernel: [ 948.476170] 00000009 ffffffff 808b0000 807757d8 00000018 80403f20 00000000 80a10000
Wed Feb 16 21:03:20 2022 kern.warn kernel: [ 948.492807] ...
Wed Feb 16 21:03:20 2022 kern.warn kernel: [ 948.497666] Call Trace:
Wed Feb 16 21:03:20 2022 kern.warn kernel: [ 948.502539] [<800080e0>] show_stack+0x30/0x100
Wed Feb 16 21:03:20 2022 kern.warn kernel: [ 948.511388] [<8037e9d8>] dump_stack+0x9c/0xcc
Wed Feb 16 21:03:20 2022 kern.warn kernel: [ 948.520066] [<8002ff1c>] __warn+0xc0/0x12c
Wed Feb 16 21:03:20 2022 kern.warn kernel: [ 948.528208] [<80030014>] warn_slowpath_fmt+0x8c/0xac
Wed Feb 16 21:03:20 2022 kern.warn kernel: [ 948.538080] [<80556224>] dev_watchdog+0x2f4/0x2fc
Wed Feb 16 21:03:20 2022 kern.warn kernel: [ 948.547453] [<800a1030>] call_timer_fn.constprop.0+0x1c/0x8c
Wed Feb 16 21:03:20 2022 kern.warn kernel: [ 948.558707] [<800a1b48>] __run_timers.part.0+0x238/0x284
Wed Feb 16 21:03:20 2022 kern.warn kernel: [ 948.569267] [<800a1be8>] run_timer_softirq+0x54/0xa4
Wed Feb 16 21:03:20 2022 kern.warn kernel: [ 948.579151] [<806d3f0c>] __do_softirq+0x164/0x368
Wed Feb 16 21:03:20 2022 kern.warn kernel: [ 948.588504] [<80034b08>] irq_exit+0xcc/0x12c
Wed Feb 16 21:03:20 2022 kern.warn kernel: [ 948.596999] [<8039acb4>] plat_irq_dispatch+0x68/0xf0
Wed Feb 16 21:03:20 2022 kern.warn kernel: [ 948.606871] [<80003508>] except_vec_vi_end+0xb8/0xc4
Wed Feb 16 21:03:20 2022 kern.warn kernel: [ 948.616745] [<804b8570>] cpuidle_enter_state_coupled+0x214/0x4cc
Wed Feb 16 21:03:20 2022 kern.warn kernel: [ 948.628714] [<804b626c>] cpuidle_enter+0x54/0xac
Wed Feb 16 21:03:20 2022 kern.warn kernel: [ 948.637916] [<80060b54>] do_idle+0x26c/0x31c
Wed Feb 16 21:03:20 2022 kern.warn kernel: [ 948.646401] [<80060e7c>] cpu_startup_entry+0x2c/0x34
Wed Feb 16 21:03:20 2022 kern.warn kernel: [ 948.656278] [<808d4d44>] start_kernel+0x5b8/0x5e4
Wed Feb 16 21:03:20 2022 kern.warn kernel: [ 948.665628]
Wed Feb 16 21:03:20 2022 kern.warn kernel: [ 948.668704] ---[ end trace e18c9e42b3972a91 ]---
@bmork What can I do else? I've configured my APN / IPv4 and the /dev/cdc-wdm device below WAN, but still no connection.
UPDATE: I got a connection, but it's not 5G-NSA (like it was with the stock firmware). How can I tell the modem to go 5G-NSA?
Untested, but should work:
fw_setenv CheckBypass 0
mtd -r -e Kernel write <OEM-backup-image> Kernel
Clearing CheckBypass ensures that the bootloader validates the image. Caveat: If something is wrong, then it will copy the image in Kernel2 into Kernel and retry. This could revert to a very old OEM image, or whatever you have in Kernel2.
You can also use this for a simplfied revert to OEM if you believe you have a good OEM image in Kernel2. Then you could clear CheckBypass and erase Kernel, letting the bootloader clean up on next boot
I see that you got it (sort of) working. Just for completeness: This part is exactly like making any other QMI device working. I have no better intstructions than the generic 3G/LTE instructions in the Wiki.
This can mostbly be considered informational debug, despite the scaring stack trace. The TX queue timeout for usbnet devices is set to 5 seconds by default. Which usually is long enough. You don't want to wait any longer to transmit a packet. But occasional failures to meet that deadline is still expected for any mobile device. This could be casued by some error, like a firmware lockup, but more likely it's just a temporary radio issue.
Ok, it works now. It's still slow like LTE, but I have 5G-NSA here.
I tried:
picocom /dev/ttyUSB2
AT+QNWPREFCFG="nsa_nr5g_band"
+QNWPREFCFG: "nsa_nr5g_band",1:3:5:7:8:20:28:38:40:41:77:78
AT+QNWPREFCFG="mode_pref",AUTO
OK
according to https://forums.quectel.com/uploads/short-url/avUSxfJeKqWJzAie8wEZCshlXjm.pdf , page 97
At least in the original firmware, setting the band to "AUTO" included LTE+5G NSA , thus I got better speed than setting it to LTE only. However, doing this from OpenWrt picocom, my speed stays LTE-ish.
Also tried:
AT+QNWPREFCFG= "mode_pref",LTE:NR5G
AT+QNWPREFCFG="policy_band"
AT+QNWPREFCFG="rat_acq_order",NR5G:LTE
AT+QNWPREFCFG="nr5g_disable_mode",1
OK
AT+CFUN=0
OK
AT+QMBNCFG="AutoSel",0
OK
AT+QMBNCFG="Deactivate"
ERROR
AT+QMBNCFG="Deactivate"
ERROR
AT+QMBNCFG="select","ROW_Generic_3GPP_PTCRB_GCF"
OK
AT+CFUN=1,1
OK
Then, the picocom disconnected, the modem came back after 2 minutes and I suddenly got 200 MBit of 5G-NSA speed :-).
@bmork Thanks for your help, much appreciated. After fiddling with the above mentioned AT+ commands and the manual from Quectel, my 5G-NSA speed is back and everything works fine under OpenWrt. I've got incoming connections on the T-Mobile "internet.t-d1.de" APN and DynDNS running. Very much thank you again!
AT+QENDC and AT+QENG should tell you if NSA is available. Running these through ModemManager, but you can also use picocom directly:
root@OpenWrt:/# mmcli -m any --command='AT+QNWINFO'
response: '+QNWINFO: "FDD LTE","24201","LTE BAND 3",1450'
root@OpenWrt:/# mmcli -m any --command='AT+QENDC'
response: '+QENDC: 1,1,0,1'
root@OpenWrt:/# mmcli -m any --command='AT+QENG="servingcell"'
response: '+QENG: "servingcell","NOCONN"
+QENG: "LTE","FDD",242,01,31A6A03,113,1450,3,5,5,79E1,-100,-9,-69,16,0,-,27
+QENG: "NR5G-NSA",242,01,65535,-32768,-32768,-32768'