Orbi LBR20 How-To / Megathread

How To Tutorials related to Routers and Firmware
Forum rules
This forum is for tutorials only--not for help or assistance.
Post Reply
hazarjast
Posts: 133
Joined: Wed Dec 11, 2019 8:38 am
Has thanked: 16 times
Been thanked: 35 times

Orbi LBR20 How-To / Megathread

Post by hazarjast » Fri Oct 02, 2020 10:44 am

VOXEL FIRMWARE V9.2.5.2.26SF RELEASED
Updated version of Voxel firmware is out and can be downloaded below:
https://voxel-firmware.com/Downloads/Vo ... 6SF-HW.zip

Release notes can be found here:
https://www.snbforums.com/threads/custo ... -hw.75558/


VOXEL FIRMWARE V9.2.5.2.25SF RELEASED
Updated version of Voxel firmware is out and can be downloaded below:
https://voxel-firmware.com/Downloads/Vo ... 5SF-HW.zip

Release notes can be found here:
https://www.snbforums.com/threads/custo ... -hw.74426/


VOXEL FIRMWARE V9.2.5.2.24SF RELEASED
Download can be obtained here: https://www.voxel-firmware.com/Download ... 4SF-HW.zip
Change log can be found here: https://www.snbforums.com/threads/custo ... -hw.73983/
Notable fix is "PresharedKey" addition for WireGuard clients along with a fix for OpenVPN Client issues.


"DON'T CROSS THE STREAMS!"
Just wanted to get a quick note out there that those previously running my earlier mods (on older firmware) or CJ (on newer firmware) and wanting to flash to Voxel's firmware should not only downgrade to 2.5.2.20 prior to flashing it but also factory reset to ensure none of my stuff is running as it may cause conflicts. Also, it is imperative that you do not copy/paste scripts and logic from my earlier mods or CJ into Voxel firmware without adaptation. Please follow exactly the QuickStart instructions.

Ex.: If there are desired iptables rules, those should be entered into the custom '/mnt/circle/overlay/opt/scripts/firewall-start.sh' by themselves *only* without the loop wrapper ("do; while" etc.) logic. Very strange things will happen if you do include the loop logic (SSH not accessible etc.).

For some further explanation...
My approach to execution and persistence of iptables rules etc. was very different by hijacking stock firmware services to run specific scripts infinitely using loops at certain intervals because it was the only way I knew how to do it at the time and enforce the desired settings. With Voxel's use of overlay filesystem on '/mnt/circle' and modification of 'net-wall' the necessity for a lot of this older logic can be thankfully done away with.

Eventually maybe I will get around to writing a new 'how-to' thread for Voxel firmware apart from this thread since it has grown quite large, but not sure if/when I will have time to do it so I am at least calling things out here front (top?) and center :)


***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



***'CIRCLE_JERK' AUTO DEPLOYMENT TROUBLESHOOTING AND MANUAL DEPLOYMENT INSTRUCTIONS***
Thank you to those that have tested automatic deployment via 'deploy_circle_jerk.ps1' and provided feedback. Some troubleshooting help and manual deployment instructions can be found below:
  • Mind Your SKU
    The .ps1 script has only been tested on a fresh US Retail model SKU LBR20-100NAS on firmware v2.6.3.50. You won't find this SKU designation on the label since Netgear seems to be stealth about their SKU variations but if you bought the unit through Amazon US or Netgear US then it should be this SKU. There are other North American SKUs for the device such as the US Cellular and Bell Mobility. If you don't have a US Retail unit, you may have to use the manual deployment instructions below this troubleshooting list. A partial list of current device SKUs can be found here:
    https://kb.netgear.com/000062073/What-c ... d-by-LBR20
  • Mind Your Firmware Source
    There have been indications from at least one user that the firmware provided by the gui update feature appears to be a somewhat different variant than the one provided for manual download on Netgear's US support site. For clarity, the one I tested on came directly from the following link:
    https://www.downloads.netgear.com/files ... 6.3.50.zip
    Google Drive mirror of the same here:
    https://drive.google.com/file/d/1lbOeSO ... sp=sharing
  • Start With a Fresh Slate
    Along with using the firmware from the previous point, it is recommended to factory reset prior to attempting auto-deployment to be sure no non-default config will cause an issue during the deployment process. If you have two 'sliders' under 'Parental Controls' then you are likely not starting with a fresh slate.
  • Mind Your Network Interfaces
    This script assumes only one network adapter is active and connected directly to the LBR20 LAN (br0) interface. If you have other network interfaces (whether physical or virtual) you may need to disable them under Windows Device Manager in order for the deployment script to be able to detect the LBR20's IP and MAC address properly. A common indicator that you have more than one network interface active is if the 'telnet-enable2.exe' step fails in the script with an error similar to the following:

    Code: Select all

    EnableTelnet : Could not enable telnet!
    At D:\circle_jerk-main\deploy_circle_jerk.ps1:136 char:3
    +   EnableTelnet
    +   ~~~~~~~~~~~~
        + CategoryInfo          : NotSpecified: (:) [Write-Error], WriteErrorException
        + FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException,EnableTelnet
    
    If you cannot disable interfaces which are not the one connected to the LBR20 then I would recommend using the manual deployment instructions.
  • Addressing Windows Defender Exclusion Issues
    If you try to add the Windows Defender exclusions via the 'circle_jerk_defender_exclusions.reg' file and get an error saying that the registry was locked or you didn't have proper permission, be sure that you don't have Defender / Security Center open and/or actively running a scan. Try rebooting or temporarily stopping Defender ('Security Center > Virus and Threat Protection > Manage Settings > Real-time protection > Off'), or just add the process exceptions manually for 'telnet-enable2.exe' and 'deploy_circle_jerk.ps1' ('Security Center > Virus and Threat Protection > Manage Settings > Exclusions > Add or remove exclusions > Add an exclusion > Process'). If you do decide to temporarily disable Windows Defender entirely please go back and add the manual process exclusions and re-enable Defender afterwards. I do not want to see anyone get a virus because they failed to re-enable protection :)
  • Check the Script Output
    The script should produce output similar to the below screenshot:
    Image
    If you are missing one of the 'telnet' lines or 'transfer successful' lines then telnet commands or TFTP transfer may have not occurred. If telnet commands are missing or came back with an error, check the 'autotelnet_log.txt' file in the current directory to see if it provides any clues to the failure. If TFTP 'transfer successful' line is missing, try running 'TFTP -i [LBR20_IP] PUT circle_jerk.zip' manually from the same directory to see if it comes back with any errors. A common issue would be TFTP failing to connect to the LBR20 in case the outbound 'allow' rule for it failed to be created by the script or the rule was disabled/removed by accident.
  • Try a Restart
    If the deployment script seems to have executed successfully but you cannot access SSH after enabling/applying Circle in the web gui, restart the router and see if SSH is available after 5-10 minutes.
  • Deploy Manually
    If your issue is not covered above or you still have issues after following the aforementioned troubleshooting directions, then it will likely be less hassle for you to deploy the mod manually as outlined below.
***'CIRCLE_JERK' MANUAL DEPLOYMENT INSTRUCTIONS***
  1. Create Windows Defender exception for 'telnet-enable2.exe': 'Security Center > Virus and Threat Protection > Manage Settings > Exclusions > Add or remove exclusions > Add an exclusion > Process > telnet-enable2.exe'.
  2. Install Windows TFTP client. From Windows search bar, search for 'Windows Features' and select the result which says "Turn Windows features on or off". Scroll down to "TFTP Client" and click in the box next to it to select it then click 'OK'. Windows will install TFTP Client.
  3. Add a windows firewall rule to allow the application 'C:\Windows\System32\TFTP.exe' outbound firewall access. Or create an 'allow' rule for outbound on port 69. By default Windows will block outbound communication to TFTP port 69 so either one of these rules will allow this.
  4. From an Administrator command or powershell prompt in the folder you you extracted the circle_jerk files to, execute the following command (where '[IP]' is the IP address of the LBR20, '[MAC]' is the uppercase MAC address of the router's LAN (br0) interface with any separation characters (':' or '-') removed and '[PASSWORD]' is your web gui 'admin' password):

    Code: Select all

    .\telnet-enable2.exe [IP] [MAC] admin [PASSWORD]
  5. Use Putty or Windows' telnet client to telnet into the device and execute the following command:

    Code: Select all

    touch /var/tftpd-hpa/circle_jerk.zip ; chmod 777 /var/tftpd-hpa/circle_jerk.zip
  6. From the command or powershell prompt you already had open from executing 'telnet-enable2.exe', issue the following TFTP command to upload the 'circle_jerk.zip' package to the router (where '[IP]' is the ip address of the LBR20):

    Code: Select all

    tftp -i [IP] PUT circle_jerk.zip
  7. From your telnet session, execute the following command:

    Code: Select all

    unzip /var/tftpd-hpa/circle_jerk.zip -d /mnt/circle/ ; rm -f /var/tftpd-hpa/circle_jerk.zip ; /mnt/circle/mods/circle_jerk_install
    (the above may be line-wrapped in your browser and/or when pasted into your telnet session, but it is in fact all a single line and should be entered/executed as such)
  8. Enable Circle under 'Parental Controls' in the web gui. Once this is complete, the SSH daemon will be ready to connect to and TTL mangle / hosts file mods will run every 4 minutes thereafter. You can now SSH into the unit and make any desired modifications to the scripts under '/mnt/circle/mods'. If not, reboot the router and wait 5-10 then try SSH again.
  9. Replace '[PASSWORD]' in the following command with your plaintext 'admin' password, then exute it at a powershell prompt to obtain your 'root' SSH password:

    Code: Select all

    (([string](new-object System.Security.Cryptography.SHA256Managed | ForEach-Object {$_.ComputeHash([System.Text.Encoding]::UTF8.GetBytes(("[PASSWORD]")))} | ForEach-Object {$_.ToString("x2")})).ToUpper()).Replace(" ", "")
As a final note, if you're not comfortable creating Windows Defender exclusions for the 'telnet-enable2.exe' provided in the 'circle_jerk' deployment repository, you don't have to use it. All that it is, is a 'pyinstaller' compiled version of the source Python script from which it was created. If you have an updated version of Python 3 already available on your PC you can execute the Python script directly instead:
https://raw.githubusercontent.com/bkerl ... enable2.py

***v2.6.3.50 MOD (AKA 'CIRCLE_JERK') AUTO DEPLOYMENT INSTRUCTIONS***
The 'circle_jerk' mod package can be found on its GitHub repository page (the instructions that follow assume a Windows 10 client PC is being used which is directly connected to the LBR20 via Ethernet with no other LAN connections present):
https://github.com/hazarjast/circle_jerk
  1. At the top of the repository page look for the green "Code" button to click and you will have the option to "Download .ZiP".
  2. Once downloaded/extracted, double-click the 'circle_jerk_defender_exclusions.reg' file to add its content to your registry. This is required since Windows Defender views my PowerShell code as malicious and will delete it along with 'telnet-enable2.exe' if you do not add process exclusions for it. If you have another antivirus installed you will need to add manual exclusions for processes 'deploy_circle_jerk.ps1' and 'telnet-enable2.exe'.
  3. Once .reg file is imported and/or any manual AV exclusions for the .ps1 and .exe process names have been added, you should open a new powershell prompt *as an administrator* in the same directory you extracted the 'circle_jerk' .zip package to, and issue the following command:
    Powershell -noprofile -executionpolicy bypass -file .\deploy_circle_jerk.ps1
  4. The script may take anywhere from a few seconds to a couple minutes to run its initial tasks but will eventually prompt you to enter your LBR20 'admin' web gui password. Once you have done this, hit 'Enter' and the script will activate telnet on the LBR20 and deploy the mod files to the unit.
  5. The script will inform you when the process is complete and will instruct you to now enable Circle under the web gui along with providing your unique SSH password (you should store this in a safe place as you'll need it any time you want to SSH into your LBR20).
  6. Enable Circle under 'Parental Controls' in the web gui. Once this is complete, the SSH daemon will be ready to connect to and TTL mangle / hosts file mods will run every 4 minutes thereafter. You can now SSH into the unit and make any desired modifications to the scripts under '/mnt/circle/mods'.
On reboot the unit will wait for an active Internet connection (waiting for either the modem or WAN port to connect), then Circle will fire up and activate SSH again along with running your 'recurring' script every 4 minutes. If you disable Circle and reboot, the mod files will still be available but they will not run. If you wish to restore native Circle functionality simply factory reset the device. This won't erase the '/mnt/circle/mods' directory, but will restore the default circle scripts and you would need to manually run 'telnet-enable2.exe' in order to enable telnet and configure SSH/scripts to run again (else you could delete 'mods' folder entirely and run the powershell again to redeploy).

'Circle_Jerk' Script Breakdown
  • circle_jerk_install
    This creates a backup of the Circle scripts it will overwrite, then overwrites them with symlinks back to 'circle_jerk'.
  • circle_jerk
    This script has 3 sections. In the first section 'call_once' commands are executed such as defining a new 'MOTD' banner and starting the SSH daemon. The second 'call_recurring' section calls commands which are executed every 4 minutes. The third and final 'call_end' section calls commands which are executed when Circle is disabled from the web gui such as killing the SSH daemon.
  • call_once
    Contains commands which are executed only once when Circle is enabled or the device boots up. By default this starts the dropbear SSH daemon and changes the 'MOTD' banner from the default Chaos Calmer one. Other examples of popular commands are given as examples but populated with example values only and commented out to prevent them from running unless you want them to.
  • call_recurring
    Contains commands which are executed only 4 minutes. These commands or calls to other scripts should vetted to make sure they are safe to call multiple times (i.e. the TTL mangle commands offered by default in the called 'fw_rules' script are executed in a pair of iptables commands: the first checks the presence of a rule while the second only adds a rule if it isn't found to be present by the first command). You don't want to just add any command here such as a single iptables command as this will 'stack' duplicate rules in iptables and cause slowdowns and an eventual crash when the device runs out of memory.
  • call_end
    Contains commands which are executed only when Circle is disabled in case you no longer wish for SSH to run or to toggle it in case of a dropbear or other troubleshooting issue.
  • fw_rules
    Contains iptables command pairs which check iptables for the presence of a rule then add it if it is not found. By default rules to harden SSH access from bruteforce attacks and those which mangle TTL are present (the SSH rules are probably overkill since SSH is bound by default to the IP of the 'br0' LAN interface but I wanted to provide extra security by default in case dropbear's 'start_db' script was modified by a user and no longer bound to listening on a single IP/interface).
  • banner
    Creates a fancy-pants ASCII art 'MOTD' to replace the default Chaos Calmer one.
  • start_db
    Located in the 'dropbear' subfolder of '/mnt/circle/mods', this script checks to see if dropbear is already running and if not, makes sure its certificate files are generated (if also not present). It also binds SSH to IPv4 'inet' address of the LAN ('br0' interface) and sets the root password to match that of the web gui 'admin' user (aka 'http_passwd_hashed').

***UPDATES REGARDING LATEST ROUTER FW v2.6.3.50 AND LTE FW A06***
I received my 'development' LBR20 unit and have made progress on modding the latest firmware.
(I use the term 'modding' loosely as my hacks are nowhere near as comprehensive as someone like Voxel who compiles their mods into actual full-release firmware packages. Just want to clarify that point to set proper expectations of what my humble contributions consist of.)

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 successfullly 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:

  1. 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).
  2. 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.
  3. 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.
  4. '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).
  5. 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 :)
    Image
  • hidden_manual_set_ant.htm
    Appears to allow manual config of the *WiFi* antenna array in the unit.
    Image
  • currentsetting.htm
    Summarized setting info from the unit.
    Image
  • debuginfo.htm
    Some very basic info from the unit. Seems mostly useless at present.
    Image
  • POT.htm
    Some basic uptime info?
    Image
  • DEV_device_info.htm
    A bit more detailed device info overview.
    Image
  • LED_light_info.htm
    Some info about the current LED lights' state.
    Image
v2.6.3.50 Modding Success
With the Armor filesystem no longer being a quick and easy way to bootstrap our custom commands I focused on the Circle (Parental Controls) feature and its associated filesystem since most people I know don't use Circle on the LBR20 anyways. I found the Circle filesystem to be not only reboot-persistent but also factory reset persistent at its root as well ('/mnt/circle'). Some additional checks revealed that a TFTP daemon is active on the LBR20 as well which makes it easy to 'push' binaries/scripts to the unit instead of having to create everything on the unit directly or 'pull' files from the internet. The Circle daemon has a handy watch dog feature that checks and relaunches processes every 4 minutes as well which updated scripts can leverage to enforce things like hosts file entries and iptables rules which can 'fall off' due to interface state changes or Netgear scheduled iptables reloads.

With a new target filesystem and technical underpinnings for custom configuration upload/persistence in place I was able to 'hijack' Circle to accomplish what Armor was doing for us previously. I then pieced together a PowerShell deployment script which makes the basic modding process as simple as running the script and providing your 'admin' password. The script enables the TFTP client in Windows, runs the updated 'telnetenable' client to enable telnet on the device, telnets to the device to create a required empty file that allows us to upload a .zip of our scripts and Dropbear SSH daemon (so we don't have to rely on unsecured telnet going forward), extracts this .zip under '/mnt/circle/mods', then sets up the SSH root credentials. From there, all we have to do manually is login to the web gui and enable Circle under 'Parental Controls'. This launches the main script which starts SSH and any other 'one time' commands at first run only and then 'enforces' our '/etc/hosts' and iptables rules on a recurring schedule every 4 minutes thereafter.

Since what we are doing amounts to 'jerking' Circle around to do our bidding (and because I tend to have an odd sense of humor) I have affectionately named this updated mod collection 'circle_jerk'. Tomorrow I will provide the link to the mod's GitHub repository along with deployment steps and a breakdown of the scripts for those who wish to add their own configuration changes.

***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 LTEHacks Facebook group which may be helpful to you: https://www.facebook.com/679762084/vide ... 196347085/ .
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':
Image
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:
Image

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.
Image

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:
Image

***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.

brad2388
Posts: 32
Joined: Wed Apr 11, 2018 8:38 pm
Has thanked: 0
Been thanked: 3 times

Re: Orbi LBR20 How-To / Megathread

Post by brad2388 » Mon Oct 05, 2020 7:31 am

Debating on one of these. But we have a grandfathered whole home plan.

It wont work in my em7511. Wondering if this plan will work in this device?

hazarjast
Posts: 133
Joined: Wed Dec 11, 2019 8:38 am
Has thanked: 16 times
Been thanked: 35 times

Re: Orbi LBR20 How-To / Megathread

Post by hazarjast » Mon Oct 05, 2020 9:36 am

Any plan will work with the LBR20 assuming you configure it to be compatible. Read between the lines in my "Sending AT Commands to the Modem" section and check for spelling typos. That's all I will say here. Feel free to DM (hazarjast at proton mail dot com) if you need clarification.

brad2388
Posts: 32
Joined: Wed Apr 11, 2018 8:38 pm
Has thanked: 0
Been thanked: 3 times

Re: Orbi LBR20 How-To / Megathread

Post by brad2388 » Mon Oct 05, 2020 4:17 pm

hazarjast wrote:
Mon Oct 05, 2020 9:36 am
Any plan will work with the LBR20 assuming you configure it to be compatible. Read between the lines in my "Sending AT Commands to the Modem" section and check for spelling typos. That's all I will say here. Feel free to DM (hazarjast at proton mail dot com) if you need clarification.
Emailed

hazarjast
Posts: 133
Joined: Wed Dec 11, 2019 8:38 am
Has thanked: 16 times
Been thanked: 35 times

Re: Orbi LBR20 How-To / Megathread

Post by hazarjast » Wed Oct 07, 2020 12:48 pm

brad2388 wrote:
Mon Oct 05, 2020 4:17 pm
Emailed
I replied to your email. Please let me know if you didn't get my reply for some reason.

hazarjast
Posts: 133
Joined: Wed Dec 11, 2019 8:38 am
Has thanked: 16 times
Been thanked: 35 times

Re: Orbi LBR20 How-To / Megathread

Post by hazarjast » Wed Oct 07, 2020 1:22 pm

OP updated with some info on locking specific cell IDs (i.e. specific towers) using AT+QNWLOCK syntax.

hazarjast
Posts: 133
Joined: Wed Dec 11, 2019 8:38 am
Has thanked: 16 times
Been thanked: 35 times

Re: Orbi LBR20 How-To / Megathread

Post by hazarjast » Thu Oct 08, 2020 3:41 pm

OP updated with my findings surrounding an "expiring" carrier aggregation quirk observed on T-Mobile and my subsequent workaround.

ssnacks
Posts: 1
Joined: Thu Oct 08, 2020 6:43 pm
Has thanked: 0
Been thanked: 2 times

Re: Orbi LBR20 How-To / Megathread

Post by ssnacks » Thu Oct 08, 2020 6:53 pm

Great work. Another option if you don't want to be dependent on external DNS to keep the firmware from being updated is to add an entry for devcom.up.netgear.com to /etc/hosts. I confirmed that gives me back a "Service unreachable" when I attempt to update.

Code: Select all

echo "127.0.0.1 devcom.up.netgear.com" >> /etc/hosts

hazarjast
Posts: 133
Joined: Wed Dec 11, 2019 8:38 am
Has thanked: 16 times
Been thanked: 35 times

Re: Orbi LBR20 How-To / Megathread

Post by hazarjast » Fri Oct 09, 2020 8:40 am

Yes, hosts file entry works great too; I should have mentioned this method as well. Thanks for sharing it!

I didn't really delve into it here but I like controlling all DNS queries from the device for other reasons as well such as blocking telemetry connections back to netgear and their partners. NextDNS provides stats down to the client level of what gets blocked so it's fun to see what calls are being made :)

cabegol
Posts: 1
Joined: Wed Oct 21, 2020 7:40 am
Has thanked: 0
Been thanked: 0

Re: Orbi LBR20 How-To / Megathread

Post by cabegol » Wed Oct 21, 2020 8:06 am

I'm sorry for the very ignorant question, can somebody help me with the first steps to create the ttl_mod file? Thank you!

Post Reply