U7 Pro high latency issues opgelost na reboot

[Sa1]

Loop al een behoorlijke poos tegen een probleem aan. Na vrij veel troubleshooting en inzet van Claude om dingen te proberen moet ik zeggen dat ik tegen de beperkingen van mijzelf aanloop, en vooral tegen de beperkingen van mijn creativiteit om verder te denken.

Kort door de bocht zie ik op mijn U7 Pro (~1jr oud) hoge latency naar de gateway (maar ook naar alle andere pingbare hosts). Op dat moment gaan de pings naar 100+ ms, met uitschieters naar 1000+. Het effect is dat alle Wireless clients op dit AP traag voelen. Wat natuurlijk de pret wel drukt. Een reboot doet tijdelijk de latency weer terug gaan naar 0ms (0,4-0,7ms). De ervaring is dan ook goed.

De overige APs vertonen deze gekkigheid niet. Deze zijn dan ook niet aangesloten op de switches in onze woonkamer, maar óf direct op de US-24, of via een US-8 op een andere plek. Heb 3x AC Pro, 1x U6 Pro en dan de problematische U7 Pro.

Mijn internet verbinding wordt geleverd door Odido, is een 1/1gbit via hun eigen netwerk. Dit is aangesloten op een Unifi USG Ultra. Op alle acces points en bedraadde clients haal ik de verwachtte snelheden, en als de U7 pro goed werkt ook.

Globale config:

• 2.4 GHz radio disabled on all SSIDs, behalve IoT
• 5 GHz: 80MHz channel width, channel 48 (non-DFS) op U7.
• 6 GHz: 160MHz channel width, channel 5
• Automatic Channel Optimization (ACS): disabled
• MLO (Multi-Link Operation): disabled
• Fast Roaming: Enabled (ook disabled geprobeerd)
• BSS Transition: Enabled

Overige:

Connectiviteit loopt als volgt:

Unifi USG Ultra -> US-24 -> US-8 -> USW Ultra -> U7 Pro

De fysieke route van US Ultra en US-8 heb ik al meerdere malen omgedraaid, maakt niet uit. Als ik de U7 hang aan de USW8 krijg ik een melding dat PoE onvoldoende is, daarom hem ik hem aan de Ultra hangen, die heeft namelijk PoE+.

De Ultra wordt gevoed door een poweradapter (60watt), omdat ook de US-24 alleen gewone PoE heeft.

Zaken die ik al uitgezocht heb:

• Confirmed wired uplink healthy: 1000Mbps full duplex, zero TX/RX errors, zero dropped packets (via SSH: ip -s link show eth0)
• PoE power delivery confirmed sufficient: USW Ultra on dedicated 60W adapter
• Issue occurs independently of client count (reproduced with 0 to 40 connected clients)
• Issue reproduced across multiple firmware versions, both stable and experimental
• Kabels vervangen van alle devices.
• SONOS apparaten gebundeld op 1 switch (ARC, 2xSUB, 2xERA100) + wifi uitgeschakeld.
• Andere SONOS apparatuur wifi uitgeschakeld en bekabeld aangesloten (op 2 na die wifi moeten blijven, een 2x ONE)
• Zowel STP als RSTP geprobeerd
• Priority STP ingesteld, US-24: 0, US-8: 4096, US-Flex: 8096, maar ook hier mee geëxperimenteerd, maakt allemaal niets uit. Staat nu als dit ingesteld.
• Alle settings staan fixed, dus channel, width, power. Er is niets wat op 'auto' staat, bij geen van de ap's.

Lijkt structureel rond 2 uur nachts te ontstaan, mogelijk een instelling of iets, maar niets wat ik kan vinden. Ik gebruik HA, maar heb alle automations die 'iets' doen met Unifi uitgeschakeld, heb ook uiteindelijk de integration vanuit HA nu uitgeschakeld om 100% zeker te zijn dat vanuit HA niets gestuurd wordt.

Heb geen AI optimalisatie of iets gepland staan, dus deze kan ik niet verklaren.

Vanuit de tool Uptime Kuma laat ik nu het IP van de AP pingen, om een gevoel te krijgen wanneer het mis gaat:



Om 08.00 vanmorgen heb ik hem zelf weer herstart, der stond namelijk ook een nieuwe FW klaar.

Zijn er dingen die ik mis? En wat kan dit verklaren? De AP lijkt goed. De kabels lijken goed, is het een instelling in een van de switches. Ik weet het niet meer.

edit:
Had de USW-Ultra per ongeluk Flex genoemd. Dat klopt niet. Het is dus een 8 ports USW Ultra.

[laurens0619]

Vervelend maar wel "fijn" dat het iedere nacht ontstaat. Dit maakt het wat makkelijker troubeshooten.

Paar zaken die je kan proberen:
- Hoe is de ping naar een bekabeld apparaat op dezelfde switch? Kun je die mee laten monitoren?
- Wat gebeurt er als je alles sonos apparatuur een paar dagen loskoppelt?
- Wat zie je op de switch als je packet capture gaat doen?

[Sa1]

Sonos Arc toegevoegd aan uptime kuma.

Als ik alle Sonos apparatuur loskoppel, je bedoelt alles ook de bedrade varianten? Want dat wordt primair een conflict met de rest van het gezin. Kan de draadloze dingen wel is los trekken, maar dat doe ik dan morgen eerst vaststellen wat er met de Arc gebeurd.

Hoe bedoel je een package capture, op de switchpoort waar de AP op zit? Ff kijken hoe dat moet. Maar vooral dan als het probleem zich voordoet, toch?

[laurens0619]

Sonos voor een nachtje alles eruit halen. Als t dan om 0200 niet stuq gaat weet je iets.

Ik weet dat unifi en sonos geen vrienden zijn. Kun je niet alles op de wifi verbinden?

packet capture idd op die switch

[Sa1]

Alles op wifi is natuurlijk wel mogelijk, maar ongewenst. Heb mijn arc al vrij lang, en destijds toen ik nog wel alles wireless had, verloor hij eens in de paar maanden de rear speakers. De setup is een arc, 2 subs en 2 rears. Toen ik over ben gegaan op bedraad heb ik die problemen niet meer gehad. Maar dat was nog wel met een 'oude' nano hd als AP.

Vannacht weer het probleem. De nacht er voor niet. Ik heb echt geen idee wat het verschil is / was.

De PING naar de ap:



Ping naar Arc op hetzelfde moment, welke aangesloten zit aan zelfde switch:



Heb een package catpure gemaakt via SSH op eth0 van de AP. Op de swtich, de Ultra is geen SSH beschikbaar (kom ik nu achter) en snap ik niet hoe ik het moet doen. Via google wordt vertelt dat ik in de GUI dit kan selecteren, maar die optie heb ik nergens, noch bij settings noch bij insight.

De package capture van de AP heb ik, maar ondanks dat ik wireshark wel kan installeren en de capture kan openen, kan ik er verder niet veel mee. Is er iets specifieks waar ik naar kan / moet kijken? Heb overigens ook een capture van de 'normale' situatie, waar dus de latency niet hoog is. Vlak na een reboot.

Als ik ze 'snel' vergelijk, dan zie ik in degene met problemen veel RTSP meldingen.



Waar de 23.110 mijn docker installatie is en de 30.212 is een camera die verbonden is aan de AP. De relatie daar tussen is Frigate wat op de docker draait.

Wat ik ga doen, ter check, als de problemen er weer zijn, dan trek ik die camera er wel ff uit.


Zie ook dat er een melding is geweest over STP state flapping. Frequent STP role changes op de 2e poort van de US-8. Daar zit de USW Ultra op aangesloten. Als ik daar op zoek, is het of een onjuiste instelling of een kabel. De kabels heb ik uitgesloten dus resteert een onjuiste instelling, maar in wat. De priorities zijn volgens mij goed.

GW Ultra (geen) - US-24 prio 0, US-8 prio 4096, USW Ultra prio hoger

---

Nouja, de traagheid was al weer snel terug. Heb de camera der uit gehaald, maar voegt niets toe. Blijft bezig.

Heb de Ultra een factory reset gegeven, en opnieuw geadopt. Maar maakt ook niets uit.

Er zit wel een verschil in netwerk verkeer. Als ik een package capture (op de AP U7) doe als de problemen er zijn, dan zit ik zo op een bestand van 7MB. Wanneer de problemen er niet zijn, dan blijft hij een stuk kleiner met hetzelfde tijdsbeeld. Dit wil ik nog even 'veilig' stellen. Dat het écht zo is. Tis nu vooral een gevoel.

Heb ook mijn docker een herstart gegeven. Latency is ineens weer goed... zal de docker hier een rol spelen?!?? Jemig.. dat zou hilarisch zijn. Ik ga het ff in de gaten houden. Probleem is nu weer 'even' weg. Wellicht zit daar wel een nachtelijke update achtig iets. Als de issues er weer zijn, dan zal ik de docker vm een reboot geven (lxc container op mijn proxmox host).

---

mmm... dat lijkt het wel te zijn, de latency schoot weer omhoog en na reboot van de LXC container waar docker op draait is de latency weer goed. Helaas moet ik weg, dus mogelijk morgen weer wat tijd hiervoor.

---

edit:
heb verschillende edits gedaan met mijn ochtend ontwikkelingen ;-)

[ Voor 49% gewijzigd door Sa1 op 09-05-2026 20:46 ]

[laurens0619]

Lekker bezig

In wireshark kun je een statistisch overzicht openen. Die zou ik even draaien voor je goede en slechte ping capture

omdat je rtsp noemt denk ik nog steeds dat sonos de hoofdverdachte is dus zou die voor de test echt even paar dagen op wifi zetten

[ Voor 33% gewijzigd door laurens0619 op 09-05-2026 19:57 ]

[Sa1]

laurens0619 schreef op zaterdag 9 mei 2026 @ 19:56:
Lekker bezig

In wireshark kun je een statistisch overzicht openen. Die zou ik even draaien voor je goede en slechte ping capture

omdat je rtsp noemt denk ik nog steeds dat sonos de hoofdverdachte is dus zou die voor de test echt even paar dagen op wifi zetten

Nou... ik denk dat ik de boosdoener heb gevonden. Helaas vanavond niet echt meer tijd om naar te kijken, maar.

Dit is mijn gateway, die ping ik, en bij Seq 52 druk ik op enter bij het reboot commando op mijn docker host.

Misschien is met het macvlan gedeelte wat daar niet meer goed staat oid. Geen idee. Maar voor latere zorg. Voor nu denk ik dat ik een gerichte zoektocht kan opstarten.

---

toch nog ff snel iets geprobeerd, maar als ik Frigate docker container uit zet, dan gaat het goed. Dus ping hoog... frigate uit, ping laag...

what the heck... nouja..... stapje dichter bij oorzaak denk...

wat kan je toch op het verkeerde been gebracht worden door van alles en nog wat.

---

Okay.. vrouw boos, maar goed.. wel weer een stapje verder... 2 wifi cameras zitten op deze AP. Als één van beide ingeschakeld worden op Frigate, dan knalt de ping omhoog. De overige cameras zijn bedraad. één van beide cameras die via wifi gaan, die ga ik morgen voorzien van een kabel. Maar de andere is een tablet die aan de muur hangt. Het is toch eigenlijk te zot voor woorden.

ik ga hier verder naar zoeken, maar moet het nu echt ff loslaten...

[ Voor 28% gewijzigd door Sa1 op 09-05-2026 21:49 ]

[laurens0619]

Aaaah rtsp niet rstp

Oeps! Vergeet mn sonos/loop comments dan. Ik zat teveel in mn “het zal wel weer het sonos unifi slecht huwelijk” tunnelvisie

Lijkt er idd op dat er iets geks met die camerq aan de hand is. Doet die geen rtsp over multicast oid? Dan kun je op wifi gekke dingen krijgen.

Hypothese:

“Camera heeft slechte verbinding, snachts nog slechter en is daarom op lage linkrate verbonden. Hij stuurt continue een video stream door maar door lage linkrate kost dat enorm veel airtime waardoor de rest van je wifi in elkaar dondert”


Of nog simpeler: er lopen meerde rtsp streams die je wifi plat leggen. Rond 0200 gaat er een extra stream lopen

Punt :p


Hier wat technische uitleg die ik vond erover mbt multicast over wifi

https://superuser.com/questions/768103/ip-cameras-multicast-rtsp-conflicting-with-wireless-devices

[ Voor 162% gewijzigd door laurens0619 op 09-05-2026 23:04 ]

[Sa1]

Aardige hypothese idd. Nu alleen proberen om te zetten naar praktijk.

Eerst heb ik, en ik weet dat het 'er omheen werken' is, de wifi camera in de berging voorzien van een kabel. Met wat knutsel werk en een usw flex die ik nog had liggen is dat gelukt.

De andere wifi camera, welke onderdeel is van de tablet, kan niet via draad aangesloten worden. Een andere wifi camera die buiten hangt, die heeft geen issues en het AP daar ook niet. Althans, dat denk ik dus, maar misschien moet ik ook die maar is gaan checken.

Met alleen de camera van de tablet ging de latency omhoog. Dus camera AAN latency 80-150ms, camera uit, direct drop naar 0,5ms, aan weer omhoog en uit weer laag. Heel consistent.

Ter test heb ik een nieuwe SSID aangemaakt, daar de tablet aan gehangen, geen issues. Zelfde settings, native VLAN en dus in zelfde ip segment. Tab 9a van samsung is het, 433mbps up en down linkrate.

Het rare is, dat als ik de streams vanaf een andere client initieer. Dus de berging camera bijvoorbeeld; als ik de Frigate camera uit schakel, dan is de latency goed. Start ik de stream vanaf mijn laptop, niets aan de hand. Zet ik dezelfde stream weer aan in Frigate, pats... hoge latency.

Irritant

[laurens0619]

Zou t kunnen dat de frigate een multicast stream opvraagt en je laptop unicast?

Welke cameras hebben we het over?

Theoretisch is het verklaarbaar dat als een apparataat continu data aan het versturen is op wifi je airtime volloopt en clients een hoge ping krijgen. Als mijn kind continu aan t gillen is hoor ik mn vriendin ook nauwelijks meer, de airtime is dan op

Is allemaal afhankelijk van snelheid verbinding/datastroom.

Misschien weet @dion_b nog iets hoe verder te analyseren?

[ Voor 15% gewijzigd door laurens0619 op 10-05-2026 12:56 ]

[Drardollan]

Ik moet gelijk aan een uitgeschakelde IGMP snooping ergens in het netwerk.

En ook je connectiviteit zal niet meewerken, loopt over behoorlijk wat schakels. Ook de combinatie van verschillende modellen Unifi’s is geen aanrader, al zal dat voor dit probleem geen verschil maken.

[Sa1]

We zijn inmiddels bijna een week verder en de boel is stabiel. Om nog de laatste vragen te beantwoorden.

Het zijn Reolink cameras. De stream is een RTSP stream. Gezien de opmerking over Multi- en Unicast zou ik nog kunnen proberen om de optie "Multicast to Unicast" in te schakelen. Geen idee of dat een oplossing biedt.

IGMP snooping staat aan, waar de carrier de US-24 is. En inderdaad, ik zou het liefst een nieuwe switch van een paar honderd euro halen. Ik denk niet dat dat opweegt tegen de voordelen als ik eerlijk ben. Ideaal, nee zeker niet, zou echter, zoals je inderdaad al aangeeft, niet het verschil moeten maken (denk ik).