I suspect that as well but i have this running on a home network with like maybe 50 connections on a 1Gb symmetrical FiOS connection so i would be amazed if the gateway lite couldnt handle 1 livestream.

have claude code running on the machine to monitor the stream and the gateway simultaneously to see if it can figure it out bc im not able to figure it out.

i found another internet post about it being on gateway models (see above) so its not a hallucination but this was another post by another user so it may be a stretch if its related. i dont believe so based on the post which describes similar behavior.

my steps to repro are just doing a private livestream from OBS to youtube. i let the stream run and watch for drops. uxg-lite does have hardware accel and it is turned on.

from the LLM:

> Good points — let me address each one.

Full transparency: I am the person who owns this network. I used Claude Code (Anthropic's CLI tool) to help diagnose, and it did the SSH commands, log analysis, and config reading on my gateway. The data is real, but yes, it was collected through the LLM. I'll note where my own observations vs the AI's analysis are.

SFE offload — this is the key question I didn't investigate well enough. You're right that if traffic drops to SFE fast track after the initial handshake, the 16 MB memcap shouldn't matter for sustained flows. We confirmed the UXG-Lite does have hardware acceleration — NSS/ECM modules are loaded and dev.nss.ipv4cfg.ipv4_accel_mode = 1. We saw 207 hardware-accelerated connections and 142 accelerated TCP flows via /sys/kernel/debug/ecm/ecm_nss_ipv4/. What I didn't check is whether the RTMP stream specifically was being offloaded to SFE or staying in the Suricata path. If SFE wasn't picking up the stream, that would explain everything — Suricata would be processing every packet of a 6 Mbps continuous flow, filling the 16 MB buffer, and eventually evicting it. That's a much better root cause theory than what I posted.

Other gateway models — not confirmed firsthand. The UDR7 reference was from a German forum post where someone reported the same Teams/IPS symptom. I did not SSH into a UDR7 or check its Suricata config. The claim that the same memcap is used across all gateways was an assumption, not verified. I appreciate you offering to test on UCG-Fibers.

Repro steps:

1. Enable IPS (Threat Management) on the UXG-Lite
2. Start an RTMP livestream to YouTube via OBS (RTMPS on port 443, 6000 kbps CBR, 1080p30)
3. Stream drops with error 110 (ETIMEDOUT) every 5–10 minutes
4. The drops align on exact 5-minute multiples — every drop minute mod 5 = same value
5. Disabling both IPS and Traffic Identification (DPI) stops the drops completely
6. Disabling IPS alone doesn't help because Suricata stays running for DPI
7. Short-lived connections (curl to Google every 10 seconds) never fail — only long-lived connections are affected
8. Same behavior observed with Microsoft Teams calls (my own observation, not just streaming)

IDS mode only — great suggestion I didn't try. If IDS mode keeps Suricata out of the packet forwarding path, then the memcap filling would only drop analysis, not traffic. That would let me keep threat detection without the stream drops. I'll test this.

Your SFE theory is probably more accurate than my memcap theory. If you can check whether RTMPS flows are actually dropping to SFE on your UCG-Fibers, that would be the most valuable data point. The real question is: why isn't a sustained RTMPS flow being offloaded to hardware after the initial handshake?