ASUS bevestigt massale verbindingsproblemen met routers en komt met oplossing

ASUS bevestigt dat veel van zijn routers de afgelopen week te maken hebben gehad met massale verbindingsproblemen. Het bedrijf beweert dat het probleem nu is opgelost en dat gebruikers die hun router opnieuw opstarten, geen problemen meer horen te ervaren.

Rond 16 mei klaagden gebruikers massaal dat hun ASUS-routers plots last hadden van verbindingsproblemen, ontdekte Bleeping Computer. Bij gebruikers die het apparaat opnieuw opstartten stopte de router om de zoveel minuten met werken omdat het apparaatgeheugen overbelast raakte, meldden meerdere gedupeerden op onder meer het ASUS-forum en Reddit. Het is onduidelijk welke routers er precies de dupe waren van deze bug.

ASUS laat nu weten de oorzaak van het probleem gevonden te hebben. Volgens het bedrijf was het 'een fout in de configuratie van onze serverinstellingen', maar verdere uitleg wordt niet gegeven. Het bedrijf beweert dat de problemen voor de meeste gebruikers nu te fixen zijn door de router te rebooten. Mocht dat niet lukken, dan raadt ASUS aan om de huidige configuratie-instellingen op te slaan en de router terug naar fabrieksinstellingen te zetten. Vervolgens kunnen gebruikers de instellingen weer uploaden naar de router.

ArsTechnica schrijft dat de fout mogelijk voortkomt uit een corrupt definitiebestand voor ASD, een ingebouwde beveiligingsdaemon. Deze component wordt automatisch bijgewerkt, ook als gebruikers automatische firmware-updates uit hebben staan. Daarom was het probleem ook niet op te lossen door de firmwareversie terug te zetten. Vermoedelijk raakten de bestandssysteemruimte en het geheugen van de routers na het ophalen van dat bestand vol, waardoor ze vastliepen.

Door Kevin Krikhaar

Redacteur

20-05-2023 • 12:54

180

Submitter: Dr. Boktor

Reacties (180)

180
173
63
1
0
74
Wijzig sortering
Wow, ik dacht dat mijn router(s) kapot waren heb letterlijk gisteren nieuwe hardware gekocht en geinstaleerd. (Overgestapt naar ubiquiti)

Vind dit trouwens zeer gevaarlijk dat het uberhaupt mogelijk is een fout bestand te publiceren en dat deze dan vervolgens geforceert wordt op alle routers, ben blij dat die ASUS routers niet meer in m'n netwerk zitten, want dat kan echt goed fout gaan. (inb4 Ubiquiti net zo erg is en ik een foute keuze gemaakt heb)

Met dit nieuws en dan ook nog eens de "exploderende" 7800X3Ds op bepaalde moederborden en hoe ASUS hier mee omging, is het een slechte paar weken voor ASUS.

Overigens heb ik zelf ook een groot probleem met mijn huidige AM4 Asus moederbord waar ik elke ochtend m'n CMOS moet clearen voordat m'n PC wil opstarten... (geen typefout ik heb het over AM4 niet AM5 zoals bovenstaande issue)

[Reactie gewijzigd door Akamatsu op 22 juli 2024 14:21]

Ik ben een tijdje geleden ook overgestapt naar Ubiquiti vanwege aanhoudende problemen met de Asus RT-AC86U-router. Over het algemeen is het een goede router, behalve dat veel smarthome-apparaten op basis van ESP regelmatig niet compatibel lijken te zijn en vaak verbinding verliezen. Zelfs na urenlang zoeken op internet en het wijzigen van instellingen, bleef het probleem bestaan. Mijn ouders hadden exact hetzelfde probleem met een mesh netwerk bestaande uit drie Asus AX92U routers.

Asus is een prima merk, maar ik sla hun routers voorlopig even over.

Mijn ervaring met de Unifi Dream Router van Ubiquiti is echter helemaal anders. Deze router werkt perfect en heeft ook nog eens een scherpe prijs voor een geavanceerd beheerplatform. Met een extra U6 Lite-access point is het perfect voor mijn woning.

In het begin heb ik ook geëxperimenteerd met TP-Link Omada, omdat dit aanzienlijk goedkoper is dan Unifi. Echter, het Omada-platform had meer tijd nodig om volwassener te worden en vergelijkbaar te zijn met Unifi. Hoewel het mooi zou zijn als Omada een serieuze concurrent van Unifi zou worden, was dat ten minste een paar maanden geleden nog niet het geval.
Ik heb hier ook een aantal ESP (8266 / 32) projectjes draaien. En ook bij mij verloren ze regelmatig de connectie met mijn RT-AX82U. Dacht dat het probleem bij de esp lag. Dat ze resette door statische ontladingen in huis. Na wat speurwerk op internet bleek het probleem bij de Asus router te liggen (of tenminste een incompatibiliteit instelling tussen de ESP en de router). De volgende instelling moet op disabled staan:
"Enable IGMP Snooping" (Wireless => Professional).
Geen idee wat de gevolgen ervan waren, maar merk eigenlijk niets verder met het netwerk behalve dan dat de ESP projectjes geen verbindingsproblemen meer vertoonde. :)
Klopt, IGMP snooping op Asus access points doet funky dingen met ESP's.
Ben er nog niet achter wat er nu precies mis gaat, aangezien het enige wat menig ESP project gebruikt met multicast is mDNS, maar ook als je dat niet aan hebt staan schijnt er iets mis te gaan.

Ander punt wat met menig AP (waarbij Asus het vaakst genoemd wordt) mis gaat met ESPs is dat band steering aan staat.
Ook korte disconnects om gebruikers te forceren naar een andere mesh node te verbinden zijn nogal funest voor ESPs en Asus is ook daar koploper qua vermeldingen van "funky issues".

Kortom:
- IGMP snooping uitzetten
- ESP forceren om op 802.11g te connecten
- Band Steering uitzetten

Dan heb je het gros van de issues wel opgelost.
Heb je op je LAN een IGMP-querier actief? Dat is wel nodig in combinatie met IGMP-snooping.
Het gekke is dat als je EEN Asus Router of Mesh uit de doos haalt, deze settings allemaal fabrieksaf goed staan. (ik heb regelmatig een Asus in handen)

igmp staat disabled
band steering staat disabled

Het is dan toch echt het onkundige geklooi van de mensen zelf die zaken aanzetten waar ze dus niks vanaf weten.

Op zich niet vreemd, als men tegenwoordig al een cdtje in de speler duwt, noemt men zich al IT Expert.
Ik heb nog nooit zo'n Asus ding in handen gehad en zou dus ook niet weten of dergelijke settings vroeger ooit default een andere waarde hadden, of wellicht dat er een 'wizard' in zit die die settings aan zou kunnen passen?
Kan me voorstellen dat "Band Steering" bijv. bij het activeren van een mesh oplossing aangezet zou kunnen worden?
band steering zet dat juist niet aan.
Weet je wat bandsteering is?

In een asus ga je daar ook qua term niets over vinden.
In het menu wordt het Smart Connect genoemd......wat inhoud, dat je 1 ssid kan instellen voor al je banden (2.4g, 5g, 6g band)
Dat is sowieso binnen de IT een NO-GO. Zeker in een omgeving met smart devices.
Beste is gewoon altijd een zichtbare ssid te hebben voor elke band apart.
Heb je dus 3 banden thuis, moet je 3 verschillende ssid namen zien in je netwerk.
band steering zet dat juist niet aan.
Weet je wat bandsteering is?
[...]
Yep, ik weet wat BandSteering is, namelijk dat je AP heel kort een disconnect forceert zodat je device gaat proberen naar een andere band (2.4/5/etc) band probeert te switchen.
Ik heb dit destijds gedaan. Ook een deel tips die hieronder genoemd werden heb ik op fora gelezen en heb geprobeerd. Helaas is het destijds niet gelukt.

In een AImesh setup met 3x AX92U had ik de meeste problemen. Wellicht spelen hier instellingen achter de schermen die niet te wijzigen zijn een rol. Met slechts de RT-AX82U meen ik me te herinneren dat het wijzigen van instellingen de verbinding wel verbeterde en voor normaal gebruik acceptel was, maar niet zodanig dat ik er gelukkig mee was voor gebruik icm Home Assistant. Een klein percentage aan onnodige downtime maakte automations dan al onnodig ingewikkeld doordat er contingencies in verwerkt moesten worden.
Ik heb een RT-AX82U maar ik weet eigenlijk niet of ik er last van gehad heb, het is mij ieder geval niet opgevallen. Maar ik draai de Merlin firmware waarbij het automatisch updaten van firmware niet mogelijk is en voordat ik had geüpdatet naar de Merlin firmware had ik automatisch updaten ook niet aan staan. Bij mij staat "Enable IGMP Snooping" gewoon aan, ik zal wel mazzel gehad hebben of zo :)
Ik heb ook niks gemerkt en IGMP snooping staat aan in de Merlin 388.2.2 versie . Dit is een RT-AX88U
vreemd, want standaard asus wrt of merlin wrt, daarbij staan deze settings fabrieksaf op disabled.
ik heb bijna wekelijks een Asus in handen.
Held!! Ik stoei hier al tijden mee.
IGMP snooping schijn je nodig te hebben om kpn tv te kunnen kijken anders gaat het beeld haperen bij switches zonder IGMP: https://forum.kpn.com/ken...-is-het-belangrijk-456968
Kan bevestigen dat esp gerelateerde chips connectie verliezen naar de ac86u.

Ik ben zelf naar een ax86u pro overgestapt en nog geen enkele disconnect gehad tussen esp en router.
Same here met mijn mesh netwerk met 4 stuks ax mini. Zeer regelmatig raken ze het netwerk kwijt en verbinden dan niet meer. Het enige dat dan werkt is dan terug naar fabrieksinstellingen en opnieuw laten verbindingen, een paar dagen later is de volgende aan de beurt. Enige oplossing schijnt bedraade backhaul te zijn. Echt jammer...
Ik gebruikte een bedrade backhaul met de AX92U's. Het mocht niet baten. Het bleef een drama met zowel ESPs en downtime die andere onverklaarbare issues.
Fouten worden gemaakt. Maar misschien weet jij een manier om ten alle tijden bugs te voorkomen. Ik denk dat je met die kennis flink wat euro's per uur kunt vragen als consultant.
Als het probleem zo wijdverspreid is, dan is er simpelweg gewoon niet goed genoeg getest voordat de aanpassing die dit veroorzaakte werd doorgevoerd. Ja fouten worden gemaakt, nee, dit had niet door een fatsoenlijke test setting mogen komen.
Klopt maar als zelfs Windows en iOS updates bugs kunnen hebben, en dan met bedrijven als Microsoft en Apple achter zich.

Lijkt het mij dat veel bedrijven het gewoon verkeerd aanpakken, zelfs als de financiën het toestaan.

Nou weet ik niet hoe Asus dit aanpakt, maar wenselijk lijkt dit mij niet, zelfs als auto updates uit kunnen.
Dat is appels met peren vergelijken. Windows en in mindere mate iOS draaien op veel verschillende platforms met allerlei verschillende configuraties en andere software die er mogelijk bij betrokken is. Firmware voor routers draait op apparatuur die Asus zelf ontwikkeld heeft met software die ze zelf in de hand hebben. Als het dan mis gaat is het 100% je eigen fuckup.

[Reactie gewijzigd door MadMarky op 22 juli 2024 14:21]

Eerder appels met ramen vergelijken :o
Of we maken dingen ingewikkelder dan goed voor ons is. Dat denk ik eigenlijk.
In de "mechanische" tijd deden we dat niet. Een wekker met 30 keer zoveel tandwielen als eigenlijk nodig was, dat zou je nooit maken.
Maar met software vinden we het geen probleem als een applicatie rond 30 regels logica uitmondt in een binary van 30 MEGAbyte. Dus 40 bytes wordt een miljoen bytes.
Inclusief het volproppen met externe libraries omdat dat makkelijker is. Niet dat je zonder kan, maar het geeft steeds vaker ook problemen.
klassiek Not Invented Here syndroom.
Als er een gat tussen huidig en gewenst gedrag moet worden opgevuld, heb je altijd de keuze voor build / buy. En er is weinig mis met vertrouwen op een open source library waar een actieve community omheen zit, en dus meer ogen overheen gaan dan over eigen code. je gaat lekker klakkeloos voorbij aan de vele issues die door een community worden gedetecteerd en opgelost voordat ze een client bereiken. Daarnaast hou je je eigen resources vrij om zich te focussen op hun expertise: je eigen business logica. Precies waar je ze wilt hebben.

Tuurlijk, dependencies hebben soms dependencies. Dan krijg je er inderdaad een paar bij. En er zijn rotte appels, tuurlijk. Maar "volproppen met externe libs" toont vooral oppervlakkige angst zonder al teveel strategie of onderbouwing.
Inderdaad, net als die Chrome OS-bug door een typfoutje in de code waardoor niemand kon inloggen. Maar letterlijk niemand. Toen Google het na alle bugmeldingen en media-aandacht ook maar eens probeerde, konden zij inderdaad ook niet inloggen. Het was dus overduidelijk dat er niet getest was, want anders hadden ze meteen al gezien dat ze ook zélf niet konden inloggenz. Fouten kunnen gebeuren, maar fouten die álle apparaten treffen, zoals bij Chrome OS en nu bij deze Asus-routers, tja, daar zou wel íets meer getest mogen worden.
Ik ben zelf een software engineer, en dit is de reden dat wij Acceptatie/Preproductie omgevingen hebben, dat wij dit soort configuratie fouten of bugs kunnen zien en opsporren.

Bij het pushen van nieuwe code gaat dit eerst naar acceptatie en hier testen wij de software en kijken we of deze nog werkt zoals het hoort, dit gebeurt over een paar dagen, vervolgen promoveren wij deze naar PreProductie en testen weer wat hier met de software gebeurd, hiermee letten we op onze metrics en logging. Pas als we er 100% zeker van zijn dat dit goed werkt promoveren wij naar Prod, dit gaat meestal gepaard over meerdere weken.

Dus een configuratie fout zoals deze had al heel gauw in ons process naar voren gekomen voordat dit ooit naar Productie had gegaan.

Jazeker je kan geen foutloze code schrijven, maar je kan het wel vroegtijdig opsporen en vervolgens niet je klanten er mee bezwaren.

Ik heb zeker zat fouten gepusht naar Acceptatie/PreProd maar daar zijn deze omgevingen voor, zodat onze klanten de minste downtime/ergernis hebben.

Overigens zou een update als dit, als een update aangevoerd moeten worden en niet als geforceerde update, stel dat er een config bestand gepusht wordt wat nog meer scahde aan zou richten, zo kan je alle routers kapot maken van ASUS stel dat deze server ooit gehijacked wordt door een kwaadwillende, hiermee kan je alle routers van ASUS omzeehelpen, dat is het wat ik het kwalijkste vind aan dit probleem.
Ik denk dat je met die kennis flink wat euro's per uur kunt vragen als consultant.
Doe ik absoluut maak je daar maar geen zorgen om. ;)

[Reactie gewijzigd door Akamatsu op 22 juli 2024 14:21]

Als je test gedurende 3 minuten loopt, merk je dus niet dat de boel OOM gaat na 30 minuten.
Zoals @Akamatsu al zei, daar gaan meerdere weken overheen, niet 3 minuten. Daarnaast pushen wij de productie software naar een gelimiteerd aantal gebruikers en als dat goed gaat (ook weer meerdere weken) dan gaat de grotere rollout van start. En ook dat nog steeds gefaseerd in batches over de tijd heen. "Haast" is slecht gezelschap voor dit soort dingen.
beetje offtopic allemaal, maar ik gok dat ook jullie rapid deployment procedures kennen bijvoorbeeld bij een critieke bug die snel gepatched moet worden.

of daar hier sprake van is valt natuurlijk niet te zeggen,

maar wat me eerder opvalt is het volgende..
kennelijk gebruikt asus met ASD een soort 'beveiligings service' waarvan je als gebruiker kennelijk helemal geen weet van hebt en die je kennelijk ook niet handmatig kunt legen, of uit kunt schakelen... nu is het een fout de volgende keer een DoS...

ik hoop dus maar dat AL deze routertjes iets van OpenWRT kunnen draaien want dan zou ik zo snel mogelijk overstappen.
Uiterst kwalijk inderdaad dat er "rommel" door de servers van Asus loopt blijkbaar. Dat zou in mijn optiek altijd een "opt-in" moeten zijn, desnoods in een wizard bij de installatie. Veel Asus routers kunnen inderdaad OpenWRT of iets als (Advanced)Tomato draaien. En inderdaad, kritieke bugs gaan wat vlotter :)
Eat Your Own Dog Food.

Laat je bedrijf en je development omgeving ZELF wireless op je laatste Release Candidate firmware draaien en je komt er al snel achter of iedereen blij is of niet.
Alleen ging dit niet om firmware
In dit geval misschien niet, maar die bug van een tijdje geleden waardoor niemand meer kon inloggen op Chrome OS-apparaten, zelfs Google zelf niet, tja… dat hadden ze toch wel binnen 1 minuut kunnen ontdekken (na alle bugmeldingen en media-aandacht hadden ze het ook binnen 1 minuut door).
Fouten worden gemaakt. Maar misschien weet jij een manier om ten alle tijden bugs te voorkomen.
Het is geen fout als je als fabrikant opzettelijk geen details geeft over wat de oorzaak is. Dat is het probleem bagatelliseren, en je gebruikers dom proberen te houden. Zeker als het zoveel klanten treft is het ongepast om je als bedrijf zo op te stellen. Klanten hebben daarbij niet betaald om op deze manier problemen te ondervinden.
Fouten gebeuren altijd, dat weet iedereen. Goede ICT infrastructuur kan dat soort fouten grotendeels opvangen, in allerlei stages. En die stages hebben ze dus niet echt goed op orde bij ASUS.
Fouten worden inderdaad altijd gemaakt, daar is weinig aan te doen. Wat belangrijk is is vooral hoe je daar als bedrijf mee om gaat.
Het grote probleem hier is dat de hardware zelf niet het issue was maar externe servers waar imho die routers helemaal niks mee te maken mogen hebben behalve dat ze misschien de datum & tijd van een ASUS NTP server aflezen..
Ja: geen cloudmeuk draaien waar het niet nodig is zodat een fout niet overal direkt merkbaar is, maar een lokaal probleem blijft.
7800X3Ds eigenlijk de hele 7000 series.

[Reactie gewijzigd door Ryuukami op 22 juli 2024 14:21]

5800X3D is AM4, de issues die Asus (maar ook Gigabyte) hadden/hebben (want er is al een BIOS update) was op AM5 moederborden.

ondanks een BIOS update, dit had nooit moeten gebeuren

In ieder geval kan alle type software een bug hebben, ik zou zelf nooit zo snel iets als een router (maar ook smartphones en dergelijke) vervangen vanwege een bug, zonder er zeker van te zijn dat het echt stuk is, zonde van het geld.

Vooral met smartphones willen er weleens dingen mis gaan door bugs, soms is daar een patch voor nodig en soms slechts een workaround.

Hetzelfde met Windows overigens.

[Reactie gewijzigd door Mizgala28 op 22 juli 2024 14:21]

Klopt ik had het over de 7800X3D, zelf heb ik OOK issues met mijn 5800X3D op een AM4 Asus moederbord, dat ik mijn CMOS moet clearen elke ochtend, dus ik heb ze even door de war gehaald. reactie aangepast.
Wow, ik dacht dat mijn router(s) kapot waren heb letterlijk gisteren nieuwe hardware gekocht en geinstaleerd. (Overgestapt naar ubiquiti)
Same here, verwacht vandaag een powerline adapter kit te krijgen. Eens kijken wat die aan prestaties neer kan zetten. Mochten de prestaties acceptabel zijn, dan is het is een mooie backup oplossing, want het is niet fijn om midden op de dag geen calls meer te kunnen doen omdat er geen wifi in het kantoor is.
Overigens heb ik zelf ook een groot probleem met mijn huidige AM4 Asus moederbord waar ik elke ochtend m'n CMOS moet clearen voordat m'n PC wil opstarten... (geen typefout ik heb het over AM4 niet AM5 zoals bovenstaande issue)
Dit probleem heb ik met een Gigabyte AM4 bord als de stroom er helemaal af geweest is.
Vreemd, in mijn geval staat de stroom er wel constant op
wauw... idem hier. er is er zelfs 1 al terug naar bol.com voor reparatie
heb ax89x in aimesh modus.. kon in die paar mins dat tie het wel deed de settings saven.
heb eerst ook nog andere voeding geprobeerd.
uiteindelijk aimesh node factory reset gedaan , en config geupload , die draait nu als hoofdnode.
de andere factory reset en in de doos naar bol.com.
mogen ze meteen daar geld voor terug geven , alle Asus meuk gaat bij deze de deur uit als ik afhankelijk ben van die idioten bij Asus om mijn thuisnetwerk draaiende te houden, wat een zware tegenvaller zeg.
CMOS batterij is vervangen en terwijl de pc laten leeglopen. --> CMOS batterij er dus uitlaten, voedingskabel uit psu trekken, dan paar keer op powerknop duwen zodat pc wil opstarten (hierdoor lopen condensators vd voeding leeg). Pc paar uurtjes en liefst overnight laten staan. Dan pas nieuwe CMOS er in en dan pas pc terug op stroom aansluiten
Wow, da’s best een snelle vervanging naar Unifi 😊. Heb zelf ook een Asus mesh met verschillende type Asus routers (in meterkast, werkkamer, zolder, tuin). Dit probleem bij Asus viel me pas op toen ik geen bereik in de tuin had. Alle routers uit en aan gedaan en de firmwares via het hoofdknooppunt laten bijwerken en alles draait weer als een zonnetje.

Unifi stond 2 jaar terug ook op het lijstje maar ik vond het zo belachelijk prijzig, dat ik toch maar 2 asus routers heb bijgekocht. Moet zeggen dat ik erg tevreden ben met Asus mesh.

[Reactie gewijzigd door DrDelete op 22 juli 2024 14:21]

Ik gebruik de Asuswrt-Merlin firmware op mijn Asus-router en heb hier tot nu toe geen problemen mee ervaren.
Dat is inderdaad de betere keuze.

Zelf heb ik OPNSense draaien op een dedicated servertje. Teveel gedoe met 'phone-home', zelfs als het uitstaat. Daarbij, custom firmware geven (over het algemeen) meer opties en leuke features.
Maar Merlin heeft dit ASD gebeuren juist ook toegevoegd in zijn firmware:

https://www.snbforums.com/threads/what-is-asd-process.76242/
Bedankt voor deze link. Lijkt mij die ASD is een vrij onbetrouwbaar component die wordt door Asus geduwt in de firmware, en ook Merlin heeft hem geïntegreerd.
Ik gebruik beide ( Merlin en standaard) en heb ook geen problemen gehad.
Misschien dat nieuwere modellen problemen hadden met A.i.protection
De Merlin firmware draait ook op mijn router, maar hier zat het probleem in de mesh node die geen Merlin firmware kan draaien. Hierdoor konden apparaten geen wifi via die node meer gebruiken.

Harde reset van de mesh node, (oude) firmware opnieuw installeren en de meshnode opnieuw inregelen lijkt het probleem verholpen te hebben.
Inderdaad, bijzonder tevreden met WRT-Merlin op mij RT-AC86U
Heb ik ook op mijn ax88u draaien. Tot nu toe geen problemen. Voorwaarde is wel dat ik iedere ochtend rond 4 uur de router opnieuw laat opstarten. Doe ik dit niet, dan verlies ik om de dag minimaal 50 procent van mijn devices zowel bedraad als draadloos. Dit probleem heb ik al minimaal 2 jaar zowel met de ASUS stock firmware als Merlin
Maybe one or more devices periodically change their MAC-address resulting in new IP allocation resulting in a IP shortage?
Dat zou betekenen dat die continue home phonen naar Asus, en daar blijkbaar ook nog eens functioneel afhankelijk van zijn. Lijkt me wel een privacy-concern - wat regelt het ding nog meer achter de gebruikers' rug om met Asus?

Een router is gewoon een router lijkt me, zolang je daarvan afblijft zou er functioneel niks aan moeten veranderen. Dat updates-kunnen-uitzetten-maar-niet-helemaal-kunnen-uitzetten moet ook maar eens afgelopen zijn.

[Reactie gewijzigd door Boxman op 22 juli 2024 14:21]

Toevallig vandaag een nieuwe ASUS router geïnstalleerd. Bij de onboarding krijg je een keuze om games via hun server te laten lopen voor een snellere Ping. Wellicht gaat het om die gebruikers.
Hoe kan een game via een relay laten lopen voor een lagere vertraging zorgen als er vrijwel inherent sprake zal zijn van een omleiding?
Even vlug opgezocht en ik denk dat het om de WTFast service gaat. Deze service routeerd packets via "betere routes" (privé en niet belast). Dit is handig voor landen met een minder goede IT infrastructuur. Voor moderne landen zoals ons is dit totaal niet nodig en kan het inderdaad het verkeer trager maken.
Niet helemaal waar, er is in verleden en durf niet 100% zeker te zeggen dat dit nog steeds zo is Nederlandse providers geweest die hun verkeer via bijvoorbeeld Duitsland routeerde om zo minder transit kosten te hebben, hierdoor had je wel degelijk performance vermindering
Alleen moet bijvoorbeeld WTFast dan wel aan peering doen met je eigen internetprovider, anders moet het verkeer alsnog via Duitsland en wordt het effect weer teniet gedaan.
dat is welgeteld 1 of hooguit 2 keer gebeurd, en alleen bij 1 provider. bovendien wass dat met een paar dagen ook al weer opgelost... kans dat een volgend (of het zelfde) bdrijf dat nóg eens doet zal niet heel groot zijn.
Waarschijnlijk pushen ze dan hun eigen dsn servers of zo ? Lagere ping zal je er niet van krijgen , maar asus kan dan wel weer data vergaren over gebruikers die voor deze optie kiezen .

Is slechts een vermoeden hoor , geen idee of het in de praktijk zo gaat . Heb zelf nog nooit die optie gezien op mijn asus router maar ja gebruik hem dan ook met merlin firmware dus niet stock .
Ik weet daar niks van, en ik had hier ook een paar keer dat ie uit viel. Ach ja, de anderhalf jaar dat ik dat ding heb één keer een dagje 3x de router resetten. Ook geen ramp.
Volgens mij was het opgelost nadat ik handmatig een firmware update heb gedaan.

[Reactie gewijzigd door Wolfos op 22 juli 2024 14:21]

"it's not a bug, it's a feature" veel dingen hebben tegenwoordig beveiligingsupdates nodig en dan heb je liever dat de fabrikant die aanbiedt, dan dat je dummies zélf daarvoor verantwoordelijk stelt.

Het is niet omdat een device voor jou maar 1 enkele functie mag vervullen en dat ook nog eens volledig zonder dat er ooit ook maar 1 exploit voor te vinden is, dat dit voor iedereen zo is, laat staan voor fabrikanten die meer functionaliteit willen aanbieden en dat bij 99% zelfs selling points zijn, eerder dan "evil genius phone home botnet"-gedrag.
Nee, dat heb ik liever niet. Worden zij gehackt, lekt er een private key uit, dan heb je ineens een wereldwijd botnet. Laat het bij de installatie desnoods een (dwingende) vraag zijn om het aan te zetten, maar niet default "aan". Ik maak die keuze liever zelf. Overigens werkelijk geen idee wat je met de twee laatste zinnen wil zeggen.
Dat updates-kunnen-uitzetten-maar-niet-helemaal-kunnen-uitzetten moet ook maar eens afgelopen zijn.
Volgens het artikel gaat het om een een ingebouwde beveiligingsdaemon. Ik vermoed een service die voorkomt dat je router ingezet zou kunnen worden voor een botnet. Als dat zo iets is dan is het logisch dat je het updaten hiervan niet kan uitschakelen, want het heeft een belangrijker doel dan welk excuus dan ook niet je firmware te willen upgraden.

Uiteindelijk heeft een ander meer last van het niet upgraden van jouw router dan jijzelf.
Je doet je naam wel eer aan met zulke argumenten :P
Als dat zo iets is dan is het logisch dat je het updaten hiervan niet kan uitschakelen, want het heeft een belangrijker doel dan welk excuus dan ook niet je firmware te willen upgraden.
Feature of niet, als jij kiest om updates uit te zetten op jouw eigendom, dan moeten die gewoon uit. Precies om deze reden, de betrouwbaarheid is namelijk aangetast en er wordt geen openheid gegeven dat dit proces loopt op de achtergrond. Doen ze dat wel, dan hakt dat waarschijnlijk in de verkoopcijfers.

Het lijkt een beetje op het kinderporno argument, alsof we voor 'the greater good' bijvoorbeeld zouden moeten toestaan dat je internetverkeer via een speciale beveiligingsdaemon gecontroleerd moet worden.
Uiteindelijk heeft een ander meer last van het niet upgraden van jouw router dan jijzelf.
Het bovenstaande is artikel is anders een regelrecht voorbeeld van het tegendeel.
Je redeneert nu tot in het absurde door de discussie ineens te beperken tot een ander argument aangaande kinderporno, dus ik doe even met je mee:

Wil je alles zelf doen en potentieel zo lek zijn als een mandje? Bouw dan gewoon een eigen router. Windows 2003 was een redelijk stabiel OS, beschikbaar voor x64 en heeft zeker weten geen security updates meer, prima keuze.

Ik doe overigens ook het liefst zo veel mogelijk in eigen beheer, maar maak me geen illusies dat ik onmogelijk het werk van 100-en security specialisten die er hun beroep van hebben gemaakt voor elk device in huis zelfstandig beter kan. Voor huis-tuin-en-keuken gebruikers, lijkt het verplichten van security updates me een must. Ik durf zelfs nog wel te verdedigen dat ik van mening ben dat er wetgeving voor moet komen die fabrikanten (binnen het redelijke) verantwoordelijk houdt voor de security van de apparaten die ze leveren. U doet het liever 100% zelf, dan bent u 100% verantwoordelijk voor schade die via uw machines aangericht wordt. En ja, dan is een weekje 'verbindingsproblemen' toch echt een kleiner problem dan daadwerkelijk een gecompromitteerd systeem hebben, met alle schade en maatschappelijke gevolgen die dat aanricht.

[Reactie gewijzigd door hottestbrain op 22 juli 2024 14:21]

Als je dat ene voorbeeld uit context trekt om vervolgens te pretenderen dat dat het enige is wat ik heb gezegd en volledig voorbij te gaan aan de resr van mijn post, ja dan wordt het een absurdistische discussie.
Ik ben wat in de war van je comment, maar wie weet interpreteer ik het iets anders dan jij: ik ging juist wel op het verhaal in, terwijl jij nu uitsluitend op dat ene stukje absurdisme aanslaat?
zie je wel vaker als mensen een argument niet kunnen winnen.

voor hen is het vaak: mijn eigendom en dan houdt eigenlijk alles op.

en ja sommige mensen vinden het ook absurd dat er in HUN huis naar verdwenen kindertjes wordt gezocht, in HUN huis mogen ze natuurlijk precies doen wat ze zelf willen ;) -

maar goet @Boxman misschien moet je het kinderporno argument liever niet gebruiken ;) er zijn best situaties te bedenken waarin je zo'n vergelijking zou moeten kunnen trekken maar zeker NIET in deze. dat is gewoon absurd.

Aan de ander kant valt er natuurlijk wel iets te zeggen, voor dat verhaal;
op mijn router, in mijn netwerk wil ik wel graag de controle hebben, of kunnen krijgen:
• als ik verantwoordelijk ben voor wat er op mijn netwerk gebeurt,
• of als ik enorme last heb van wat er op mijn netwerk gebeurt
dan wil ik graag op zijn minst de optie hebben om daar iets aan te kunnen doen.

Dat asus zo'n feature als ASD op zijn routers meeleverd en default aan zet vind ik prima.. maar als blijkt dat het regelmatig tot problemen leidt of in potentie zorgt dat mijn verbinding stuk gaat, dan los ik dat veiligheidsprobleem misschien liever via andere wegen op. dus in die zin heeft @Boxman wel een punt, ook al kwam her er nu niet echt lekker uit;)

[Reactie gewijzigd door i-chat op 22 juli 2024 14:21]

Misschien moeten we al het internet verkeer door een soort grote firewall laten lopen zodat de regering ons kan beschermen tegen kwaad van buitenaf en om te kijken of er geen anarchistische posts worden gedaan.

Dat is ineens geen goed idee mag ik hopen. Als Asus zoiets doet, moet dat bij de aankoop bekend zijn en het moet een opt-in zijn. Dit kan en mag niet onder het mom van "wij weten wat goed voor je is". Dat is gewoon eng.
Ik weet niet of ik het een botnet zou noemen maar er zit wel een kern van waarheid in als Asus extern aan je router kan gaan knoeien wanneer je zo'n service gebruikt.
Van een forumtopic op het SNBForums:
And to be more clear, the asd (Asus Security Daemon) process is a security feature on the Asus router that downloads signatures from Asus periodically (unrelated to Trend Micro). It actually does this in both stock and Merlin, but for some reason merlin wasn't affected. So apparently they released a bad signature file, but didn't release it to merlin yet (from what @RMerlin has said in an old thread, sounds like they release a different signature for his or possibly a different timetable).
Edit; Het heeft dus te maken met TrendMicro AiProtection.

[Reactie gewijzigd door Glassertje op 22 juli 2024 14:21]

AiProtection kun je gewoon uitzetten, dus dan was het probleem de hele tijd toch makkelijk op te lossen?
Ik heb AiProtection UIT op mijn AX92U's. En toch had ik er last van, WiFi werkte uiteindelijk helemaal niet meer na vele reboots. Had al een doos gehaald om ze terug te sturen voor garantie.
Hier zelfde verhaal. Uiteindelijk alles opnieuw ingesteld (XD5). Buurman zelfde verhaal vandaag geholpen met nieuwe netwerk installeren. Dit is de eerste keer slechte ervaring met ASUS.
Apart, ik heb hier ook AX92U's (up-to-date firmware). AIProtection uit, geen problemen gehad. Sowieso wil ik dat soort functies nooit aan want het kost gewoon performance (latency/throughput).

[Reactie gewijzigd door NLxAROSA op 22 juli 2024 14:21]

Ik liep wel een aantal versies achter qua firmware.
Ik snap niet hoe z'n router in je Lan effect op heeft als de ASUS servrr eruitliggen?????
Staat standaard ook niet eens aan. Hier is de laatste versienummer van het betreffende bestand uit 2021. (chknvram2021083002)

Lijkt me nogal wiedes als je zoiets aanzet, dat er ergens verbinding mee wordt gemaakt om te updaten.
ArtTechnica schrijft dat de fout mogelijk voortkomt uit een corrupt definitiebestand voor ASD, een ingebouwde beveiligingsdaemon.
Als dit klopt, dan is het een klassiek geval van een beveiligingsmiddel dat contraproductief werkt. Maar al te vaak vergeet men dat beschikbaarheid ook een onderdeel is van informatiebeveiliging.
Maar al te vaak vergeet men dat beschikbaarheid ook een onderdeel is van informatiebeveiliging.
Wat vrij ironisch is, aangezien de CIA triad één van de bekendste aspecten zijn van information security. :+

[Reactie gewijzigd door Anonymoussaurus op 22 juli 2024 14:21]

Ik denk niet dat het vergeten is maar dat er door samenloop van omstandigheden iets is fout gegaan. Het blijft nog altijd voor een groot deel mensenwerk.
Kwalijke zaak dat je router afhankelijk is werking van instellingen op de server van de fabrikant en al helemaal als je automatisch bijwerken ed uit hebt staan.

Gebruik zelf al jaren AVM-spul en heb dit daar standaard in uit staan (zowel bijwerken door AVM als provider).
Weet iemand of bij AVM toch allicht zo'n geintje ook speelt?
Zo ja, hoe is het eventueel te voorkomen?
Ik heb zelf ook een Fritzbox. Ik denk dat ook die (en eigenlijk alle kant en klare routers) afhankelijk op een of andere zijn van een server van de fabrikant.
Heb het niet gezien in de tracing.
Maar ja, ik trace geen 24/7 🙃
Hier een thread van begin dit jaar: https://www.snbforums.com/threads/what-is-asd-process.76242/
Gebruikers die het uit probeerden te schakelen (waarvoor ze bash scripts etc moeten maken of aanpassen) kregen CPU resource problemen. Wel raar dat zoiets niet gewoon in een nette UI feature uit te schakelen is.
Laatste maanden hoor je van verschillende hardware onderdelen van Asus veel problemen. Moederborden en laptops zijn niet meer van de bouw kwaliteit en betrouwbaarheid die Asus vroeger bracht.
Ik zou qua laptops en smartphones durven zeggen dat ze al enkele jaren (vooral sinds de pandemie) mindere kwaliteit leveren.

Al geldt dat niet voor al hun producten, het is precies hetzelfde net als met andere merken waar je goede en slechte producten hebt.

Altijd dus op het product zelf letten en niet op het merk, ik heb slechte ervaringen met MSI gehad, maar hun huidige line up is met sommige producten nu gewoon prima.
Ik had dus toevallig m’n modem en kabels bij het tv meubel opnieuw gemanaged en netjes weggewerkt met tywraps, alles losgemaakt en weer ingeplugd in de ochtend. Daarna was alles weer werkend. Diezelfde avond thuisgekomen en toen deed de WiFi niets.. ik zoeken zoeken, mezelf gek verklaard, geen internet, wel WiFi connectie. Werd er gek van.. ochtend erna alles weer gechecked, opnieuw de router opgestart en toen deed ie het weer. Dit was dus de oorzaak.. grrr
Ik ben afgelopen week overstapt van Ziggo naar KPN, met een Asus router (als router) achter de Experiabox en 2 accesspoint waarvan ook eentje van Asus.
Vooral de Pixel 6a van mevrouw Chielllie en de LG tv bleven maar wifi haperingen vertonen.
Gisteravond uren getest en ineens werkt het weer als zonnetje.
Wel raar dat dit niet eerder gecommuniceerd is, want het was gekmakend.

Op dit item kan niet meer gereageerd worden.