Orbi losing packets

[Escondido]

Hello,

I'm seeing packet losses with my Orbi.

I have the RBK53 (RBK50, boxed with two remote Orbi devices).

The Orbi is hardwired to my firewall.  Also hardwired to my firewall is a Linux computer.

Using the Linux computer, overnight I ran a ping test to 8.8.8.8.  In the morning, I had no packet loss.

At the same time I also ran the same ping test from two computers connected via WiFi to the Orbi:

1) Desktop with fast USB WiFi adapter (Connected to Orbi with 5 bars and 500+ mbps),

2) Older laptop with internal WiFi adapter (Connected to Orbi with 5 bars and 80+mbps).

In the morning, the ping test from the Linux computer had zero packet loss.  The desktop and laptop each had 1% packet loss.

Any ideas why this would be?  The 1% loss is fairly high.

[DarrenM]

You may want to try the latest firmware for orbi.

https://community.netgear.com/t5/Orbi/Announcing-availability-of-OrbiOS-2-1/m-p/1448548#M16957

DarrenM

[Escondido]

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.

[Escondido]

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.

[webminster]

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.

[webminster]

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.

[st_shaw]

---

@webminster wrote:

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.

[webminster]

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.

[st_shaw]

---

@webminster wrote:

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.

[Escondido]

A little bit more information on my post - I am running my tests while connected via WiFi to the router, not a satellite.

At Webminster's suggestion, I am going to ping test different devices connected to router/satellites to see what happens.

[Escondido]

So far I'm not losing packets.  I'm not sure if it was due to the firmware update or the rebooting of the devices.

I ran a ping test to 8.8.8.8 for 1.5 days.  On average, I am losing about 8 ms in latency using WiFi vs. hardwired, but I can live with that.

I'll continue to monitor to see if I get any packet losses, but so far things are looking good.

[webminster]

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.

[jmschnur923]

Using ping to my fios gateway I am getting no packet loss with about 5ms latency.

thr route is far sat to  sat one to Orbi router to fios gateway.

daisy chain. 2.1.2

I did get losses and much more latency in precious firmware version.

[jmschnur923]

I tried several devices. About 1000 pings. One was lost. Late Cy varied from 2-11 ms.

[jmschnur923]

Test was done with iPad Pro.

[webminster]

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.

[webminster]

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.

[tagteam]

Check out the link below.

https://kb.netgear.com/000051205/What-is-Ethernet-backhaul-and-how-do-I-set-it-up-on-my-Orbi-WiFi-Sy...

[PyroDog]

Sounds like the same issue I was having. I managed to fix it on my setup:

https://community.netgear.com/t5/Orbi/Packet-loss-pattern/m-p/1479220/thread-id/20248#M20332

[webminster]

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...

[Phatman113]

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.

[webminster]

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.

[Escondido]

It appears Netgear has been listening.

If you try to download the latest firmware, they give you v2.0.1.4, a version released last year - four firmware releases ago.

The "latest" firmware "prior" to this was v2.1.2.18, a newer release from January 2018.

So they're acknowledging there's a problem with their firmware and are downgrading everyone to a version 4 releases ago.

The firmware's zip files are interesting, take a look at the dates below:

"Latest" Version 2.0.1.4

Release notes date: 2/14/2018

Img file date: 11/10/2017

"Prior" Version 2.1.2.18

Release notes date: 1/17/2018

Img file date: 1/5/2018

The Orbi firmware product manager needs to make sure their resume is up-to-date.