Universiteit Groningen: Android-telefoons veroorzaken wifi-problemen - update

De langdurige wifi-problemen bij het Eduroam-netwerk van de Rijksuniversiteit Groningen zijn het gevolg van Android-telefoons van studenten. Met name Android-smartphones van HTC en Samsung zouden zo vaak verzoeken richting het netwerk sturen dat dit overbelast raakt.

Sommige Android-mobieltjes van HTC en Samsung versturen meer dan 200 verzoeken per seconde bij het draadloze Eduroam-netwerk van de Rijksuniversiteit Groningen. Het gaat om mobieltjes met de oude Android-versies 4.0.3 tot en met 4.1.2 met daarin een bug. Gevolg is dat het netwerk overbelast raakt en RuG-studenten en -medewerkers geen of een traag werkende internetverbinding krijgen. De problemen spelen al sinds september.

"De servers van de RuG draaien op volle toeren om de stortvloed aan toegangsverzoeken op te vangen, maar dat kan niet eindeloos zo doorgaan", zegt Tom Kuipers, afdelingshoofd netwerkinfrastructuur bij het Centrum voor Informatie Technologie of CIT van de RuG. Bij de servers van het CIT melden zich dagelijks meer dan 10.000 smartphones en tablets en over heel september en oktober lag dat aantal op 52.000 unieke mobiele apparaten.

Het Centrum probeert de desbetreffende Samsung- en HTC-smartphones te isoleren op het netwerk en roept gebruikers met die modellen op om hun toestel regelmatig in vliegtuigmodus te zetten om het netwerk te ontlasten. Daarnaast wil de universiteit met Samsung en HTC om de tafel om de problemen op te lossen. "We kunnen de desbetreffende leveranciers niet verplichten deze bug op te lossen, maar we kunnen wel druk op ze uitoefenen om de fout nader te bekijken en uit de wereld te helpen", zegt Kuipers.

Het probleem is in het verleden al aangestipt door de Universiteit van Princeton, die vergelijkbare problemen had. In Nederland kampten de netwerken van de Universiteit Twente en de Universiteit van Amsterdam met wifi-problemen, waarbij laatstgenoemde naar iPhones die op het onlangs uitgebrachte iOS 7 draaien als mogelijke oorzaak verwees.

Update dinsdag 08.05: Volgens Gertjan Scharloo, technische netwerkconsultant bij de Universiteit van Amsterdam, zijn er geen wifi-problemen bij het netwerk van die universiteit geweest.

Reacties (203)

[broodplank]

Een toegangsverzoek word aangevraagd als er nog geen verbinding is lijkt me zo. Het grootste probleem is dat er mensen zijn die altijd hun wifi aan hebben staan, die zal continu blijven scannen naar netwerken. Echter is de scan interval makkelijk te beperken de volgende property: "wifi.supplicant_scan_interval". Wat daarnaast ook speelt is dat (veel te veel) mensen de bar slechte stock ROM gebruiken met WPA Supplicant v6, deze is ook sterk verouderd maar word alsnog veel gebruikt, met WPA Supplicant v8 is dit probleem al grotendeels verholpen. Het zelfde geld voor de kernels van stock roms, deze zijn echt bijzonder triest in elkaar geflanst.

Ik heb zelf een S4 (i9505) en toen ik deze net uit de winkel had werd ie ten eerste 95 graden met een benchmark, ten tweede werkte 3 sensoren niet, en ga zo maar door. Gelukkig heb ik er verstand van en heb me eigen AOSP 4.3 (nu bezig met 4.4) gemaakt voor de S4 die veel stabieler is, soepeler, de batterij langer mee gaat en ga zo maar door. Hiermee wil ik dus eigenlijk zeggen dat het probleem met de wifi niet bij Android ligt maar bij de makers van de telefoon. AOSP werkt altijd goed tot er van die troep als TouchWiz, Sense of wat dan ook over heen komt.

Samsung maakt goede hardware maar daar blijft het bij. De software is zodanig triest dat ik daar niet eens over wil beginnen

[Gropah]

Beetje raar hoe het hier allemaal gaat. Vorige week was het nog iOS7, volgende week Windows Phone en de week daarna BlackBerry 10? Persoonlijk vind ik iOS7 nog geloofwaardig, omdat dat een plotselinge verandering was waardoor het veroorzaakt kon worden. Immers vlak daarvoor ging alles gewoon nog goed, of beter gezegd, merkte ik er weinig van als gebruiker. Maar dat het aan deze oude versie's van android ligt vind ik persoonlijk erg raar, want dan zou er toch al heel lang overlast moeten zijn?

[michel2412]

Op de HU lijkt dit niet anders te zijn op het Eduroam netwerk.

[NL-RaVeR]

Ik merkte ook dat die op de HU regelmatig eruit lag of slechte verbindingen had. Als is het voor mij al bijna een jaar geleden dat ik daar voor het laatst ben geweest en dus ruim voordat dit "android" probleem begon...

Snap niet waarom ze aangeven vliegtuigmodus aan te zetten. WiFi uitzetten is genoeg, probleem heeft verder toch niks met 2/3/4G te maken??

[mar-10]

Uit de interne verslaglegging van het CIT:

Wat doet het OS?
De systemen die problemen geven draaien meerdere DHCP clients (dhcpcd's), waarbij alle afzonderlijke clients tegelijkertijd verzoeken afvuren op het netwerk. Dit leidt tot situaties waarin sommige devices meer dan 200 verzoeken per seconde het netwerk insturen, hetgeen de DHCP servers buitengewoon zwaar belast.

De universiteit vraagt gebruikers dus om de vliegtuigmodus aan te zetten zodat alle processen van de DHCP gekilled worden.

[Reactie gewijzigd door mar-10 op 22 juli 2024 13:43]

[Menesis]

Waarom niet vragen of ze simpelweg wifi uitzetten? Dan kunnen ze op 3G of 4G verder =)

[svenvv2]

Ik kan dit probleem reproduceren op een galaxy SII en het uitzetten van de wifi killed de dhcpd processen niet. Alleen een reboot lost de problemen op, al komen ze weer terug op het moment dat ik van AP wissel of de lease verloopt.

[sfranken]

Wifi uitzetten != vliegtuigmodus aanzetten

[DigitaldumpKing]

Wifi is sneller, Er is lang niet overal zo'n goede dekking voor 3g/4g en het gaat van je databundel af terwijl je ook wifi kan gebruiken

[Anoniem: 420148]

Daar heeft de Uni geen last van.

[onox]

Maar niet naar de AP's van eduroam.

[Anoniem: 510390]

Wifi is al jaren ruk op de HU, kom er nog maar weinig (morgen voor het laatst hopelijk) maar ik loop er al 8 jaar en t is zeker 6 jaar geklooi geweest waardoor ik altijd maar een ethernet kabel mee nam voor in de klas, om vervolgens mijn WIFI te delen voor de rest van de klas!

[Kontsnorretje]

Zo ook op het Windesheim College is (of was, ik zit er niet meer op school) dit een probleem met Eduroam.

[kamerplant]

Daarnaast wil de universiteit met Samsung en HTC om de tafel om de problemen op te lossen. "We kunnen de desbetreffende leveranciers niet verplichten deze bug op te lossen, maar we kunnen wel druk op ze uitoefenen om de fout nader te bekijken en uit de wereld te helpen", zegt Kuipers.

Het gaat om mobieltjes met de oude Android-versies 4.0.3 tot en met 4.1.2 met daarin een bug.

Uhm dat lijkt mij dan een kort en helder gesprek. Dit is echt een zwakte van het Android platform, dat updates zo tergend langzaam bij endusers terecht komen. En als die er zijn worden ze lang niet altijd geïnstalleerd.

[Aeternum]

Dat heeft niets te maken met het platform. Maar meer met de eigen distributies van de telefoonbouwers. Google heeft het probleem al lang verholpen en als al die fabrikanten stock android zouden gebruiken speelde het probleem niet.

[kamerplant]

Onder "het platform" versta ik de totale keten. De keten die begint bij Google en eindigt bij de eindgebruiker. Dat Google zelf z'n zaakjes wel in orde heeft doet niet ter zake als elders in de keten een zwakke schakel is.

[sfranken]

Niet helemaal met je eens. Google levert Android op een bepaalde manier af en een OEM (bijvoorbeeld Samsung) gaat dan nog van alles aan lopen passen. Google kent het eigen product niet meer want Samsung heeft erin zitten rommelen; en om precies die reden kan Samsung niet bij Google bitchen als X of Y niet werkt.

Gelukkig heeft Google met de Nexus lijn en Motorola toestellen waar er verder geen OEM tussen zit.

[.oisyn]

Het heeft alles te maken het platform, of eigenlijk met hoe het platform geprofileerd wordt, namelijk als eentje met een open en aanpasbaar karakter. Daaruit volgt direct dat elke fabrikant er lekker mee kan doen wat ze wilt, en dat heeft zowel z'n voordelen als z'n nadelen. Het update-verhaal is een duidelijk nadeel. Ik zeg niet dat de fabrikanten niet meedelen in de schuld, maar het is weldegelijk iets dat je Android aan kunt rekenen. Google had er immers ook voor kunnen kiezen om de touwtjes veel meer in handen te houden (uiteraard deels ten koste van bepaalde voordelen die het platform nu geniet). Ergo, om terug te gaan naar de originele opmerking:een zwakte van het Android platform? Ja.

[Reactie gewijzigd door .oisyn op 22 juli 2024 13:43]

[sfranken]

Gelukkig is dit met 4.3.x al beter; veel OS dingen zitten in "Google Play Services" die Google kan updaten wanneer nodig; dus buiten eventuele fabrikanten/skins om

[edwingr]

Dat heeft niets te maken met het platform. Maar meer met de eigen distributies van de telefoonbouwers. Google heeft het probleem al lang verholpen en als al die fabrikanten stock android zouden gebruiken speelde het probleem niet.

Dan nog heeft het vanalles met het platform te maken. Het platform schept de voorwaarden waaronder dit kan gebeuren. Het is een bijkomend nadeel van de vrijheid die telefoonbouwers hebben om het systeem naar eigen inzicht toe te passen.

[watercoolertje]

Als mensen dat is zouden snappen Maar helaas...

[Leooow]

Dit lijkt me meer het probleem bij HTC en Samsung die de updates zo tergend langzaam verwerken en dat die vaak niet bij de end-user terecht komt.

[mvdejong]

Of de providers, die voor de branded toestellen nog eens moeten besluiten die updates in hun branded versie van het OS te verwerken en uit te rollen naar hun klanten. Dat is vaak ook een tergend traag proces.

[Brummetje]

Eduroam is nooit echt super stabiel geweest... (Hogeschool Utrecht that is)

Heb ook een beetje het idee dat ze maar zo iets roepen.. Eerst was het iOS7, nu weer toestellen van HTC en Samsung. Lijkt erop dat ze geen idee hebben en dat het netwerk gewoon niet stabiel is. En om er dan voor te zorgen dat het lijkt alsof ze iets doen ze maar zo iets roepen.

[Reactie gewijzigd door Brummetje op 22 juli 2024 13:43]

[Anoniem: 120539]

Eerst was het iOS7, nu weer toestellen van HTC en Samsung. Lijkt erop dat ze geen idee hebben en dat het netwerk gewoon niet stabiel is.

Link naar het artikel waar dat inderdaad geroepen werd.

[My Tec Master]

Eduroam in Groningen deed het bij mij altijd lekker. Zowel op de Hanzehogeschool als bij RUG gebouwen. Ik prefereerde dit netwerk dan het Hanze netwerk.

[Rctworld]

Inderdaad, het is een wonder dat mobiele providers er geen last van zouden hebben. Die hebben wat meer android clients dan Eduroam

[Anoniem: 120539]

Mobiele providers doen wat minder met Wi-Fi...
(en daar gaat dit artikel over)

[_Dune_]

Het gaat dan ook hier om WiFi en niet om UMTS/GPRS. De providers gebruiken namelijk geen WiFi.

[Anoniem: 80466]

Maar die gebruiken 3G/4G en niet wifi.

[cadsite]

Ik zou toch denken dat een toestel anders omspringt met WiFi verzoeken dan 2/3/4G verzoeken, neen?

[Rctworld]

Er staat nergens dat de bug alleen optreed bij WiFi alleen dat dit bij Eduroam (wat WiFi) is voor problemen zorgt. Maar het zou inderdaad best kunnen dat 3G er geen last van heeft

[DarRoe]

Ik heb zelf een groot project mogen leiden van het instaleren van een wifi netwerk bestaande uit 32 AP's. Het oude wifi netwerk hier viel ook vaak uit en dit werd meestal veroorzaakt door een android toestel. We hebben dat toen kunnen verhelpen door het wifi netwerk alleen op "g" te draaien in plaats van "n". Wel wat langzamer maar stabiliteit is belangrijker.

[rhk22463]

Klinkt mij bekend in de oren.
Ik gok dat Eduroam veelal CISCO AP's met roaming gebruikt en DHCP + Radius in een bepaalde opzet zoals aanbevolen door de leveranciers.
Dat werkte bij ons bedrijf compleet ruk toen BYOD werd ingevoerd en we zijn iets groter dan RUG als het gaat om WIFI clients
CISCO is maanden bezig geweest en kreeg het maar niet gevonden, van alles aangepast en zelfs zaken als multicast en routers IOS upgrades doorgevoerd (wat heeft dat er mee te maken zeggen wij dan...).
Nu wij echter CISCO AP's vervangen hebben door een ander merk en het WIFI roaming netwerk anders opgezet hebben op een pilot locatie lijken deze problemen verleden tijd.
Specifieke apparaten die voorheen problemen gaven hebben we weten te isoleren door te proben en die mensen kregen niet het benodigde token geinstalleerd voor toegang tot het netwerk. De keuze is dan aan hen : of ze vragen een zakelijke toestel aan dat wordt ondersteund en geleverd door ons, of ze schaffen een eigen toestel aan dat op de lijst met ondersteunde toestellen staat. Doen ze dat niet dan mogen ze alleen via ons interne 3G-netwerk connecten (alleen beschikbaar binnen de vestiging waar ze dan zijn)

[Reactie gewijzigd door rhk22463 op 22 juli 2024 13:43]

[Bor]

Een project met 32 AP's wordt doorgaans niet als erg groot geclassificeerd. Dat aantal zou je zelfs in 1 wat groter gebouw kunnen halen. Met meerdere locaties zit je zo aan dat aantal.

[DarRoe]

Voor een stage project was het wel een uitdaging.

[Trackerfire]

Kan heel goed dat dit een bug is van de genoemde versies. Ikzelf had met mijn HTC One thuis op ons Wifi Netwerk met 4.1.2 altijd last van een constant wegvallende verbinding en niet alleen thuis. Kwam ik bij vrienden of familie en ging daar met dit toestel op 't netwerk, meteen wifi problemen ook bij de andere gebruikers. Sinds de update naar 4.2.2 hebben zowel ik en mijn omgeving geen last meer van WiFi problemen als ik op het netwerk zit met mijn HTC One. Lijkt me een goede zaak om dit met de fabrikanten/Google/Android op te lossen, want het probleem beperkt zich dus absoluut niet tot Eduroam alleen!

[xxtremexx]

Hier met mijn HTC One X ook serieus problemen op mijn WIFI netwerk, als mijn HTC verbinding heeft met het WIFI netwerk kan ik met geen enkel ander apparaat het netwerk op, o.a. mijn Macbook, iPad en een Lenovo laptop weigeren een verbinding op te bouwen. Bij mij is dit begonnen na installatie van Cyanogenmod en helaas nog geen oplossing behalve natuurlijk WIFI uitzetten op One X.

[Nox]

CGM is ondertussen allang bij 4.2.2 dus die zou deze bug niet mogen bevatten.

[rhk22463]

Je geeft zelf denk ik al een mogelijke reden: je Cyanogenmod .
Draai zelf de versie die is meegeleverd en geupdated door HTC en heb werkelijk nergens problemen met WIFI op mijn HTC One X (draait 4.2.2).

Overigens is de HTC One een ander toestel dan de One X die jij hebt, dus... de HW en ook SW is daar anders.
Ik neem aan dat je WIFI netwerk- en DHCP setup gecontroleerd hebt om fouten daar uit te sluiten.

[Reactie gewijzigd door rhk22463 op 22 juli 2024 13:43]

[xxtremexx]

Alles gecontroleerd, fout ligt echt bij de One X i.c.m. Cyanogenmod, in het verleden heb ik namelijk nooit een WIFI issue gehad met andere apparatuur.

[sjongenelen]

De HTC One heeft veel last van WiFi bugs. Ik begreep dat dit een hardware aandoening is

[casparvl]

Ik heb zelf een Samsung Galaxy S3 en heb al maanden op de publieke AMC & Eduroam (ook op 't AMC) netwerken last van het feit dat mijn telefoon constant data uit aan het wisselen is (~20kb/s up en down, waargenomen met een network monitor app). Dit slurpt een hoop batterij (na 8u is ie volledig leeg). Echter waar normaal aan wordt gegeven welke apps je batterij leegslurpen kon ik dat hier volgens mij niet herlijden (heb inmiddels m'n telefoon beide netwerken laten 'vergeten'...). Vraag me af of de in dit artikel genoemde bug die voor veel verzoeken aan t netwerk zorgt de boosdoener kan zijn geweest.

[calvinturbo]

Binnenkort komt er er een update uit, Android 4.3 voor de S3.
Als dit artikel klopt, zouden die problemen dan opgelost moeten zijn.

[casparvl]

Ja ik las het eerder vandaag, thanks. Hoop inderdaad dat het daarmee verholpen is Ben benieuwd...

[calvinturbo]

Mocht je hiermee bekend zijn, dan kan je Android 4.3 ook handmatig flashen.
Lees meer hierover op http://www.sammobile.com/...ng-galaxy-s-iii-gt-i9300/

[svenvv2]

Ik denk eerlijk gezegd dat je netwerkgebruik niet aan 'deze' bug ligt. Deze is namelijk in 4.2 al verholpen.

[calvinturbo]

Er is geen 4.2 voor de S3..

[RoelandO]

Vreemd dat ze verzoeken je vliegtuigmodus aan te zetten. Het uitschakelen van de wifi-verbinding op die telefoons is toch ook genoeg?

[jelgervanzaane]

Het gaat er om dat android meerdere dhcp clients draait. De vliegtuigmodus sluit deze schijnbaar af, terwijl het uitschakelen van wifi dat niet doet.

[NaoPb]

Even verder lezen dan je neus lang is mensen. Er draaien dus meerdere DHCP clients op de telefoon. Dat is dan ook de bug, want er hoort er maar één te draaien. Dat los je op door 'm in vliegtuigmodus te zetten, dan worden die processen afgesloten en los je daarmee het probleem op.
Door je Wifi uit te zetten kun je welliswaar geen verzoeken meer sturen, maar daardoor heb je zelf ook geen verbinding. Dat is dus alleen een oplossing voor de overbelasting, maar hierdoor heb je zelf alsnog geen internetverbinding.

[sfranken]

Hoezo is het een bug als je meerder DHCPd instances draait? Ik heb hier ook dhcdp@eth0, dhcpd@lo, dhcpd@wlan0 en dhcpd@loopback1 hoor... Enige verschil is dat er maar één fysieke verkeer doorlaat: dhcpd@eth0, de rest kijkt daarnaar.

[reaL_G]

het gaat om het aantal verstuurde verzoeken.
wifi uitzetten moet al voldoende zijn.

[cyberstalker]

Waar worden die DHCP-verzoeken dan naartoe gestuurd? Als WIFI uit staat is het erg lastig om een verzoek uit te sturen.

[FreshMaker]

Heb je wel verder gelezen ?

Hoe gaat zo'n server verzoeken ontvangen als de WiFi uitstaat ?

[BlackMage]

Komt waarschijnlijk omdat ze een 'captive portal' gebruiken. Daar willen die telefoons automatisch heen en die bug zorgt voor een loop.

Zo'n captive portal is toch enorm slecht om te gebruiken in zo'n groot netwerk, want vrijwel iedereen, zelfs zonder inloggegevens, gaat even het 'gratis netwerk' checken en gebruiken dus resources ondanks dat ze er niet eens gebruik van kunnen maken. Daarnaast vergeten ze daarna het netwerk weer te 'vergeten' dus gaat de telefoon zich elke keer aanmelden als ie in de buurt is.

Genoeg andere opties.

[Petervanakelyen]

Voor zover ik weet maakt het eduroam netwerk gebruik van WPA2-Enterprise voor authenticatie, niet van een captive portal.

[Anoniem: 132566]

Nee, niet van WPA2-Enterprise, als ik een lezing bijwoon kan ik ook gewoon aandocken op Eduroam (open wifi), maar krijg je een web-portal waar je je username en password in mag voeren, voordat je verder kunt surfen- dus wel degelijk captive portal.

Dus een oplossing zou ook kunnen zijn, meer capaciteit, extra AP's met goed bereik en dan kijken of je kunt met deze manier van werken kunt balancen tussen meerdere AP's.
Op de Application layer (portal level) zal dit geen effect hebben (blijft het probleem bestaan), dus het moet hem dan toch op layer 1 en 2 gebeuren door de roaming apparatuur beter in te richten.

[Reactie gewijzigd door Anoniem: 132566 op 22 juli 2024 13:43]