This post will serve to store the historical info originally present in the OP. It is here for posterity only and presents outdated info and instructions which SHOULD NOT be used.
------------------------------------------------------------------------------------------------------------------------------------------------------
VOXEL FIRMWARE V9.2.5.2.29.1SF-HW RELEASED
Updated version of Voxel firmware is out and can be downloaded below:
https://www.voxel-firmware.com/Download ... 2.29.1.zip
Release notes can be downloaded here:
https://www.voxel-firmware.com/Download ... 1SF-HW.log
VOXEL FIRMWARE V9.2.5.2.29SF-HW RELEASED
Updated version of Voxel firmware is out and can be downloaded below:
https://www.voxel-firmware.com/Download ... 9SF-HW.zip
VOXEL FIRMWARE V9.2.5.2.28S.1F-HW RELEASED
!!! Please upgrade to this version ASAP as there are many security vulnerabilities patched !!!!
Updated version of Voxel firmware is out and can be downloaded below:
https://www.voxel-firmware.com/Download ... 1SF-HW.zip
Release notes can be found here:
https://www.snbforums.com/threads/custo ... -hw.76775/
Also in this version is 'get-sms.sh' a tool for reading SMS messages. If you can test the tool and report any issues, this would be most appreciated. Usage below:
Code: Select all
get-sms.sh - read all SMS
get-sms.sh #num - read SMS #num
get-sms.sh #start #end - read SMS from #start to #end.
***VOXEL V9.2.5.2.23.1SF-HW***
Voxel has made a new revision already which includes improved QCA WiFi drivers taken from Netgear stock v2.6.5.2. This should improve WiFi performance for those that use WiFi on the LBR20:
https://www.voxel-firmware.com/Download ... 1SF-HW.zip
This was done for the RBK50 as well. More details can be found here;
https://www.snbforums.com/threads/custo ... ost-700398
***VOXEL FIRMWARE IS HERE!***
https://www.voxel-firmware.com/Download ... 3SF-HW.zip
That's right folks! The legend himself has applied his optimization skillz to the LBR20. Being the first Voxel release for the LBR20 I would like get as many LBR20 owners who can test it as possible so we can provide valuable feedback and support for future revisions. Also, please consider
donating some $$$ if you are are happy with his work as I know for a fact he had to pay over $650 USD of his own money in his country to obtain an LBR20 in order to compile firmware for it. This has not yet been announced in the SNB forums as he would like some extended testing which I told him we would be happy to provide
Netgear's latest stock firmware (2.6.4.2+) includes more encryption for Netgear's internal HTTPS certs which makes the source firmware harder to work with and it provides no real feature enhancements. Thus, this first release is based off of the popular 2.5.2.20 stock firmware GPL sources and has been tested to run just fine with A05 and A06 LTE (Quectel) modem firmware (tested by me on T-Mobile/Sprint).
Because it is built on 2.5.2.20 source, it is recommend to flash to Netgear 2.5.2.20 prior to flashing Voxel's firmware otherwise softbrick could occur requiring TFTP recovery (
https://kb.netgear.com/000059634/How-to ... ndows-TFTP).
Voxel firmware V9.2.5.2.23SF enhancements vs Stock:
- Many component packages updated
- Various Netgear bugs fixed
- Many CVEs are patched including very serious CVE-2019-11477 and CVE-2019-11478 (kernel)
- OpenSSL compiled to leverage hardware acceleration (crypto engine) along with ASM acceleration; up to 8x faster than stock
- Modern compiler was used when building (9.4.0 vs. 5.2.0 used by Netgear). Cortex-A7 specific compiler flags used when compiling source (i.e. '-O2' and '-O3') and FPU functionality enabled vs. Netgear's generic ARM target and flags (i.e. '-Os'). This allows the firmware to take full advantage of hardware power which leads to faster performance all around as the unit is more responsive similar to Voxel firmware for the Orbi RBK50 (more details here: https://www.snbforums.com/threads/custo ... -hw.60308/).
- Ability to completely disable Netgear Circle and Armor which frees up a great deal of resources for faster performance
- OpenVPN client and WireGuard clients added (no GUI, CLI-only ); Voxel has tested WG but I have not yet as I do not have a WG server spun up at the moment
- Up-to-date Dropbear SSH server is running by default allowing secure root access out of the box
- Fully functioning overlay filesystem under '/mnt/circle' which allows for modification and addition of files which cannot be easily changed on stock firmware. Example: creating '/mnt/circle/overlay/etc/rc.local' allows us to make our own 'rc.local' for things which we want executed on startup.
- Netgear 'net-wall' binary replaced by custom script which calls original binary but allows use of custom firewall and direct iptables rules easily as well. Leveraging circle overlay we can create '/mnt/circle/overlay/opt/scripts/firewall-start.sh' which can include our own iptables rules which will execute on each interface state change (i.e. should not get wiped out by other Netgear processes; exception to this is PDP or APN changes which *do* require a reboot or re-execution of 'firewall-start.sh' to add back iptables rules lost by Quectel connection manager reconnection upon PDP or APN changes).
- Updated CIFS package for 'mount' command which allows the mounting of CIFS network shares (i.e. Windows PC or SMB share from NAS) for use with Entware packages etc. (ex. mount.cifs //192.168.1.100/DiskC /mnt/share -o user=username,iocharset=utf8,vers=3.02)
As-of-yet untested functionality:
- Accelerated OpenVPN Server (the one available in GUI)
- DNSCrypt Proxy-2 and stubby
- Adding Orbi satellites (i.e. RBS20 etc.)
- Armor (BitDefender) and Circle (but we all know these are crap, resource hogs anyways better handled by other purpose-built devices/software and not shoehorned into a router)
Known limitations:
- Filesystem '/mnt/circle' is only 26MB so cannot install larger things on it like Entware packages (thus the example to use CIFS mount for Entware storage on another file server)
QuickStart.txt from the linked firmware package above reproduced below for reference:
Code: Select all
Quick Start Guide
(!) IMPORTANT NOTE: it is strongly advised to update to the stock firmware 2.5.2.20
before flashing this version.
https://www.downloads.netgear.com/files/GDC/LBR20/LBR20_V2.5.2.20.zip
Warning:
I am not responsible for any damage of your router if you decide to try this custom
firmware. You should do all under your own risk and responsibility. Your router is
your router and you should understand the risk to brick it.
1. Flashing Voxel’s custom firmware build and rolling back to the stock.
Nothing special. The procedure is similar to flashing downloaded official stock
firmware. In general all your current settings (used in the stock firmware) should be
kept. But it is recommended to make the backup of your current settings before flashing.
Identically you can revert to the stock firmware.
2. Overlay partition on Circle partition.
Original stock firmware uses tmpfs overlay partition (in RAM). So all you changes in
the files/dirs are kept only until next reboot of router/satellite. If you need to keep
your changed/added files you should use /mnt/circle/overlay directory where you should
add your new or modified files keeping the dirtree of Orbi. For example, if you wish to
use your own /etc/dnscrypt-proxy-2.toml just place it into:
/mnt/circle/overlay/etc/dnscrypt-proxy-2.toml
3. Setting up ssh access to the router and satellite.
After flashing and your settings you may need to have SSH access to router. SSH daemon
dropbear in Orbi uses port 22 and accepts root login with your WebGUI password.
4. Open your own firewall ports.
If you need to make several ports accessible from WAN then create the text file
/mnt/circle/overlay/etc/netwall.conf with ports you need to open. Example of this file:
------------------------------------------------------------------------
ACCEPT net fw tcp 22,8443
ACCEPT net fw udp 1194
------------------------------------------------------------------------
(to open TCP ports 22 and 8443 and UDP port 1194).
NOTE: this file should contain LF symbol at the end of last line (press ENTER key in
your text editor).
Additionally you can use your own custom script to add your own iptables rules. This
script should be named firewall-start.sh and be placed in the:
/mnt/circle/overlay/opt/scripts/
directory, i.e. /mnt/circle/overlay/opt/scripts/firewall-start.sh with 755 permission
attributes (i.e. executable).
5. Enable DNSCtypt Proxy-2 or stubby.
To enable DNSCrypt Proxy-2 run from telnet console the commands:
nvram set dnscrypt2=1
nvram commit
reboot
To enable stubby run from telnet console the commands:
nvram set stubby=1
nvram commit
reboot
If both DNSCrypt Proxy-2 and stubby are enabled, only stubby will be used.
To disable DNSCrypt Proxy-2 or/and stubby set them to "0" by nvram.
6. Disable Armor (BitDefender) and Circle update startup.
To disable Armor update daemon run from telnet console the command:
nvram set noarmor=1
nvram commit
reboot
To disable Circle update daemon run from telnet console the command:
nvram set nocircle=1
nvram commit
reboot
7. Disable ReadyCLOUD (XAgent/XCloud).
To disable ReadyCLOUD update daemon run from telnet console the command:
nvram set nocloud=1
nvram commit
reboot
8. WireGuard client.
To start its using you should
(1). Prepare the text file in Unix format (https://en.wikipedia.org/wiki/Text_file#Unix_text_files)
with name wireguard.conf defining the following values: EndPoint, LocalIP, PrivateKey,
PublicKey and Port of you WireGuard client config from WG provider.
Example:
------------------------- cut here ---------------------------------------
EndPoint="wireguard.5july.net"
LocalIP="10.0.xxx.xxx/24"
PrivateKey="XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX="
PublicKey="XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX="
Port="48574"
------------------------- cut here ---------------------------------------
NOTE: no spaces before/after "=" symbol in example above.
NOTE: the name of the file wireguard.conf is lowercase.
(2) Place this wireguard.conf file to /mnt/circle/overlay/etc/ directory. I.e.
/mnt/circle/overlay/etc/wireguard.conf
(3) Enter by ssh/telnet to your router (LBR20) and set the nvram variable wg-client
to 1
nvram set wg-client=1
nvram commit
(4) Reboot your router.
NOTE: to disable WireGuard client starting just set wg-client to "0" and reboot
the router.
9. OpenVPN client.
Important: only TUN clients are supported
To install OpenVPN client: just create /mnt/circle/overlay/etc/openvpn/config/client
directory and put your *.ovpn file (and CA/CERT/KEY if any).
See "Overlay partition on Circle partition".
You can start/stop OpenVPN client manually from telnet console for testing:
/etc/init.d/openvpn-client start
or
/etc/init.d/openvpn-client stop
to stop it. Log file for OpenVPN client is /var/log/openvpn-client.log, check it if you
have problems.
NOTE: you can add your own delay for starting OpenVPN client after reboot by the
command from telnet:
nvram set vpn_client_delay=120
nvram commit
(to set 120 sec. delay)
10. Mounting a CIFS Share.
It is possible to mount remote network share using the Common Internet File System (CIFS).
Example how to mount CIFS Share:
mkdir /mnt/share
mount.cifs //192.168.1.100/DiskC /mnt/share -o user=username,iocharset=utf8,vers=3.02
Voxel
***UPDATES REGARDING LATEST ROUTER FW v2.6.3.50 AND LTE FW A06***
As my last update from 2/18 indicated, router firmware v2.6.3.50 made some significant changes, chiefly disabling the ability to make changes on '/mnt/ntgr/...' which are reboot-persistent. Aside from the new router firmware version there is also a new LTE (Quectel modem) firmware version, A06. This modem firmware update was much more helpful than the router firmware as it appears to have improved modem stability on T-Mobile for me along with allowing the modem to connect to B41, which I did not see it do successfully before (B41 LTE may not be available in all markets). It works perfectly fine paired with 2.5.2.20 router firmware in my testing.
Digging into v2.6.3.50
Netgear seems to have finally stepped up their security game in fw v2.6.3.50 and, while that's a good thing in general, it has made modding a bit more difficult. As many have noticed already, the 'debug.htm' page with the checkbox for enabling telnet was removed and classic Netgear 'telnetenable' utilities do not work to enable telnet on this newer firmware either. This brings the LBR20 in line with the Orbi flagship products as most of those already lost [easy] telnet abilities in 2020 already. So, I had to crack open my dev unit and look for the jumper terminal pins I found while disassembling my original unit to see if they were indeed UART for accessing a serial console. After some fiddling with the pins and a multimeter I was off to the races at 115200 baud with an FTDI cable.
I was initially met with some frustration due to having TX and Ground reversed (and thus not being able to get any response to my keyboard inputs) but once I got that sorted I was greeted with a familiar Chaos Calmer root shell. From there I was able to confirm some relevant pieces of information that have changed in this new firmware. I won't list all my findings here but only those which are germane to our modem and iptables modding efforts:
- Armor/BitDefender filesystem ('/mnt/ntgr/..') is no longer listed in 'df' output; it is fully under the root ('/') filesystem which is mounted with overlay_fs (thus why nothing sticks after a reboot).
- The 'debug.htm' telnet functionality is not just hidden with javascript as it was in some other Orbi product firmware last year, the functionality to enable telnet at all from the web gui ('net-cgi' function calls) has been completely removed as far as I can tell.
- The 'telnetenable' daemon *is* still listening on port 23/UDP as revealed by 'ps' list of its running process and an nmap scan. Many had surmised that it wasn't listening since it does not respond to telnetenable 'magic packets' sent to enable 'telnetd' (telnet daemon) on 23/TCP. Packet captures and strace confirmed it would receive the packet but it was discarded and no 'ACK' was returned.
- 'telnetenable' daemon binary has been changed. It's file size was larger and it appears to have been compiled with a newer GCC toolchain. An strace revealed it is also checking magic packet authentication password values against 'http_passwd_hashed' which is an unsalted SHA256 hash of the classic, plaintext 'http_passwd' (aka, the web gui 'admin' password set when you first setup the router).
- Despite modifying telnetenable clients to send magic packets with an SHA256 hash of the 'admin' password, the daemon would still not respond to enable requests. After some professional assistance from a master reverser (thank you, Bjoern!) it was determined that Netgear has now customized the Blowfish encryption algorithm of telnetenable. This was why magic packets got no response since all the telnetenable client programs/scripts thus far only support the standard Blowfish implementations. The reverser was able to use these findings to create a new telnetenable client which sends successful magic packets to the LBR20 (and likely other Orbi routers as well).
Other Goodies Found
Found some other 'hidden' goodies so far in the new firmware web interface as well. Here is an inventory that might be worth further exploration by folks who have the time and/or interest:
- hidden_info.htm
Nice summarized info page of device settings. Of particular interest is the ability to 'select' specific modem carrier firmware. I haven't been brave enough to select something from the dropdown to test but I'm curious if it would switch to the selected MBN and restart the modem. Hope someone brave tests this and reports back
- hidden_manual_set_ant.htm
Appears to allow manual config of the *WiFi* antenna array in the unit.
- currentsetting.htm
Summarized setting info from the unit.
- debuginfo.htm
Some very basic info from the unit. Seems mostly useless at present.
- POT.htm
Some basic uptime info?
- DEV_device_info.htm
A bit more detailed device info overview.
- LED_light_info.htm
Some info about the current LED lights' state.
***OLDER POSTS FOLLOW***
***IMPORTANT NOTE 02/18/21***
Coming out of hibernation for a moment to post a warning for Netgear LBR20 owners: the latest firmware (2.6.3.50) appears to change the partition structure making the Armor partition used to bootstrap custom scripts non-reboot-persistent. Also, telnet is not as easy to enable. I don’t have time to spend on engineering a solution to resolve this at present so recommend staying on older firmware for now. Can’t say I didn’t warn you . You can find the 2.5.2.20 firmware here in case Netgear pulls it but be aware that the filesystem changes that occur when moving beyond this version do not revert and '/mnt/ntgr/...' changes will still not persist on reboot unless you make some further partition modification manually:
https://drive.google.com/file/d/1Tc09ja ... sp=sharing
Finally, some of my original assumptions were wrong such as the unit not having serial terminal software installed (it does in fact have 'minicom'). I am leaving the original OP info intact below for reference as some of it may still be helpful but just know it is outdated.
***ORIGINAL POST FOLLOWS; ONLY RELEVANT FOR VIRGIN LBR20s ON THE ORIGINAL 2.5.2.20 (OR EARLIER) FIRMWARE***
Hi All,
I wanted to start a thread on the Orbi LBR20 as I have seen increased interest in it since release and I get a lot of questions about it. For those who aren't familiar with it or its capabilities they have posted a video unbox/overview of the unit on the Wireless Joint Facebook group which may be helpful to you:
.
Of primary interest to most is the fact that it has both a Quectel Cat. 18 modem in it and runs a Netgear-customized version of OpenWRT Chaos Calmer (like other models in the Orbi line). The current firmware (2.5.2.20) also offers easy debugging and telnet access which makes bending the device to one's will relatively simple. With these details in mind, the following are a few FAQs I receive frequent PMs about that will hopefully be helpful to you:
Telnet/Root Access
At least on firmware 2.5.2.20, achieving command line access to the device is quite simple. Simply navigate to http://[IP_of_LBR20]/debug.htm and tick the box for 'Enable Telnet':
Once enabled you can simply use your favorite telnet client (I prefer Putty) to connect to telnet (port 23) on the device IP. Login using the same credentials you use to login to the web GUI.
Sending AT Commands to the Modem
There is no serial terminal software installed by default but one can easily echo commands to the AT port device ('/dev/ttyUSB2') and read the output with cat using one-liners in order to send useful commands to the modem. Be aware that syntax is very important here; graves accents surrounding the 'echo' command, return / new line characters following the actual AT command, and ensuring any double quotes required in a given AT command are escaped appropriately using backslashes are all imperative. Some examples of useful commands are noted below:
Code: Select all
cat /dev/ttyUSB2` echo -e "AT+CGSN\r\n" > /dev/ttyUSB2`
cat /dev/ttyUSB2` echo -e "AT +EMGR=1,7,\"012345678911121\"\r\n" > /dev/ttyUSB2`
cat /dev/ttyUSB2' echo -e “AT+QCFG=\"band\",0,2000,0,1\r\n” > /dev/ttyUSB2`
*** UPDATED 03/06/21. 'TTL_MOD' SCRIPT SIMPLIFIED; SWITCHED TO LOOPED SCRIPT FOR REGULAR INTERVAL EXECUTION***
Modifying IPTables, Blocking Auto Firmware Updates, and Disabling WiFi
As many who have hotspot limits will understand, it is very useful when a device has a full fledged copy of iptables installed and the Orbi definitely has this. While it is quite easy to add iptables rules over telnet to the device, it is another thing entirely to get those rules to persist after reboot or any interfaces changes.
Also, as was mentioned in the linked video overview of the device, Netgear has persisted with their stupidity in pushing firmware updates to devices without warning which can be a hassle for many reasons (not least of which is the quality of Netgear code and all their various product firmware bugs up to this point). So it would be nice to be able to block this 'feature' since we are in fact the owners of the device and not Netgear. Fortunately we can do this simply enough by either appending '/etc/hosts' or overwriting '/etc/resolv.conf' with a DNS server of our choosing that blocks access to the Netgear auto-update domain.
Finally, since my use case does not make use of WiFI on the Orbi, it would be nice to deactivate the radios on boot to save power and not add to all the existing RF congestion in my neighborhood; this can be done easily as well.
First the bad news: since the device reloads the root partition from ROM on every reboot we can't very well modify existing startup scripts under the root ('/') filesystem in the usual manner; we must be more creative here. The good news is that Netgear stores and runs the Armor (BitDefender) and Circle applications off of storage mounts which are persistent across reboots and not overwritten from ROM each time. Even if you don't have Armor or Circle enabled, there are some associated processes which load on every boot anyways so we can use these to 'piggy-back' off of in order to create and call a 'bootstrap' script containing the commands, or calls to additional scripts, that we want to be sure run on next boot if the device is powered down or restarted.
We will start by creating our main 'bootstrap' script. Turning off the WiFi radios is a single command under OpenWRT distros ('wifi down') so that will be an easy one-liner to add at the start of our bootstrap but I suggest including a 'sleep' for at least 60 seconds before taking wifi down so that we make sure the unit has finished loading first. Another useful task is blocking auto firmware updates by either modifying the DNS resolver or modifying the hosts file. This can be a simple one-liner in our bootstrap too. Finally we need a method to consistently enforce specific TTL values on the modem interface even during state changes (such as Ethernet interface link up/down); this is not so easily a one liner and would be helpful to run at a regular interval so we will create external scripts for this and add them to crontab via a few lines at the end of our 'bootstrap' script.
Under the existing folder for Netgear's Armor (/ntgr/mnt/armor/), we can create our own folder for 'mods' and underneath, the script files and crontab definition text file for the commands we we want to run (don't forget to 'chmod +x [filename]' to make any scripts executable!). The actual call to our bootstrap script will be made by simply appending a semicolon and its full path to the 'command' argument of 'procd_set_param' in the init.d script for the 'bbox-bdheartbeatd' daemon. The screenshot below illustrates how we modify the referenced line in the existing script:
Following are the scripts/files we have created:
'bootstrap' script
This runs one-time, one-liner commands such as turning off wifi and appending to hosts file to block auto firmware updates. It also creates cronjobs for everything that needs to run regularly. (We dump out the existing crontab to a temporary file, append it with our jobs, re-create the crontab, then remove our temporary file.)
Code: Select all
#!/bin/sh
sleep 60
wifi down > /dev/null 2>&1
/mnt/ntgr/armor/mods/ttl_mod &
'ttl_mod' script
This calls iptables and ip6tables commands to check for our mangle rules on the modem interface and add them if they are not found. Also blocks auto firmware updates.
Code: Select all
#!/bin/sh
while [ 1 ]
do
# IPv4 TTL mod
iptables -t mangle -C POSTROUTING -o wwan0 -j TTL --ttl-set 65 > /dev/null 2>&1 || \
iptables -t mangle -I POSTROUTING 1 -o wwan0 -j TTL --ttl-set 65
# IPv6 TTL mod (prevents leaks not covered by IPv4 rules)
ip6tables -t mangle -C POSTROUTING -o wwan0 -j HL --hl-set 65 > /dev/null 2>&1 || \
ip6tables -t mangle -I POSTROUTING 1 -o wwan0 -j HL --hl-set 65
echo "127.0.0.1 localhost http.fw.updates1.netgear.com devcom.up.netgear.com" > /etc/hosts
sleep 300
done
From a workflow perspective, with these scripts/files in place a couple minutes after the next boot the host will disable WiFi and execute our 'ttl_mod' script every five minutes to block auto firmware updates and enforce our iptables mangle for both ipv4 and ipv6.
Sometime after the initial setup above, as an alternative to the hosts file method of blocking auto firmware updates, I instead decided to block them by adding 'devcom.up.netgear.com' to the deny list on my DNS server solution. Other DNS servers are similarly easy to exclude the domain in this way (Unbound, DNSMasq, Untangle, OpenDNS, etc.). Once I added the deny entry in NextDNS, I edited my 'bootstrap' script to remove the line appending '/etc/hosts' and instead to overwrite '/etc/resolv.conf' so that it would use NextDNS as opposed to the cellular provider's DNS servers. The Orbi device itself is using DNSMasq but only as a blind forwarder so it would be a bit more work to set the domain exclusion on the device rather than just changing its nameserver which is why I did it this way (please it's cool to keep tabs on any domains that the Orbi calls out to on its own and view them graphed out in NextDNS).
In case anyone was wondering I used the packet capture function from the same 'debug.htm' web page we used to enable Telnet from, in order to confirm with certainty (using Wireshark) what domain the firmware updates come from.
Quirks I've Noticed So Far
One annoyance I've encountered is that sometimes on bootup and attach to the cellular network, the DHCP on the WWAN0 interface (modem) gets a '192.168.0.1' address assigned to it along with DNS nameserver of '192.168.0.2' and subsequently my August Connect (WiFi bridge adapter for August smart lock products) stops connecting to August's servers (thus becoming unusable). I'm not exactly sure what is going on to cause this. It is kind of like how the old MR1100 IP Passthrough functionality breaks on some versions of its firmware. I thought maybe just my nameserver mod would allow the August Connect to resolve the August domain and that would resolve but it did not. The only 'fix' so far has been to reboot the LBR20 and then the next network attach shows it using the standard T-Mobile DoD reserved address space with my modded nameserver selected. Given this issue only occurs sometimes when I have to reboot the device it is not a showstopper for me but I thought it worth sharing in case others were having issues with their 'smart' / IoT products.
Megathread?
That's all I have to share for now but I hope others will add replies with tidbits they have found useful in their use of the LBR20. Hopefully we can get a nice 'megathread' going which will be a useful source of info to other LBR20 owners. I will come back to this and update as I come across new info or delve into more mods with this device. I have reached out to the developer of the famed Voxel firmware for other Netgear routers and inquired about creating a bounty for the creation of Voxel firmware for this device since it's based on a similar SoC to other Orbi devices; have not heard anything back yet but it would be a very cool possibility to have a fully modern build of OpenWRT with package support while still retaining any proprietary bits/integrations required for the nice modem and WiFi connectivity. A guy can dream, right? Unfortunately I won't have enough time to delve into such an undertaking myself.
***UPDATED 10/7/20***
Cell Locking In my testing this week I've found I have a tower broadcasting two, adjacent cell IDs. One is on B66 (B4) and gets 2xCA (B66 PCC w/ B2 SCC) but the speed falls off more during periods of congestion. The other is on B2 and gets 3xCA (B2 PCC w/ B66 & B71 SCCs). I was able to confirm the CA combos with AT+QCAINFO. The latter seems generally less congested sometimes coming in at 2x the DL speeds of the former during times of peak load. The frustrating part was that the LBR20 kept wandering back to the B66 cell whenever the winds would change and the signal would be ever so slightly stronger than the B2 cell. Thus I found it helpful to lock the modem to the faster cell. This can be done with AT+QNWLOCK.
Sadly, the LBR20 does not have the newer, more stable syntax of AT+QNWLOCK="common/lte", it only has the legacy AT+QNWLOCK="common/4g" which Quectel admins claim "may have issues" (
https://forums.quectel.com/t/lte-cell-p ... -ec25/3581). Nevertheless, the command seems like it works fine from my testing. Just need to obtain the EARCFN and PCID of the cell you wish to lock to first with AT+QENG="servingcell" and/or AT+QENG="neighbourcell" (the former if you're actively connected to the desired one, the latter if you're not). Once you have those, you can run AT+QNWLOCK="common/4g",1,[EARCFN],[PCID]. In my case (see side note below code block about entering the command):
Code: Select all
echo -e "AT+QENG=\"servingcell\"\r\n" > /dev/ttyUSB2
AT+QENG="servingcell"
+QENG: "servingcell","NOCONN","LTE","FDD",310,260,6C150D,222,1125,2,4,4,A6F7,-81,-8,-54,21,0,90,-
OK
echo -e "AT+QNWLOCK=\"common/4g\",1,1125,222\r\n" > /dev/ttyUSB2
AT+QNWLOCK="common/4g"
+QNWLOCK: "common/4g",1,1125,222
OK
As a side note I've noticed that even with escaping double quotes etc., the QENG command does not like to return output by catting the modem device while sending the command with 'echo -e' like all the other commands I ran so far. So, for at least issuing AT+QENG commands, I open two telnet sessions, in the first I run 'tail -f /dev/ttyUSB2' and in the second I issue the command with 'echo -e "AT+QENG=\"servingcell\"\r\n" > /dev/ttyUSB2'. This setup appears to work reliably:
***UPDATED 01/15/21. THE FOLLOWING SECTION MAY BE GENERALLY INTERESTING/USEFUL BUT I LATER FOUND MY CA DROPOUTS TO BE CAUSED BY T-MOBILE/SPRINT MERGER TOWER CHANGES IN MY AREA AND I NO LONGER RUN THIS SCRIPT SINCE IT BECAME DISRUPTIVE TO RUN AT ANY REGULAR INTERVAL AND ATE UP DATA WITH ALL THE SPEEDTESTS*** ̶*̶*̶*̶U̶P̶D̶A̶T̶E̶D̶ ̶1̶0̶/̶8̶/̶2̶0̶*̶*̶*̶
"Expiring" CA Quirk on T-Mobile
For whatever reason after what seems like an arbitrary amount of time (but usually between 12 and 24 hours), my local T-Mobile tower seems to cease honoring carrier aggregation during downloads. AT+QCAINFO will still show 3xCA (B2 PCC, w/ B66 and B71 SCCs) but a speedtest quickly reveals only the PCC is actually active (download speed will not break 100Mbps which is a dead give away in my setup that only one band is in use). A detach and reattach to the network restores CA abilities in short order (accomplished by AT+CGATT=0, followed by AT+CGATT=1, with about a 15-20 second gap in between to wait for the detach to complete). Given I don't care to manually run speedtest all day and detach/reattach to the network when CA seems to drop off, I have automated this with the following script which can be added to our 'cronjobs' definition file to be called at regular intervals: 'ca_chk' script
Code: Select all
#!/bin/sh
sleep 600
while [ 1 ]; do
if [ "$(/bin/speedtest.sh run > /dev/null 2>&1 && grep "final result" /tmp/ookla_speedtest_result | awk '/download:/ {print $12}')" -lt "100000" ];
then echo -e "AT+CGATT=0\r\n" > /dev/ttyUSB2 ; sleep 20 ; echo -e "AT+CGATT=1\r\n" > /dev/ttyUSB2 ; mv -f /tmp/ookla_speedtest_result /mnt/ntgr/armor/mods/speedtest_reset_connection
else mv -f /tmp/ookla_speedtest_result /mnt/ntgr/armor/mods/speedtest_result
fi
sleep 3600
done
exit 0
So as you have probably gathered by looking at the text of "ca_chk", we have hijacked the built-in Ookla API configuration to check our connection speed once per hour (starting 10 minutes after initial boot of the router). If the speed is less than 100Mbps (you can change that value to suit your situation more appropriately), the modem performs a detach/reattach to the network to restore full CA throughput then copies the speedtest result back to our persistent storage with a filename that indicates the detach/reattach occurred. If the speed is fine, the result file is simply moved over to persistent storage with a filename indicating only a test was performed but no detach/reattach took place.