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 ap onthoudt dat en past er zich op aan

[Decarsul]

@Tha Render_2 en @nelizmastr

Multicast blocking en igmp snooping heb ik wel aan staan op de Grand stream en brocade. Daar de flex mini daar weer achter zit en het daarmee effectief scheidt van de rest van het netwerk, zou dat toch (in theorie) geen probleem mogen zijn?

Zou wel het een en ander verklaren omdat de itv box op diezelfde mini zit...

[ Voor 12% gewijzigd door Decarsul op 09-05-2026 08:55 ]

[Decarsul]

The Eagle schreef op vrijdag 8 mei 2026 @ 22:33:
[...]

Das niet wat ik bedoel. Dit bedoel ik:
[Afbeelding]
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 ap onthoudt dat en past er zich op aan

Interesting....

[Yaksa]

Waarom leg je geen vaste kabels naar de AP's?
En niet zeggen dat het niet kan, er is altijd een mogelijkheid.
WiFi is nou eenmaal nogal gevoelig voor verstoringen, zet een gevulde boekenkast voor het AP of laat iemand (people are bags of water) voor het AP heen en weer lopen en je hebt al een verminderde verbinding.

[Decarsul]

Yaksa schreef op zaterdag 9 mei 2026 @ 09:13:
Waarom leg je geen vaste kabels naar de AP's?
En niet zeggen dat het niet kan, er is altijd een mogelijkheid.
WiFi is nou eenmaal nogal gevoelig voor verstoringen, zet een gevulde boekenkast voor het AP of laat iemand (people are bags of water) voor het AP heen en weer lopen en je hebt al een verminderde verbinding.

Waaruit haal je uit dat mijn ap's niet bekabeld aangesloten zijn?

Alles is namelijk bekabeld aangesloten, maar ja... Erg lastig om een kabel op een telefoon aan te sluiten.

[a.boogerd]

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]

Waarom zit je niet op kanaal 6? Die lijkt vrij te zijn volgens dit overzicht. Nu ben je in "gevecht" met 2 andere devices die op kanaal 11 uitzenden.

Zitten er nog apparaten van jezelf hier tussen? Schakel ze uit als je ze niet gebruikt/nodig hebt. Verlaag de signaal power om te zorgen dat ze elkaar niet/minder storen.

Stel een vaste signaal sterkte in, geen automatische functie hiervoor gebruiken.

Hoe zijn de testen op 5GHz band? heb je het probleem ook op 5 GHz.

[Decarsul]

a.boogerd schreef op zaterdag 9 mei 2026 @ 13:12:
[...]

Waarom zit je niet op kanaal 6? Die lijkt vrij te zijn volgens dit overzicht. Nu ben je in "gevecht" met 2 andere devices die op kanaal 11 uitzenden.

Zitten er nog apparaten van jezelf hier tussen? Schakel ze uit als je ze niet gebruikt/nodig hebt. Verlaag de signaal power om te zorgen dat ze elkaar niet/minder storen.

Stel een vaste signaal sterkte in, geen automatische functie hiervoor gebruiken.

Hoe zijn de testen op 5GHz band? heb je het probleem ook op 5 GHz.

Alles met horse en secrity is van mij. Ik stond op dat moment voor het huis. Die kpn is de buurman aan de overkant van de straat. Per AP heb ik zelf vast een kanaal ingesteld. De 11 is in huis. Vanaf schuur wordt er op 6 uitgezonden

Radio power staat op basis van rssi. Bevalt me even goed als wanneer ik ze op medium zet.

5ghz heeft ongeveer hetzelfde als op de 2.4ghz. alleen dus bijna geen blokken timeouts meer gezien sinds ik van de dfs kanalen ben gegaan. Wel nog de blokken van hogere latency (dus 5 a 6 pings waar de ms van 10 naar 300+ schiet)

[a.boogerd]

Kanaal 6 lijkt ongebruikt bij je huis niets is beter dan een leeg kanaal gebruiken. Zou deze AP naar 6 zetten.

vervolgens meten bij de schuur en zijn "signaal omgeving" wat daar de gebruikte kanalen zijn en signaal sterktes. Dit zou ook gewoon 6 mogen zijn als huis en schuur ver genoeg van elkaar af zitten en elkaar niet in de "weg" zitten.

Dit doe je idem voor je security wifi. Never mind. Waarschijnlijk een 2e ssid op dezelfde AP

Als AP's te dicht op elkaar op dezelfde kanalen zitten dan moet je met de radio power het signaal knijpen. Anders ga je het signaal alleen maar wegdrukken en jezelf in de "weg" zitten.

Kijk ook goed na of er geen andere storende apparaten voor de 2.4GHz in de omgeving actief is. Zoals bluetooth (zie discover tab van de WiFiman app), draadloze-babyfoons of andere draadloze point-to-point apparaten, magnetron, Zigbee apparaten (hue)

"Radio power staat op basis van rssi. Bevalt me even goed als wanneer ik ze op medium zet." Wat is basis? maak anders een snapshot van de Radio pagina van je AP.

[ Voor 29% gewijzigd door a.boogerd op 09-05-2026 14:40 ]

[Decarsul]

a.boogerd schreef op zaterdag 9 mei 2026 @ 13:58:
Kanaal 6 lijkt ongebruikt bij je huis niets is beter dan een leeg kanaal gebruiken. Zou deze AP naar 6 zetten.

vervolgens meten bij de schuur en zijn "signaal omgeving" wat daar de gebruikte kanalen zijn en signaal sterktes. Dit zou ook gewoon 6 mogen zijn als huis en schuur ver genoeg van elkaar af zitten en elkaar niet in de "weg" zitten.

Dit doe je idem voor je security wifi. Never mind. Waarschijnlijk een 2e ssid op dezelfde AP

Als AP's te dicht op elkaar op dezelfde kanalen zitten dan moet je met de radio power het signaal knijpen. Anders ga je het signaal alleen maar wegdrukken en jezelf in de "weg" zitten.

Kijk ook goed na of er geen andere storende apparaten voor de 2.4GHz in de omgeving actief is. Zoals bluetooth (zie discover tab van de WiFiman app), draadloze-babyfoons of andere draadloze point-to-point apparaten, magnetron, Zigbee apparaten (hue)

"Radio power staat op basis van rssi. Bevalt me even goed als wanneer ik ze op medium zet." Wat is basis? maak anders een snapshot van de Radio pagina van je AP.

Ja, dat begrijp ik dat niks beter is dan een leeg kanaal. Probleem van de buren... die blijven switchen, rete irritant, schuur kant is nog erger met ziggo... die zendt nogal hard uit. En die van de schuur zal ik ook op 6 zetten zodra ik het transmissie probleem wat ik al heb met 1 AP, heb opgelost.

Ja klopt, ik hou het wel zo dat ik al mijn SSID's per AP op hetzelfde kanaal hou.

Ohh kijk nou, een bleutooth scanner, dat wist ik nog niet... Deze zal ik in de gaten moeten houden maar op moment is alles hierin op -65db of lager. Verwacht hier dus niet veel issues.

Ah mijn fout wat betreft de RSSI, het heet RRM. in de 'Basis' staat dit op auto. Dit heb ik getest op medium en high, low werkt niet. Allen hetzelfde resultaat. Ik hoop alleen dat de RRM ervoor zorgt dat de zender niet te veel te vaak te hoog zend (heb iemand in huis die wat gevoelig is voor radio signalen)

[Decarsul]

Even een update...

Ik heb nu ook getest op 5ghz. Sinds het uitzetten van 5ghz op de DFS kanalen lijkt het erop dat de blokken van timeouts nagenoeg weg zijn, hier en daar heb ik nog een timeout, maar dat is een enkele (nog niet goed, maar stuk beter dan voorheen).

Ping testen op 5ghz, net als op 2.4ghz blijven op dit moment redelijk constant. 2.4ghz heeft iets hogere ping blokken waarbij de latency even naar 3 a 400 sprint en daarna weer terug. 5ghz heeft hier en daar ook een piekje, maar eigenlijk nooit boven de 30ms.

Wel hebben we nog steeds het issue dat we af en toe vanaf de telefoons gewoon geen internet hebben, facebook reageerd niet en youtube bufferd. (casten naar chromecast niet gedaan in de test), reguliere sites zoals tweakers op zo'n moment ook niet te laden. Daarom zit ik te denken aan DNS issues, misschien dat pihole te veel blokt of er iets anders aan de hand is.

[Decarsul]

Voor de mensen die geïnteresseerd zijn in hoe ik daadwerkelijk 'test'. Hiervoor gebruik ik Uptime Kuma.
Er zullen vast veel meer functies in zitten dan waar ik nu mee 'bekend' ben. Maar hierbij even een screenshot van hoe dat eruit ziet.
Dit is een 'verse' installatie op mijn unraid server, omdat die toch hele dagen aan staat. Kan ik de laptop weer lekker uit zetten.

[Decarsul]

Weer even een update.

Gezien er vanochtend / vannacht geen issues zijn geconstatered, denk ik... even uptime kuma overzetten naar een ander Vlan. Kijken of er toch nog iets verborgen zit in de routeringen etc.

Blijkt dat unraid gewoon even zelf bedacht had om het IP van mijn router aan deze docker te geven... Volgens mij heb ik even iets om uit te zoeken, want als dit vaker gebeurd....

[Decarsul]

Wederom even een update.

Het issue met dockers die ip adressen krijgen die ze niet horen te krijgen lijkt een docker / unraid ding te zijn. Dus als je ipvlan gebruikt voor dockers dan altijd vast ip adres instellen... hebben we dat ook weer geleerd.

Bijkomend had unraid de gateway van de betreffende vlan niet meer in zijn geheugen ofzo, dit ook weer gefixt waardoor ik de daadwerkelijke situatie van de home clients kon testen, waarbij kuma in het thuis vlan deel zit en de DNS services in een andere vlan.

Over de afgelopen 20+ uur, heb ik geen issues geconstateerd in kuma. de HTTP test naar facebook toont wel een hoge gemiddelde reactie tijd van ruwweg 500ms waar dit bij tweakers rond de 50ms ligt.

Ook nog geen signalen vernomen vanuit de Fam dat 'internet eruit ligt'.

To be continued...

[Decarsul]

Weer even een update.

De issues zijn niet te meten als ik uptime kuma mag geloven, maar bestaan nog wel.
Gisteren had ik het zelfs nog vanaf mijn telefoon naar het interne netwerk, waardoor ik mijn camera's niet kon bekijken, die wel werkten zonder wifi en dan met Wireguard aan....

Dit deed mij denken, dat er misschien wel iets is met de AlwaysOn functie van Wireguard, dus nu ook aan het testen zonder gebruik te maken van Wireguard. . . . to be continued