Thanks DarrenM, I appreciate the info on the update firmware.
I did see that others were still seeing packet drops with certain devices. I'm seeing packets dropped with a desktop using a Belkin USB Wifi and a laptop using a built-in Wifi.
But the new firmware is definitely worth a try - I am currently on V2.0.0.74. If it works I'll report back.
After a bit of struggle, I was able to update my RBR50 and two RBS50 units to the latest firmware V2.1.1.16.
(Serious Netgear, if my RBR50/RBS50 units appears to be working well, why do I need to reboot the RBR50 in order for the updates to work properly? And why do I need to manually update all the units? This isn't junior league.)
Anyway, the packet drops are still happening with the latest firmware V2.1.1.16. Things look OK, then packet time will increase, then there is a loss of packets. And as before, when I run the test at the same time from a hardwired system, I am not losing packets.
The below ping tests were run at the same time:
Test from Orbi system
Reply from 8.8.8.8: bytes=32 time=34ms TTL=252
Reply from 8.8.8.8: bytes=32 time=31ms TTL=252
Reply from 8.8.8.8: bytes=32 time=31ms TTL=252
Reply from 8.8.8.8: bytes=32 time=160ms TTL=252
Reply from 8.8.8.8: bytes=32 time=36ms TTL=252
Request timed out.
Request timed out.
Reply from 8.8.8.8: bytes=32 time=30ms TTL=252
Reply from 8.8.8.8: bytes=32 time=31ms TTL=252
Reply from 8.8.8.8: bytes=32 time=31ms TTL=252
Reply from 8.8.8.8: bytes=32 time=32ms TTL=252
Test from hardwired system
64 bytes from 8.8.8.8: icmp_seq=23 ttl=253 time=28.9 ms
64 bytes from 8.8.8.8: icmp_seq=24 ttl=253 time=28.8 ms
64 bytes from 8.8.8.8: icmp_seq=25 ttl=253 time=29.3 ms
64 bytes from 8.8.8.8: icmp_seq=26 ttl=253 time=30.2 ms
64 bytes from 8.8.8.8: icmp_seq=27 ttl=253 time=30.3 ms
64 bytes from 8.8.8.8: icmp_seq=28 ttl=253 time=28.7 ms
64 bytes from 8.8.8.8: icmp_seq=29 ttl=253 time=29.6 ms
64 bytes from 8.8.8.8: icmp_seq=30 ttl=253 time=33.6 ms
64 bytes from 8.8.8.8: icmp_seq=31 ttl=253 time=30.7 ms
64 bytes from 8.8.8.8: icmp_seq=32 ttl=253 time=28.7 ms
64 bytes from 8.8.8.8: icmp_seq=33 ttl=253 time=29.3 ms
So something is definitely wrong with the Orbi system where it is losing packets.
Does anyone have any thoughts on how to fix this? Thanks in advance.
Not much help, but I see similar issues on my RBK50, running 2.1.1.16, pinging hosts from my laptops to my wired network. Packet latencies and some drops. Orbi as an AP plugged into a switch. Hosts on the switch pinging other hosts on switch are fast and no loss. No idea yet why.
Model: RBK50| Orbi AC3000 High-Performance Tri-Band WiFi System
But, for me, the most curious thing? My gateway device for my network is at 192.168.1.1. That's where my worst loss is - pinging that address through the wireless laptop through the Orbi. Pinging other devices (different addresses), not too bad. And pinging 192.168.1.1 from other machines on the wired network is zero loss / sub-ms RTT.
Not sure why the Orbi in AP mode on its own DHCP-assigned address should have such a packet loss to the gateway. There's no duplicate addresses, no static routes, whatever.
EDIT: A little more experimentation seems to be implicating the satellite as adding latency (at least) to the issue. Getting the laptop to connect to the router seems to decrease the latency variance and decreasing the lost packets.
EDIT: A little more experimentation seems to be implicating the satellite as adding latency (at least) to the issue. Getting the laptop to connect to the router seems to decrease the latency variance and decreasing the lost packets.
Wireless add latency compared to wired. Pinging through the satellite uses two wireless hops, thus more latency than devices connected to the Orbi router. Packet loss over the WiFi would indicate RF interference and/or a marginal WiFi connection, either between your device and your AP or between the Orbi router and satellite, or both.
Aware that there'd be some extra (millisec or so) addition latency from the satellite to router. But it's not clear if interference is to blame for the packet loss or variance in RTTs. Maybe so, all I have is the "good" status on the 5G backhaul. I don't believe you have control of any backhaul parameters like channel, to test that out... wired backhaul isn't an option here.
Aware that there'd be some extra (millisec or so) addition latency from the satellite to router. But it's not clear if interference is to blame for the packet loss or variance in RTTs. Maybe so, all I have is the "good" status on the 5G backhaul. I don't believe you have control of any backhaul parameters like channel, to test that out... wired backhaul isn't an option here.
I believe RF interference can lead both to packet loss and to variable RTTs. This is because the WiFi radio will defer transmission when it senses a channel is busy.
You are right that you do not have control over backhaul parameters. The one parameter you do have control over is the physical position of the router and satellites. You can also potentially control the source of interference, if it's from a device you own.
You could move the router and satellite closer together temporarily and see if that impacts the loss and variability. Whatever issues you are experiencing might be on both the backhaul and the client channels, however.
If you haven't already, you should run a WiFi scanner to see what else is on the air.
Just installed the 2.1.2.10 beta this morning, been running a couple of casual tests. Hasn't helped my latency variations though the satellite to some hardwired addresses on my local network. Variations on a local Linux box from 2ms to 300ms, sometimes no packet loss, sometimes between 1% and 20+%. The loss and variances are cyclic. Tried looking at Wifi Analyzer for any obvious conflicts on the 5G band, don't see any.
I've tested with a laptop, and an Android tablet. When connected to the satellite at least, they both behave the same. Will probably put my previous router (ASUS 88U) back in this weekend for comparative test, and to make a final decision on this thing.
So am tempted to test using the wired backhaul just to see what difference that makes. Am running in AP mode, router WAN port connected to wired net switch, the satellite currently using no LAN ports.
To try the Ethernet backhaul, would I be able to just connect a LAN port on the satellite to a nearby switch on same wired network? Since the router is already connected to the Ethernet, I don't have to add additional cabling there, correct?
Just wanting to isolate that the problem is related to the wireless backhaul.
So tried a few other things just to eliminate them - swap cables, change switch ports, etc. to no good. I noticed I was getting losses on connections to the router as well - so decided it wasn't just the satellite, and testing the ethernet backhaul was probably useless.
I downgraded shortly ago to 2.0.0.76 again. I do still get some wobbles in ping time up to 300ms occasionally, but as of yet haven't dropped a ping. So that does seem to make a difference.
I figure I'll swap back to the ASUS 88U after a while for comparison, see how that does. If I have to try to lock this at old firmware just to avoid losing packets, I'll just return it. I'm too old to keep treating this as some science experiment. Besides, I noticed this morning after the 2.1.2.10 update, my LG TV started failing to connect on power on. Just too many little things...
Anyone have an update for this? I just got my Orbi, one satellite failed during firmware upgrade and i'm waiting on the RMA now, but with just my router and wall satellite I'm seeing dropped packets all over the place. Not constant, but not limited to wifi either. Running firmware v. 2.1.2.18. From a wired device to another wired device in the house (goes through the Orbi Router, no backhaul involved on either side) and it just drops 1-2% of the packets over a long period of time. sampled at the right time, for a short interval (<1min) it'll drop 90% of the pings. At the same time, pings to 8.8.8.8 drop as well, so it's like the main router can't keep up with something... I've got a fairly large scale network for a single house, but still shouldn't be seeing this kind of drop, ESPECIALLY for wired systems. Previous router was a Turris Omnia, I just moved to the Orbi for the mesh, since the Omnia coudln't quite reach all the spaces I needed it to.
I moved back to my ASUS 88U for a brief period. Reinstated my coverage issues, but certain things did stabilize (packet loss, odd disconnects on my work Skype calls).
I'm back on the Orbi again, with good coverage, but having the packet loss and Skype disconnections again. Ran a quick test where I jacked into my powerline Ethernet during a long series of calls, and didn't get a disconnect.
So, not the most controlled testing, but the Orbi is definitely causing some issues, and configuration changes (channel assignment, beamforming, whatever) isn't resolving it.
