Orbi LBR20 How-To / Megathread

[outrage18]

Progress, thanks for your email help. Unfortunately I'm getting connection refused when I try SSH to 192.168.1.1 port 22. Telnet works fine though. Can anyone help?

In case this might help others; I had previously used the auto update to get to v2.6.3.50 had not factory reset and was using a non-standard WAN IP. Script failed installing telnet. However, it worked straight up after:
1. reverted to v2.5.2.20
2. factory reset
3. Minimal setup -- only admin password & security questions.
4. manual update to v2.6.3.50 using hazerjast's link
5. disable windows defender private networks

[hazarjast]

Progress, thanks for your email help. Unfortunately I'm getting connection refused when I try SSH to 192.168.1.1 port 22. Telnet works fine though. Can anyone help?

In case this might help others; I had previously used the auto update to get to v2.6.3.50 had not factory reset and was using a non-standard WAN IP. Script failed installing telnet. However, it worked straight up after:
1. reverted to v2.5.2.20
2. factory reset
3. Minimal setup -- only admin password & security questions.
4. manual update to v2.6.3.50 using hazerjast's link
5. disable windows defender private networks

If telnet is still accessible that means that dropbear (SSH) wasn't started as part of dropbear startup is killing telnet daemon. OP was updated with troubleshooting suggestions and manual deployment steps if the script did not complete deployment fully. I would start there going through the troubleshooting steps and provide detail of what you see under '/mnt/circle/mods' and '/tmp/circle*'. If you see the scripts under 'mods' folder then you can run 'circle_jerk' script directly which should get SSH going. If SSH does not come back after a reboot though it would seem there is some unique problem occurring with your unit which may be related to the previous firmware version upgrades/downgrades.

[outrage18]

Thanks, when I reboot - I lose telnet as well. So I haven't been able to go in and check scripts. Visible running at 5M, indicating TTL rules not having desired effect. Taking a break for now, but will try more this eve, lmn if you have further thoughts. Perhaps I need to dig into the manual install steps.

[hazarjast]

Thanks, when I reboot - I lose telnet as well. So I haven't been able to go in and check scripts. Visible running at 5M, indicating TTL rules not having desired effect. Taking a break for now, but will try more this eve, lmn if you have further thoughts. Perhaps I need to dig into the manual install steps.

Yes, I would recommend performing the manual deployment steps.

[das1996]

Small updated. Tested with the freedompop sim. Seems they're not enforcing ttl now either. I did notice some strangeness. On initial boot with the fp sim, no internet after setting apn. Had to reboot the unit again.

Changed ttl to higher value (165). Hard web page refreshes were still relatively fast. Not the 128kbps I seen in the past.

Can others on att or att mvno's share their experience?

[egauk]

I run the NextDNS CLI daemon on my upstream PFSense firewall which has a WAN rule that allows incoming traffic from the Orbi (WAN) to the LAN IP of the PFSense which the CLI listens on (port 53). On the Orbi I am just overwriting '/etc/resolv.conf' with "nameserver [PFSense_IP]" so that it uses NextDNS for all its local DNS queries.

For those that want to use NextDNS directly on their Orbi I am using the below method, which is working well.

1. Create a resolve.conf with your NextDNS specific DNS Servers in the /mnt/circle/mods directory.

   Code: Select all

   nameserver 49.90.28.221
   nameserver 49.90.30.222
   nameserver 2a07:b8a0:0000:0000:0000:0000:00ae:2be1 # IPV6 wwan0
   nameserver 2a07:b8a1:0000:0000:0000:0000:00ae:2be2 # IPV6 wwan0
   

2. Add your NextDNS programmatic IP update URL and resolv.conf copy command to call_recurring using vi

   Code: Select all

   # Link IP to NextDNS
   curl https://link-ip.nextdns.io/abc123/abc12345678 > /dev/null 2>&1
   
   # Use NextDNS DNS Servers
   cp resolv.conf /etc/resolv.conf
   

[hazarjast]

For those that want to use NextDNS directly on their Orbi I am using the below method, which is working well.

1. Create a resolve.conf with your NextDNS specific DNS Servers in the /mnt/circle/mods directory.

   Code: Select all

   nameserver 49.90.28.221
   nameserver 49.90.30.222
   nameserver 2a07:b8a0:0000:0000:0000:0000:00ae:2be1 # IPV6 wwan0
   nameserver 2a07:b8a1:0000:0000:0000:0000:00ae:2be2 # IPV6 wwan0
   

2. Add the following to call_once using vi

   Code: Select all

   # Use NextDNS DNS Servers
   cp resolv.conf /etc/resolv.conf
   

3. Add your NextDNS programmatic IP update URL to call_recurring using vi

   Code: Select all

   # Link IP to NextDNS
   curl https://link-ip.nextdns.io/abc123/abc12345678 > /dev/null 2>&1
   

I would recommend moving the resolv.conf copy command into call_recurring since interface changes like cellular disconnect/reconnect will overwrite resolv.conf. This is why my example scripts that block Netgear auto update domains, by making entries for them in /etc/hosts, are in the recurring script.

[egauk]

Excellent point, I modified my original post.

[alamont]

Glad it worked. Not sure why a reboot was necessary as my tests with clean reset worked without reboot but I can add that as something to try for others in troubleshooting.

For TTL most folks would use mangle on the router to avoid having to set on each client device for carrier plans that differentiate on-device data from tether traffic using TTL. On the router it is set to mangle outgoing packets to 65 because on WAN exit it decrements to 64 which is the desired value once the traffic is on the carrier network. Some LAN setups may require adjusting this value but in most cases you wouldn’t want it to mangle to a value of 64 because it would then decrement and arrive with a value of 63.

Thanks hazarjast I think I better understand the purpose of the circle mod, let me know of the following question should be in another thread but since it pertains to the LBR20, I'll try here:

I have done no testing on location of the house I'm trying to get signal for, other than use an iphone that got weak At&t signal. I've used cellmapper to try and get a good idea of tower location and bands available, but I'm not sure what bands will truly be available once I start setting up a LTE antennas/modem. I know that the MOFI400 allows for scanning the local area for available bands, essentially seeing what's available to lock on to or aggregate. Is there a basic way to seach the available "landscape" of bands on the LBR20, or does it just give you the strongest band available and tell your the strength? I'm trying to avoid having to buy a MOFI4500 for fine tuning of antennas, AND an LBR20 for it's better modem/wifi. Any advice?

[hazarjast]

Thanks hazarjast I think I better understand the purpose of the circle mod, let me know of the following question should be in another thread but since it pertains to the LBR20, I'll try here:

I have done no testing on location of the house I'm trying to get signal for, other than use an iphone that got weak At&t signal. I've used cellmapper to try and get a good idea of tower location and bands available, but I'm not sure what bands will truly be available once I start setting up a LTE antennas/modem. I know that the MOFI400 allows for scanning the local area for available bands, essentially seeing what's available to lock on to or aggregate. Is there a basic way to seach the available "landscape" of bands on the LBR20, or does it just give you the strongest band available and tell your the strength? I'm trying to avoid having to buy a MOFI4500 for fine tuning of antennas, AND an LBR20 for it's better modem/wifi. Any advice?

Yes, certainly don't buy a MoFi just for doing a site survey that would be money wasted, IMHO. If anything an android phone with LTE Discovery app or renting a an LTE spectrum scanner/analyzer like a SureCall device would be cheaper and easier to deal with than lugging an overpriced MoFi around. I believe The Wireless Haven still offers site surveys as well if you prefer a turnkey solution:
https://thewirelesshaven.com/shop/tower-survey/ce ... y-reports/

In the LBR20 web gui, "Connection Status" will only show the currently connected band info (the "servingcell") but if you telnet/SSH into the unit you can run AT commands which will allow you more info via "neighbourcell" command and possibly others. I don't really have much experience in performing site surveys or band locking with a Quectel modem so please do not take this reply as comprehensive but I have used and covered cell locking in the OP which may help you (which I find easier / more useful in my current setup); just search the OP for "servingcell" and that should bring you to the section I'm referring to

Using the newly found minicom utility the command to check neighboring cell band and signal strength would be as follows:

Code: Select all

echo -ne "AT+QENG=\"neighbourcell\"\r\n" | microcom -X -t 1000 /dev/ttyUSB2

More detail on interpreting "servingcell"/"neighbourcell" output and locking to a desired cell here from one of my earlier replies:
https://wirelessjoint.com/viewtopic.php?p=14418#p14418

And you can use this handy table to match EARCFN in "neighbourcell" output to LTE band (ex. an EARCFN of 1125 would be LTE B2):
https://www.cablefree.net/wirelesstechn ... cy-earfcn/

Be warned that if that if you lock a specific cell and it goes offline (due to malfunction, service, etc.) you'll have to disable cell locking or reboot (first ensuring there aren't any scripts with cell lock commands in them that will execute on next startup) in order to get it back in "auto" mode else you will be offline until that cell comes back online again. The newer modem firmware A06 for US Retail models may have updated the cell locking command and/or syntax, I am not sure but I have only tested on A05.

[shinesmart]

Anyone have the A05 LTE firmware. Upgraded to A06 yesterday and it’s been very unstable. The connection seems to hang and I have to reboot to get reconnected every time it hangs.

Didn’t have this issue on the A05.

Cheers!

* I’m still on 2.5.3.4 and the TTL scripts are working fine with old method. Don’t see the need to update to 2.6.....but thought the LTE update was safe.

[hazarjast]

Anyone have the A05 LTE firmware. Upgraded to A06 yesterday and it’s been very unstable. The connection seems to hang and I have to reboot to get reconnected every time it hangs.

Didn’t have this issue on the A05.

Cheers!

* I’m still on 2.5.3.4 and the TTL scripts are working fine with old method. Don’t see the need to update to 2.6.....but thought the LTE update was safe.

Sorry to hear you're having issues. Unfortunately Netgear does not appear to offer archive versions of modem firmware, only the latest. It is very curious though that A06 would be giving these issues as on T-Mobile it has been more stable for me. If you get a chance to reply it would be good to know your carrier for the benefit of others who may be considering the A06 upgrade. Do you have any AT commands for cell/band locking you are sending to the modem aside from the iptables commands for TTL adjustment?

You can always interactively launch the Quectel connection manager and direct it's output to a log file for further investigation ('quectel-CM' command). On A06 you may find that the modem is connecting on a new band which is less stable; if that is the case then cell or band locking to the cell or band it was connecting on previously would likely help stabilize your connection.

[shinesmart]

I’m using Visible in my LBR20. So, yesterday I did a factory reset 2.5.3.4, updated to A06 LTE and recreated all the scripts using telnet and old method. The unit appears to work fine during the day, but each morning, the speeds are back to the capped 5mbps/5mbps. It’s as if the scripts are somehow being disabled every night. Once I reboot.....it works fine all day (60mbps/35mbps) until the next morning.

No AT commands, no cell locking. Only the TTL mod and the hosts mod scripts.

Will monitor it for the next day or two and report back. Thanks again for your help!

[hazarjast]

I’m using Visible in my LBR20. So, yesterday I did a factory reset 2.5.3.4, updated to A06 LTE and recreated all the scripts using telnet and old method. The unit appears to work fine during the day, but each morning, the speeds are back to the capped 5mbps/5mbps. It’s as if the scripts are somehow being disabled every night. Once I reboot.....it works fine all day (60mbps/35mbps) until the next morning.

No AT commands, no cell locking. Only the TTL mod and the hosts mod scripts.

Will monitor it for the next day or two and report back. Thanks again for your help!

I found that cronjobs were getting wiped out. I updated old method in OP to just call a script that stays running in background instead of using cron. I would try using that method.

[shinesmart]

Ok, will try the updated script. Just to be clear, if I don’t need to turn off WiFi and don’t need the 60 second wait, can you let me know the bootstrap script format?

Is it just:

#!/bin/sh

/mnt/ntgr/armor/mods/ttl_mod &

Thanks again!

[hazarjast]

Ok, will try the updated script. Just to be clear, if I don’t need to turn off WiFi and don’t need the 60 second wait, can you let me know the bootstrap script format?

Is it just:

#!/bin/sh

/mnt/ntgr/armor/mods/ttl_mod &

Thanks again!

Yes, that should be all that is required if all you are doing is changing the TTL.

[shinesmart]

With the revised basic ttl_mod script, I’m now getting uncapped speeds of 60/30. Upon each reboot, speeds are initially 5/5, but after about 10 minutes they are back to the higher speeds.

It appears the script isn’t running until 10 minutes after each reboot. I can live with it, but is there’s a way to have it execute immediately after the reboot? Is it the “sleep 600” that’s causing it?

Here are exact scripts:

BOOTSTRAP
#!/bin/sh

/mnt/ntgr/armor/mods/ttl_mod &

TTL_MOD
#!/bin/sh

while [ 1 ]
do

iptables -t mangle -C POSTROUTING -o wwan0 -j TTL --ttl-set 64 > /dev/null 2>&1 || \
iptables -t mangle -A POSTROUTING -o wwan0 -j TTL --ttl-set 64

ip6tables -t mangle -C POSTROUTING -o wwan0 -j HL --hl-set 64 > /dev/null 2>&1 || \
ip6tables -t mangle -A POSTROUTING -o wwan0 -j HL --hl-set 64

echo "127.0.0.1 localhost http.fw.updates1.netgear.com devcom.up.netgear.com" > /etc/hosts

sleep 600

done

[hazarjast]

With the revised basic ttl_mod script, I’m now getting uncapped speeds of 60/30. Upon each reboot, speeds are initially 5/5, but after about 10 minutes they are back to the higher speeds.

It appears the script isn’t running until 10 minutes after each reboot. I can live with it, but is there’s a way to have it execute immediately after the reboot? Is it the “sleep 600” that’s causing it?

Here are exact scripts:

BOOTSTRAP
#!/bin/sh

/mnt/ntgr/armor/mods/ttl_mod &

TTL_MOD
#!/bin/sh

while [ 1 ]
do

iptables -t mangle -C POSTROUTING -o wwan0 -j TTL --ttl-set 64 > /dev/null 2>&1 || \
iptables -t mangle -A POSTROUTING -o wwan0 -j TTL --ttl-set 64

ip6tables -t mangle -C POSTROUTING -o wwan0 -j HL --hl-set 64 > /dev/null 2>&1 || \
ip6tables -t mangle -A POSTROUTING -o wwan0 -j HL --hl-set 64

echo "127.0.0.1 localhost http.fw.updates1.netgear.com devcom.up.netgear.com" > /etc/hosts

sleep 600

done

You have to wait at least 5 minutes because it takes 3-5 minutes just for the unit to boot and load all services including the Bitdefender script which we piggy-back our bootstrap off of. The first fire off of the script never works to get the IPv6 TTL mangle for some reason so it "leaks" IPv6 traffic without the mangle until the script fires off again the second time. Sleep 600 is what has the script wait 10 minutes (600 seconds) before it fires off the iptables commands again to enforce them and then IPv6 rules works; do *not* remove the sleep command as the loop will execute too quickly without waiting which may produce a race condition or other issue. You can reduce it down to 300 seconds if you wish so that the iptables commands run every 5 minutes instead of 10.

Newer firmware with 'circle_jerk' mod executes as soon as any Internet access is detected (much sooner than 10 minutes) and IPv6 rules works the first time without issue but I've not found any way to get the old mod on older firmware to execute the IPv6 iptables rule successfully on first run. One could try picking another Bitdefender service to piggy-back off of which might shave off some time or allow the IPv6 command to take effect sooner but that is just my speculation.

FWIW, I typically go 90 days or more between any reboots (LBR20 is on a UPS backup as well so power never goes out for it) so waiting ~10 minutes was never an issue for me on the older firmware. If you find a way to get the TTL rules applied faster for those using the older mod/firmware please share it as I'm sure others would benefit. Since I am moving to the newer firmware and mod method I likely won't be investigating this issue of IPv6 commands any further.

As an aside, I did go back into the OP and update 'ttl_mod' this AM with newer insert ('-I') method of adding iptables rules instead of add ('-A') method; that along with 'POSTROUTING 1' syntax ensures the iptables rules always get inserted at the top of the chain. Also added comments over each IPv4/IPv6 section to explain what each command set touches. I have also gone back and updated sleep to 5 minutes (300 seconds) So, you could update your ttl_mod script with these changes if you would like.

[shinesmart]

Played around with setting the sleep value at 120 and then 60. Appears that “sleep 60” seems to work best as it executes the script every minute, so once all the services are loaded....it fires up the ttl_mod much faster (approx 2-3 into the reboot).

I’m waiting on my second LBR20 to arrive this weekend to try the new circle_jerk method. I’ll keep this current unit on the older firmware as my stable option.

Thanks for your detailed help.

[hazarjast]

Played around with setting the sleep value at 120 and then 60. Appears that “sleep 60” seems to work best as it executes the script every minute, so once all the services are loaded....it fires up the ttl_mod much faster (approx 2-3 into the reboot).

I’m waiting on my second LBR20 to arrive this weekend to try the new circle_jerk method. I’ll keep this current unit on the older firmware as my stable option.

Thanks for your detailed help.

That works

Sounds good, I will be upgrading my stable unit to the newer firmware this weekend to use 'circle_jerk' as Voxel appears to have now accepted my offer to ship my 'dev' unit to him so that he can release his firmware for the LBR20. Hopefully one day soon this will mean we no longer have to bootstrap off of anything but can run the device in any way we wish without dancing around Netgear's code.

No problem!

[hazarjast]

Some folks have asked that I provide some additional explanation on example commands in the circle_jerk, 'call_once' script that are commented out by default (and those that aren't). Mostly those which are commented out are things I personally use so I commented them out because they could be detrimental to your specific setup but I will provide some additional detail about them below:

Code: Select all

# Replace default Chaos Calmer MOTD
/mnt/circle/mods/banner

Pretty self-explanatory. Just gives a cool ASCII art banner replacement to the "OS/DK" which comes from Chaos Calmer by default. Website from which the ASCII art was generated is referenced in the script so you can make something of your own creation if you wanted to. This is completely unnecessary to the function of the mod but I figure why not leave your stamp on it?

Code: Select all

# Start SSH
/mnt/circle/mods/dropbear/start_db

Starts dropbear (SSH daemon) with a wrapper that checks if host keys are generated and, if they aren't yet, it generates them, sets 'root' password to the value of 'http_passwd_hashed' (the SHA256 hash of your web gui 'admin' password), starts dropbear bound to IPv4 (inet) IP of 'br0' (LAN interface), then kills any running telnet daemon for security.

Code: Select all

# Modem control examples
# Do *NOT* uncomment unless you know what you're doing
# and have modified for your appropriate carrier context
# The AT command below has been obfuscated to protect the innocent
#kill $(ps | grep '[q]uectel-CM' | awk '{print $1}')
#ln -sf /mnt/ntgr/armor/mods/default.script.wwan /usr/share/udhcpc/default.script.wwan
#echo -ne "AT+EMGR=1,7,\"012345678901234\"\r\n" | microcom -X -t 1000 /dev/ttyUSB2 > /dev/null 2>&1
#quectel-CM -s r.ispsn -a 0 -4 > /dev/null 2>&1 &

This section contains commands surrounding the modem and it's connection to the carrier. I have noticed that in some very specific scenarios which have not been nailed down, the modem seems to restore some or all of its default NVRAM values such as those which store the modem's device specific serial identifier (a.k.a. the "eye em ee eye"). So in order to enforce the value we wish to have, commands are executed to do the following in respective order:

1. Kill the active cellular connection by ending any Quectel connection manager ('quectel-CM') processes.
2. Symlink overwrite a custom version of udhcpc's 'default.script.wwan' which replaces the default one.
3. Set our desired NVRAM value (this specific 'AT' command has been obfuscated and doesn't exist as shown; the comment already explains this)
4. Start the cellular connection again via Quectel connection manager with 'r.ispsn' APN (one which Sprint hotspots use) and IPv4 settings.

You'll probably notice step #2 references the old '/mnt/ntgr/...' path. This is because it was something I was doing with the older firmware prior to circle_jerk. What I was doing was adding a line to 'default.script.wwan' which called the firewall rules script ('fw_rules') so that any time the connection was stopped or started by the Quectel connection manager and udhcpc (DHCP client service) was called, the iptables rules for TTL etc. would be added again after the firewall reload that naturally occurs on a reconnect. With circle_jerk already enforcing our rules via 'run_recurring' every 4 minutes this line is not required and wouldn't work anyways since we can't store anything on the Armor/BitDefender mount in the newer firmware anyway. This line is completely vestigial and should honestly just be removed the next time I get around to updating the installer repository.

If you want to know more about 'quectel-CM' command and its syntax you can look at the following PDF. Since this is 'trade-secret' OEM stuff Quectel has chosen not to publish updated versions of this document publicly so realize that some stuff won't match up with the version of the program that is running on the LBR20:
https://www.quectel.com/UploadImage/Dow ... e_V1.8.pdf

Code: Select all

# Cell Locking example
# Again, do *NOT* attempt unless you know what you're doing
#echo -ne "AT+QNWLOCK=\"common/4g\",1,1125,111\r\n" | microcom -X -t 1000 /dev/ttyUSB2 > /dev/null 2>&1

This code locks to my local CellID ('111') on B2 EARCFN ('1125'). I have provided detail on cell locking (and its caveats) in the OP and a couple times elsewhere in my replies to this thread. I would refer anyone looking for more detail on this topic to start with my latest reply which deals with cell locking, here:
https://wirelessjoint.com/viewtopic.php?p=17476#p17476

I prefer cell locking to band locking because with band locking, if you lock a single band, you lose CA (carrier aggregation) with other bands. You can of course create a lock to a mask/index/group of bands if you add the hex of the individual bands together but it's still some guesswork as to which PCC and SCC (primary carrier and secondary carrier) band combos your carrier and tower will support so for me, that is why I just lock to a cell (if I lock at all) so that I don't have to worry about creating the perfect group of bands with band locking. Also, if you're creating an index of bands which includes every available carrier band for your carrier that is pretty useless as it just has the modem working as it normally does by picking the strongest band for PCC (same as the default 'auto' setting which doesn't lock bands). The cell locking command on the LBR20 is also cleared on reboot which makes recovering from an incorrect lock easier; I believe band locking is stored in NVRAM so a reboot would not quickly resolve locking to an undesired band setting.

There maybe some situations in which band locking to a single band allows a more stable connection and the loss of possible CA is not a concern to the user but still, even in that case, I see no reason why locking to the cell wouldn't be the better alternative. I'm certainly not a Quectel expert here though so if anyone has some use cases in which they prefer to make the argument in favor of band locking, I am perfectly willing to hear them out and learn something new which enhances my understanding so that I can pass on more accurate or useful detail to others on this topic. For those that absolutely want to proceed with band locking I would point you to the following thread which gives the commands and a helpful spreadsheet that does the hex math for you when creating indexes of multiple bands. I would recommend that you obtain and keep record of the current band setting in the LBR20 prior to band locking it just in case you want to go back to its default setting at a later date:
https://wirelessjoint.com/viewtopic.php?t=943

Code: Select all

# Uncomment below section  if you want to disable all WiFi services
#kill $(ps | grep '[c]heck_status.sh' | awk '{print $1}')
#ln -sf /mnt/circle/mods/check_status.sh /sbin/check_status.sh
#/sbin/check_status.sh &
#wifi down
#/etc/init.d/soap_agent stop
#/etc/init.d/netscan stop
#/etc/init.d/wifison-monitor stop
#/etc/init.d/wsplcd stop
#kill $(ps | grep '[w]pa_supplicant' | awk '{print $1}')
#kill $(ps | grep '[t]ri_band_detect.sh' | awk '{print $1}')
#kill $(ps | grep '[h]ostapd' | awk '{print $1}')

Since the LBR20 is part of the Orbi family I realize many will be using its mesh WiFi capabilities. However, all I care to use it for is the LGA soldered EG18 Quectel modem inside, lol. Thus, the above commands kill off most every wireless related service on the box to clean up chatty serial console output when debugging and free up resources on the box for anything else I should care to run on it. I already have a nice UBNT WiFi setup so mostly turning off the LBR20 WiFi is for me about freeing up the airwaves from any further spectrum congestion. The unit runs a fair amount cooler and draws less power which further extends its life and the life of my PoE adapter which powers it. Obviously don't uncomment these commands if you want to use the LBR20's WiFi functionality.

Code: Select all

# Uncomment below section if you want to cripple telemetry sent
# to Netgear's AWS Instance
#/etc/init.d/aws stop

Netgear is utilizing Amazon Web Services IoT platform to manage their devices (although to what extent I have no idea); this is the API client for the AWS IoT platform. Much of its use probably has to do with the phone 'app' functionality to control the router using your iPhone or Android device when outside of your home. It is also appears to perform telemetry collection for their support folk and R&D guys. I don't need to control the router with my phone and am already blocking the unit from phoning home to 'devcom.up.netgear.com' anyways (which is their server that runs on AWS), so there's no reason for me to let the API client continue to idle.

[mtnchar]

Thank you for all the updates. I am sticking the 2.5.2.20 version presently, it has been very solid and so has the A05 modem firmware (for non-T-mobile carriers). My routers have stayed up for weeks without disconnection issues (but I am not using T-Mobile or Sprint).

I did note that the while loop for TTL mods does not seem work on my 2.5.2.20. When I check the iptables the entries are missing (despite the fact the script shows as an active process on the ps command). I found the modem that was connecting to a TTL sensitive carrier kept slowing down. Took me a while to pickup on the issue since it is a rarely used connection. After investigating the iptables mangle entries there were no ttl entries for ipv6 and sporadically for ipv4. Switching back to running the script through a cronjob has worked well. I saw some posts about TTL issues and maybe the while loop is unreliable.

I went back to using the cronjob function to run the TTL script and host update blocks every 3 minutes and this seems be solid on the 2.5.2.20. Was there a reason to abandon the cronjob method?

What are the tricks are to restore to 2.5.2.20 if a router updates. I know the new firmware changes the file-system layout destroying some partitions permanence between boots, is there a way to change the filesystem back to the version that has permanence on /mnt like the original/virgin 2.5.2.20 units?

I am only using this as modem, I wish the LBR20 had a bridge mode to bypass the routing hop, wireless, and network functions. The LBR20 is a fairly cheap way to get a solid and configurable Cat18 modem with external antenna connectors. I can't see anything in the new "updates" beyond 2.5.2.20 at least for me that really improves stability or the user experience but it does add quite a bit of complexity to access the device's configuration. I have been very happy with the stability and performance and it destroys the Mofi4500in performance at my location.

I will be adding your kill scripts to my cronjob to keep the rest of unneeded processes from running. The LBR20 is definitely cooler with the Wifi system disabled.

Thankfully if we get force upgraded you have a method of addressing the issues as far as we know. Maybe someday we'll get an open source firmware option and get our LBR20s away from Netgear's whims

[shinesmart]

Agreed, the A05 LTE firmware was the most stable before I upgraded to A06.

On A06, the speeds would randomly drop to 5mbps/5mbps overnight requiring a reboot to get back to faster speeds.

Followed hazarjast’s recommendation and deleted the cronjob method and moved to the simple script with “bootstrap” and “ttl_mod”. Also updated the ttl_mod script with the latest update in the OP.

So far the unit has been somewhat stable. I’m still on 2.5.3.4 with Visible sim and TTL is set at 64. I only use the unit in WiFi mode. I’m on day 2 with consistent speeds around 60/30.

My second LBR20 arrived yesterday, so will be testing the “circle_jerk” method on the most recent firmware soon.

[hazarjast]

Thank you for all the updates. I am sticking the 2.5.2.20 version presently, it has been very solid and so has the A05 modem firmware (for non-T-mobile carriers). My routers have stayed up for weeks without disconnection issues (but I am not using T-Mobile or Sprint).

I did note that the while loop for TTL mods does not seem work on my 2.5.2.20. When I check the iptables the entries are missing (despite the fact the script shows as an active process on the ps command). I found the modem that was connecting to a TTL sensitive carrier kept slowing down. Took me a while to pickup on the issue since it is a rarely used connection. After investigating the iptables mangle entries there were no ttl entries for ipv6 and sporadically for ipv4. Switching back to running the script through a cronjob has worked well. I saw some posts about TTL issues and maybe the while loop is unreliable.

I went back to using the cronjob function to run the TTL script and host update blocks every 3 minutes and this seems be solid on the 2.5.2.20. Was there a reason to abandon the cronjob method?

What are the tricks are to restore to 2.5.2.20 if a router updates. I know the new firmware changes the file-system layout destroying some partitions permanence between boots, is there a way to change the filesystem back to the version that has permanence on /mnt like the original/virgin 2.5.2.20 units?

I am only using this as modem, I wish the LBR20 had a bridge mode to bypass the routing hop, wireless, and network functions. The LBR20 is a fairly cheap way to get a solid and configurable Cat18 modem with external antenna connectors. I can't see anything in the new "updates" beyond 2.5.2.20 at least for me that really improves stability or the user experience but it does add quite a bit of complexity to access the device's configuration. I have been very happy with the stability and performance and it destroys the Mofi4500in performance at my location.

I will be adding your kill scripts to my cronjob to keep the rest of unneeded processes from running. The LBR20 is definitely cooler with the Wifi system disabled.

Thankfully if we get force upgraded you have a method of addressing the issues as far as we know. Maybe someday we'll get an open source firmware option and get our LBR20s away from Netgear's whims

As noted in a previous reply, some disconnect or interface state changes cause the cronjobs to be wiped out so they aren't reliable. I've not seen the while loop script have the issue you speak of but if cronjobs work better for you then that is all that matters. Use what seems to work best in your situation.

There are no 'tricks' to restoring to 2.5.2.20, should just be able to flash it. However, since the armor partition gets put into overlay FS you would have to undo that and I've not experimented to see if/how that is possible so you would be in uncharted territory there.

[hazarjast]

Agreed, the A05 LTE firmware was the most stable before I upgraded to A06.

On A06, the speeds would randomly drop to 5mbps/5mbps overnight requiring a reboot to get back to faster speeds.

Followed hazarjast’s recommendation and deleted the cronjob method and moved to the simple script with “bootstrap” and “ttl_mod”. Also updated the ttl_mod script with the latest update in the OP.

So far the unit has been somewhat stable. I’m still on 2.5.3.4 with Visible sim and TTL is set at 64. I only use the unit in WiFi mode. I’m on day 2 with consistent speeds around 60/30.

My second LBR20 arrived yesterday, so will be testing the “circle_jerk” method on the most recent firmware soon.

What you're describing with the overnight throttle to 5Mbps would have nothing to do with the modem firmware and everything to do with TTL mangle no longer being in place when using Visible or a similar carrier (since Visible throttles to 5Mbps for hotspot). I've been on A06 for a couple weeks without a connection drop or any throttle issues.

[shinesmart]

What do you think was causing the cronjobs to be deleted?

I was running A05 for weeks with no issue, then the problem started the day I updated to A06. Didn’t update the firmware, just the LTE.

I would like to dig deeper into this.......so if a method is discovered which allows one to downgrade to A05 I’ll be happy to test. I know the TTL mod is independent on LTE firmware, or at least it should be, but curious to know what was causing the issue.

Cheers!

[hazarjast]

What do you think was causing the cronjobs to be deleted?

I was running A05 for weeks with no issue, then the problem started the day I updated to A06. Didn’t update the firmware, just the LTE.

I would like to dig deeper into this.......so if a method is discovered which allows one to downgrade to A05 I’ll be happy to test. I know the TTL mod is independent on LTE firmware, or at least it should be, but curious to know what was causing the issue.

Cheers!

Cron appears to get wiped when net-wall firewall gets reloaded due to interface state changes. Modem firmware downgrade process itself shouldn’t be hard, the issue is finding A05 since Netgear doesn’t host an archive of older firmware links. If it is out there somewhere on their download site you would need to build a wrapper script to interface with the Akamai NetStorage platform API they use to query for it (this also may require certificate based authentication which would require extracting a cert from an unknown certificate store in the unit).

On the newer firmware there is a hidden page with an MBN firmware image selection (see OP for details). This would allow you to try a more carrier specific firmware image to see if it helped your issue. This is a catch 22 though since you want to stay on the older firmware and I do not believe the image selection is available on the older firmware hidden page.

If you find anything which enables persistent crontab entries definitely share it here in case it may help others. Unfortunately I do not have a lot of time to spend looking at the older firmware to solve this issue.

[mtnchar]

So far my cronjobs have stayed put. I am not sure what kind of interface change would cause cronjobs to die. Netgear has a couple of jobs in there as well (that I should probably get rid of as they look like update checks). So far crontab -l has shown the same three jobs for several days.

If you are having speed issues I would check the mangle tables to make sure the TTLs are still there. Mine were disappearing at times with the while(1) script, I don't know why maybe there was a typo I didn't catch. Oddly, the ipv6 mangle ttl was not persisting at times and this was causing speeds to downgrade.

To list the mangle tables at the command line on the router:

ip6tables --table mangle --list

iptables --table mangle --list

[hazarjast]

So far my cronjobs have stayed put. I am not sure what kind of interface change would cause cronjobs to die. Netgear has a couple of jobs in there as well (that I should probably get rid of as they look like update checks). So far crontab -l has shown the same three jobs for several days.

If you are having speed issues I would check the mangle tables to make sure the TTLs are still there. Mine were disappearing at times with the while(1) script, I don't know why maybe there was a typo I didn't catch. Oddly, the ipv6 mangle ttl was not persisting at times and this was causing speeds to downgrade.

To list the mangle tables at the command line on the router:

ip6tables --table mangle --list

iptables --table mangle --list

Cronjobs were wiped a few times when cellular connection has dropped; if your connection is relatively stable that's probably why you haven't seen it. It was rare for me as well but definitely observed it a few times. Netgear's cronjobs get reloaded when your custom crontab gets overwritten; that is why you see their jobs no matter what.

Yes, the ipv6 rule seems to be the one that has the hardest time sticking. There may be a bug somewhere in ipv6 stack which is being compensated for with ip6tables refreshes but I cannot say for certain.

Short args work as well for the lazy (myself included):
iptables -t mangle -L
ip6tables -t mangle -L

[shinesmart]

Before I run the auto deploy on the circle_jerk, can you advise what exactly the scripts are enabling/disabling?

All I want is the speed cap removed (Visible) and the firmware auto update disabled. Does the auto script also disable wifi? If so then I won’t run in auto mode.

[hazarjast]

Before I run the auto deploy on the circle_jerk, can you advise what exactly the scripts are enabling/disabling?

All I want is the speed cap removed (Visible) and the firmware auto update disabled. Does the auto script also disable wifi? If so then I won’t run in auto mode.

Neither the TFTP deployment nor the telnet commands actually start anything in regards to 'circle_jerk'. Only installation actions are performed (backup of existing circle scripts and symlinking to circle_jerk). What 'starts' it up is enabling the parental controls slider in the web gui and hitting 'apply'. Any startup config specific to me, like disabling wifi, has been left in the scripts but is commented out so it won't execute those commands unless you login and manually uncomment them.

The auto deploy will likely fail if you try it on older firmware though since 'telnetenable' is different on the newer firmware. Manual deployment to older firmware would *probably* work if you just used 'debug.htm' to enable telnet and skip the 'telnet-enable2.exe/py' step but I offer no guarantees since I haven't compared circle partition on older firmware to circle partition on newer firmware. Caveat emptor!

TL;DR
Deploying circle_jerk package won't disable your wifi but auto deploy has only been tested on newer firmware so YMMV.

[shinesmart]

Updated my Dev LBR20 unit today with v2.6.3.50 and A06 LTE firmware.

Did the manual circle_jerk install and all is working as expected. Visible sim and TTL of 64. Compared speeds on this Dev unit with my other Main unit running v2.5.3.4 and A06 (with old armor scripts, no cronjobs), and the speeds are almost identical 60/30. The iptables mangle definitely enables much faster on the Dev unit with newer firmware/method. As I have 2 Visible sims, will run both simultaneously for few days to compare.

Thanks again!

[TinMan]

So with the updated ttl_mod script do we just make that script and comment out the TTL mod section of the script in fw_rules or do they both need to run? My Verizon tablet plan continues to use hotspot data and Circle keeps turning itself off so I'm trying to figure out what I'm doing wrong.

[shinesmart]

Comparison shows the new firmware 2.6.3.50(A06) with circle_jerk has slightly faster and more consistent speeds. Also the unit seems more reliable overall.

Day 3 and it’s been online 100% vs the other unit with older firmware 2.5.3.4(A06) which I had to reboot at least twice due to it randomly going offline.

Is there a way to change the ‘root’ password on the new method to make it shorter?

Cheers!

[hazarjast]

Updated my Dev LBR20 unit today with v2.6.3.50 and A06 LTE firmware.

Did the manual circle_jerk install and all is working as expected. Visible sim and TTL of 64. Compared speeds on this Dev unit with my other Main unit running v2.5.3.4 and A06 (with old armor scripts, no cronjobs), and the speeds are almost identical 60/30. The iptables mangle definitely enables much faster on the Dev unit with newer firmware/method. As I have 2 Visible sims, will run both simultaneously for few days to compare.

Thanks again!

Excellent! Thanks for sharing an update

[hazarjast]

So with the updated ttl_mod script do we just make that script and comment out the TTL mod section of the script in fw_rules or do they both need to run? My Verizon tablet plan continues to use hotspot data and Circle keeps turning itself off so I'm trying to figure out what I'm doing wrong.

'ttl_mod' is a script with iptables commands used on the older firmware which uses Armor as a bootstrap. 'fw_rules' is a script with iptables commands used with the newer firmware which uses Circle as a bootstrap. It seems you may have conflated the two methods especially given your description of Circle "turning itself off". To help you in the best way possible it would be good to know which firmware version you are currently on and which specific steps you have taken to mod your unit thus far.

[TinMan]

'ttl_mod' is a script with iptables commands used on the older firmware which uses Armor as a bootstrap. 'fw_rules' is a script with iptables commands used with the newer firmware which uses Circle as a bootstrap. It seems you may have conflated the two methods especially given your description of Circle "turning itself off". To help you in the best way possible it would be good to know which firmware version you are currently on and which specific steps you have taken to mod your unit thus far.

I'm on the latest router firmware but still on A05 for the modem. I did the manual deployment of circle_jerk and thought I followed the instructions exactly, but I must have done something wrong. The scripts are in the /mnt/circle/mods folder but none of them are being run. I added the ttl_mod script later to see if that would help, and then realized after the fact that the fw_rules script already had the iptables commands, and also then realized that none of the scripts have been running. I was able to get the banner to load by manually running the script over telnet in PuTTY, but it reverted back to the stock banner as soon as I rebooted. I'm thinking maybe I need to do a hard reset and start over completely, but thought I'd see if you had any ideas just in case it's something simple that I might have missed.

[hazarjast]

Comparison shows the new firmware 2.6.3.50(A06) with circle_jerk has slightly faster and more consistent speeds. Also the unit seems more reliable overall.

Day 3 and it’s been online 100% vs the other unit with older firmware 2.5.3.4(A06) which I had to reboot at least twice due to it randomly going offline.

Is there a way to change the ‘root’ password on the new method to make it shorter?

Cheers!

Thank you for posting your test results; these are good data points for config/carrier comparison. I did not get a chance to upgrade to 2.6.3.50 over the weekend so still running A06 modem on 2.5.2.20 firmware on T-Mobile with a connection uptime of 19 days. It may be quite relevant that you were on 2.5.3.4. That specific firmware version was only provided for the US Cellular SKU of the LBR20 (LBR20-1USNAS). The instability you experienced may have its root in the fact that the US Cellular firmware was trying to use the US Cellular specific MBN in A06 despite your VZW SIM being inserted. Too many SKU-specific router and firmware versions to keep track of with this unit, lol.

The long password hash was chosen for security. You could change the following line in 'start_db' script to set the password to something else of your own desire but I would discourage embedding anything plaintext in the script for security reasons:

Code: Select all

echo "root:$(config get http_passwd_hashed)" | chpasswd > /dev/null 2>&1

[shinesmart]

Think you’re right about the MBN mismatch with the Visible sim since the feature to select a preferred MBN only exists in the newer firmware.

The password issue is no big deal, just that I wanted to ssh into the device on the fly from my iPhone to make any script or ttl adjustments. Luckily, I found an iOS app, ‘iTerminal’ that lets me save the ssh session together with user/pw, so logging into root is just one click. From there I can make the changes using native commands like vi, :wq...etc. without getting on my desktop.

[TinMan]

So I think I might have gotten it to work. I started by doing a hard reset on the modem and manually reloading the newest firmware. Then when I telneted in I noticed that the /mnt/circle/mods folder and all the scripts were still present, so I deleted all of that, and redid the manual deployment of circle_jerk. Now it looks like Circle is no longer turning itself off and the scripts are loading (custom banner is there when I telnet in). I had to disable my Bitdefender Total Security in order to download the circle_jerk files from GitHub and do the manual deployment, so hopefully it doesn't cause any issues once I turn it back on. If scripts do, in fact, continue to work for the next day or two I'll load the latest modem firmware as well and see how that fares.

I haven't figured out how to SSH in but I'll see if I can figure that out. When try to do it in PuTTY, I get the login screen, but typing "admin" as the user and then entering the root SSH password doesn't work. Is "admin" the proper user name for SSH?

[mtnchar]

I am glad to hear shinesmart had some success with the updates and modem firmware. I may trial the new firmware at least on my Visible LBR20. The Visible LBR20 seems to get kicked off the network connection about every 3-4 days and needs a restart on 2.5.2.20 firmware. So far the AT&T connected LBR20s on 2.5.2.20 run for weeks without disconnections. At my location Visible is lucky to run about 15/8mbs, I was going to try some Yagis to see if it helps boost my speed a bit.

[shinesmart]

Login via SSH as root, not admin!

[TinMan]

Login via SSH as root, not admin!

That worked. Thanks!

[outrage18]

Netgear is aware of an issue with the current firmware and is working on a fix that will be part of the next fw release. - After spending most of my evening on hold and talking to Netgear Tier 1 and 2 support about my issue; LBR20 will not connect to LTE after reboot; the Tier 2 support tech informed me that Netgear developers are aware of the issue and are working on a fix. However, there is no time frame as to when a fix will be available. If you use the App, you will be notified of a new fw release which fixes the issue. In the mean time, I was told that if your LBR20 fails to connect to LTE internet after a reboot; you will need to perform a factory reset and it is best to minimize rebooting.

[hazarjast]

Netgear is aware of an issue with the current firmware and is working on a fix that will be part of the next fw release. - After spending most of my evening on hold and talking to Netgear Tier 1 and 2 support about my issue; LBR20 will not connect to LTE after reboot; the Tier 2 support tech informed me that Netgear developers are aware of the issue and are working on a fix. However, there is no time frame as to when a fix will be available. If you use the App, you will be notified of a new fw release which fixes the issue. In the mean time, I was told that if your LBR20 fails to connect to LTE internet after a reboot; you will need to perform a factory reset and it is best to minimize rebooting.

I do not know anyone else on 2.6.3.50 having this issue but you could play with the MBNs to see if helps due to possible mismatch as I was saying a few posts back. I would not waste too much time with Netgear, their support folk and the people who write their firmware are separate entities so who knows if they are really talking to actual 'developers' or not. From the description it is not even clear if the router firmware is meant or if they could actually mean Quectel in reference to the modem firmware. On the off chance that a new router firmware release resolves your specific issue it may break other things that allow mods to work as we have already seen with the current firmware. As someone who works with folks in "Tier 2" support quite a lot in my day job I would take what they say with a grain of salt.

[egauk]

Netgear is aware of an issue with the current firmware and is working on a fix that will be part of the next fw release. - After spending most of my evening on hold and talking to Netgear Tier 1 and 2 support about my issue; LBR20 will not connect to LTE after reboot; the Tier 2 support tech informed me that Netgear developers are aware of the issue and are working on a fix. However, there is no time frame as to when a fix will be available. If you use the App, you will be notified of a new fw release which fixes the issue. In the mean time, I was told that if your LBR20 fails to connect to LTE internet after a reboot; you will need to perform a factory reset and it is best to minimize rebooting.

For me the issue was the Traffic Meter located under Advanced > Advanced Setup > Traffic Meter

If I enable the traffic meter with no limits, after a reboot the router would bounce the connection around every minute. Once disabled the connection was stable again. It may not be the same issue, but I was able to consistently reproduce with two LBR20s.

Router Firmware Version
V2.6.3.50

[outrage18]

Thanks, I never used traffic meter. However, I had set to 4G only under LTE settings and now leave it to auto 3G/4G.

After I got off phone with Netgear, I removed circle-jerk thru factory reset and deletion of /mnt/circle/mods folder. The unit worked as it should. I then re-ran the circle-jerk auto-install script, adjusted TTL value and that one useful command and confirmed full speeds on Visible. After only one reboot, however, the LBR once again would fail to connect once again.

It's now back to stock on latest fw, ran overnight and I've rebooted at least 10x -- no issues. So, sadly it seems circle_jerk is problematic on my unit...

[outrage18]

Never used the orbi app, but Netgear tells me that it will notify me of updated fw availability. SOO, I just installed the Android version and lo and behold, it is gave me an option to update to fw version 2.6.4.2; which is NOT available on the Netgear LBR20 download site... Since, I've little to lose, I upgraded. As expected, lbr worked fine after upgrade and survived 2 reboots.

I then tried the circle_jerk automated install script which failed with message "...No connection could be made because the target machine actively refused it at 192.168.1.1:23" However, manual install worked. I was able to enable circle, ssh in and make minimal necessary changes to call_once and fw_rules scripts. Speedtest.net showed excellent unthrottled speeds on Visible. I then rebooted and once again the LBR failed to connect. Statistics is showing "link Down" for WAN, LAN and LTE. Connection status shows 0.0.0.0 both for IP address and DNS Server; while SIM is READY and SIM IMSI is shown correctly. In addition, Band Number is shown as '2' which is a Visible/vzw band available here. But Connection Status is 'disconnected'

Update: Netgear is processing an RMA to replace my unit.

[das1996]

I'd be weary of using any netgear cr@p on my phone devices. The analytics and phone home stuff is plentiful.

I dread the day we have an actual fiber outage here and I need to connect this lbr20 as backup.

[hazarjast]

Thanks, I never used traffic meter. However, I had set to 4G only under LTE settings and now leave it to auto 3G/4G.

After I got off phone with Netgear, I removed circle-jerk thru factory reset and deletion of /mnt/circle/mods folder. The unit worked as it should. I then re-ran the circle-jerk auto-install script, adjusted TTL value and that one useful command and confirmed full speeds on Visible. After only one reboot, however, the LBR once again would fail to connect once again.

It's now back to stock on latest fw, ran overnight and I've rebooted at least 10x -- no issues. So, sadly it seems circle_jerk is problematic on my unit...

In all actuality it’s probably some of my custom commands that you are uncommenting in the scripts. I have not seen anyone report issues who is using the basic scripts. It’s the Quectel connection manager and additional AT commands that can definitely cause issues depending on how they are customized and when they execute. I would recommend sticking to the basics if using the commands which I commented out (for my personal setup) cause issues. This is why they are commented out as they are untested on anything but my own setup and carrier.

[hazarjast]

I'd be weary of using any netgear cr@p on my phone devices. The analytics and phone home stuff is plentiful.

I dread the day we have an actual fiber outage here and I need to connect this lbr20 as backup.

You can always kill the telemetry with hosts file entries and killing any unwanted daemons on startup. This is detailed in the OP.

[hazarjast]

Never used the orbi app, but Netgear tells me that it will notify me of updated fw availability. SOO, I just installed the Android version and lo and behold, it is gave me an option to update to fw version 2.6.4.2; which is NOT available on the Netgear LBR20 download site... Since, I've little to lose, I upgraded. As expected, lbr worked fine after upgrade and survived 2 reboots.

I then tried the circle_jerk automated install script which failed with message "...No connection could be made because the target machine actively refused it at 192.168.1.1:23" However, manual install worked. I was able to enable circle, ssh in and make minimal necessary changes to call_once and fw_rules scripts. Speedtest.net showed excellent unthrottled speeds on Visible. I then rebooted and once again the LBR failed to connect. Statistics is showing "link Down" for WAN, LAN and LTE. Connection status shows 0.0.0.0 both for IP address and DNS Server; while SIM is READY and SIM IMSI is shown correctly. In addition, Band Number is shown as '2' which is a Visible/vzw band available here. But Connection Status is 'disconnected'

Update: Netgear is processing an RMA to replace my unit.

Hope your RMA replacement helps but I doubt it. It’s clear from your replies your unit works fine on 2.6.3.50 and the latest one you downloaded as long as you don’t have the mod active. I suspect if you leave my custom setup commands commented out things would work better. You could have a lemon but what you describe sounds like it’s related to the custom commands I commented out for a reason.

[kirewade]

Hey quick question. How do i check if i am getting CA and can you band lock on this router?

[egauk]

Hey quick question. How do i check if i am getting CA and can you band lock on this router?

Confirm Carrier Aggregation Combos (I've noticed it only activates CA after initial speed test)

Code: Select all

echo -ne "AT+QCAINFO\r\n" | microcom -X -t 1000 /dev/ttyUSB2

You can band lock, I used this thread to help me through the process.
https://wirelessjoint.com/viewtopic.php?f=16 ... band+excel

[frank33v]

I have been using my Orbi LBR20 on AT&T successfully now all winter following the original instructions with the ttl mod script and shutting down wifi and blocking updates.

I am on 2.5.2.20 and FW A05.

For some reason my MAGIC keeps reverting back and it I lose internet connection. Reboot, redo magic and I am back in business. Less than 24hrs later it happens again.

IS this a known issues now? Do I need to upgrade and try to figure out this new process listed above to make my Orbi stable with AT&T.

[mtnchar]

Never used the orbi app, but Netgear tells me that it will notify me of updated fw availability. SOO, I just installed the Android version and lo and behold, it is gave me an option to update to fw version 2.6.4.2; which is NOT available on the Netgear LBR20 download site... Since, I've little to lose, I upgraded. As expected, lbr worked fine after upgrade and survived 2 reboots.

I then tried the circle_jerk automated install script which failed with message "...No connection could be made because the target machine actively refused it at 192.168.1.1:23" However, manual install worked. I was able to enable circle, ssh in and make minimal necessary changes to call_once and fw_rules scripts. Speedtest.net showed excellent unthrottled speeds on Visible. I then rebooted and once again the LBR failed to connect. Statistics is showing "link Down" for WAN, LAN and LTE. Connection status shows 0.0.0.0 both for IP address and DNS Server; while SIM is READY and SIM IMSI is shown correctly. In addition, Band Number is shown as '2' which is a Visible/vzw band available here. But Connection Status is 'disconnected'

Update: Netgear is processing an RMA to replace my unit.

I have had the exact same issue on Visible with 2.5.2.20 and FW A05. I am not sure what causes this to happen. I switched my LBR20s so the one refusing to connect to Visible connected to ATT without issues. The other LBR20 had been on ATT for months connected with the Visible sim with no issue. I just had to update the configurations a bit (just the APNs).
I haven't yet tried to switch back. I am wondering if something in the Visible SIM config is causing the issue.

What is the best way to factory reset the modem of the LBR20? Is the AT&F command the best way to restore the modem to factory defaults and delete carrier network configurations? I have not tried sending the modem this command to see if this might fix the issue, then re-insert the SIM as things are working now, but I suspect the same issue will eventually happen to all my LBR20s with Visible.

[gscheb]

Hello,
Skimmed thru this whole post. Wanting to know if you can use a AT&T post pay tablet plan with little effort? Been using it in a Netgear LB1120 with AT&T post pay tablet plan with no issues. Just this is an out of date device Category 4 modem with no band 66. Just looking to upgrade but want to keep it simple. Like change the APN and ready to go simple.

[outrage18]

ATT Post pay tablet plan will work with just APN change - but you risk termination as TOS requires SIM be used only in a tablet.

[egauk]

How is everyone using custom DNS when Circle is enabled?

With Circle enabled the custom/static DNS option cannot be selected in the UI? With Circle disabled I can set custom DNS, but then it reverts back to dynamic when I re-enable Circle.

[egauk]

That works

Sounds good, I will be upgrading my stable unit to the newer firmware this weekend to use 'circle_jerk' as Voxel appears to have now accepted my offer to ship my 'dev' unit to him so that he can release his firmware for the LBR20. Hopefully one day soon this will mean we no longer have to bootstrap off of anything but can run the device in any way we wish without dancing around Netgear's code.

No problem!

Fingers crossed that Voxel is able to release his firmware for the LBR20

[outrage18]

How is everyone using custom DNS when Circle is enabled?

With Circle enabled the custom/static DNS option cannot be selected in the UI? With Circle disabled I can set custom DNS, but then it reverts back to dynamic when I re-enable Circle.

This custom DNS server example uses Google public DNS servers
In the /mnt/circle/mods directory, create a new resolv.conf file, that contains the IP addresses of your desired DNS servers
vi resolv.conf
Hit ‘a’ to append and paste in the following lines:

nameserver 8.8.8.8
nameserver 8.8.4.4
nameserver 2001:4860:4860::8888 # IPV6 wwan0
nameserver 2001:4860:4860::8844 # IPV6 wwan0

Write & Quit
Esc
:wq
Edit the ‘call_recurring’ script
vi call_recurring
Using arrow buttons, navigate to the end of the last line of the script, hit a to append from that location, hit enter twice to leave a blank line and start a new line then paste in the following

# This command periodically overwrites stock DNS servers with the ones you
# saved in the new resolv.conf file
cp /mnt/circle/mods/resolv.conf /tmp/resolv.conf

Write & Quit
esc
:wq

Reboot; give it a couple minutes after the LBR20’s WiFi link comes up and load up 192.168.1.1/adv_index.htm, you should see the Google IPv4 DNS servers, or the ones you choose to use under INTERNET PORT

[frank33v]

I have been using my Orbi LBR20 on AT&T successfully now all winter following the original instructions with the ttl mod script and shutting down wifi and blocking updates.

I am on 2.5.2.20 and FW A05.

For some reason my MAGIC keeps reverting back and it I lose internet connection. Reboot, redo magic and I am back in business. Less than 24hrs later it happens again.

IS this a known issues now? Do I need to upgrade and try to figure out this new process listed above to make my Orbi stable with AT&T.

Bump...Is this a known issue?? Do I need to upgrade and figure out the circle_jerk hack? Perhaps my firmware got corrupted? I did have a power outage.

[shinesmart]

Finally was able to find the LTE downgrade file to go from A06 back to A05.

https://www.downloads.netgear.com/files ... ge(US).zip

Hope this helps if anyone needs to downgrade.

[mtnchar]

Bump...Is this a known issue?? Do I need to upgrade and figure out the circle_jerk hack? Perhaps my firmware got corrupted? I did have a power outage.

What magic is getting lost? Did this unit every get upgraded beyond 2.5.2.20, this seems to affect persistence of settings and I would go forward and try hazarjast's solution for the newest updates. If not I would upgrade the LTE firmware to A06 as this did help some settings for me that seems to be spontaneously resetting.

[wasabi]

I completed the upgrade today and wanted to share - as I went ahead and jumped to the most recent firmware V2.6.4.2. Happy to report that circle_jerk installs just fine with this version and as far as I can tell works.

My speed test just after the install is great (possibly better than before) but I haven't had any real run time with it yet (literally just finished the process).

For reference and to possibly help newbies - here are the steps I did:

1. Used WebUI to Reset to Factory (Administration > Backup Settings)
a. Note: this resets the Orbi to 192.168.1.1
2. Set admin password and recovery questions, left everything else default skipping where possible
3. Updated to V2.5.3.4 firmware via pre-downloaded zip (Orbi was not connected to internet)
a. Probably not needed but I did it by accident (chose wrong file lol)
4. Updated to V2.6.3.50 firmware via pre-downloaded zip (Orbi was not connected to internet)
a. This was in the OP
5. Connected to Orbi to internet/LTE by updating the APN
a. I'm using Calyx so only needed to set this to r.ispsn
6. Updated to V2.6.4.2 firmware via WebUI directly
a. Had not seen any comments about this version so it must be super new
7. Updated LTE Firmware from R01A05 to R01A06 via WebUI directly
8. After all firmware updates completed successfully - performed another factory reset
a. Probably not needed but I wanted a completely clean slate and since I hadn't done any actual configuration yet, so why not
9. Set admin password and recovery questions
10. Selected the mobile network configuration for Sprint\T-Mobile via the new /hidden_info.htm page
a. Selected: Commerical-TMO
b. Note: This does not set the APN - that will be done later
11. Set my desired internal IP and DHCP Range (eg: Change the LAN Setup IP to: 10.10.10.1)
12. Installed Circle_Jerk following Manual Instructions
a. Far simpler than I thought it would be to be honest
13. Rebooted
14. Logged into SSH via Putty (success)
15. Configuration of Circle_Jerk was completed:
a. Disabled WiFi
b. Configured the modem
c. Disabled Netgear IOT check-ins
d. Set DNS nameservers to Google DNS (instructions from a post in this megathread)
16. Adjusted the Authentication Type to IPv4v6
17. Rebooted
-Complete-

Thank you Hazarjast and to the many others that have posted tips and tricks in this megathread!

[muenchris]

You step 15.c step says "Disable Netgear IOT check-ins".
What exactly did you do here?
Is this helping with the problem that some IOT device do not work with the LBR20?

Thanks

[bigcache]

Weird, I choose to auto deploy, but after I got the SSH password, the command jump out:

Connect request failed.

And of course cannot ssh to LBR20, and I telnet to find there's no mods in that directory.

[Cool Ranch]

Any idea how to band lock this router to 2 and 71? I can't find the commands

[egauk]

Any idea how to band lock this router to 2 and 71? I can't find the commands

You will need to use the band calculator to determine the hex for locking the bands.
https://wirelessjoint.com/viewtopic.php?f=16&t=943

Example Command

Code: Select all

echo -ne "AT+QCFG=\"band\",0,42000001003300385a\r\n" | microcom -X -t 1000 /dev/ttyUSB2

[Cool Ranch]

You will need to use the band calculator to determine the hex for locking the bands.
https://wirelessjoint.com/viewtopic.php?f=16&t=943

Example Command

Code: Select all

echo -ne "AT+QCFG=\"band\",0,42000001003300385a\r\n" | microcom -X -t 1000 /dev/ttyUSB2

worked perfectly. Instantly locked to 2 with 71 as back up. Thank you so much <3

[shinesmart]

Need some help! Trying to lock Band 66, with Band 2 as the backup. This is what I tried:

echo -ne "AT+QCFG=\“band\”,0,20000000000000002a\r\n" | microcom -X -t 1000 /dev/ttyUSB2

Also, what’s the command for removing the band lock and putting it back to Auto?

[shinesmart]

Was able to request the EG18 modem AT Commands Manual from Quectel and put together the following Telnet commands that work with the LBR20:

Enable Auto Band Setting:
echo -ne "AT+QCFG=\"nwscanmode\",0,1\r\n" | microcom -X -t 1000 /dev/ttyUSB2

Enable Default Band Setting:
echo -ne "AT+QCFG=\"band\",0,42000001003300385a\r\n" | microcom -X -t 1000 /dev/ttyUSB2

Check Current Band Setting:
cat /dev/ttyUSB2` echo -e "AT+QCFG=\"band\"\r\n" > /dev/ttyUSB2`

Check Extended Configuration:
cat /dev/ttyUSB2` echo -e "AT+QCFG=?\r\n" > /dev/ttyUSB2`

Unfortunately, I couldn’t figure out how to lock Band 66, so I changed back to Auto.

[shinesmart]

*** UPDATE ***
It’s safe to update to v2.6.5.2! CircleJerk still present and all is working as expected. No need to reinstall CJ. Performed about 4 reboots……and all is well.
***************

Anyone tested the new firmware 2.6.5.2? Does circlejerk still work with no issues?

May test it this weekend.

[hazarjast]

I have been using my Orbi LBR20 on AT&T successfully now all winter following the original instructions with the ttl mod script and shutting down wifi and blocking updates.

I am on 2.5.2.20 and FW A05.

For some reason my MAGIC keeps reverting back and it I lose internet connection. Reboot, redo magic and I am back in business. Less than 24hrs later it happens again.

IS this a known issues now? Do I need to upgrade and try to figure out this new process listed above to make my Orbi stable with AT&T.

Sorry for months late reply. Life got busy again.

Yes, I have seen this happen but I was not able to consistently reproduce this on Sprint/T-Mobile and do not have a nano SIM for my AT&T plan (using it in a Unite Explore which requires micro SIM so can't cut it down). I worked with one other person on Verizon who saw this too but only after reboots not every day. You will see in some of my commented out commands in the CJ scripts that I was putzing around with killing the quectel connection manager just after startup, setting 'magic' then re-launching the connection with quectel connection manager. However others earlier in this thread of have uncommented these commands so caveat emptor if you decide to play with them.

As a summary, if this happens it can be mitigated by setting 'magic' again periodically in a scripted fashion but because this has not been reproducible behavior (especially for me on A06 modem firmware), I have not invested much time or effort into it.

[hazarjast]

ATT Post pay tablet plan will work with just APN change - but you risk termination as TOS requires SIM be used only in a tablet.

Pretty much anything done using the methods in this thread and forum are ToS violations to lesser or greater degrees (depending on which lawyer you ask on a given day) which is why I advise everyone to be discreet and careful and know the risks they are taking when proceeding any specific modifications to stock device firmware.

IMHO, If something is sold as "unlimited" data it should deliver on this promise when paid for. Unfortunately many carriers (especially in USA) like to bait and switch their customers in order that profitability for shareholders increases infinitely. With modern network management and the fat backbones available with all the 5G fixed-point home internet product rollouts, network capacity is no longer a defense for this behavior in most markets. Thus, we play their game and make our devices of choice into "approved" devices to use the data pipes for which they already charge us $$$.