NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
New V4.6.3.16
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
34 Replies
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.
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...
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.
- 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.
Thats exactly the situation. Devices connected directly also stall. This is a routing related issue.
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.
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
The fact the stability issues remain in v4.6.3.16 and yet Netgear remain silent on it, is terrible. I have never experienced customer service like it and Netgear should be ashamed.
Surely someone in Netgear care that one of their most expensive products is totally ruined by a firmware update? A firmware update FORCED on users with no way to turn back? No? Oh yes, i forgot, revenue from parental controls.
guys... I followed your suggestion. I returned my ORBI and bought an ASUS ZenWifi AX6600.
Now everything works.
Thanks... it was a pleasure to spend some time in this forum.
