Re: RBK53 issues with 2.5.1.8

GadgetVirtuoso2 · ‎2020-04-05

Add me to the list of everyone having issues with 2.5.1.8. Yesterday I completely reset the unit and it worked for about a day. Now a day later I'm having issues with WiFi all over again. Anything plugged into the router has had no issues with internet. Anything wireless sees everything from DHCP to dropped packets to DNS issues. Wired devices see no internet issues and are seeing speeds near my service speeds of 500/500 Mbps. After I reset the units I was seeing 300-400+ Mbps pretty steadily but now the speeds are back down to less than 50Mbps, if the speed test can even run at all.

I've done a WiFi scan and I've selected channels that aren't being used my neighbors, but being in a single family home I don't get a whole lot of signal noise from them anyway. I've set DNS to use Google DNS, I was seeing failed resolutions on Cloudfaire's system as a number people have in recent months for some services.

Ping results from my MBP, These dropped packets and high ping times crop up periodcially and I'm only sitting 10FT from the main unit.

Tie-Interceptor:~ matthew$ ping orbilogin.com
PING orbilogin.com (172.16.1.1): 56 data bytes
64 bytes from 172.16.1.1: icmp_seq=0 ttl=64 time=3.767 ms
64 bytes from 172.16.1.1: icmp_seq=1 ttl=64 time=14.462 ms
64 bytes from 172.16.1.1: icmp_seq=2 ttl=64 time=9.454 ms
64 bytes from 172.16.1.1: icmp_seq=3 ttl=64 time=3.266 ms
64 bytes from 172.16.1.1: icmp_seq=4 ttl=64 time=5.963 ms
64 bytes from 172.16.1.1: icmp_seq=5 ttl=64 time=10.158 ms
64 bytes from 172.16.1.1: icmp_seq=6 ttl=64 time=8.213 ms
64 bytes from 172.16.1.1: icmp_seq=7 ttl=64 time=14.071 ms
64 bytes from 172.16.1.1: icmp_seq=8 ttl=64 time=2.485 ms
64 bytes from 172.16.1.1: icmp_seq=9 ttl=64 time=8.604 ms
64 bytes from 172.16.1.1: icmp_seq=10 ttl=64 time=43.186 ms
64 bytes from 172.16.1.1: icmp_seq=11 ttl=64 time=2.012 ms
64 bytes from 172.16.1.1: icmp_seq=12 ttl=64 time=3.321 ms
64 bytes from 172.16.1.1: icmp_seq=13 ttl=64 time=2.850 ms
64 bytes from 172.16.1.1: icmp_seq=14 ttl=64 time=2.760 ms
64 bytes from 172.16.1.1: icmp_seq=15 ttl=64 time=2.764 ms
64 bytes from 172.16.1.1: icmp_seq=16 ttl=64 time=12.485 ms
Request timeout for icmp_seq 17
Request timeout for icmp_seq 18
64 bytes from 172.16.1.1: icmp_seq=18 ttl=64 time=1994.081 ms
64 bytes from 172.16.1.1: icmp_seq=19 ttl=64 time=993.288 ms
64 bytes from 172.16.1.1: icmp_seq=20 ttl=64 time=190.391 ms
64 bytes from 172.16.1.1: icmp_seq=21 ttl=64 time=2.732 ms
64 bytes from 172.16.1.1: icmp_seq=22 ttl=64 time=2.788 ms
64 bytes from 172.16.1.1: icmp_seq=23 ttl=64 time=1.962 ms
64 bytes from 172.16.1.1: icmp_seq=24 ttl=64 time=3.797 ms
64 bytes from 172.16.1.1: icmp_seq=25 ttl=64 time=4.714 ms
64 bytes from 172.16.1.1: icmp_seq=26 ttl=64 time=4.011 ms
64 bytes from 172.16.1.1: icmp_seq=27 ttl=64 time=3.789 ms
64 bytes from 172.16.1.1: icmp_seq=28 ttl=64 time=8.354 ms
64 bytes from 172.16.1.1: icmp_seq=29 ttl=64 time=257.786 ms
64 bytes from 172.16.1.1: icmp_seq=30 ttl=64 time=2.906 ms
64 bytes from 172.16.1.1: icmp_seq=31 ttl=64 time=2.210 ms
64 bytes from 172.16.1.1: icmp_seq=32 ttl=64 time=3.318 ms
64 bytes from 172.16.1.1: icmp_seq=33 ttl=64 time=53.918 ms
64 bytes from 172.16.1.1: icmp_seq=34 ttl=64 time=5.087 ms
64 bytes from 172.16.1.1: icmp_seq=35 ttl=64 time=8.635 ms
64 bytes from 172.16.1.1: icmp_seq=36 ttl=64 time=2.607 ms
64 bytes from 172.16.1.1: icmp_seq=37 ttl=64 time=4.313 ms
64 bytes from 172.16.1.1: icmp_seq=38 ttl=64 time=3.778 ms
64 bytes from 172.16.1.1: icmp_seq=39 ttl=64 time=9.654 ms
64 bytes from 172.16.1.1: icmp_seq=40 ttl=64 time=4.007 ms
64 bytes from 172.16.1.1: icmp_seq=41 ttl=64 time=12.065 ms
64 bytes from 172.16.1.1: icmp_seq=42 ttl=64 time=11.442 ms
64 bytes from 172.16.1.1: icmp_seq=43 ttl=64 time=4.169 ms
64 bytes from 172.16.1.1: icmp_seq=44 ttl=64 time=3.052 ms
64 bytes from 172.16.1.1: icmp_seq=45 ttl=64 time=1.969 ms
64 bytes from 172.16.1.1: icmp_seq=46 ttl=64 time=8.843 ms
64 bytes from 172.16.1.1: icmp_seq=47 ttl=64 time=9.007 ms
64 bytes from 172.16.1.1: icmp_seq=48 ttl=64 time=7.251 ms
64 bytes from 172.16.1.1: icmp_seq=49 ttl=64 time=4.591 ms
64 bytes from 172.16.1.1: icmp_seq=50 ttl=64 time=162.554 ms
64 bytes from 172.16.1.1: icmp_seq=51 ttl=64 time=34.826 ms
64 bytes from 172.16.1.1: icmp_seq=52 ttl=64 time=9.537 ms
64 bytes from 172.16.1.1: icmp_seq=53 ttl=64 time=3.984 ms
64 bytes from 172.16.1.1: icmp_seq=54 ttl=64 time=5.372 ms
64 bytes from 172.16.1.1: icmp_seq=55 ttl=64 time=11.460 ms
Request timeout for icmp_seq 57
64 bytes from 172.16.1.1: icmp_seq=58 ttl=64 time=932.542 ms
64 bytes from 172.16.1.1: icmp_seq=59 ttl=64 time=771.034 ms
64 bytes from 172.16.1.1: icmp_seq=60 ttl=64 time=3.333 ms

CrimpOn · ‎2020-04-05

Are you also going to join the list of people "going back" to 2.3.5.30?

PCSP · ‎2020-04-05

Should I update firmware 2.5.1.8? Now I stay at 2.3.5.30 for a few months

FURRYe38 · ‎2020-04-06

What is the Mfr and model# of the ISP modem/ONT the NG router is connected too?

What is the size of your home? Sq Ft?
What is the distance between the router and satellite(s)? 30 feet is recommended in between RBR and RBS to begin with depending upon building materials when wirelessly connected. https://kb.netgear.com/000036466/How-far-should-I-place-my-Orbi-satellite-from-my-Orbi-router

What channels are you using? Auto? Try setting manual channel 1, 6 or 11 on 2.4Ghz and any unused channel on 5Ghz.

Try enabling Beamforming and MIMO(MIMO may or maynot be needed) and WMM. Under Advanced Tab/Advanced Settings/Wireless Settings

Try disabling the following and see:
Armor, Circle, Daisy Chain, Fast Roaming, IPv6 and Set 20/40Mhz Coexistence to 40Mhz only. Set Short preamble instead of Long preamble modes. Save settings and reboot the router and satellite(s).

You can try Voxels FW for Orbi:
https://community.netgear.com/t5/Orbi/Voxels-FW-available-for-50-series-Orbi-only-available/m-p/1883...
You can revert back to stock FW if it doesn't work out for you.

@GadgetVirtuoso2 wrote:
Add me to the list of everyone having issues with 2.5.1.8. Yesterday I completely reset the unit and it worked for about a day. Now a day later I'm having issues with WiFi all over again. Anything plugged into the router has had no issues with internet. Anything wireless sees everything from DHCP to dropped packets to DNS issues. Wired devices see no internet issues and are seeing speeds near my service speeds of 500/500 Mbps. After I reset the units I was seeing 300-400+ Mbps pretty steadily but now the speeds are back down to less than 50Mbps, if the speed test can even run at all.

I've done a WiFi scan and I've selected channels that aren't being used my neighbors, but being in a single family home I don't get a whole lot of signal noise from them anyway. I've set DNS to use Google DNS, I was seeing failed resolutions on Cloudfaire's system as a number people have in recent months for some services.

Ping results from my MBP, These dropped packets and high ping times crop up periodcially and I'm only sitting 10FT from the main unit.
Tie-Interceptor:~ matthew$ ping orbilogin.com
PING orbilogin.com (172.16.1.1): 56 data bytes
64 bytes from 172.16.1.1: icmp_seq=0 ttl=64 time=3.767 ms
64 bytes from 172.16.1.1: icmp_seq=1 ttl=64 time=14.462 ms
64 bytes from 172.16.1.1: icmp_seq=2 ttl=64 time=9.454 ms
64 bytes from 172.16.1.1: icmp_seq=3 ttl=64 time=3.266 ms
64 bytes from 172.16.1.1: icmp_seq=4 ttl=64 time=5.963 ms
64 bytes from 172.16.1.1: icmp_seq=5 ttl=64 time=10.158 ms
64 bytes from 172.16.1.1: icmp_seq=6 ttl=64 time=8.213 ms
64 bytes from 172.16.1.1: icmp_seq=7 ttl=64 time=14.071 ms
64 bytes from 172.16.1.1: icmp_seq=8 ttl=64 time=2.485 ms
64 bytes from 172.16.1.1: icmp_seq=9 ttl=64 time=8.604 ms
64 bytes from 172.16.1.1: icmp_seq=10 ttl=64 time=43.186 ms
64 bytes from 172.16.1.1: icmp_seq=11 ttl=64 time=2.012 ms
64 bytes from 172.16.1.1: icmp_seq=12 ttl=64 time=3.321 ms
64 bytes from 172.16.1.1: icmp_seq=13 ttl=64 time=2.850 ms
64 bytes from 172.16.1.1: icmp_seq=14 ttl=64 time=2.760 ms
64 bytes from 172.16.1.1: icmp_seq=15 ttl=64 time=2.764 ms
64 bytes from 172.16.1.1: icmp_seq=16 ttl=64 time=12.485 ms
Request timeout for icmp_seq 17
Request timeout for icmp_seq 18
64 bytes from 172.16.1.1: icmp_seq=18 ttl=64 time=1994.081 ms
64 bytes from 172.16.1.1: icmp_seq=19 ttl=64 time=993.288 ms
64 bytes from 172.16.1.1: icmp_seq=20 ttl=64 time=190.391 ms
64 bytes from 172.16.1.1: icmp_seq=21 ttl=64 time=2.732 ms
64 bytes from 172.16.1.1: icmp_seq=22 ttl=64 time=2.788 ms
64 bytes from 172.16.1.1: icmp_seq=23 ttl=64 time=1.962 ms
64 bytes from 172.16.1.1: icmp_seq=24 ttl=64 time=3.797 ms
64 bytes from 172.16.1.1: icmp_seq=25 ttl=64 time=4.714 ms
64 bytes from 172.16.1.1: icmp_seq=26 ttl=64 time=4.011 ms
64 bytes from 172.16.1.1: icmp_seq=27 ttl=64 time=3.789 ms
64 bytes from 172.16.1.1: icmp_seq=28 ttl=64 time=8.354 ms
64 bytes from 172.16.1.1: icmp_seq=29 ttl=64 time=257.786 ms
64 bytes from 172.16.1.1: icmp_seq=30 ttl=64 time=2.906 ms
64 bytes from 172.16.1.1: icmp_seq=31 ttl=64 time=2.210 ms
64 bytes from 172.16.1.1: icmp_seq=32 ttl=64 time=3.318 ms
64 bytes from 172.16.1.1: icmp_seq=33 ttl=64 time=53.918 ms
64 bytes from 172.16.1.1: icmp_seq=34 ttl=64 time=5.087 ms
64 bytes from 172.16.1.1: icmp_seq=35 ttl=64 time=8.635 ms
64 bytes from 172.16.1.1: icmp_seq=36 ttl=64 time=2.607 ms
64 bytes from 172.16.1.1: icmp_seq=37 ttl=64 time=4.313 ms
64 bytes from 172.16.1.1: icmp_seq=38 ttl=64 time=3.778 ms
64 bytes from 172.16.1.1: icmp_seq=39 ttl=64 time=9.654 ms
64 bytes from 172.16.1.1: icmp_seq=40 ttl=64 time=4.007 ms
64 bytes from 172.16.1.1: icmp_seq=41 ttl=64 time=12.065 ms
64 bytes from 172.16.1.1: icmp_seq=42 ttl=64 time=11.442 ms
64 bytes from 172.16.1.1: icmp_seq=43 ttl=64 time=4.169 ms
64 bytes from 172.16.1.1: icmp_seq=44 ttl=64 time=3.052 ms
64 bytes from 172.16.1.1: icmp_seq=45 ttl=64 time=1.969 ms
64 bytes from 172.16.1.1: icmp_seq=46 ttl=64 time=8.843 ms
64 bytes from 172.16.1.1: icmp_seq=47 ttl=64 time=9.007 ms
64 bytes from 172.16.1.1: icmp_seq=48 ttl=64 time=7.251 ms
64 bytes from 172.16.1.1: icmp_seq=49 ttl=64 time=4.591 ms
64 bytes from 172.16.1.1: icmp_seq=50 ttl=64 time=162.554 ms
64 bytes from 172.16.1.1: icmp_seq=51 ttl=64 time=34.826 ms
64 bytes from 172.16.1.1: icmp_seq=52 ttl=64 time=9.537 ms
64 bytes from 172.16.1.1: icmp_seq=53 ttl=64 time=3.984 ms
64 bytes from 172.16.1.1: icmp_seq=54 ttl=64 time=5.372 ms
64 bytes from 172.16.1.1: icmp_seq=55 ttl=64 time=11.460 ms
Request timeout for icmp_seq 57
64 bytes from 172.16.1.1: icmp_seq=58 ttl=64 time=932.542 ms
64 bytes from 172.16.1.1: icmp_seq=59 ttl=64 time=771.034 ms
64 bytes from 172.16.1.1: icmp_seq=60 ttl=64 time=3.333 ms

FURRYe38 · ‎2020-04-06

If your system is working, keep it on whats working. If you choose to update, manually download the FW files from NGs download support site first, then install the RBS first then RBR lastly. I recommend a factory reset and setup from scratch after updating.

@PCSP wrote:
Should I update firmware 2.5.1.8? Now I stay at 2.3.5.30 for a few months

GadgetVirtuoso2 · ‎2020-04-06

@FURRYe38 wrote:
What is the Mfr and model# of the ISP modem/ONT the NG router is connected too?

Don't know, had these units for nearly 2 years now but not having any trouble getting an IP from my ISP or any internet issues.

What is the size of your home? Sq Ft?

a bit over 1000sq ft.

What is the distance between the router and satellite(s)? 30 feet is recommended in between RBR and RBS to begin with depending upon building materials when wirelessly connected. https://kb.netgear.com/000036466/How-far-should-I-place-my-Orbi-satellite-from-my-Orbi-router
What channels are you using? Auto? Try setting manual channel 1, 6 or 11 on 2.4Ghz and any unused channel on 5Ghz.
I think I'm currently on 6, but like I said I'm not seeing much noise from neighbors and I've tried 1 and 11 which made not difference.
Think I'm on 44 for 5GHz right now/
Try enabling Beamforming and MIMO(MIMO may or maynot be needed) and WMM. Under Advanced Tab/Advanced Settings/Wireless Settings
Turning this on made connections unstable. Devices would frequently and randomly disconnect.
Try disabling the following and see:
Armor, Circle, Daisy Chain, Fast Roaming, IPv6 and Set 20/40Mhz Coexistence to 40Mhz only. Set Short preamble instead of Long preamble modes. Save settings and reboot the router and satellite(s).
Not using any of that crap, and not daisy chaining anything. IPv6 is disabled. Already disabled 20/40 Coexistence.I don't have any old devices that need the long preamble but I'd be surprised if that helped anyone except for the odd device having connectivity issues.
You can try Voxels FW for Orbi:
https://community.netgear.com/t5/Orbi/Voxels-FW-available-for-50-series-Orbi-only-available/m-p/1883...
You can revert back to stock FW if it doesn't work out for you.
Might give that a shot, couldn't be much worse than this nonsense.
Interestingly enough I left the ping running from my MBP and since then the single throughout the house seems to be more stable. We have seen when maintaining a ping when testing VPN connections or other network troubleshooting will sometimes keep a connection alive when it might otherwise die when it shouldn't. Still seeing the occasional lost packed but it does appear to be more stable.

FURRYe38 · ‎2020-04-06

"

What is the size of your home? Sq Ft?

a bit over 1000sq ft."

Might be that having too much wifi signal in such a small home foot print maybe also problmatic. Something that would not be recommended for a small home size. Thought it worked for a while, you may have cause some damage to the system having too much wifi singles over lapping between each of the RBS and the RBR. 1000sq ft would or should only need the 1 RBR and 1 RBS. Having two additonal RBS would be over loading on signals in the home and may cause some problems or degradation to the wifi radios on your units.

You might remove two RBS from operation and test just with the RBR and 1 RBS alone. Ensure 30 feet is the distance in between to start. Check operation with these two first.

GadgetVirtuoso2 · ‎2020-04-06

That's absurd that the radios would be damanged by being to close. The worst that would happen is there is would be too much overlap from the freqencies and cause too much noise, in which case you could simply turn down the power on the radios. These units can't put out enough signal to damage the other radios even if they were sitting side-by-side. The amount of RF that would be required to do actual damage would be enough to be hazardous to people and therefore would never pass FCC licensing as consumer grade equipment. Anything that powerful would require a license to operate.

But to you point I did turn down the radios, because I make use of the ethernet ports in both units to some devices around the house, without any change in performance. Based on the NetSpot analysis even with the radios at 100% there is not enough noise to be a problem. The units are at the further points of the house, maybe not 30 feet but close to it, with the RBR in the middle.

FURRYe38 · ‎2020-04-06

I would test with just the 1 RBR and RBS and see if you see any differences in behavior.

Then add 1 RBS and check. Yes I would reduce the power output on the RBR as well. Again, you home size seem small for having the RBR and 3 RBS all going at the same time. I have to 5000sq ft home and use just 1 RBR and 1 RBS, coverage is great and works well.

GadgetVirtuoso2 · ‎2020-04-08

I loaded the Voxel FW and everything was good for about 36 hours, then everything went to hell.

Today is turned off both satellites and tried running on just the router. Connection constantly drops. 5Ghz devices can't connect to 5Ghz. Devices can't get IPs and are disconnected. I've turned off nearly every feature possible. This hardware is complete crap. There's no reason that the hardware should perform so poorly after 18 months give or take.

Retired_Member · ‎2020-04-09

@GadgetVirtuoso2 wrote:
I loaded the Voxel FW and everything was good for about 36 hours, then everything went to hell.
Today is turned off both satellites and tried running on just the router. Connection constantly drops. 5Ghz devices can't connect to 5Ghz. Devices can't get IPs and are disconnected. I've turned off nearly every feature possible. This hardware is complete crap. There's no reason that the hardware should perform so poorly after 18 months give or take.

Sounds like you need to dump 2.5.1.8

amd stop performing manual firmware updates

FURRYe38 · ‎2020-04-09

Go back to v30 and see if this corrects the problem. If it still happens, then your RBR needs to be replaced. Ya, HW should not be failing that early. My friends RBK50 is still working 3 years and counting and I haven't touched it since installing it for him.

@GadgetVirtuoso2 wrote:
I loaded the Voxel FW and everything was good for about 36 hours, then everything went to hell.
Today is turned off both satellites and tried running on just the router. Connection constantly drops. 5Ghz devices can't connect to 5Ghz. Devices can't get IPs and are disconnected. I've turned off nearly every feature possible. This hardware is complete crap. There's no reason that the hardware should perform so poorly after 18 months give or take.

GadgetVirtuoso2 · ‎2020-04-09

ITs now dead. Tried to flash and now its stuck on flashing white. Tried reseting it several times but it is dead. Its not broadcasting or giving out IPs.

Retired_Member · ‎2020-04-10

@GadgetVirtuoso2 wrote:
ITs now dead. Tried to flash and now its stuck on flashing white. Tried reseting it several times but it is dead. Its not broadcasting or giving out IPs.

Wow ......all this firm/software bricked your Orbi? Way to go to those that advocate fw updates and resets