Orbi 771 lags every 60 minutes exactly

The previous discussion was reply locked, but I have some more information on the issue that I've been dealing with for the past year and a half.

Previous discussion: Orbi RBE771 Latency issues every 60 minutes

Every 60 minutes on the dot, my Orbi lags for about 30 seconds. Games become choppy, video calls become choppy, streaming video can also be interrupted. After ~30 seconds, everything returns to normal and my high speeds and low ping resumes.

Summarizing my system:

Orbi 771 RBR directly connected to NETGEAR CM3000, which is directly connected to COAX into the wall (No Splitter). Xfinity is the internet provider. Orbi 771 RBS is ~30 feet away from the RBR and is one floor above. My computer is connected via Ethernet to the RBR. My work laptop is connected to the RBR. Both my computer, laptop, and phone all experience the issue.

Summarizing some of the things tried in the past:
- Tried various channels. I'm currently using channel 11 for 2.5 ghz channel and channel 48 for my 5 ghz channel, but I have tried them all
- Xfinity tech has come to the house twice in the past year and a half and has seen no issues.
- Disabled Guest Network
- Disabled 20/40MHz Coexistence
- Disabled Armor
- Disabled Traffic Meter
- Verified and tried different cables and brands.
- Factory reset Orbi and Netgear CM3000.
- The issue has been present for every single firmware version since October 2024. I have upgraded to each version as they have become available in hopes of it fixing the issue

----

Now getting to the new data.

I installed Wireshark and successfully ran a couple captures during the choppiness event and eventual recovery. I then ran the captures through Claude Sonnet 4.6 (Extended) to analyze and graph the issues.  Here's what it had to say (with sensitive information redacted with "x" and addresses masked):

"""

The satellite is the trigger. The LLDP packet at t=28s contains a self-identification that cracks the whole case open. The device at 192.xxx.x.11 (MAC xx:xx:xx:xx:xx:aa) broadcasts its own name and firmware:

System name: RBE770

System description: OpenWrt 19.07-SNAPSHOT @ RBE770

That's your Orbi satellite. And it's sending EAPoL (802.1X port authentication) frames to the IEEE multicast address at t=1s, t=9-10s, and t=16s — exactly during the choppy window.

These EAPoL frames mean the satellite is re-authenticating its backhaul connection with the main Orbi router. When this happens, the router's DPI engine has to re-examine and re-classify all traffic flowing through the satellite link. That re-classification is what causes the 300-370 ms buffering cycles you see for the entire first 19 seconds. At t=19s, re-authentication finishes, the DPI engine settles, and packets start flowing smoothly.

This also explains the DHCP failure: a device (MAC xx:xx:xx:xx:xx:bb) sent two DHCP Discovers at t=9.8s and t=12.8s asking for 192.xxx.x.22, and the router never replied. The satellite's backhaul disruption was breaking DHCP forwarding too — it wasn't just gaming that was affected.

Diagnosis: the 60-minute timer is the satellite backhaul lease

The Orbi satellite's wireless backhaul uses a timed connection interval. Every ~60 minutes it re-syncs with the main router, which triggers EAPoL re-authentication. That re-authentication is what kicks the DPI engine into the buffering state. It's not a QoS database refresh from the internet — the trigger lives entirely inside your own home network.
"""


I have lots of data and charts I am trying to attach here as well, but it's unfortunately not letting me attach an image to this post.

Unfortunately, I'm not sure what I can do to resolve the issue, but it's had a large impact on my work and recreation over the past year and a half so I am hoping this increased data helps lead to a resolution.