Wifi Timeouts

[Decarsul]

Goedendag allen!

Mijn issue / hulpvraag:
Ik heb al tijden last van wifi timeouts. Casten naar chromecast wordt onderbroken, ping timeouts van wifi naar LAN, bufferende video's etc.
Het issue deed zich ook voor met de Unify 6 Lite and Unify U7 Pro (u7 pro maakte het nog erger vanwege issues met de 2.4ghz radio)

Hoe kan ik dit oplossen?

Netwerk:
Mijn netwerk ziet er zo uit.
De Chromecast is via de flex mini met een kabel aangesloten (usb-c adapter + RJ45), maakt dus geen gebruik van WiFi.

Test Methode
Mijn test methode is altijd geweest: simultaan pingen vanaf PC en Laptop (en ms surface) naar 1 AP (in dit geval het IP van de GWN7670 welke 'los' staat). De AP via LAN heeft nooit een timeout of grote verhoging in reactie, waar die dit via WiFi wel heeft. De timeout perioden zijn sporadisch / niet te voorspellen, maar over het algemeen ongeveer 30 seconden lang. Naast de timeouts is er met de ping vanaf Wifi een delay van 3 - 5ms welke nagenoeg constant is, met hier en daar blokken van +/- 10x een delay van 200ms+. Tijdens het testen heb ik roaming uitgezet / 2de AP uitgezet om roaming te voorkomen.

Troubleshooting:
2de AP uitgezet
5ghz radio uitgezet (vermindering van ping timeout)
5ghz radio gelimiteerd tot kanaal 36,40,44,48 (vermindering van ping timeout)
MLO uitgezet
Roaming uitgezet
Getest met 1 SSID
Vlan op SSID aan / uit gezet (mocht het een routing issue zijn
Client Isolation aan / uit gezet

Aannames:
Omdat het issue alleen optreedt op WiFi en de ping via het bekabelde netwerk stabiel is, ook wanneer ik via een Vlan de ping test doe, heb ik niet gekeken naar issues in routering.

Feiten:
Wifi kanalen staan vast (op 11 in huis en 6 in schuur).
Woon in buitengebied, geen / weinig andere WiFi binnen bereik.

[ Voor 4% gewijzigd door Decarsul op 08-05-2026 11:01 ]

[Decarsul]

Extra informatie:
Mogelijk relevant.... Maar waarschijnlijk geen issue omdat ik de problemen ervaar op IP niveau.
Ik gebruik momenteel 3 DNS'en in mijn netwerk. PfSense zo geconfigureerd dat deze in volgorde worden gebruikt, dus failover. Voor Vlan 30 waarop de 'thuis' aparaten zitten.
De eerste DNS is Lan-Cache op mijn Unraid server. Deze gebruikt PiHole op Unraid als Upstream DNS.
PiHole op Unraid. Primare upstream DNS voor Lan-Cache, secundaire vanuit PfSense mocht Lan-cache falen.
PiHole in Proxmox. Tertiare DNS mochten Lan-Cache of PiHole op unraid niet beschikbaar zijn.
AdGuard publieke DNS als 4de DNS, mocht het interne netwerk compleet kapot zijn.

Alle requests op poort 53 in Vlan30 worden via NAT naar al deze DNS'en gerouteerd welke op Vlan 120 zitten.

[ Voor 4% gewijzigd door Decarsul op 08-05-2026 10:55 ]

[MasterL]

Oke even voor mijn beeldvorming.. Je hebt de GWN7670 welke centraal in jouw tekening staat met de pijl op 180°, hier verbind je een client naartoe en je hebt ICMP timeouts naar? De GWN7728P? Pfsense of Pihole? Heb je dit probleem op elke SSID/VLAN/L2domain/subnet vanaf dit AP? Ik neem aan dat er meerdere netwerken zijn vanwege het feit dat het een trunk is en geen access port.
Lang verhaal kort vanaf welk device ping je en waar naartoe? Zit dit in 1 VLAN/subnet?

Heb je dezelfde problemen als je met het AP verbind in de schuur? (als zelfde VLAN/SSID?).
Simultane test zou natuurlijk helemaal top zijn maar waarschijnlijk lastig.
Verder kleine tip als je echt NAT/port forwards gebruikt tussen interne VLANS dit is niet nodig.
Routing + firewalling is meer dan voldoende, NAT tussen subnets voegt niks toe behalve complexiteit.

[Decarsul]

@MasterL
De AP die centraal op de tekening staat maak ik verbinding mee, met de laptop en surface (en telefoons).
Vanuit de Laptop / surface doe ik een ping naar het IP van deze AP. (ook getest met pingen naar de router of de switch vanaf het wireless device, zelfde issue).
Al het testen gebeurd binnen 1 Vlan / Subnet

In de normale situatie heb ik inderdaad 3 SSID's beschikbaar op de AP's, waarvan 2 met Vlan 1 zonder.
Vlan30 vanuit PfSense gezien is de PVID. Dus voor de GWN wordt dit gezien als Vlan1.

Ja, zelfde problemen met de AP in de schuur. Evenals een Unify 6 AP Lite als ik deze aansluit (de U7 heb ik geretourneerd).

Welke simultane tests doel je hier op? 2 wifi devices, elk op 1 AP en dan pingen naar datzelfde IP om te kijken of er onderscheid is tussen de 2 AP's?

Ja die begrijp ik, heb ik alleen gedaan voor de DNS omdat je 'moet' routeren om het verkeer te herleiden zonder dat dit overschreven kan worden door lokale instellingen.

[MasterL]

Oke kijk, hypothetisch gesproken als jij 1 meter van "GWN7670 welke centraal in jouw tekening staat met de pijl op 180° verbind op hetzelfde VLAN/SSID waarin het management netwerk zit zou je geen timeouts moeten hebben naar dit AP. Ik bedoel je zit in hetzelfde VLAN/SSID/L2domain dus dan hou je niet zoveel opties over:
1: Extreme interferentie waarbij zelfs op een korte afstand de radiosignalen verstoord worden.
2: Defecte hardware, daarom mijn vraag probeer hetzelfde op een andere AP.
3: Soort van broadcast/multicast/loop ding wat jouw AP compleet omver trekt.

Vergeet de simultane test even voor nu dat was meer om een defect uit te sluiten.

[Decarsul]

@MasterL

Ja okay, dat was / is dus ook mijn gedachtegang. Er zou geen timeout mogen optreden, zeker omdat ik geen timeouts elders in het netwerk krijg moet het rond de AP zitten.
Met compleet andere hardware heb ik hetzelfde, dus de AP zelf zou het dan ook niet mogen zijn. (lees zelfde issue met unify en grandstream). Daarmee heb ik naar mijn idee hardware falen uitgesloten.

Een broadcast loop zou nog kunnen. Ik heb op de AP zelf geen multicast dingen specifiek geconfigureerd. Dit heb ik echter wel in de switch omdat ik ook IGMP snooping nodig heb voor KPN iTV.

[a.boogerd]

Wat gebeurt er als je de AP pingt vanaf een bedraade verbinding. Laat desnoods 2 ping test draaien 1 vanaf een bedraad apparaat en een andere die via wifi direct verbinding heeft.

Heb je ook al geprobeerd de AP met een andere kabel aan te sluiten en op een andere switch?

[dion_b]

Ik lees hier veel over mogelijke issues op layer 2 en 3, maar laten we beginnen bij het begin: layer 1, de fysieke verbinding.

Behalve de (aanname) dat er geen sprake is van interferentie en keuze van enkele kanlen lees ik niets daarover.

Hoe is het WiFi-signaal?
- welke RSSI van de AP(s) meet je op de client devices?
- welke RSSI van de clients meet je op de APs?
- wat is je kanaalbreedte in de twee banden? Probeer tijdelijk die zo laag mogelijk te zetten (dus 20MHz) voor optimale SNR en stabiliteit.

Ik durf ook de constatering te betwijfelen dat 5GHz uitzetten of beperken tot non-DFS kanalen iets uitmaakte. Heb je A/B test gedaan waarbij je de oude instellingen op de andere AP wel aan liet, en daadwerkelijk een verschil tussen de twee AP's gezien op dat moment? Als dit *wel* verschil uitmaakt kun je gelijk stoppen met alle troubleshooting op layer 2 en hoger en is het nodig te ontdekken wat hier gebeurt.

Misschien geen issue, maar wel eerste om uit te sluiten want met gare layer 1 gaat alles daarboven ook problematisch zijn.

Als dat allemaal goed is, zou ik vervolgens nog wat dieper naar de VLANs kijken. Beide AP's hangen hier aan een trunk. Je hebt al de VLAN op de SSIDs uitgezet. Probeer anders een stap verder te gaan: eentje (bijv de hoofd-AP) tijdelijk untagged op VLAN 30 zetten (en uiteraard geen VLAN op de SSIDs dan).

[Decarsul]

@a.boogerd
Dank voor je reactie.
Wanneer ik het erover heb dat ik ping vanaf mijn PC, dan is dat dus de ping test via een bekabelde verbinding. Waarbij de PC de bekabelde is, en de Laptop / Surface de Draadloze verbinding.

Ja, de AP's heb ik getest met een andere Kabel. Daar deze PoE gevoed worden heb ik getest met een cat5e (standaard installatie) en cat7 (tijdelijke installatie van een metertje of 3 lang) kabel.

@dion_b
De RSSI hangt rond de -50dBm gemeten vanaf surface, met een gemiddelde van -52 op 2.4ghz kanaal 11.
De RSSI van de surface hangt rond -60dBm gemeten vanaf AP.
Radio van 2.4ghz staat op 20mhz, 5ghz staat op 40mhz.

Ik heb niet specifiek getest met DFS kanalen aan op AP2 en uit op AP1 en dan ook nog gelijktijdig een test draaien. Zou ik zeker nog kunnen doen.

Wat de kabel betreft. Als deze te slecht zou zijn, zou ik verwachten dat de ping verzoeken vanuit het vaste netwerk eenzelfde trend laten zien op moment dat mijn WiFi ping inzakt, dit is dus niet zo. Hierom denk ik niet dat het te maken heeft met Layer 1.

Wat de Vlans betreft. De poort waar ze aanhangen op de switch heeft vlan 30 untagged, krijg ook een IP uit betreffende subnet, de 84 en 120 zijn tagged en ip uit deze subnet krijg ik alleen op de SSID's met een vlan toekenning.

[a.boogerd]

Decarsul schreef op vrijdag 8 mei 2026 @ 13:45:
@a.boogerd
Dank voor je reactie.
Wanneer ik het erover heb dat ik ping vanaf mijn PC, dan is dat dus de ping test via een bekabelde verbinding. Waarbij de PC de bekabelde is, en de Laptop / Surface de Draadloze verbinding.

Zou de AP zelf pingen vanaf beide kanten

[Decarsul]

a.boogerd schreef op vrijdag 8 mei 2026 @ 14:19:
[...]

Zou de AP zelf pingen vanaf beide kanten

Dat is wat ik constant doe. Vanaf bekabelde netwerk <1ms. Vanaf Wifi 8 - 11ms. met uitschieters naar 200ms+. En dan dus ook hier en daar volledige timeout.

[ Voor 8% gewijzigd door Decarsul op 08-05-2026 14:21 ]

[laurens0619]

Decarsul schreef op vrijdag 8 mei 2026 @ 13:45:

@dion_b
De RSSI hangt rond de -50dBm gemeten vanaf surface, met een gemiddelde van -52 op 2.4ghz kanaal 11.
De RSSI van de surface hangt rond -60dBm gemeten vanaf AP.
Radio van 2.4ghz staat op 20mhz, 5ghz staat op 40mhz.

Ik heb niet specifiek getest met DFS kanalen aan op AP2 en uit op AP1 en dan ook nog gelijktijdig een test draaien. Zou ik zeker nog kunnen doen.

Wat zijn de waaardes op 5ghz?

2.4ghz signaal staat voor mij gelijk aan klapperend signaal dus die probeer ik altijd te vermijden

[Decarsul]

@laurens0619
5ghz zit rond de -61dbm op de surface en -65dbm op de AP.

[dion_b]

Decarsul schreef op vrijdag 8 mei 2026 @ 15:03:
@laurens0619
5ghz zit rond de -61dbm op de surface en -65dbm op de AP.

Dat is nog steeds meer dan goed genoeg voor een stabiele verbinding. Tenzij er gekke interferentie is, is alles boven de -67dBm doorgaans rotsstabiel. Hier ligt het alvast niet aan dus. Wel eens met @laurens0619 dat 5GHz in beginsel altijd boven 2.4GHz te perfereren valt qua stabiliteit _{en als de dekking op 5GHz onvoldoende is dat oplossen ipv op 2.4GHz terug te vallen}

Decarsul schreef op vrijdag 8 mei 2026 @ 14:21:
[...]

Dat is wat ik constant doe. Vanaf bekabelde netwerk <1ms. Vanaf Wifi 8 - 11ms. met uitschieters naar 200ms+. En dan dus ook hier en daar volledige timeout.

Misschien lees ik het niet goed, maar ik volg niet exact waar je tussen ping hier. Die "<1ms", is dat van bekabeld netwerk (en zo ja welke host?) naar de AP in VLAN30?

[Decarsul]

@dion_b de sub 1ms ping is vanaf een pc, Via kabel, naar AP op vlan30

[a.boogerd]

Als ik het goed begrijp betreft het je wifi signaal dat tijdelijk weg valt? De verbinding aan de bekabelde zijde van de AP blijft werken.

Als je 2 apparaten via wifi verbind en laat pingen. Valt de verbinding dan op beide apparaten op hetzelfde moment weg?

[Decarsul]

a.boogerd schreef op vrijdag 8 mei 2026 @ 17:47:
Als ik het goed begrijp betreft het je wifi signaal dat tijdelijk weg valt? De verbinding aan de bekabelde zijde van de AP blijft werken.

Als je 2 apparaten via wifi verbind en laat pingen. Valt de verbinding dan op beide apparaten op hetzelfde moment weg?

Ja en nee. Het signaal en de verbinding (op wifi) lijkt intact te blijven, maar data transport wordt vertraagd (hoge latency) of verdwijnt compleet (timeout). Ondertussen lijkt er geen nieuwe handshake plaats te vinden en blijft het icoontje op sterk signaal staan. In de grafieken van netspot (zoiets als wifiman) blijft het signaal ook constant op de bovengenoemde sterkte.

Op de kabel blijft alles onder de 1ms. Dus daar geen transport issues.

[ Voor 5% gewijzigd door Decarsul op 08-05-2026 17:53 ]

[Decarsul]

En 2 apparaten op wifi zelfde ap beiden een ping resulteert in vertraging of timeouts op hetzelfde moment

[laurens0619]

En dan zijn ze 100% zeker verbonden met 5ghz?

[The Eagle]

Zomaar my 2ct:
Ik heb hier een full Ubiquiti setup met 3 AP's, bedrade backbone. Ook hoop timeouts.
De AP's een scan laten doen van hun RF omgeving zodat ze wisten waar interferentie zat en het probleem was grotendeels opgelost.
Dus als je die mogelijkheid hebt: doen. Je bent vast niet de enige die draadloos werkt in de buurt

[Decarsul]

laurens0619 schreef op vrijdag 8 mei 2026 @ 18:06:
En dan zijn ze 100% zeker verbonden met 5ghz?

Nee. Dit is allemaal getest op 2,4ghz met maar 1 ssid op 1 ap actief.

Doe vanavond een test op 5ghz.

[Decarsul]

The Eagle schreef op vrijdag 8 mei 2026 @ 18:09:
Zomaar my 2ct:
Ik heb hier een full Ubiquiti setup met 3 AP's, bedrade backbone. Ook hoop timeouts.
De AP's een scan laten doen van hun RF omgeving zodat ze wisten waar interferentie zat en het probleem was grotendeels opgelost.
Dus als je die mogelijkheid hebt: doen. Je bent vast niet de enige die draadloos werkt in de buurt

Nee klopt. Ik ben niet de enige en helaas niet zo een mogelijkheid waar ik vanaf weet.

Maar... Hier in de rimboe valt het allemaal wel mee qua saturatie. Zie screenshot van zojuist.

[laurens0619]

Wifi netwerken maak ik mij nooit zon zorgen om qua wifi storing.

Deurbellen, magnetrons, babyfoons daarentegen brrrr

2.4 pas ik zelf alleen toe als mn apparaat geen 5ghz kan. In de regel is die stuk schoner dan 2.4

Hopelijk zijn de test resultaten op 5 beter

[tlpeter]

Ook hier Unifi waarbij ik continue van AP naar AP over ga. Veel klachten van mijn dochter dat "de Wifi" het niet doet. Dit lijkt bij mij door een recente update ofzo want het heeft perfect gewerkt.

[Tha Render_2]

Met alleen de startpost gelezen te hebben: die specifieke +- 30 seconden timeout is verdacht en wijst meestal niet naar RF issues. Chromecast, Reolink -> veel multicast/broadcast rotzooi op het netwerk. Mijn eerste idee: je wifi airtime wordt sporadisch “verstopt” door multicast/broadcast flooding of buffering.

Misschien heb je dit al geprobeerd, zoals gezegd heb ik enkel de startpost gelezen, maar trek eens de chromecast en alle Reolinks uit. Resultaat? Nog niet beter, probeer eens zonder de flex mini's, ik heb daar al rare multicast/STP issues mee gezien in het verleden.

[nelizmastr]

Tha Render_2 schreef op vrijdag 8 mei 2026 @ 21:53:

Misschien heb je dit al geprobeerd, zoals gezegd heb ik enkel de startpost gelezen, maar trek eens de chromecast en alle Reolinks uit. Resultaat? Nog niet beter, probeer eens zonder de flex mini's, ik heb daar al rare multicast/STP issues mee gezien in het verleden.

De Flex Mini ondersteunt bovendien geen igmp snooping, daarvoor moet je een segment hogerop in de Unifi familie, dus die switches gaan bij multicast verkeer ouderwets over de huig.

[The Eagle]

Decarsul schreef op vrijdag 8 mei 2026 @ 18:38:
[...]

Nee klopt. Ik ben niet de enige en helaas niet zo een mogelijkheid waar ik vanaf weet.

Maar... Hier in de rimboe valt het allemaal wel mee qua saturatie. Zie screenshot van zojuist.

[Afbeelding]

Das niet wat ik bedoel. Dit bedoel ik:

Dit is een scan van alle RF interferentie op elk kanaal van de 5Ghz. Ongeacht wat er dan ook iets veroorzaakt. Erg handig, want dat al onthoudt dat en past er zich op aan