Google Cast-apparaten veroorzaken wifi-drop-outs bij verschillende routers

Apparaten die Google Cast ondersteunen kunnen ervoor zorgen dat draadloze accesspoints tijdelijk vastlopen. Dit zou komen doordat Google-apps bij het ontwaken uit sleep veel te veel packets over het lokale netwerk sturen om Cast-compatibele apparaten te ontdekken.

Het zou gaan om recente versies van het Android-os en van Google-apps die kunnen casten, zoals YouTube. Normaal gesproken zou een mdsn multicast discovery packet om de 20 seconden het lokale netwerk op gestuurd worden om de verbinding met een Cast-apparaat te onderhouden. Volgens een ontwikkelaar van TP-Link worden er echter in bepaalde gevallen, afhankelijk van hoe lang het apparaat in slaap heeft gestaan, meer dan 100.000 van deze packets in een korte tijd uitgezonden. Het resultaat is dat het accesspoint tijdelijk de geest geeft en lokaal netwerkverkeer stil ligt.

Het probleem werd in kaart gebracht door gebruiker nonameleft1, die een posting maakt op het Google-productforum. Hij verzamelde vier forumtopics, afkomstig van de fora van Linksys, Netgear, TP-Link en Synology, waarin hetzelfde probleem door gebruikers omschreven wordt. De eerste meldingen van het probleem zijn in oktober 2017 gepost.

De problemen zouden zich in ieder geval voordoen bij de TP-Link Archer C1200, de Linksys WRT3200ACM en de WRT32X. Die apparaten hebben allemaal bèta-updates gekregen. Ook de Synology RT1900 AC lijdt hieronder, maar daarvoor is nog geen update.

Gebruikers kunnen het probleem zelf tijdelijk oplossen door Cast-compatibele apparaten, zoals een Google Home, Chromecast of een specifiek model tv tijdelijk van het netwerk af te halen. Google heeft zelf nog niet op het probleem gereageerd. Een update om het probleem aan hun zijde op te lossen, zou updates voor modems en routers overbodig maken.

Reacties (194)

[Arnout]

Op je smartphone of tablet kun je dit doen om het te stoppen:

https://tweakers.net/ext/f/j5FcNGyBhTFuGWCK3nl8I2xY/full.jpg

En deze uitzetten. Dit stopt direct het flooden, dit moet je dan wel per device doen.
Dit zit onder Settings | Google | Cast Media Controls

Dit is op een OnePlus 5 met Android 8. Sinds de jaarwisseling is dit probleem opgelost, tenminste, ik heb er geen last meer van. Kan ook goed komen door een Play Services update; het probleem kwam plotseling en is op dezelfde manier weer verdwenen.

------------------------------
Edit maandag 11u: Ik heb de beta van Play Services geïnstalleerd en dit lijkt het probleem ook te verhelpen. Je kunt de beta eenvoudig installeren via https://play.google.com/apps/testing/com.google.android.gms

[Reactie gewijzigd door Arnout op 23 juli 2024 13:34]

[darkcarlaza]

Zet het anders weer eens een tijdje aan om voor ons te testen. Dan weet je zeker of het de Play update, of deze instelling was.

[Arnout]

Ik heb hem weer even aangezet en de floods zijn terug. Het is dus nog niet opgelost.

Ik ben erg benieuwd of bovenstaande switch bij anderen ervoor zorgt dat hun router niet vastloopt. Zelf heb ik daar namelijk geen last van (Asus RT-AC87U met asuswrt-merlin).

[pdidi]

Ik heb geen sniffer, maar los je het niet automatisch voor alle devices op door met de Home app de Chromecast optie 'Laat anderen je gecaste media bedienen' uit te zetten?

[Reactie gewijzigd door pdidi op 23 juli 2024 22:22]

[user549890]

Heeft er iemand bewijs als dit effectief werkt? Als ik op Google zoek vind ik uiterst weinig fora & artikels met deze 'fix'.

Mijn 5ghz wifi op een Proximus modem heeft de laatste tijd ook random wifi drops van enkele seconden.

edit: na enkele uren de optie uit te zetten bij Cast Media Control lijkt mijn wifi stabiel te draaien!

[Reactie gewijzigd door user549890 op 23 juli 2024 22:22]

[Arnout]

Hier eentje, derde reactie: https://community.spotify...rantz/td-p/3603988/page/4

edit: wauw, het werkt dus!

[Reactie gewijzigd door Arnout op 23 juli 2024 22:22]

[Mitzzy87]

Ik had er ook last van. Na veel reset's en aanpassingen op mijn router(mediabox xl ziggo) ben ik er achter. De chromecast 2 aangemeld op 5,0ghz netwerk via de Google home app en vinkje om andere apparaten op het zelfde netwerk aan te melden uit. Ik kwam erachter dat ik geen cast icoon had als mijn laptop, telefoon, tablet verbonden waren met het 5,0ghz netwerk. Als ik alles verbind op het 2,4ghz netwerk werkt alles prima. Ik heb dan op elke app gewoon mij cast icoon weer. Dus mijn chromecast 2 aangemeld op 5,0ghz en alle apparaten in huis op 2,4ghz om de chromecast te bedienen en goed te laten functioneren. Het probleem met de router heb ik trouwens nooit geconstateerd.

[Anoniem: 710407]

Dus als ik het goed begrijp zal elk android apparaat je netwerk flooden tot dat google van deze beta een release maakt?

Enig idee welke app er geupdate moet zijn? Want voor zo ver ik kan zien geef je met die link toestemming om de beta versies van google apps te installeren. Het liefst word ik namelijk geen beta tester en wacht ik de release notes van de betreffende app af.

In iedergeval bedankt voor de research gaat een hoop mensen wat haren besparen.

[Arnout]

Je wordt met deze link bèta tester van Play Services. Dit is de meest gebruikte deel van Android (5 miljard downloads) en je kunt er van uit gaan dat ook betàs goed werken.

https://play.google.com/apps/testing/com.google.android.gms

Je kunt er op elk moment weer uitstappen.

[Stoelpoot]

Ohh, vandaar. Vanavond even een ronde maken met de fix over alle Android-devices in huis dus.

Bedankt @Arnout voor die tip!

[Arnout]

Graag gedaan.

Maarrrr... Waar het in december vrij duidelijk was, lukt het me nu niet om de 'broadcaststorm' op mijn eigen netwerk onder controle te krijgen... ook met de instelling op 'uit' zie ik nog veel MDNS verkeer...

Wordt wel echt tijd dat Google eens wat gaat doen, lijkt me nog steeds dat het een bug in Play Services is.

[Stoelpoot]

Oh, das jammer. Oh well, dan zal ik moeten leven met 's avonds 1 of 2 keer een momentje geen internet. Geen overdreven drama nu ik Skyrim speel, gelukkig.

Heb je trouwens geen nieuw Android apparaat op je netwerk oid wat het dan veroorzaakt?

[Reactie gewijzigd door Stoelpoot op 23 juli 2024 09:21]

[Arnout]

Probeer het in ieder geval eerst even.

[HarmoniousVibe]

Ik heb hier ook last van. Let erop dat de firmware die in het artikel wordt gelinkt voor de apparaten uit de VS is! TP-Link zelf zegt dat je je router kunt bricken als je niet de juiste regio kiest. Ik heb nog geen Europese beta-release kunnen vinden.

[SeelenSchmerz]

Er wordt in het Tweakers artikel de nadruk gelegd op Google Home, Chromecast of een specifiek model tv.
In de posting op het Google-productforum wordt ook melding gemaakt van Android telefoons.
Nu vraag ik mij af of Android telefoons ansich ook dit soort wifi-dropouts kunnen veroorzaken zonder dat er zich Google Home of Chromecast devices op het netwerk bevinden?

[Arnout]

Ik heb toen ik het probleem had, onderzoek gedaan door een sniffer in te zetten (MDNS laat zich makkelijk sniffen). Mijn telefoon zond ook een flood uit nadat ik het scherm weer aan deed. Dit gebeurde niet op mijn werk AP. Het gebeurde alleen thuis.

Vermoeden is dat zodra je smartphone ontdekt dat er een Chromecast is, hij antwoorden begint te geven op broadcasts van de Chromecast. Die antwoorden waren (of zijn) het probleem.

[Bor]

Als de dropouts worden veroorzaakt door simpelweg te veel packets kan in principe elk device dit veroorzaken. In mijn ogen is het een issue dat zowel aan de Google kant als aan de router kant opgelost dient te worden.

[SeelenSchmerz]

Ik begrijp dat elk apparaat dit zou kunnen veroorzaken, maar naar aanleiding van dit artikel ben ik benieuwd of Android telefoons dit ook daadwerkelijk doen (als er geen andere Google Cast devices zoals Chromecast/Home zich op het netwerk bevinden).

Op het wifi netwerk van de zaak zijn er ook met enige regelmaat moeilijk te verklaren wifi-dropouts. Echter zijn er geen Google Chromecast/Home devices op aangesloten, maar wel Android telefoons.

Zijn er specifieke apps of functionaliteit die standaard aan staan op Android telefoons en dit gedrag vertonen (ook al zijn er geen andere Google chromecast/home devices op het netwerk)?

[Reactie gewijzigd door SeelenSchmerz op 23 juli 2024 22:22]

[Nox]

Elk apparaat kan dit ja. Maar je hebt je op een netwerk gewoon te gedragen. Ik kan met mijn pc een arp flood doen, en de switch in hubmodus krijgen. Ja er is beveiliging voor maar die vind je op de duurdere modellen terug en moet je goed instellen.

[Fareeb]

Ik heb dus de laatste tijd dat mijn 5Ghz band van me modem steeds uitvalt. Heb dan ook een Google Home, Android TV en Chromecast en tijdlang geen last gehad dus denk dat dit dan idd door een update komt.

[FurrBeast]

Zit je toevallig ook bij KPN?
Daar is namelijk al maanden lang een probleem met de Experia v10.
Wellicht dat deze combinatie (modem + Cast) problemen geeft. Heb er zelf namelijk ook last van thuis.
https://forum.kpn.com/int...rbinding-op-de-v10-442731

[ace6717]

Ik had dezelfde gedachte en heb net gepost om te vragen wie, met problemen, een cast compatibel device heeft:
https://forum.kpn.com/int...1/index24.html#post572580

[hoeksmarp]

Mijn schoonouders ondervinden de problemen met hun experiabox (beter gezegd, ik ondervind ze), maar zij hebben hun chrome cast standaard niet aangesloten en niet aangesloten gehad toen ik bij ze was. Ik denk dan ook dat het twee verschillende problemen moeten zijn.

[John Duh]

Het lastige is inderdaad dat het verschillende problemen zijn, die zich ook nog eens niet altijd onder dezelfde omstandigheden voordoen. Zo heb ik bijvoorbeeld geen last van Wi-Fi uitval bij mijn Experiabox V10, waarbij er ook een range extender van TP-Link en een Chromecast aan hetzelfde netwerk hangen. Een collega, die bij dezelfde provider (NLEx) zit, heeft echter wel last van de inmiddels beruchte Wi-Fi uitval van de Experiabox V10.

Edit:
Daarom is er waarschijnlijk ook nog geen definitieve oplossing gevonden en worden work-arounds geadviseerd, zoals bijvoorbeeld het uitschakelen van de 5 GHz frequentie.

[Reactie gewijzigd door John Duh op 23 juli 2024 22:22]

[Noresponse]

Ik had het zelfde idee. Dit probleem is zo gek en het schijnt niet alleen KPN te zijn, maar de klacht is ook bij andere aanbieders. Ik heb zelf ook de asus router RT66U en heb zelfs een nieuwe router gekocht, omdat mijn internet steeds opeens weg was en ik steeds opnieuw moest verbinden. Wat een Joke en gebruikt gelukkig de Asus Router boven als soort switch box en draadloos uitgeschakeld.

[Exorcist]

Ik heb het tot dusver altijd gegooid op de telefoon van mijn vrouw, omdat als zij binnenkwam het wifi wegviel. Maar, tegelijk startte ik dan vaak de TV met CC achterin..(Asus AC-68U). Dit zou dus best de reden kunnen zijn. Ik gebruik hier drie Chromecasts en één Chromecast Audio, dus zoek dan maar uit wat zoiets veroorzaakt.

[GMJansen]

Ik zou zeggen: wireshark

[feranderd]

Ik las het artikel en er ging een lampje branden. Heb ook dit probleem en bij nader inzien altijd bij Google cast.

[Reactie gewijzigd door feranderd op 23 juli 2024 22:22]

[cbr600f4i]

Ik heb dit al zeker een jaar, setup Ziggo, 2.4Ghz, Routermerk moet ik morgen ff kijken, Apple apparaten. Nu moet ik alles ff checken of het technische verhaal overeenkomt met hetgeen boven wordt beschreven maar zodra ik de chromecast verwijder zijn de wifi issues voorbij.

[El Wobbello]

Dank voor de link naar het topic. Zelfde probleem hier.

[Vexxon]

Ik heb een Expedia V9 en ondervind hetzelfde probleem eigenlijk sinds de update naar de bèta van Oreo. Met de laatste update is het iets verbeterd, maar nog niet zoals het zou moeten zijn.

[FreshMaker]

Ik heb een Expedia V9 .........

Je weet toch wel dat Expedia een reisorganisatie/website is ?

[Reactie gewijzigd door FreshMaker op 23 juli 2024 22:22]

[Vexxon]

Kak vandaar...

[Fareeb]

Ik heb internet via SSHnet, maar geen idee welke provider dat is en kan dat ook niet achterhalen. Daar aan gekoppeld is een Genexis Hybrid Modem dus ga even kijken of ik daar iets over kan vinden. Toch goed om te zien dat ik niet de enige ben.

[supersnathan94]

Bij SSHnet is het afhnakelijk van de locatie. Sommigen hebben KPN anderen Ziggo of iets via de lokale uni bijvoorbeeld.

Je kunt via deze lijst soms wel zien wat je hebt: http://helpdesk.sshnet.nl/v12/

Als je een genexis hybrid modem hebt is de kans groot dat dit via Telfort gaat. OnsbrabantNet zou ook nog kunnen als je in die regio zit.

[GMJansen]

Tracert naar een website.
Wellicht dat je tussen de eerste hops een bekende provider tegenkomt?

[Fareeb]

Goeie tip! Even geprobeerd en zie toch alleen sshunet.nl staan. Ik denk dat het via de netwerk van de uni gaat gezien ik op campus woon.

[OrangeTux]

Ik heb ook sinds enkele dagen af en toe problemen op mijn 5 Ghz verbinding. Ik heb een Asus RT-N66U.

[Luchtbakker]

Ik heb sinds 3 weken uitval van mijn 5Ghz, maar dan op een asus RT-AC68U. Ik kan echter in de router niet achterhalen of de chromecasten (heb 3x een v2) de oorzaak zijn.

[Malarky]

Op mijn Netgear R7000 na 3 jaar voor het eerst 5Ghz compleet uitgeschakeld 2 weken geleden. Verbinding dropte constant.

Op 2.4Ghz ook veel drops overigs dacht dat XVortex buggy was geworden. Gelijk testen zonder Chromecast

[HWAM]

https://community.netgear...me-wifi-routers-nighthawk

https://community.netgear...0-9-18/m-p/1485238#M79342

Moet je hier maar eens lezen. Netgear is druk bezig. Sinds november veel firmware problemen met de R7000. Ik heb een nieuwe Router gekocht, R7000 was niet meer stabiel te krijgen.

[Phusebox]

Oh eens even kijken. Ik dacht al dat ik gek werd de afgelopen maanden. Kan ik mijn r7000 misschien weer uit de doos halen die klaar stond voor de recycling.

[Edgarz]

Dat is waarschijnlijk opgelost na een factory reset. Kun je direct de nieuwe 382.x/384.x firmware erop zetten :-)

[vlijmen]

Bij mij werden na de xxxx2 update de radio's volledig uitgezet op de AC68U's die als AP ingesteld stonden. Merkte het niet omdat draadloos overal goed genoeg is voor gsm gebruik. Maar met de xxxx4 update van begin deze maand kwam ik er achter en ze dus handmatig weer aangezet. Misschien dat eens checken of er geen settings gewijzigd zijn.

[teus1950]

exact hetzelfde ook met asus rt n66u en philips android tv

[mathijs727]

Zelfde probleem op de Asus RT-AC66U.
Sinds ongeveer een week speelt het probleem elk paar uur op en dan komen er een 3 seconden geen packets meer door.
Vooral leuk wanneer je multiplayer games speelt /s

[GroeneThee]

Idem hier! Zat al te kijken naar een nieuw modem. Kijk het nog wel even aan nu.

Gebruik wel de Merlin firmware.

[Reactie gewijzigd door GroeneThee op 23 juli 2024 22:22]

[SirLenncelot]

Of dit hetzelfde probleem is weet ik niet. Hier ook veel problemen gehad met WiFi nadat ik mijn Chromecast weer ging gebruiken. Steeds deed ofwel de 2.4 ofwel de 5 GHz band het. Omdat niet al mijn apparaten 5Ghz ondersteunen heb ik deze maar uitgeschakeld. Niet echt een lange termijn oplossing, maar voor nu prima.

Overigens icm een experiabox modem/router.

[Reactie gewijzigd door SirLenncelot op 23 juli 2024 22:22]

[supersnathan94]

Is het dan niet een idee om de chromecast juist wel op die 5GHz band te zetten met een ander SSID? Zit je wel in hetzelfde netwerk, maar dan via andere AP. Kan die 5GHz er lekker uitklappen zonder dat je er last van hebt.

[aryan1171]

Huh... Ik heb een Airport Extreme en een Sitecom WL-309 die constant wegvallen (Bij de Airport 5Ghz en bij de Sitecom weet ik het niet zeker; nooit opgelet.). Ik heb bij de Airport Extreme een stukje gevonden over hoe spaties en speciale tekens in de SSID voor problemen kunnen zorgen maar dit had ik echt niet verwacht. Ik heb mijn Chromecast losgekoppeld en wacht nu om te kijken of de 5Ghz weer wegvalt. Het valt me ook op dat het meestal ergens in de nacht gebeurt. Als ik ik wakker wordt zie ik meestal dat mijn telefoon constant probeert te verbinden met WiFi wat natuurlijk niet lukt

[supersnathan94]

De extreme wordt standaard geconfigureerd met spaties in de naam. Dat kan ie wel hebben hoor. Alleen spaties op het einde is een probleem. Dat is meer omdat je die niet ziet en het net lijkt of het allemaal klopt.

[Anoniem: 1027729]

Heb inmiddels 4 monteurs van kpn over de vloer gehad en heb inmiddels wel weer tv en internet maar wifi valt continu weg... gaat nu ongeveer al een maand zo het schijnt idd teidelijk te helpen als je 5g uit zet.. komt idd door een foute update van kpn/telfort alle expiria boxen hebben er bijna last van.. vind het echt tegenvallen dat het nog niet is opgelost..

[Mayonaise]

Laatste tijd valt de wifi van mijn Archer c50 ook regelmatig uit. Dit sinds ik ben overgeschakeld van een iPhone naar een Oneplus 5t.

Heb momenteel geprobeerd om de breedte van de 5Ghz kanaal te verkleinen, ben benieuw of het helpt. Want had deze probleem ook met de 2.4Ghz kanaal en de iPhone, de breedte verkleinen had geholpen. Volgende oplossing die ik ga uitproberen is IPv6 uit zetten.

[Bouddieehh]

Hey Fareeb,

Ik heb hier ook last van sinds ik Android TV heb. Ik gebruik het alleen niet. Weet jij of chromecast uit te schakelen is?

[Fareeb]

Ik weet eerlijk gezegd niet of dat uit te schakelen is. Heb je bij instellingen gekeken op je tv? Volgens mij zie je daar de cast opties tussen staan en wellicht kan je het daar ook uitschakelen.

[Bouddieehh]

Settings > Apps > Google Cast Receiver > Disable

Zou moeten werken, ik ga het testen.

[DenOkster]

Ik heb dus de laatste tijd dat mijn 5Ghz band van mijn modem steeds uitvalt.

[Anoniem: 1028015]

Heb hetzelfde probleem met mijn TP-Link Archer C7.

[Barryke]

Ik zie hetzelfde met een Asus RT-AC3200 ..een van de 2 5GHz banden klapt er soms even uit..

[Sandwalker]

Jammer dat de fout erin zit. Goed dat de software geupdate kan worden. Een chromecast is niet echt iot. Maakt meteen ook duidelijk dat er voor iot apparaten met een lange levensduur ook nog wat geregeld moet worden voor softwareupdates na twee jaar

[Caelestis]

De fout zit niet in de chromecast maar in de routers. Een dDOS zoals dit onzin zou eigenlijk niet mogelijk moeten zijn in moderne routers. Leuk dat je de cast zou willen fixen maar daarmee heb je nog steeds een kwetsbare router die dan makkelijk door iets anders de nek om gedraaid kan worden.

En nee een chrome cast is geen IoT device en zal het ook nooit worden. Per definitie is een IoT device iets wat niks met de mens te maken heeft dus zodra jij ook maar iets met dat ding kan doen als mens is het geen IoT meer.

[Bor]

Deels heb je gelijk. Het is overigens een DOS ipv een dDos in dit geval. Een router zou niet kwetsbaar moeten zijn voor een enkel WIFI device dat te veel packets stuurt. Het issue duurt overigens niet even lang als er te veel packets worden verstuurd maar in de praktijk veel langer. In meerdere gevallen lijkt het noodzakelijk om de router te rebooten of WIFI aan en uit te schakelen.

Een router die kwetsbaar is in dit geval krijg je blijkbaar vrij simpel over stuur. Dat is thuis erg lastig maar wat te denken aan publieke WIFI punten of zelfs bedrijfsnetwerken?

[kuurtjes]

Het is onmogelijk voor een router om een enkel WiFi device te blokkeren tijdens een DoS aanval. Als je je wilt gaan beschermen daartegen, moet je elke keer als het device voor verbinding vraagt, een berekening uitvoeren om te zien of dit device geblokkeerd moet worden. Dit opzich kan de DoS zijn. Daarom is het uiteindelijk bij het WiFi device zelf.

Of de router moet een fysieke actie gaan doen, zoals de LAN poort blokeren, of de Wifi tijdelijk uitzetten, maarja, dan heb uiteindelijk hetzelfde probleem.

[PPie]

Als je je wilt gaan beschermen daartegen, moet je elke keer als het device voor verbinding vraagt, een berekening uitvoeren om te zien of dit device geblokkeerd moet worden.

Klinkt als een triviale packet counter per client.
Simpel om daar een threshold bij te maken en daar een actie aan te hangen, zoals het device een dissassociation message sturen?

[kuurtjes]

Sorry, maar tegen een DoS aanval kan een router niets beginnen. Alleen op Layer 7 zou de router kunnen helpen. En dus niet op L2 of L3 zoals waarschijnlijk hier het geval is.

[Caelestis]

Uhm routers werken op L1-2-3 niet op L7

[Bor]

Uhm routers werken op L1-2-3 niet op L7

Een pure router werkt op layer 3 van het OSI model. Layer 1 is de fysieke laag, daar heeft een router in feite niets mee van doen. Layer 2, datalink, is waar schitches opereren.

[Caelestis]

Dat klopt helemaal maar een router kan meerdere onderdelen bevatten zoals een hub voor modem link (L1) en switch voor Lan (L2). Dus om te zeggen dat een router op alle drie kan werken is niet feitelijk onjuist tenzij je het definitie van "router" als los staand onderdeel wil beoordelen.

[Johan9711]

Aangezien meeste routers tegenwoordig een ingebouwd access point en switch hebben kan je gerust stellen dat het op layer 1, 2 en 3 opereert.

[kuurtjes]

Alleen L7 aanvallen, die gebaseerd zijn op de uiteindelijke L7 applicatie, kunnen in theorie onderschept en afgeweerd worden door routers. L7 gaat nog steeds via alle onderliggende layers. Daarom zeg ik dan ook dat tegen een DoS aanval op L2 of L3 een router niets kan beginnen... De lijnen lopen gewoon vol, en dat is niet iets wat "fout" is aan routers.

[Bor]

Alleen L7 aanvallen, die gebaseerd zijn op de uiteindelijke L7 applicatie, kunnen in theorie onderschept en afgeweerd worden door routers.

Waaruit concludeer je dat het hier om een L7 aanval gaat? Dat lijkt namelijk helemaal het geval niet te zijn. Voor zover bekent is gaan de routers gewoon over hun nek door het aantal packets. Dit zou je ook zonder Chromecast kunnen bewerkstelligen.

[kuurtjes]

Nergens concludeer ik dat het om een L7 aanval gaat. Dat is ook mijn punt niet. Ik bedoel dat een router niet tegen L2 of L3 gaat kunnen beschermen.

@Caelestis zei: "De fout zit niet in de chromecast maar in de routers."

Dat is dus niet juist. Een router kan zichzelf gewoon niet tegen L2 of L3 beschermen.

Het enigste wat IN THEORIE een router wel kan, is op L7 gaan beschermen. Niet dat ze het doen, maar dat is het enigste waar wel beschermd kan worden als je je router iets tegen DoS wilt laten doen.

[Reactie gewijzigd door kuurtjes op 23 juli 2024 22:22]

[PPie]

Een router kan zichzelf gewoon niet tegen L2 of L3 beschermen.

De router kan packets droppen op L2 en L3 en voor TCP op L4 het window verkleinen.
Als het een access point is kan het device meer doen, waaronder het spammende device wippen door een dissassociation message te sturen naar de spammer.
Een router zal niet iets op L7 kunnen.

Het originele probleem lijkt een probleem in de Google applicatie die niet doorheeft dat de telefoon slaapt, maar wel requests voor blijft queuen, het probleem lijkt inderdaad niet in de Chromecast zelf te zitten.

[DenOkster]

Layer 7, een router, lol bij jou zit ie denk ik op layer 8.

[kuurtjes]

Tjah, dan moet je wel begrijpen wat ik bedoel.

[DenOkster]

Routers weken niet op de application layer van het OSI model.

[kuurtjes]

Daarmee dat het ook niet een fout is dat ze niet tegen DoS beschermt zijn. Alleen als je L7 wel gaat onderscheppen kan je iets of wat tegen DoS doen. Maar dat was dan ook niet mijn punt.

[Gwaihir]

Is dat niet een beetje zwart-wit? Er hoort 20s tussen te zitten, dus 100.000 pakketten ineens is meer dan 3 weken aan berichtjes in één klap verstuurd. Dan zitten die devices óók fout, los van hoe de router ermee om gaat.

En dat is geen dDOS, want van één device. Hier ontstaat een zo langzamerhand een nieuw aandachtsgebied voor consumenten routers: de devices op het netwerk zijn steeds minder te vertrouwen (door o.a. bugs en hacks voor botnet gebruik). Hoe daar goed mee om te gaan? Jan-met-de-pet gaat het ook niet gelijk snappen als devices er automagisch afgekegeld worden..

[GeroldM]

Of bouw de mogelijkheid in dat de Google cast apparaten niet in "slaap" vallen. Ook niet geweldig als oplossing (of zelfs als work-around), maar dat zou de meest simpele pleister op de wond zijn.

[PPie]

Het lijkt niet het Chromecast device te zijn wat slaapt, maar een telefoon die wil weten dat de Chromecast die ooit gezien is, nog steeds beschikbaar is.

[Finraziel]

Toch op zijn minst in beide apparaten dan hoor... dat een router onderuit kan gaan als deze geflood wordt... tja, ok, zou beter zijn als dat niet gebeurde. Maar eigenlijk vind ik het apparaat dat begint te flooden erger, als het daar niet voor ontworpen is.

[jozuf]

Weinig ddos, aan. Het is niet distributed. Zoals hierboven gezegd is dit een dos.

[WhatsappHack]

Behalve als je meerdere apparaten hebt die wakker worden en dan hetzelfde trucje uithalen. Eg, jij zet je TV aan en dan wordt je Chromecast wakker en je Home reageert erop. Je telefoon vangt een pakketje op en wordt ook wakker. Alle drie gaan ze vlak na elkaar packets flooden door de firmware bug. Dan is ‘t wel distributed en flink ook voor lokale begrippen.

[Anoniem: 1026227]

Niet waar wat je zegt. Een koelkast, wasmachine of TV (mits voorzien van connectivity en bij deze ook met een AI assistent) maken wel degelijk onderdeel uit van een IOT netwerk. Je kunt via je koelkast je TV aanzetten, je airco hoger zetten of bv je auto laten voorrijden.

[batjes]

De meeste consumenten routers zijn vrij simpel plat te leggen. Juist een DOS is de meest makkelijke manier. De duurdere routers hebben hier wel bescherming tegen (meestal in de vorm van: voldoende resources), maar het goedkope grut wat 9/10 huishoudens thuis heeft staan echt niet. Wifi, bekabeld, maakt niet uit. Overspoel dat ding met packets en 9/10 routers klapt onderuit of loopt zo goed als vast.

Het is meestal gewoon een gebrek aan kracht of geheugen wat er in die krengen zit, dus moet het opgevangen worden met allerlei exceptions, wat ze nu waarschijnlijk ook doen "if honderdduizendmiljoen castpackets within X time > drop".

En ze kunnen niet elke package flood zo maar in de exception gooien want genoeg legitiem dataverkeer wat zich ook zo gedraagt en dus mogen ze voor elke situatie apart exceptions gaan uitvoeren.

Het probleem ligt bij Google's cast, niet bij de routers (of naja, de meeste mensen willen een zo goedkoop mogelijke router)

[Caelestis]

En als het "probleem" in de chromecast is gefixed wat houdt het volgende apparaat tegen om hetzelfde "aanval" uit te voeren? En nieuwe EU wetgeving die zegt "foei mag je niet meer doen"?
De chromecast is het symptoom en de router is het probleem.

[batjes]

Voor elk soort packetspam mogen ze aparte exceptions gaan inbouwen. Het houdt niet op, er komen meer protocollen bij dan dat ze kunnen patchen. En een catch all voor alle packet spam werkt niet want er is genoeg legitiem verkeer wat er op lijkt.

Het probleem is niet zo zeer dat de router vol bugs zit. Maar meer dat de meeste routers zo'n burst packetspam niet aan kunnen en gewoon vast lopen door gebrek aan CPU kracht of RAM geheugen.

Nog geen 2 weken geleden was er een vergelijkbaar bericht met 1 of ander apparaat wat op een andere manier het wifi netwerk vol zat te spammen waardoor een boel routers onderuit gingen.

Zolang we voor een duppie op de eerste rang willen zitten, zal dit zich blijven voordoen.

[Caelestis]

Dan is er een andere vraag. Is het een probleem als de cast het "aanval" uitvoert en je router kan het wel zonder enige probleem aan en je er verder niks van merkt? Is het dan "working as intended"?

[batjes]

De router krijgt die packets gewoon binnen, naar mijn mening moet een router die packets enkel routeren. Niets meer, niets minder. Die zou dat juist niet in de gaten moeten houden "He, dit spamt als een malle, mag niet". Als je dat automatiseerd ga je gewoon gegarandeerd op problemen uitlopen.

Van goedkope chineze import hardware is het niet zo erg dat het zich niet aan protocollen houdt. Van Google mag je toch wel verwachten dat het zijn verantwoordelijkheid neemt om op nette manieren gebruik te maken van internet en netwerken.

De huidige fix is -waarschijnlijk- een specifieke regel voor deze situatie waar nu packets gewoon gedropt worden. Working as intended, of work-around?

[Caelestis]

in dit geval gaat het om mDNS dus de router hoeft niks te routen. Het gaat om hostname discovery dus het fix zal inderdaad iets zijn van packet drops op port UDP 5353. Ben alleen erg benieuwd of dat fix dan niet gelijk alles wat gebruik maakt van mDNS tergend traag maakt of dat er een verschil tussen ipv4 en ipv6 implementatie is.

[WhatsappHack]

Common sense. Men kent de internet specificaties en weet hoe het werkt en wat de beperkingen zijn. Als je apparaat uit het niets honderd duizenden pakketjes per seconde gaat versturen dan is het gewoon kak ontworpen en op dat moment geen haar beter dan bijvoorbeeld een udpflooder.

Dat is een zwakte van het protocol, en een apparaat dient zo geprogrammeerd te zijn dat ie enkel doet wat ie moet doen in plaats van zo gestoord veel pakketjes te flooden. Het probleem ligt dan ook inderdaad bij het apparaat dat de flood uitvoert, niet aan het medium.

[Zer0]

En nee een chrome cast is geen IoT device en zal het ook nooit worden. Per definitie is een IoT device iets wat niks met de mens te maken heeft dus zodra jij ook maar iets met dat ding kan doen als mens is het geen IoT meer.

Alledaagse voorwerpen worden hierdoor een entiteit op het internet, die kunnen communiceren met personen en met andere objecten, en die op grond hiervan autonome beslissingen kunnen nemen.
Dat is IoT

[Caelestis]

Internet of Things is een netwerk van apparaten dat zonder tussen komst van de mens autonome beslissingen kunnen maken. Zodra de mens een factor wordt is het gewoon internet of people.

[bskibinski]

Kun jij aangeven waar in de definitie van iot wordt gezegd dat het compleet zonder tussenkomst van mensen moet zijn? Of is dat je eigen interpretatie?

https://en.m.wikipedia.org/wiki/Internet_of_things

Als ik dit zo lees,
The Internet of things (IoT) is the network of physical devices, vehicles, home appliances and other items embedded with electronics, software, sensors, actuators, and network connectivity which enables these objects to connect and exchange data.[1][2][3] Each thing is uniquely identifiable through its embedded computing system but is able to inter-operate within the existing Internet infrastructure.

Onder applications wordt de nest genoemd, en smart verlichting, producten die aan te sturen zijn door mensen.

Ze kunnen soms ook autonoom beslissing en maken, of data delen met andere iots, maar om volgens de definitie iot genoemd te mogen worden moet het apparaat benaderbaar zijn via het internet (door mens of machine).

Vandaar dat het 'internet of things' heet en niet het 'autonomous network of things'

[Reactie gewijzigd door bskibinski op 23 juli 2024 22:22]

[bskibinski]

Het gaat erom dat het volledig autonoom werkt.

Nogmaals, is dit je eigen interpretatie, of kan jij mij de definitie tonen waar je dat vandaan hebt?

Ik heb hier zelf een nest en Philips hue verlichting. En deze werken deels autonoom, maar je blijft ze ook handmatig bedienen, als je het net wat warmer wilt hebben, of een andere kleurschema wilt hebben, etc. En toch zijn dit ook iot apparaten, zelfs al zet je het hele autonomen gedeelte uit, blijven ze benaderbaar via het internet, en dus een iot.

Maar ik laat me graag corrigeren als je een bron kan tonen die je statement kracht bij zet, dan kunnen we Wikipedia ook gelijk corrigeren

[Caelestis]

dan kunnen we Wikipedia ook gelijk corrigeren

Ik hoop dat je begrijpt dat als je de mogelijkheid heb om je "feiten" aan te passen naar wens het nooit feiten waren om mee te beginnen.
Niet dat wiki altijd fout zit maar ook lang niet altijd goed. Ik hecht daarom nogal weinig waarde aan argumenten die alleen wiki als hun bron materiaal gebruiken.
Als jou ervaring met je nest en hue jou beeld schetsen van wat nou precies IoT is ben je dan niet schuldig aan hetzelfde waarvan je mij beticht? Jouw artikel gaat namelijk alleen over het zelf lerende aspect van de nest AI en niet over hoe jij het bediend.

[bskibinski]

"Mijn artikel" gaat over de definitie van iot, met als daarin de nest als 1 van de voorbeelden. Wiki is ook niet de bron, de bronnen in het wiki artikel zijn de bron.

Ik beticht je nergens van, ik vraag aan je waar jij je definitie van iot vandaan haalt, iets waar je de hele tijd geen antwoord op geeft.

Ik geef juist zelf aan dat ik het misschien fout heb, ik besef mij zeer goed dat wiki artikelen fouten kunnen hebben, vandaar dat ik aan je vraag hoe je aan die definitie komt, zodat we een eventuele fout uit Wikipedia kunnen halen.

Edit:
En ik heb het voor de rest nooit gehad over dat mijn ervaringen met nest bepalen wat voor mij een iot is. Het aangehaalde stukje uit Wikipedia uit mijn eerste commentaar is waar ik mij op baseer.

[Reactie gewijzigd door bskibinski op 23 juli 2024 22:22]

[bskibinski]

Jij bent een mooie! Nu draai je het om Om even jou te quoten uit je eerdere comments, blijkbaar ben je dat vergeten:

Per definitie is een IoT device iets wat niks met de mens te maken heeft dus zodra jij ook maar iets met dat ding kan doen als mens is het geen IoT meer.

en daarna:

Internet of Things is een netwerk van apparaten dat zonder tussen komst van de mens autonome beslissingen kunnen maken. Zodra de mens een factor wordt is het gewoon internet of people.

Waarop ik als eerste aan je vroeg:

Kun jij aangeven waar in de definitie van iot wordt gezegd dat het compleet zonder tussenkomst van mensen moet zijn? Of is dat je eigen interpretatie?

Vervolgens draai je om de concrete vraag heen en draai je het zelfs om dat mijn interpretatie niet goed is? Dat terwijl ik helemaal geen interpretatie heb gegeven, alleen de beschrijving uit het wiki artikel, die zelf als voorbeeld een Nest aandroegen als voorbeeld van een IoT device, waarvan je weet dat daarmee menselijke interactie mogelijk is, en dus volgens jou definitie geen iot device zou mogen heten.

Dus nog een keer de vraag:
Waar in de definitie van IoT staat dat:
"Per definitie is een IoT device iets wat niks met de mens te maken heeft dus zodra jij ook maar iets met dat ding kan doen als mens is het geen IoT meer.".
Ik kan dit namelijk nergens, maar dan ook nergens terug vinden.

En mocht jij het wel ergens kunnen vinden, dan hoor ik het graag, want dan heb ik en ik denk vele met mij IoT verkeerd begrepen.
edit typo en laatste onnodige zin weg.

[Reactie gewijzigd door bskibinski op 23 juli 2024 22:22]

[bskibinski]

Ik maak geen aanname en heb geen definitie.

Jij claimt wel dit: "Per definitie is een IoT device iets wat niks met de mens te maken heeft".
Laat me zien waar je dit vandaan haalt. Zoniet, dan geloof ik je niet.

[Caelestis]

https://www.itu.int/rec/T-REC-Y.2060-201206-I
Er zit geen nederlandtalig versie bij dus zal je het moeten doen met engels
Ik wens U heel veel lees plezier.

[macdoggie]

In dat document staat notabene op pagina 3 figuur 1 human to human en human to thing communication genoemd.

Ik heb geen zin om het hele document door te nemen, maar als je even zou kunnen aangeven op welke bladzijde staat dat er geen mens aan te pas kan komen zou fijn zijn.

Ik lees ook dit:
NOTE – Human body related services refer to the services provided by capturing, communicating
and processing the data related to human static features and dynamic behaviour with or without
human intervention.

[Reactie gewijzigd door macdoggie op 23 juli 2024 22:22]

[Caelestis]

reactie op je edit-
Human static features = Oftewel zaken als vinger afdrukken, gezichts herkening, warmte patroon oftewel alles wat jou unique maakt
Dynamic behaviour = Jou gedragspatroon

Simpel voorbeeld hoe je dit moet zien. IoT camera scant gezichten op een vliegveld en het systeem gaat automatisch verdachte personen flaggen om apart te nemen.

heb je ook het volgende gelezen?

– Autonomic networking: Autonomic networking (including self-management,
self-configuring, self-healing, self-optimizing and self-protecting techniques and/or
mechanisms) needs to be supported in the networking control functions of the IoT, in order
to adapt to different application domains, different communication environments and large
numbers and types of devices.
– Autonomic services provisioning: The services need to be able to be provided by capturing,
communicating and processing automatically the data of things based on the rules
configured by operators or customized by subscribers. Autonomic services may depend on
the techniques of automatic data fusion and data mining.

[WhatsappHack]

“based on the rules configured by operators or customized by subscribers.”

‘Nuff said. Er is dus interactie mogelijk met de mens en dan is het alsnog een IoT-device.

Ik ben ook benieuwd hoe je het anders wou doen, die dingen moeten toch echt ingesteld worden wil het exact doen wat je wilt. Dat ze na het instellen naar wens zo autonoom mogelijk werken, en in de ideale situatie nooit meer directe interactie nodig hebben, is een heel ander verhaal...

[Reactie gewijzigd door WhatsappHack op 23 juli 2024 22:22]

[WhatsappHack]

Dat document spreekt jou claim dat niets IoT kan zijn als een mens het apparaat (“thing”) kan bedienen/aanpassen absoluut tegen.
Ik heb het vage idee dat jij de kop “manageability” op pagina 12 verkeerd hebt geïnterpreteerd en daaruit je overtuiging voor die stelling ontleent. En toegegeven staat het ook nogal vaagjes omschreven.

In het totaalplaatje komt het er op neer dat een IoT device autonoom moet kunnen werken zonder interactie met de mens, maar dat de mens het apparaat wel moet kunnen instellen. De noodzaak voor de mens om actie te ondernemen moet daardoor omlaag gebracht worden. Dus ja, een Nest is een prima voorbeeld. Die leert zelf wat je waarschijnlijk t fijnst vindt qua schema en leert van je - zo hoef je minder vaak de verwarming aan te zetten of juist uit/lager/hoger. Of een Google Home kan ervoor zorgen dat je lampen van kleur veranderen zonder dat jij je lekkere biefstuk alleen achter moet laten in de keuken terwijl je hond ernaar zit te loeren: en doe je dit elke dag rond 6 uur? Dan gaat ie dat vanzelf doen door wat ie leert óf geleerd heeft van je andere IoT-enabled devices.

Een kern van IoT is dus juist wel dat het door een mens bediend moet KUNNEN worden, maar dat ze over t algemeen autonoom moeten kunnen werken (al dan niet na een leercurve.). Uiteraard zijn er ook devices die nooit interactie nodig hebben. Bijvoorbeeld een sensor in je buiten brievenbus die doorgeeft aan je smartphone dat er post gedecteerd is. Die hoef je alleen maar uit/aan te kunnen zetten en zal verder altijd autonoom opereren, geen verdere interactie nodig. Maar een apparaat dat wel interactie KAN krijgen of soms zelfs nodig heeft kan wel degelijk onder IoT vallen. (Dus ook thermostaten, koelkasten, beveiligingssystemen, noem het maar op.)

Daarnaast kan t ook nog zo zijn dat als ik op “thing” B iets instel, dat “things” A, C en F dit oppikken en automatisch een actie ondernemen - of vice versa. Dan is het grotendeels autonoom, maar toch afhankelijk om éérst menselijke input te krijgen. Het een sluit het ander niet uit, maar het mooie is wel dat jij enkel op B iets hoeft te doen en niet all vier de handelingen zelf hoeft uit te voeren. Het is eigenlijk gewoon onderdeel van domotics wat dat betreft.

De menselijke input is dus niet per definitie noodzakelijk, maar het is ook niet verplicht dat deze afwezig is voordat iets een “thing” genoemd mag worden - sterker nog: het is verplicht dat voor bepaalde zaken menselijke interactie mogelijk is.

Ik geef iedereen die beweert dat jou stelling “iets dat bedient wordt door de mens kan geen IoT zijn” niet klopt dan ook gewoon gelijk, en het document dat je aandraagt bevestigt dat gewoon.

[Reactie gewijzigd door WhatsappHack op 23 juli 2024 22:22]

[Caelestis]

Als jij als mens niks instelt wat een IoT apparaat moet doen dan heeft het apparaat geen functie. Ik heb het kop manageability niet verkeerd geïnterpreteerd omdat dat er niet toe doet.
Het is een beetje het zelfde soort verhaal van wat is het verschil tussen een drone en een model auto, vliegtuig of helicopter.

Autonomie

niks meer niks minder. Het gaat erom dat er taken uitgevoerd worden zoals het apparaat zelf denkt het uit te kunnen voeren. Taken dat jij als mens niet bediend. En zo ook dus met IoT.

IoT is dat jij je koelkast een opdracht geeft om de melk bij te vullen als er nog 1 karton staat.
IoT is niet dat je op een display op je koelkast de webwinkel van de AH krijgt en zelf de bestelling gaat plaatsen.

IoT is jij stelt jouw NEST in dat het altijd 21 graden in huis is en dat ding aan de hand van weer voorspellingen en sensors je CV gaat aanpassen om zo efficient mogelijk dat temp vast te houden tot zelfs het moment dat hij detecteert wanneer jij je voordeur open doet als je thuis komt van werk en daar op reageert.
IoT is niet dat je zomer modus aan zet op je thermostaat en het uit zet om 23:00 om het vervolgens weer om 5:00 weer aan te zetten.

IoT is als jij je woonkamer kamer in loopt het licht aan gaat en als je de TV aan zet het systeem extra licht detecteert en algemeen licht gaat dimmen.
IoT is niet dat je de kleur van je philips hue dimt en op blauw zet via je NEST kastje.
ect...

[WhatsappHack]

“Als jij als mens niks instelt wat een IoT apparaat moet doen dan heeft het apparaat geen functie.”

Mooi, einde discussie dus. Blij dat je het toch nog met mijn uitleg en die van een paar anderen eens bent. Dan zijn we het er over eens dat een IoT-apparaat wel degelijk interactie van een mens kan en mag krijgen zonder de status “IoT-apparaat” of “thing” te verliezen.

Dat hele gedoe over dat ie daarna zoveel mogelijk autonoom moet doen voor zover dat mogelijk is, is verder volstrekt irrelevant aan de gemaakte stellingen en reeds uitgebreid besproken.

Ironisch is trouwens dat sommige voorbeelden die je zojuist geeft juist prima mogelijk zijn zonder een netwerklaag, wat dus juist wél een vereiste is voor IoT... Een bewegingssensor en een lichtsensor gekoppeld aan een dimmer zijn niet per definitie direct een IoT-apparaat namelijk... Het kan wel, maar het hoeft niet.

Maar goed. Let’s give it a rest, het ging mij puur om die stelling dat niets een IoT-apparaat kan zijn als er een menselijke factor bij betrokken is - daar zijn we het nu over eens dat die stelling niet klopte.

[Reactie gewijzigd door WhatsappHack op 23 juli 2024 22:22]

[Caelestis]

Einde discussie tja prima als jij dat wil, maar nee jij krijgt echt geen gelijk door woorden te verdraaien. Als het concept IoT teveel gevraagd is voor je is dat niet mijn probleem om te fixen.

[WhatsappHack]

We waren het al eens dat de interpretatie van mij en alle anderen die hetzelfde zeggen klopt, wat ook bevestigd wordt door alle bronnen inclusief je eigen documentje, en er is geen woord aan verdraait. Dat ik en de anderen gelijk hebben staat dus niet ter discussie, maar als je ‘t beter denkt te weten dan iedereen: prima, vooral volhouden.

Dat jij niet kan toegeven dat je gewoon een onjuiste stelling hebt geponeerd is prima, maar ga je frustratie niet afreageren op alle mensen die je 100% terecht corrigeren vanwege je stelling die niet klopt omdat je het zelf verkeerd had begrepen of verkeerd verwoord had. Geeft niet, foutjes zijn menselijk - rustig maar hoor. Het is echt geen ramp en je kan ‘t rustig toegeven en er een leermoment van maken.

Ik kap er verder mee, proved my point - fijn weekend verder!

[Reactie gewijzigd door WhatsappHack op 23 juli 2024 22:22]

[chezzorilla]

Ik heb dit probleem ook gehad, vooral heel storend bij streamen van muziek. Moest ik steeds naar boven (waar mn mediaserver draait) om weer contact te maken met mn WiFi. Ik zag in mn netwerk ook apparaten die er volgens niet in thuishoren zoals een Technicolor AP. (wat volgens mij iets te maken heeft met mn Chromecast?) Van alles geprobeerd, van firewall tot nieuwe firmware voor mn Linksys router. Vinkjes bij energiebesparing van netwerkkaart uitgezet, streaming instellingen op die kaart geoptimaliseerd, andere virussoftware. Dit alles in het gekmakende Windows 10, waar 'automatisch verbinden' niet betekent dat de WiFi automatisch weer verbindt als hij eraf ligt. Inmiddels een nieuw draadloos modem van Ziggo. Dat haperde nog even, maar nadat ik het een meter heb verplaatst (uit de buurt van het Ziggomodem van de buren) werkt het nu alweer een week als een zonnetje. Niet een keer hoven te verbinden. Fingers crossed.

[Reactie gewijzigd door chezzorilla op 23 juli 2024 22:22]

[GeroldM]

AP zal naar alle waarschijnlijkheid staan voor Access Point. Heb jij of je buurman/buurvrouw zo'n apparaat in je netwerk? Deze kunnen namelijk ook broadcasten als een tierelier, mits deze niet goed of onvoldoende zijn geconfigureerd.

En als het verplaatsen van je WiFi doos al helpt, dan is je WiFi netwerk onbewust maar wel degelijk knullig opgezet.

Heel simpel gesteld: in principe zijn WiFi doosjes niet veel anders dan kleine radio-zenders en als deze te dicht bij elkaar staan dan gaan ze elkaar overstemmen. Radiozenders kunnen niet alleen fysiek te dicht bij elkaar staan, maar ook in hun zendgebied. Het eindresultaat is altijd hetzelfde, jij en je buurman/buurvrouw hebben een slecht functionerend WiFi netwerk. En gaan extra WiFi apparatuur aanschaffen zodat het gebied waar deze WiFi netwerken elkaar overstemmen alleen maar uitbreiden.

Let wel, dit gebeurt meestal geheel onbewust.

Dit komt omdat wanneer een WiFi apparaat word ingeschakeld het op zoek gaat naar het eerste vrije kanaal waarover je WiFi signalen worden verstuurd. Dirt is de standaard instelling, en deze is zo ingesteld omdat dit makkelijk is voor de eindgebruiker. En als je in een alleenstaand huis woont, zonder enige andere stoorzenders, dan is het ook het meest makkelijke.

Woon je echter in een flat, rijtjeshuis of staat je "alleenstaande" woning toch wel erg dicht bij een andere "alleenstaande" woning, dan is die default instelling een van de stomste dingen die je kan toepassen in een WiFi netwerk.

Er zijn namelijk maximaal 13 kanalen voor het versturen/ontvangen van WiFi signalen (legaal 12, maar goed). Voor goede distributie van WiFi signalen zijn er effectief maar 3 kanalen waar je uit moet kiezen. En dat zijn de kanalen 1, 6 en 11. Waarom dat zo is, is niet zo snel uit te leggen. Je zou wel op moeten merken dat er steeds 5 "lege" kanalen tussen elk goed kanaal zit.

Pas je alleen deze kanalen toe in je WiFi netwerk, dan zul je gauw opmerken dat de reikweidte en stabiliteit van jouw WiFi netwerk behoorlijk toegenomen is. Zelfs met goedkope consumenten WiFi apparatuur. En dat allemaal gratis en voor niks.

Echter, als de buurman/buurvrouw nog steeds de automatische kanalenkiezer blijft gebruiken, dan is de toenname in reikweidte en stabiliteit wel een stuk minder. Maar als hij/zij ook alleen uit deze drie kanalen kiest, dan neemt het bereik en stabiliteit in zijn/haar WiFi netwerk ook toe. Heeft hij/ zij ook een buurman/buurvrouw met WiFi netwerk, dan moet die persoon ook meedoen, enzovoorts.

Zorg dat er altijd minstens 5 "lege" kanalen tussen elk WiFi apparaat zit, waanneer deze (te) dicht bij elkaar zijn geplaatst, want radiosignalen geven nu eenmaal helemaal niets om legale grenzen tussen terreinen.

Misschien is een klein voorbeeld makkelijk: stel jouw WiFi router van Ziggo in op kanaal 1, de buren stellen hun Ziggo WiFi geval in op kanaal 6 en beide apparaten kunnen weer terug de meterkast in, zonder dat ze op elkaar storen.

De automatische kanalenkiezer die in het leven is geroepen om WiFi configuratie zo makkelijk mogelijk te maken heeft dus nog een positief (voor de maker/verkopers van WiFi apparaten) neveneffect. Mernsen blijven maar WiFi apparaten kopen, terwijl dat in principe niet (of veel minder) nodig is als er maar meer mensen een beetje inzicht hadden gehad in hoe radiosignalen zich gedragen.

[S0epkip]

2.4ghz zit gewoon vol tegenwoordig, daar doe je niets aan, behalve verhuizen naar het platteland.

[martinors]

Juist!

[nils83]

Sonos heeft hetzelfde, sommige modellen sturen zoveel packetjes dat je netwerk tergend traag wordt. De Connect Amp heeft dit bvb en het is nog steeds niet opgelost. Met een moderne firewall kan je dit wel afblocken zonder dat de werking in het gevaar komt.

[Bor]

Dat is een heel ander euvel. Het gaat in het geval waar het nieuwsitem over spreekt niet over traagheid maar over het compleet uitvallen van de WIFI verbinding. Daar zit een wezenlijk verschil.

[WhatsappHack]

Toch kan een Sonos dat probleem dan ook veroorzaken als die inderdaad ook de facto een (D)DoS aanval uitvoert, zeker op goedkopere ap’s die doodleuk herstarten als ze teveel voor hun kiezen krijgen is dat niet ongehoord. De een wordt traag/freezed even, de ander herstart/re-init waardoor je hele wifi even wegvalt.

[TJRef]

Is er een manier om het zelf te testen? Ik heb de Nvidia Shield TV, vraag me af of dit ook hierop van toepassing is. Of geldt dit alleen voor deze apparaten die via WiFi verbonden zijn?

[Reactie gewijzigd door TJRef op 23 juli 2024 22:22]

[AlbanVE]

Ik heb een vermoeden van wel, heb al enkele maanden het probleem dat in dit artikel beschreven wordt. Heb zelf een Nvidia Shield, verbonden met de LAN, maar af en toe gaan de iphones hier er van tussen op de wifi. (Ubiquiti AC LR) Als je dan terug verbinding wil maken vraagt de AP achter het wachtwoord, wat nooit zou mogen gebeuren. Heb me al suf gezocht (als je je 4G continue hebt opstaan zoals ik, kun je wel eens schrikken als je abbo er bijna volledig door is op een uurtje...), maar het probleem is moeilijk te reproduceren. Bij mij gebeurt het wel regelmatig s'avonds, maar wat de reden daarvan is...

[Cuball]

Ik heb ook een TP-LINK AC1200 en heb deze vorige week terug gestuurd omdat ik net deze problemen ondervond (en ik kon er absoluut geen verklaring voor geven, van alles geprobeerd... als cadeau enkele grijze haren erbij gekregen) .

Nu lees ik op het forum van TP-Link dat er personen zijn met net dezelfde problemen als bij mij thuis.

Ik ben benieuwd wat ze met m'n toestel gaan doen... Die laatste beta firmware heb ik helaas nog niet kunnen testen..

http://forum.tp-link.com/...dies-after-a-little-while.

[Appelkoekje]

Precies hetzelfde Cuball. Heb mijn AC1200 maar omgeruild voor een andere router van een ander merk. Ik was er echt van overtuigt dat het een hardwarematig probleem was.

[Reactie gewijzigd door Appelkoekje op 23 juli 2024 22:22]