"Mpro mesh" veroorzaakt problemen met apparaten met bepaalde wifi chipsets
Heb een Zyxel VMG8825-T50 router met V5.50(ABPY.1)b16_20210525 firmware.
En ervaar problemen met devices die voorzien zijn van Broadcom/Cypress/Synaptics wifi chipsets als de "Mpro mesh" aan staat in de instellingen van de router. Heb overigens geen mesh netwerk, maar enkel de router, maar die instelling lijkt standaard aan te staan.
Dit kenmerkt zich door twee symptonen:
- Bij sommige (IoT) apparaten kan het vrij lang duren (een seconde of 13) voordat het lukt om de wifi verbinding op te zetten.
- Bij bijvoorbeeld een Raspberry Pi 400 met BCM43456 chipset wordt de verbinding om de paar minuten verbroken (en na 7 seconden wordt de verbinding opnieuw tot stand gebracht.)
Aan de afstand tot de router (nog geen 5 meter) kan het niet liggen. Zodra ik "Mpro mesh" uit zet via de webinterface van de router, werkt het prima.
Alleen stond de instelling vandaag spontaan weer aan, zonder dat ik dit zelf gewijzigd heb. Hebben jullie onlangs een instelling of update gepushed?
Bladzijde 1 / 1
Goedemorgen @Max_nl, er zijn recent geen firmware updates uitgerold waarbij de Mpro-instelling gewijzigd is of waarbij er een zodanige impact op is geweest dat die instelling nu anders is dan voorheen. Je kunt de instelling handmatig uitschakelen en tenzij je de boel reset, zou deze uitgeschakeld moeten blijven staan.
De beschrijving van het issue op de Raspberry Pi komt veel overeen met een apparaat dat voor een “ lease time error” zorgt. Zo’n foutmelding zorgt ervoor dat het apparaat niet het juiste IP-adres vanuit de DHCP-server toegewezen krijgt en daarom elke keer probeert te vernieuwen waardoor dit voor uitval zorgt op de verbinding.
Ik kan momenteel geen klantprofiel opzoeken met de opgegeven informatie in jouw Communityprofiel. Kun je mij een privébericht (de link is klikbaar) sturen met jouw postcode, huisnummer, geboortedatum en de laatste vier cijfers van je IBAN, alsjeblieft? Dan kijk ik in de verbinding of ik iets zie dat afwijkt van de norm en kom ik erop terug in dit topic! Thanks alvast voor je medewerking.
Beste Jason,
Ik weet zeker dat het in dit geval niet met DHCP te maken heeft.
Mocht je zelf Pi 400 hebben liggen, open dan even een terminal en type “wpa_cli -i wlan0” dan zie je alle wifi status berichten voorbij komen.
Staat mpro mesh aan dan komt regelmatig “<3>CTRL-EVENT-DISCONNECTED bssid=b8:d5:26:d9:f8:21 reason=6” voorbij.
Dat betekend dat de Zyxel de verbinding verbroken heeft (deauth).
Dit treed niet op als Mpro mesh uit staat.
Steeds 7 seconden later herstelt de verbinding zich weer (“CTRL-EVENT-CONNECTED”).
De kans is groot dat ook veel andere apparaten met dezelfde wifi chipset hier last van hebben, maar dit niet aan jullie gemeld wordt. De verbinding herstelt zich wel steeds weer, en het kan daarom zijn dat niet iedereen het opvalt.
Ik ben verder niet de enige die het opviel dat de Mpro Mesh instelling af en toe automatisch aan gaat.
Een andere gebruiker heeft dit ook al gemeld:
Naar ik begrepen heb gebruikt T-mobile een systeem waarbij de router dagelijks contact opneemt met jullie server, en checkt of er nieuwe firmware updates zijn.
Weet je zeker dat er op het moment geen andere instellingen binnengehaald (en overschreven) worden?
@Max_nl Voor het gemak van de meelezers, plaats ik mijn privébericht hier ook in het topic:
Ik zie geen enkele afwijking in de lijnmeting naar voren treden. Wat ik echter wel constateer, is dat het modem de afgelopen 15 dagen nog geen reset heeft gehad - ook al snap ik deels dat je dat op het moment niet aandurfde. Toch wil ik je verzoeken om het modem te herstarten door deze gedurende 20 seconden stroomloos te houden. Koppel ook de Pi eventjes los en vergeet het wifi-netwerk. Voeg daarna de Pi weer aan het netwerk toe, dan voer ik een reprovisie uit en zou het weer moeten werken. De mesh-functie blijft aanstaan omdat deze nu bij default aanstaat, zie ik. Dit kun je in de configuratie-instellingen op het modem aanpassen.
Als aanvulling op wat je hierboven constateert: indien er toch een firmware update is uitgerold, kan die enkel opgehaald worden wanneer het modem juist herstart is. Normaliter gebeurt dit automatisch, maar ik zie een WAN-uptime van 15 dagen en vermoed dat dit niet gebeurd is - als het klopt.
Het topic waar jij naar linkt, betrof de Mpro-app, dat is een app die Zyxel ontwikkeld heeft ter ondersteuning van de wifipunten en het mesh-netwerk. Dit staat los van de instellingen die de T50 heeft op mesh-niveau. Indien de mesh na bovenstaande stappen nog steeds automatisch blijft opkomen, laat het me weten, dan ga ik kijken of we een alternatief kunnen bedenken.
Aanvulling op de aanvulling (sorry): ik zie nu na een nieuwe meting gedraaid te hebben, dat er drie apparaten oppoppen met alle drie een lease time error. Het gaat om apparaten met MAC-adressen die ik je per privébericht zal toesturen - dit moge we uit veiligheidsoverwegingen niet openbaar delen.
Ik vermoed nog steeds dat dit zorgt voor de uitval, naast of los van de disconnect en deauth die je hierboven beschrijft. Het kan ook goed zijn dat de deauth ontstaat door de lease-problemen.
“Het topic waar jij naar linkt, betrof de Mpro-app, dat is een app die Zyxel ontwikkeld heeft ter ondersteuning van de wifipunten en het mesh-netwerk.”
Waar lees je dat de andere gebruiker de Mpro app gebruikt??
Hij schrijft juist “Ik heb de 'Mpro Mesh' setting uit staan omdat ik deze niet gebruik”
Dat komt op mij over dat de andere gebruiker -net als mij- geen Mesh netwerk heeft, ook geen Mpro app gebruik maakt, maar simpelweg de “Mpro Mesh” instelling in de webinterface heeft uitgeschakeld.
Om er vervolgens achter te komen dat na verloop van tijd de instelling automatisch weer aan gaat.
De mesh-functie blijft aanstaan omdat deze nu bij default aanstaat, zie ik. Dit kun je in de configuratie-instellingen op het modem aanpassen.
Het probleem is dus dat als ik (en de andere gebruiker) deze in de configuratie instelling van de modem -in de webinterface van de modem- uit zet, hij na enige tijd vanzelf weer aan gaat…
@Max_nl Ik zou je graag willen adviseren om eerst het probleem met de lease-time te herstellen. Zonder dat dit gecheckt is, wordt het uitsluiten van andere issues erg lastig.
Wat betreft de easymesh-functie op default: de Zyxel T50 en T54 hebben beide standaard de mesh-functie ingebouwd staan. Deze wordt geactiveerd op het moment dat je gebruikmaakt van mesh in het draadloze netwerk, maar staat zelf in principe altijd “aan”. Dat klinkt even gek, maar ligt aan de manier waarop de functie gebouwd is. Zie het een beetje net als bandsteering waarbij altijd automatisch gezocht wordt naar het voorkeursnetwerk (afhankelijk van dekking bijvoorbeeld). Je kunt dit echter wel uitschakelen wanneer je inlogt op het modem. Ik zou alleen niet weten of dit van invloed is op het connecten met de Raspberry Pi omdat je immers geen gebruikmaakt van mesh. Die melding lijkt, voor mij in ieder geval, elders vandaan te komen.
De reden dat ik de app benoemde in dat specifieke topic, is omdat ik in de waan was dat het daarom ging en er geen gehoor meer op kreeg. Toen hebben we het topic gesloten. Dat is natuurlijk een verkeerde aanname geweest en nu ik jouw verhaal naast dat van die user leg, zou het best weleens helemaal overeen kunnen komen - zeer scherp, goed dat je het aankaart!
Nu op naar de oplossing - ervan uitgaande dat ook de lease-time gefixt is - het gaat er dus om dat mesh de communicatie verstoort met de Pi, hoe dit dan ook eventueel gebeurt, het is evident dat je zonder mesh geen issue ervaart. Kun je de functie helemaal uitschakelen, dan het modem herstarten en controleren of deze nog steeds uitstaat? Het handmatig aanpassen hiervan, zou namelijk niet onderhevig moeten zijn aan een simpele herstart.
Je kunt dit echter wel uitschakelen wanneer je inlogt op het modem.
Ik heb deze dus gister opnieuw uitgeschakelt, en vandaag staat deze gelukkig nog steeds uit:
Maar de ervaring van mij en de andere gebruiker is dat deze na verloop van tijd vanzelf weer in de webinterface “aan” gaat.
Ondanks dat ik zeker weet dat ik deze uit heb gezet, en ik erna niet meer aan de instellingen gezeten heb.
@Max_nl Ik zou je graag willen adviseren om eerst het probleem met de lease-time te herstellen. Zonder dat dit gecheckt is, wordt het uitsluiten van andere issues erg lastig.
Mijn probleem is 100% reproduceerbaar.
Als deze instelling aan staat wordt de Pi om de minuut door de Zyxel van het netwerk gegooid.
Zet de instelling uit en het treed niet op.
Zet de instelling aan, en het probleem treed op.
Zet de instelling uit en het treed niet op.
Wat heeft het dan voor zin om naar DHCP problemen te kijken?
De apparaten met de genoemde MAC addressen gebruiken geen DHCP, maar hebben een statisch IP adres.
Goede punten, thanks voor je toelichtingen! Ik denk dat mijn kennis hiertoe niet ver genoeg reikt, daarom schakel ik graag de expertise van één van onze specialisten in.
@Jaap Heb jij hier een zinniger antwoord op en kunnen we het zodanig inbouwen dat die mesh-functie niet automatisch weer inschakelt na een tijdje?
@Max_nl
Even als meedenkertje.
De statische adressen bevinden zich buiten de DHCP pool?
Bovenstaande schermdump laat zien dat de DHCP pool van adres 51 t.e.m. 254 loopt.
>De statische adressen bevinden zich buiten de DHCP pool?
IPs zijn op een andere manier gereserveerd.
(Heb ze onder static DHCP ingevoerd, hoewel er niet daadwerkelijk van DHCP gebruik gemaakt wordt om niet afhankelijk van de router te zijn.)
Maar is verder het probleem hier niet.
Dat zou een probleem kunnen zijn als de Pi hetzelfde IP-adres toebedeeld zou krijgen als een van de devices met statisch IP, maar dat is niet het geval.
Het gaat er niet over of de ip’s op een andere manier gereserveerd zijn maar of de DHCP server niet in de war kan raken en de gereserveerde IP’s toch denkt te kunnen gebruiken.
programmeurs hebben soms “eigen” gedachten over hoe iets te implementeren …
Daarom de gedachte; Better safe than sorry, en een dhcp pool instellen is mogelijk in de aangepaste tmobile firmware van de router dus waarom het achterwege laten
Hi @Max_nl ,
Kan je de wifi kaart van de Pi in monitor mode zetten een wifi trace maken. Deze informatie kan zeer waardevol voor de developers.
>Kan je de wifi kaart van de Pi in monitor mode zetten een wifi trace maken.
Wordt met de standaard kernel die bij RPI OS zit niet ondersteund.
(Wellicht dat alternatieve Linux distributies als Kali daar wel kernel patches voor hebben, maar dat heb ik niet geprobeert).
De logging van wpa_supplicant opvoeren, geeft verder ook niet meer informatie dan dat hij steeds een deauthentication frame van de Zyxel ontvangt.
En waarom dat alleen gebeurt als Mpro Mesh aan staat.
Hi @Max_nl, super dat je dit gelijk kon delen! Ik wil graag vragen of jullie @TechRacing93 en @yalerta hier met jullie expertise verder bij kunnen helpen? Mijn dank is groot!
Wordt met de standaard kernel die bij RPI OS zit niet ondersteund.
(Wellicht dat alternatieve Linux distributies als Kali daar wel kernel patches voor hebben, maar dat heb ik niet geprobeert).
Als dat zou kunnen proberen graag . Deze informatie is nuttig om te zien wat er precies gebeurd aan de Pi kant. Dan kan misschien verklaard worden waarom de Zyxel de DEAUTH stuurt. En het eventueel fixen natuurlijk.
Zou je ook eens kunnen kijken met “sudo lsmod” welke driver er voor de BRCM geinstalleerd is.
Ook met Kali op de Pi zelf lukt de monitor mode niet.
Monitor ik het 2.4 Ghz kanaal vanaf een andere computer, dan lijkt het erop alsof de deauthentication vanuit het niets gebeurt.
Het ene moment gaan er gewoon pakketjes heen en weer, en 0.01 seconde later verstuurd de Zyxel een “deauthentication” met inderdaad reason code 6 “Class 2 frame received from nonauthenticated STA”. Alleen als mesh aan staat.
Andere kleine verschillen:
- Bij de probe response geeft de Zyxel andere extended capabilities als Mesh aan staat.
20/40 BSS Coexistence management support: supported QoS map: not supported WMN Notification: not supported
- Bij association response geeft hij met mesh aan inderdaad ondersteuning te hebben voor Wifi Easy-Mesh (“multi-AP Extension”, “Fronthaul BSS”)
- Bij authenticatie lijkt er al iets niet helemaal lekker te gaan als mesh aan staat. Dan stuurt de Zyxel EAPOL key “message 1 of 4” meerdere keren zeer snel achter elkaar. (reproduceerbaar, gebeurt telkens als Mesh aan staat).
Na authenticatie geen bijzonderheden tot de deauthentication.
Zonder mesh treed hij niet in herhaling:
Wifi chipset op dit model Pi 400 is de BCM43456
Linux 5.15.32-v8+ (downstream tree van raspberrypi zelf).
Kernel module is brcmfmac.
Firmware versie volgens dmesg:
n 5.806016] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43456-sdio for chip BCM4345/9 r 5.820664] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4345/9 wl0: May 14 2020 17:26:08 version 7.84.17.1 (r871554) FWID 01-3d9e1d87
@Max_nl
Easy mesh doet niet alleen meerdere ap maar ook wisselen tussen 2,4 en 5Ghz. Soms werkt het beter om je 2,4 en 5Ghz een andere naam te geven. In het begin had ik hier wel last van maar de laatste tijd eigenlijks niet meer. Wellicht is dit iets waar het modem team naar kan kijken. Dan kijk ik @Jaap even voor aan.
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.
Bestand scannen voor virussen
Sorry, we zijn de inhoud van dit bestand nog aan het controleren om er zeker van te zijn dat het veilig is om te downloaden. Probeer het nog een keer over een paar minuten.
. Deze informatie is nuttig om te zien wat er precies gebeurd aan de Pi kant. Dan kan misschien verklaard worden waarom de Zyxel de DEAUTH stuurt. En het eventueel fixen natuurlijk.
