Re: New V4.6.3.16

EdFerreira · ‎2021-09-14

Hi all,

Installed yesterday the new beta firmware V4.6.3.16. Got some improvements in the wireless connections but totally broke my lan wired stability. I have been quiet and reading the feedback but this update process is totally unbelievable. My 90 days are out so please don't tell me to open a support ticket. I'm an IT professional and i've never seen anything like this in all my years working. This router is totally unusable. And for a router in this price range it's totally unacceptable. I know some of you work for NG (or don't have anything better to do in your lifes). So tell them to get their act together, more than 2 months is not acceptable. I know i can hack HTML in order to install an older firmware but the older firmware is also very flawed. So i'm back to my old, reliable router. This is ROUTING, not rocket science. At least the core funcionality needs to work. Just remove all the nice-to-have funcionalitites. I'm sure it will work correctly then. FIX THIS DAMN THING ALREADY.

RBK752

FURRYe38 · ‎2021-09-14

What do you mean it "totally broke my lan wired stability"?

What is actually happening?

Is the RBS directly connected to the RBR or is there a LAN switch in between? If so, brand and model please.

It's recommended to factory reset the RBR and RBS and setup from scratch. I would also include a pull power OFF for 2 minutes then back ON as well including the modem.

EdFerreira · ‎2021-09-14

SBS is linked wired. It freezes constantly (if i disconnect the cable, it will link via wifi and works correctly). Was not doing that before. Yes, connected directly. I would wireshark it normally but in this case i'll not even bother with that. So they fixed wifi and broke routing. Good job. This is in a controlled lab environment, no external devices causing issues. Believe me, i know firmware development. Never seen anything like this...

FURRYe38 · ‎2021-09-14

SBS or RBS?

What on the RBS is freezing? The web page? or connections thru the RBS?

It's recommended to factory reset the RBR and RBS and setup from scratch. I would also include a pull power OFF for 2 minutes then back ON as well including the modem. Then walk thru the set wizard. Either add the RBS wirelessly during the setup wizard or afterwards. After the RBS is wirelessly connected, ethernet connect the RBS to the RBR. Be sure to use a good quality LAN cable, CAT6 is recommended. Try a different LAN cable as well. Also try a different port on the RBS. I thought I saw someone post about using different ports to connect on the RBS for ethernet connections, though LAN ports should not matter, just try.

EdFerreira · ‎2021-09-14

I know perfectly well what is recommended. Thanks for the info. Not sure if its the SBS or routing in the SBR. This firmware is broken in different places... But broken. Happens to devices connected wired in the SBS (didn't test with a switch connected to it but it will have the same result)

FURRYe38 · ‎2021-09-14

So for Orbi Home models, RBR and RBS are designated nonmenclature.

For Orbi Pro Business models, SRR and SRS or SXR or SXS are designated nonmenclature for those models.

Please try a full factory reset on the router and satellite and setup from scratch as suggested to see if problem still happens. If so, then you'll need to open a support ticket with NG and let them know what your seeing.

EdFerreira · ‎2021-09-14

My mistake. Its RBR and RBS. I did the factory reset when i installed the firmware.

FURRYe38 · ‎2021-09-14

If you can, can you connect up a LAN switch in between the RBR and RBS. When the RBS is wirelessly connected and working right, connect the RBS to this switch. Please look at the LED activity behavior on the switch, if it gives this inidication. Most switches give random LED activity for normal operation. After you connect the RBS to the switch, please look for "constant" or always ON LED activity on the switch and give it about 5 minutes before disconnecting the RBS from the switch.

Reason for asking is that I've seen an ARP storm happen when RBS are ethernet connected, usually happens for about 1-2 minutes then stops. I'm wondering if this is happening on this version of FW and maybe it's NOT stopping.

FURRYe38 · ‎2021-09-14

Wanted to check mine with RBS ethernet connected with v16.

Since mine was in AP mode already, I connected the RBS wirelessly first.

Once they were connected wireless, I connected them one at a time via ethernet, directly connected to the back of the RBR:

After the RBS was ethernet connected and up and running, I configured the RBR for router mode and let the system reboot while the RBS were ethernet connected. The system rebooted fine.

Checking one of the RBS, the web page is accessbile and I connected a iphone and a pad to the one RBS and ran a successful speed test on both.

I did not see any ARP storms or problems after the RBS connected via ethernet.

I didn't try adding a switch in to the mix.

AggedwNG · ‎2021-09-15

Lot of people having this same issue or similar.. Just curious, is LAN connectivity hosed in general for you? Are you able to wire an ethernet connection from the router into any other device other than Sattelite and maintain connectivity? I have a similar issue but happens only when connecting a device to any of the Lan ports on the router and trying to download (a file for instance).. Brings the entire network down and locks the router up.. They've been maintaining silence on this specific issue, which leads me to believe routing is hosed completely.

EdFerreira · ‎2021-09-15

Thats exactly the situation. Devices connected directly also stall. This is a routing related issue.

EdFerreira · ‎2021-09-15

wirelessly connected devices don't seem to be affected.

AggedwNG · ‎2021-09-15

Great.. That confirms it for me. They didn't even bother addressing this issue in the new fw and my 90 day warranty just lapsed.. This is humorous at best, since this product cannot even provide it's most core function.. routing. So, what this boils down to, is they were more concerned with increasing their portfolio of "feature enhancements" over functionality. Proven by the fact they did not suspend rollout of 4.6.3.7 after complaints and intentionally disabled downgrading, knowing full well this was going to be an issue.. Us in the IT domain, know exactly what this is.. This is what happens when Marketing decisions trump development.. Netgear, your Product Management team needs to be shown the door.

EdFerreira · ‎2021-09-15

Totally agree. This is a total train wreck. I'm a bit curious to know how many members has this development team. Messing up one of the most expensive products they have is laughable at least. Do they have management? No one is seeing this? And then there are a few guys here "trying" to help and wasting people's time doing so, doing trial and error testing when they know what they have done with this update. Where is the support? Problems created by their incompetence should labeled in a support contract? 2 months ago, the solution was flawed. They made it unusable with a firmware update. Who is going to give us back 2 months of not being able to use the devices? Total train wreck. Who is going to pick up the pieces? Not even a simple roll back solution...

FURRYe38 · ‎2021-09-15

You'll need to contact NG support and open up a support ticket as the forums can't seem to help you out.

https://www.netgear.com/support/#

Good Luck.

tak1313 · ‎2021-09-15

Haven't poked in here in awhile, since I put my AX in AP mode because my Asus is better at routing (also blocked updates some time ago because of this type of debacle after it was forced to update to a version I didn't want).

Just curious if they re-enabled the ability to downgrade with the beta, or if they're holding fast to their "we know what's good for you" mentality.

AggedwNG · ‎2021-09-15

I concur as well. Ridiculous is an understatement with how this is being handled..

For those of you shopping or considering this product, reading these forums, do your research first. Plenty of reasons to steer clear unless you like doing QA on a product that is being steered from a functional software development life cycle. Hard to believe this company is ISO certified..

AggedwNG · ‎2021-09-15

They're holding fast.. Its likely apart of the model they've decided to take with this product. Which is why it was likely disabled in the first place.

vmiele · ‎2021-09-16

Similar issue on my RBR750 after the firmware upgrade to 4.6.3.16.
I can not make a comparison with previous firmwares, because I have this device for a very short time.
But I use the same configuration that I've been using for 2 years with an RBK20 without any problem.
Satellite connected by cable to the router.
the problem is that the devices connected via wireless to the satellite, lose connectivity for a few moments.
Does not happen to devices connected to the router, but only to those connected to the satellite.
I have obviously tried all the suggestions read in the community, such as turn off the modem, do the factory reset, reconfigure the system by connecting the satellites via wifi and only then connect them with the cable .... tried everything. the problem persists.
The router is in "Router Mode" (as I always had my old RBK20).
As I said before... I don't know if this problem appeared with the last firmware... but surely now the system is unusable.

64 bytes from 142.250.184.100: icmp_seq=452 ttl=114 time=19.749 ms
64 bytes from 142.250.184.100: icmp_seq=453 ttl=114 time=17.717 ms
64 bytes from 142.250.184.100: icmp_seq=454 ttl=114 time=20.004 ms
64 bytes from 142.250.184.100: icmp_seq=455 ttl=114 time=13.123 ms
64 bytes from 142.250.184.100: icmp_seq=456 ttl=114 time=19.693 ms
64 bytes from 142.250.184.100: icmp_seq=457 ttl=114 time=20.294 ms
64 bytes from 142.250.184.100: icmp_seq=458 ttl=114 time=17.920 ms
64 bytes from 142.250.184.100: icmp_seq=459 ttl=114 time=13.614 ms
Request timeout for icmp_seq 460
ping: sendto: No route to host
Request timeout for icmp_seq 461
ping: sendto: No route to host
Request timeout for icmp_seq 462
ping: sendto: No route to host
Request timeout for icmp_seq 463
ping: sendto: No route to host
Request timeout for icmp_seq 464
ping: sendto: No route to host
Request timeout for icmp_seq 465
Request timeout for icmp_seq 466
64 bytes from 142.250.184.100: icmp_seq=467 ttl=114 time=199.435 ms
64 bytes from 142.250.184.100: icmp_seq=468 ttl=114 time=125.238 ms
64 bytes from 142.250.184.100: icmp_seq=469 ttl=114 time=12.153 ms
64 bytes from 142.250.184.100: icmp_seq=470 ttl=114 time=45.545 ms
64 bytes from 142.250.184.100: icmp_seq=471 ttl=114 time=11.689 ms
64 bytes from 142.250.184.100: icmp_seq=472 ttl=114 time=144.667 ms
64 bytes from 142.250.184.100: icmp_seq=473 ttl=114 time=116.345 ms
64 bytes from 142.250.184.100: icmp_seq=474 ttl=114 time=153.378 ms
64 bytes from 142.250.184.100: icmp_seq=475 ttl=114 time=73.604 ms
64 bytes from 142.250.184.100: icmp_seq=476 ttl=114 time=19.745 ms
64 bytes from 142.250.184.100: icmp_seq=477 ttl=114 time=14.055 ms
64 bytes from 142.250.184.100: icmp_seq=478 ttl=114 time=11.431 ms
64 bytes from 142.250.184.100: icmp_seq=479 ttl=114 time=11.672 ms
64 bytes from 142.250.184.100: icmp_seq=480 ttl=114 time=30.086 ms

this is what happens during a ping to google.com.

vmiele · ‎2021-09-16

Same if i ping the router directly

64 bytes from 192.168.1.1: icmp_seq=71 ttl=64 time=3.872 ms
64 bytes from 192.168.1.1: icmp_seq=72 ttl=64 time=3.673 ms
64 bytes from 192.168.1.1: icmp_seq=73 ttl=64 time=8.920 ms
64 bytes from 192.168.1.1: icmp_seq=74 ttl=64 time=11.616 ms
ping: sendto: No route to host
Request timeout for icmp_seq 75
ping: sendto: No route to host
Request timeout for icmp_seq 76
ping: sendto: No route to host
Request timeout for icmp_seq 77
ping: sendto: No route to host
Request timeout for icmp_seq 78
ping: sendto: No route to host
Request timeout for icmp_seq 79
ping: sendto: No route to host
Request timeout for icmp_seq 80
Request timeout for icmp_seq 81
Request timeout for icmp_seq 82
64 bytes from 192.168.1.1: icmp_seq=83 ttl=64 time=39.530 ms
64 bytes from 192.168.1.1: icmp_seq=84 ttl=64 time=134.120 ms
64 bytes from 192.168.1.1: icmp_seq=85 ttl=64 time=92.442 ms
64 bytes from 192.168.1.1: icmp_seq=86 ttl=64 time=91.720 ms

tak1313 · ‎2021-09-16

@AggedwNG wrote:
They're holding fast.. Its likely apart of the model they've decided to take with this product. Which is why it was likely disabled in the first place.

So another curiosity. Since the cat is out of the bag, and they know that some have figured out the F12 key method of enabling the "YES" button in the update page (if someone REALLY wanted to downgrade to stable), did the dark forces bork that ability in the 16 update, or did they leave it be?

vmiele · ‎2021-09-17

At the moment I have downgraded to V3.2.18.1_1.4.14.I have blocked the urls for the update, (the only drawback is that in the Orbi app it shows me the device OFFLINE even though it is not). Now everything works without any instability.
I still have some time to decide whether to return RBK753, I'll wait if there are updates about working firmware, otherwise... bye bye Netgear. I can't risk keeping a device that can't be updated.

AggedwNG · ‎2021-09-17

"Dark forces"... lol. More like shady business practices.. It's likely still hidden in the html. As the previous poster confirmed, he was able to downgrade. I personally tossed mine in the closet and have been running on an old router with stable firmware. Seeing as they felt the need to hide it in the first place, shows their intentions of where they plan on going with this.. I might pull mine out and do some testing this weekend but I wouldn't hedge any bets on them reversing course on that.

vmiele · ‎2021-09-17

Well, probably, if they had released a working and well tested firmware, we wouldn't be here arguing about whether or not it is correct to hide a button.

tak1313 · ‎2021-09-17

@vmiele wrote:
Well, probably, if they had released a working and well tested firmware, we wouldn't be here arguing about whether or not it is correct to hide a button.

That's why I decdided to move on awhile ago. After mine was updated without permission, I decided to put it behind my Asus router in AP for multiple reasons.

1. Asus gives FAR more control in routing

2. Asus does things for FREE that Netgear charges for.

3. To fully block updates

At this point, I am especially glad I did #3 when I did as it apparently saved a lot of grief.

Netgear just doesn't seem to have the most capable coders and they apparently don't sufficiently understand their own products. ALL tech products have issues, but the lack of proficiency, capability, and most importantly, customer support response is undeniably lacking. It's ridiculous that they maintain a pay wall and/or make it difficult for users to get support for a problem THEY created.

I got the Orbi because I needed a good mesh. I was going to stick with Asus, but decided to try Orbi since I had great experiences with Netgear stuff in the past. The Orbi is great at wifi, but nothing else (hence running it in AP mode).

Netgear - never again. When it's time to upgrade, it'll be anything but.