Update:

Superwifi gaat de tweede nacht in op kanaal 108. Op kanaal 52 is dit een fatale tijd voor mijn superwifi. Kijken wat het de komende uren en nacht gaat geven…

Vannacht lag superwifi er weer uit. De feiten:

08.03.2023 03:02:33 OWL-(VRV9517)IF[2.4G] STA_MAC(0A:C0:80:53:EB:65) is connected to AP_MAC(94:6A:B0:DA:5F:06) status: connected.
08.03.2023 03:02:23 OWL-SWP2-Bovenverdieping(C8:99:B2:54:D0:A1) leave topology
08.03.2023 03:02:05 OWL-(VRV9517)IF[5G] STA_MAC(0A:C0:80:53:EB:65) is connected to AP_MAC(94:6A:B0:DA:5F:07) status: connected.
08.03.2023 03:01:51 OWL-Sync config success
 

Dit is dus handmatig op kanaal 108 voor de volledigheid.
Wat vooral opvalt is het tijdstip dat overeenkomt met mijn eerdere post van enkele dagen geleden waar op kanaal 52 exact dit patroon in de log te zien is op hetzelfde tijdstip. Kanaal 52 en 108 overlappen niet in de frequentiereeks.

Even denken wat ik nog kan testen.

@Radioman: wat denk jij? Mijn veronderstelling is dat buiten kanaal 36-48 er radar kan storen, die op mijn locatie zeker aanwezig zal zijn. Maar is het aannemelijk dat op twee verschillende kanalen met frequenties die niet overlappen om de twee dagen, in de nacht en altijd rond 03:00 (er zit speling in van minuten/seconden) superwifi onderuit haalt. Handmatig kanaal 36 kiezen en superwifi haalde de 4 dagen in mijn test (en op zeker blijft superwifi dan ook online). Enig idee wat die sync config kan triggeren?

Ik dacht een nieuwe test te doen met kanaal 128 als handmatige keus. Daarop ging mijn superwifi op rood en was er geen beweging meer in te krijgen. Ook niet na herstart.

Daarop superwifi helemaal uitgezet zodat ik verbinding kon maken naar het modem. Het kanaal nu op auto, zonder weer gezet. Ik neem aan dat dit wil zeggen dat de weerradar niet zal storen. Opgeslagen.

Na een minuut of 5 wachten, om zeker te zijn dat het netwerk weer online was, heb ik superwifi weer aangezet. Deze werd in eerste instantie groen, knipperend groen en weer groen.

Dit zie ik ook weer terug in de log:

08.03.2023 09:16:20 OWL-Sync config success
08.03.2023 09:16:17 OWL-SWP2-Bovenverdieping(C8:99:B2:54:D0:A1) join topology
08.03.2023 09:15:30 OWL-SWP2-Bovenverdieping(C8:99:B2:54:D0:A1) leave topology
08.03.2023 09:15:05 OWL-Sync config success
08.03.2023 09:15:00 OWL-SWP2-Bovenverdieping(C8:99:B2:54:D0:A1) join topology

Door de owl sync config van 09:16:20 is de mesh configuratie van het modem doorgezet naar alle mesh punten dus ook mijn superwifi. Conclusie is dat na een rode lamp er geen complete reset nodig is.

Ik laat deze configuratie weer even staan en monitor wat het gedrag van mijn superwifi is de komende dagen. Met name in de nacht van donderdag op vrijdag zal naar ik verwacht cruciaal zijn. Rond 03:00 uiteraard 

De grote vraag blijft open wat er voor zorgt dat midden in de nacht een sync config veroorzaakt en dan superwifi offline brengt.

In de draadloos log zie ik overigens dat kanaal 52 is gekozen in de setting “auto, zonder weer”. Daar weet ik van dat het binnen twee dagen fataal is voor superwifi. Of de “zonder weer” optie verschil maakt is niet duidelijk, maar meten is weten. Ik ben er tot nu toe vanuit gegaan dat die optie een andere kanaalkeuze betekent maar er is vrolijk voor kanaal 52 gekozen. Wellicht wordt er iets anders geregeld met die “zonder weer” optie.

RSSI: 0 dBm    SNR: 0 dB    noise: -85 dBm    Channel: 52

Ik post als ik nieuws heb 

@Bram_ zou jij kunnen achterhalen wat de optie “zonder weer” bij de kanaalkeuze 5G exact doet?

@Roy74 

Zo te lezen hebben je testen weer meer vragen opgeroepen dan antwoorden gegeven.

Wat wel overeind blijft is dat, als je je kanaal fixed op 36 zet alles netjes blijft werken, in ieder geval langer dan 2 dagen. 

Wat ik zou proberen is om het kanaal eens vast te zetten op 38 ( of 40) en daarmee te checken of ook deze gewoon blijven werken. Hypothese daarachter, stel dat elke nacht toch nog een automatische kanaal selectie plaatsvindt en die selectie zou starten met kanaal 36. In je test van kanaal 36 , staat het kanaal al op 36 dus valt er daarom mogelijk niets uit. Door nu bv kanaal 38 vast te zetten , gaat mogelijk de automatische kanaal selectie toch 36 proberen en valt mogelijk toch het wifi punt uit. 

Het kost je weer wat tijd, maar niet geschoten is altijd mis.

@Radioman Er is nog iemand anders die nu ook op mijn verzoek een log heeft gepost. Ook rond 03:00 een sync config en vervolgens de fatale leave. Mogelijk heb ik nog iemand die log kan posten. Lijkt erop dat het geen lokale trigger is zoals DFS verdringing op een kanaal. Lijkt een trigger vanuit de apparatuur. Ik zat zelf te denken aan de auto channel in de 2G band. Testen zat nog en jouw suggestie voer ik uit na de lopende test. Goede optie inderdaad, ik zou graag het debuglevel eens willen ophogen nu…

Bedankt weer.

Nacht 1 na instellen kanaal op “auto, zonder weer”. Het gekozen kanaal door deze instelling is 52, te zien in de draadloos log. Het fatale kanaal dus. Meestal is het de twee nacht fataal, morgenvroeg maar weer afwachten.

Update:

Superwifi is nog altijd online. Gisteravond nog een uurtje aan het speuren geweest en kwam op een zijspoor door een oude post aangaande DHCP. Tot nu toe had ik mijn systeemlog bekeken met de focus op tijdstippen rondom het offline gaan van superwifi. Nu wat ruimer gekeken. De log stond toch aardig vol met DHCP meldingen en ook nog de nodige daemon errors. Het viel me op dat Superwifi aardig vaak een nieuw IP krijgt toegewezen, zoals gisteravond nog. Dit is te verklaren met de DHCP lease van 1 dag.

Mar  8 21:14:53 VRV9517 daemon.info dhcpd: DHCPNAK on 192.168.2.135 to c8:99:b2:54:d0:a1 via br0
Mar  8 21:14:53 VRV9517 daemon.info dhcpd: DHCPDISCOVER from c8:99:b2:54:d0:a1 (SWP2-54D0A1) via br0
Mar  8 21:14:53 VRV9517 daemon.debug dhcpd: ICMP Echo reply while lease 192.168.2.135 valid.
Mar  8 21:14:53 VRV9517 daemon.err dhcpd: Abandoning IP address 192.168.2.135: pinged before offer
Mar  8 21:14:57 VRV9517 daemon.err dhcpd: Error on ARPING request: Interrupted system call
Mar  8 21:14:57 VRV9517 daemon.info dhcpd: DHCPDISCOVER from c8:99:b2:54:d0:a1 via br0
Mar  8 21:14:57 VRV9517 daemon.info dhcpd: DHCPOFFER on 192.168.2.136 to c8:99:b2:54:d0:a1 (SWP2-54D0A1) via br0
Mar  8 21:14:57 VRV9517 daemon.info dhcpd: Reclaiming not used lease 192.168.2.136.
Mar  8 21:14:57 VRV9517 daemon.info dhcpd: DHCPREQUEST for 192.168.2.136 (192.168.2.254) from c8:99:b2:54:d0:a1 (SWP2-54D0A1) via br0
Mar  8 21:14:57 VRV9517 daemon.info dhcpd: DHCPACK on 192.168.2.136 to c8:99:b2:54:d0:a1 (SWP2-54D0A1) via br0

Het 135 adres was toegewezen aan superwifi, te zien aan het Mac adres. Die wordt afgewezen, DHCPNAK. Superwifi doet verzoek om IP aan DHCP en dan volgen er 2 errors. Ik ben geen netwerkspecialist maar het 135 adres is abandoned maar bereikbaar voor het aanboden wordt, een daemon error in de log als gevolg. Vervolgens wordt door DHCP (de modem) op verzoek van Superwifi het 136 adres toegewezen. Dat lukt en krijgt de bevestiging, DHCPACK.

Met dit in het achterhoofd gaan zoeken en dan vind ik ook de nodige gevallen ellende met mesh netwerken en DHCP, ook in combinatie met de v10a die niet uitblinkt in DHCP als ik rondlees. Advies is dan fixed IP gebruiken. Lijkt mij zinvol gezien de lease van 1 dag met dus ook een renew van 1 dag. En een stuiterende superwifi om de dag. Ring a bell? Mogelijk zit ik op een fout spoor met de kanaalkeuze. De communicatie tussen de modem en superwifi dient stabiel te zijn en is altijd aan. In theorie een kandidaat om uit DHCP te halen.

Besloten om de huidige test af te breken en superwifi te vooziem van fixed ip. Dat doe ik deze ochtend tussen het werk door. Update volgt.

Tussen de bedrijven door Superwifi voorzien van een fixed en reserved IP, buiten de DHCP pool maar in hetzelfde subnet.

Gezien de subnet mask zijn alleen de laatste 8 bits relevant, maakt 2^8=256 mogelijke IP's. De standaard DHCP pool is 1-200.

Ik heb er voor gekozen om het IP van superwifi buiten de DHCP pool te fixeren en reserved op basis van het MAC adres van superwifi. Het IP is nu 192.168.2.202. Ik zie superwifi inmiddels ook weer in de thuis app verschijnen met dit adres.

Daarna heb ik het Wifi 5G kanaal op auto gezet en geconstateerd in de wireless log dat kanaal 52 is toegewezen. Daarvan weet ik dat dit kanaal na maximaal 2 nachten fataal was voor superwifi.

Vooraf heb ik de modem 5 minuten spanningsloos gemaakt om zeker te weten dat deze clean is gestart.

Hopelijk brengt het fixed en reserved IP op basis van de MAC binding rust in de superwifi tent.

Om dit te bereiken moet je heel strikt een volgorde aanhouden omdat anders superwifi eindigt met een rode lamp. Het oude DHCP IP is namelijk nog assigned aan de superwifi.

Ik weet dat er wat mensen deze case volgen omdat ze ook een stuiterende superwifi in combinatie met de v10a hebben. Wacht maar even met deze stap. Als blijkt dat superwifi nu wel online blijft op kanaal 52 (of een ander kanaal) en het dus ligt aan DHCP perikelen dan loods ik jullie er op verzoek wel door.

Ik ben weer aan het werk
Ik post als er wat te melden is en dat kost even wat tijd.

Update:

Ik werd middels een PB voorzien van wat correcties op mijn post. Ik ben geen netwerkman en had een aanname gemaakt die niet juist bleek. Maakt voor de test niet zo veel uit want het gaat uiteindelijk erom superwifi van een IP adres te voorzien dat niet wijzigt door de DHCP leasetijd.

Mijn aanname was door een IP buiten de pool te kiezen ik een fixed IP had, Dat is niet juist, fixeren doe je op de NIC van het device en dat gaat mijn inziens niet meer sinds superwifi niet meer apart te benaderen is.

Door te reserveren in de DHCP pool voorkom ik vanuit een centrale locatie dat superwifi een ander IP krijgt. Dat is het doel. Daarom ga ik het IP kiezen binnen de DHCP pool maar reserved. Ik ga voor de 199 omdat deze nog vrij is.

Overigens blijkt superwifi draadloos te verbinden over 5G. Iedere interface heeft een eigen MAC dus daar is ook rekening mee te houden als je gaat reserveren. Voor de test is mijn configuratie voorlopig even afdoende.

Edit:

IP adres 192.168.2.199 reserved. Modem herstart. Superwifi online (groen) met dit IP (checked).

Kanaal 5G:

RSSI: 0 dBm    SNR: 0 dB    noise: -85 dBm    Channel: 52

Nu afwachten en hopen dat stabiel werkt. Achtergrond van deze zijweg is nu wat vroeg. Mogelijk is er nog een optie om te proberen mocht dit niet werken.

Dat kreng zal online blijven!

Superwifi nog online na reboot en reserved toewijzing van IP, kanaal 52. De reden dat ik vanmorgen eerst deze weg ingeslagen ben, waren de nodige DHCP meldingen in de systeemlog met betrekking tot superwifi. Dat leek mij niet goed te gaan met het vernieuwen van IP’s. Toen ik deze situatie aantrof in de DHCP tabel was dat afdoende om de zijweg te nemen met de hoogste prio. Het SuperWifi Mac van de 5G adapter kwam meerdere keren voor met een ander IP, zeker 15 maal. Leg dat naast de log en dan is het zorgelijk. Andere devices stonden er keurig netjes in met 1 entry. Nu staat superwifi er ook weer netjes 1 keer in met reserved het 199 adres. We gaan zo nacht 1 in.
 

Superwifi nog online. Vanmiddag en in het begin van de avond verlopen er veel leases. Superwifi moet met rust gelaten worden. Ik monitor vandaag.

@Roy74 ik heb al even niet gereageerd in dit topic. Vooral omdat het allemaal goed loopt. Maar ik wil je tussendoor toch even nog een keer bedanken voor de nauwkeurigheid waarmee je dit doet. 

Superwifi nog altijd online. Gelukkig want vanmiddag het ik een virtual cursus.

De lease was afgelopen miidag rond 13:45 en door het reserveren van het IP door binden van het MAC adres van Superwifi (device MAC) is dit hetzelfde IP gebleven. 

Mar 10 13:46:58 VRV9517 daemon.info dhcpd: adapter index 17
Mar 10 13:47:09 VRV9517 daemon.info dhcpd: arp replies from this address (192.168.2.199).
Mar 10 13:47:09 VRV9517 daemon.info dhcpd: arp replies from this address (192.168.2.199).
Mar 10 13:47:09 VRV9517 daemon.info dhcpd: Reclaiming not used lease 192.168.2.199.
Mar 10 13:47:09 VRV9517 daemon.info dhcpd: DHCPREQUEST for 192.168.2.199 from c8:99:b2:54:d0:a1 (SWP2-54D0A1) via br0
Mar 10 13:47:09 VRV9517 daemon.info dhcpd: DHCPACK on 192.168.2.199 to c8:99:b2:54:d0:a1 (SWP2-54D0A1) via br0

Als ik me goed heb ingelezen doet het arp request een bevraging op de arp table met daarin een entry waarin MAC en IP aan elkaar zijn gekoppeld. Daar staat het superwifi device MAC gekoppeld aan het reserved 199 adres. Lijkt dus allemaal goed te gaan. Er volgt in ieder geval geen nieuw IP. Eerder veel abandoned meldingen met als resultaat een nieuw IP voor Superwifi en de genoemde dubbele entries voor hetzelfde MAC adres met verschillende IP's (althans dat is wat ik logisch beredeneer). Nu ziet het er "clean” uit en gaan we de cruciale 2e nacht in op kanaal 52 (auto).

De volgende lease verloopt pas morgenmiddag.

Morgenvroeg kijken of superwifi nog online is...

Update 

Superwifi is de nacht doorgekomen! Eerder zou kanaal 52 fataal zijn. In de mesh log valt op dat er nu geen sync config te zien is rond 3 uur. Gedurende de nacht een normaal patroon van devices die verbinden naar modem en superwifi. De log rond 03:00 waar het normaal superwifi er mee zou stoppen:

11.03.2023 04:08:35 OWL-(VRV9517)IFF2.4G] Legacy Device STA_MAC(C0:D2:F3:86:EE:54) is connected to AP_MAC(94:6A:B0:DA:5F:06) status: connected.
11.03.2023 04:02:09 OWL-(VRV9517)IFF2.4G] Legacy Device STA_MAC(C0:D2:F3:86:EE:54) is connected to AP_MAC(94:6A:B0:DA:5F:06) status: connected.
11.03.2023 02:53:51 OWL-(VRV9517)IFF2.4G] Legacy Device STA_MAC(B0:41:1D:3D:1E:D3) is connected to AP_MAC(94:6A:B0:DA:5F:06) status: connected.

in de systeemlog valt op dat er veel minder in geschreven is. De DHCP entries volgen het normale lease patroon. Geen abandoned leases meer te zien en ik zie dat twee van de abandoned ip’s, de 134 en 135, inmiddels zijn uitgedeeld aan andere devices. Eerder waren ze assigned aan superwifi en stonden ze ook in de DHCP tabel met hetzelfde Mac adres.

Het ip van superwifi is het reserved ip zoals verwacht. Lease moment is om 18:18 en dat zal hetzelfde patroon opleveren als gistermiddag rond 13:45 is de verwachting. Zonder een verklaring te geven waar ik wel een idee bij heb, laat ik mijn netwerk in deze configuratie staan om te meten of dit stabiel blijft. Ik denk zelf wel.

Waarom kanaal 36 eerder ook stabiel bleef en nu de auto optie op kanaal 52 dat ook lijkt…

Lintje voor superwifi, zolang deed ie het nog niet op de auto kanaalkeuze . Kan ie definitief op zijn vaste plekje? Dat zien we morgenvroeg.

Heel even kort berichtje, komt net thuis na 36u weg te zijn en zie dat superwifi eruit ligt… Hier alvast even de log en een printscreen van m’n instellingen. Zie dat ik wat berichten heb gemist, maar die lees ik morgen even uitgebreid..

11.03.2023 12:26:27 OWL-(VRV9517)IF55G] STA_MAC(B2:D1:15:50:37:5B) is connected to AP_MAC(78:DD:12:CA:3C:B2) status: connected.

11.03.2023 12:08:06 OWL-IFO5G]:STA(B2:D1:15:50:37:5B) BTM Black List Added

11.03.2023 12:08:06 OWL-(VRV9517)IF55G] STA_MAC(B2:D1:15:50:37:5B) is connected to AP_MAC(78:DD:12:CA:3C:B2) status: connected.

11.03.2023 12:07:04 OWL-(VRV9517)IF55G] (BTM) STA_MAC(B2:D1:15:50:37:5B) form Original MAC(6A:DD:12:CA:3C:B1) to Target MAC(6A:86:60:64:27:41) Reason:(RSSI_Low AP_ROAM) Status: start.

11.03.2023 12:06:34 OWL-(VRV9517)IF55G] STA_MAC(B2:D1:15:50:37:5B) is connected to AP_MAC(78:DD:12:CA:3C:B2) status: connected.

11.03.2023 03:15:07 OWL-(VRV9517)IF55G] Legacy Device STA_MAC(18:B4:30:89:1C:89) is connected to AP_MAC(78:DD:12:CA:3C:B2) status: connected.

11.03.2023 03:13:01 OWL-(VRV9517)IF55G] Legacy Device STA_MAC(38:42:0B:72:9F:4A) is connected to AP_MAC(78:DD:12:CA:3C:B2) status: connected.

11.03.2023 03:12:59 OWL-(VRV9517)IF55G] STA_MAC(E2:A9:F7:90:F5:A9) is connected to AP_MAC(78:DD:12:CA:3C:B2) status: connected.

11.03.2023 03:12:32 OWL-SuperWifi Keuken(D4:86:60:64:27:40) leave topology

11.03.2023 03:12:27 OWL-(VRV9517)IF55G] STA_MAC(70:09:71:AB:16:B4) is connected to AP_MAC(78:DD:12:CA:3C:B2) status: connected.

11.03.2023 03:11:57 OWL-Sync config success

11.03.2023 02:44:25 OWL-(VRV9517)IF55G] STA_MAC(70:09:71:AB:16:B4) is connected to AP_MAC(78:DD:12:CA:3C:B2) status: connected.

11.03.2023 02:42:28 OWL-(SuperWifi Keuken)IFk5G] STA_MAC(16:48:E5:B8:89:A2) is connected to AP_MAC(6A:86:60:64:27:41) status: connected.

11.03.2023 02:22:37 OWL-(SuperWifi Keuken)IFk2.4G] STA_MAC(B2:D1:15:50:37:5B) is connected to AP_MAC(72:86:60:64:27:42) status: connected.

11.03.2023 01:50:58 OWL-(SuperWifi Keuken)IFk5G] (BTM) STA_MAC(16:48:E5:B8:89:A2) form Original MAC(6A:86:60:64:27:41) to Target MAC(72:86:60:64:27:42) Reason:(RSSI_Low 5G->2G) Status: start.

11.03.2023 01:24:57 OWL-(SuperWifi Keuken)IFk5G] (BTM) STA_MAC(B2:D1:15:50:37:5B) form Original MAC(6A:86:60:64:27:41) to Target MAC(72:86:60:64:27:42) Reason:(RSSI_Low 5G->2G) Status: start.

11.03.2023 01:19:28 OWL-(SuperWifi Keuken)IFk5G] STA_MAC(B2:D1:15:50:37:5B) is connected to AP_MAC(6A:86:60:64:27:41) status: connected.

11.03.2023 01:19:03 OWL-(SuperWifi Keuken)IFk2.4G] (BTM) STA_MAC(B2:D1:15:50:37:5B) form Original MAC(72:86:60:64:27:42) to Target MAC(72:86:60:64:27:42) Reason:(RSSI_Low 5G->2G) Status: finish.

11.03.2023 01:19:03 OWL-(SuperWifi Keuken)IFk2.4G] STA_MAC(B2:D1:15:50:37:5B) is connected to AP_MAC(72:86:60:64:27:42) status: connected.

11.03.2023 01:18:58 OWL-(SuperWifi Keuken)IFk5G] (BTM) STA_MAC(B2:D1:15:50:37:5B) form Original MAC(6A:86:60:64:27:41) to Target MAC(72:86:60:64:27:42) Reason:(RSSI_Low 5G->2G) Status: start.

11.03.2023 01:13:02 OWL-(SuperWifi Keuken)IFk5G] STA_MAC(B2:D1:15:50:37:5B) is connected to AP_MAC(6A:86:60:64:27:41) status: connected.

11.03.2023 01:12:03 OWL-(SuperWifi Keuken)IFk2.4G] (BTM) STA_MAC(B2:D1:15:50:37:5B) form Original MAC(72:86:60:64:27:42) to Target MAC(72:86:60:64:27:42) Reason:(RSSI_Low 5G->2G) Status: finish.

11.03.2023 01:12:03 OWL-(SuperWifi Keuken)IFk2.4G] STA_MAC(B2:D1:15:50:37:5B) is connected to AP_MAC(72:86:60:64:27:42) status: connected.

11.03.2023 01:11:58 OWL-(SuperWifi Keuken)IFk5G] (BTM) STA_MAC(B2:D1:15:50:37:5B) form Original MAC(6A:86:60:64:27:41) to Target MAC(72:86:60:64:27:42) Reason:(RSSI_Low 5G->2G) Status: start.

11.03.2023 01:06:36 OWL-(SuperWifi Keuken)IFk5G] STA_MAC(B2:D1:15:50:37:5B) is connected to AP_MAC(6A:86:60:64:27:41) status: connected.

11.03.2023 01:06:03 OWL-(SuperWifi Keuken)IFk2.4G] (BTM) STA_MAC(B2:D1:15:50:37:5B) form Original MAC(72:86:60:64:27:42) to Target MAC(72:86:60:64:27:42) Reason:(RSSI_Low 5G->2G) Status: finish.

11.03.2023 01:06:03 OWL-(SuperWifi Keuken)IFk2.4G] STA_MAC(B2:D1:15:50:37:5B) is connected to AP_MAC(72:86:60:64:27:42) status: connected.

11.03.2023 01:05:58 OWL-(SuperWifi Keuken)IFk5G] (BTM) STA_MAC(B2:D1:15:50:37:5B) form Original MAC(6A:86:60:64:27:41) to Target MAC(72:86:60:64:27:42) Reason:(RSSI_Low 5G->2G) Status: start.

11.03.2023 01:00:30 OWL-(SuperWifi Keuken)IFk5G] STA_MAC(B2:D1:15:50:37:5B) is connected to AP_MAC(6A:86:60:64:27:41) status: connected.

11.03.2023 01:00:02 OWL-(SuperWifi Keuken)IFk2.4G] (BTM) STA_MAC(B2:D1:15:50:37:5B) form Original MAC(72:86:60:64:27:42) to Target MAC(72:86:60:64:27:42) Reason:(RSSI_Low 5G->2G) Status: finish.

11.03.2023 01:00:02 OWL-(SuperWifi Keuken)IFk2.4G] STA_MAC(B2:D1:15:50:37:5B) is connected to AP_MAC(72:86:60:64:27:42) status: connected.

11.03.2023 00:59:57 OWL-(SuperWifi Keuken)IFk5G] (BTM) STA_MAC(B2:D1:15:50:37:5B) form Original MAC(6A:86:60:64:27:41) to Target MAC(72:86:60:64:27:42) Reason:(RSSI_Low 5G->2G) Status: start.

11.03.2023 00:54:43 OWL-(SuperWifi Keuken)IFk5G] STA_MAC(B2:D1:15:50:37:5B) is connected to AP_MAC(6A:86:60:64:27:41) status: connected.

11.03.2023 00:54:02 OWL-(SuperWifi Keuken)IFk2.4G] (BTM) STA_MAC(B2:D1:15:50:37:5B) form Original MAC(72:86:60:64:27:42) to Target MAC(72:86:60:64:27:42) Reason:(RSSI_Low 5G->2G) Status: finish.

11.03.2023 00:54:02 OWL-(SuperWifi Keuken)IFk2.4G] STA_MAC(B2:D1:15:50:37:5B) is connected to AP_MAC(72:86:60:64:27:42) status: connected.

11.03.2023 00:53:58 OWL-(SuperWifi Keuken)IFk5G] (BTM) STA_MAC(B2:D1:15:50:37:5B) form Original MAC(6A:86:60:64:27:41) to Target MAC(72:86:60:64:27:42) Reason:(RSSI_Low 5G->2G) Status: start.

11.03.2023 00:48:57 OWL-(SuperWifi Keuken)IFk5G] (BTM) STA_MAC(16:48:E5:B8:89:A2) form Original MAC(6A:86:60:64:27:41) to Target MAC(72:86:60:64:27:42) Reason:(RSSI_Low 5G->2G) Status: start.

11.03.2023 00:48:16 OWL-(SuperWifi Keuken)IFk5G] STA_MAC(B2:D1:15:50:37:5B) is connected to AP_MAC(6A:86:60:64:27:41) status: connected.

11.03.2023 00:48:02 OWL-(SuperWifi Keuken)IFk2.4G] (BTM) STA_MAC(B2:D1:15:50:37:5B) form Original MAC(72:86:60:64:27:42) to Target MAC(72:86:60:64:27:42) Reason:(RSSI_Low 5G->2G) Status: finish.

11.03.2023 00:48:02 OWL-(SuperWifi Keuken)IFk2.4G] STA_MAC(B2:D1:15:50:37:5B) is connected to AP_MAC(72:86:60:64:27:42) status: connected.

11.03.2023 00:47:58 OWL-(SuperWifi Keuken)IFk5G] (BTM) STA_MAC(B2:D1:15:50:37:5B) form Original MAC(6A:86:60:64:27:41) to Target MAC(72:86:60:64:27:42) Reason:(RSSI_Low 5G->2G) Status: start.

11.03.2023 00:01:14 OWL-(SuperWifi Keuken)IFk5G] STA_MAC(B2:D1:15:50:37:5B) is connected to AP_MAC(6A:86:60:64:27:41) status: connected.

10.03.2023 23:53:41 OWL-(SuperWifi Keuken)IFk2.4G] STA_MAC(B2:D1:15:50:37:5B) is connected to AP_MAC(72:86:60:64:27:42) status: connected.

10.03.2023 23:47:53 OWL-(SuperWifi Keuken)IFk5G] (BTM) STA_MAC(16:48:E5:B8:89:A2) form Original MAC(6A:86:60:64:27:41) to Target MAC(72:86:60:64:27:42) Reason:(RSSI_Low 5G->2G) Status: start.

10.03.2023 23:46:59 OWL-(SuperWifi Keuken)IFk5G] STA_MAC(B2:D1:15:50:37:5B) is connected to AP_MAC(6A:86:60:64:27:41) status: connected.

10.03.2023 23:46:53 OWL-(SuperWifi Keuken)IFk5G] (BTM) STA_MAC(B2:D1:15:50:37:5B) form Original MAC(6A:86:60:64:27:41) to Target MAC(72:86:60:64:27:42) Reason:(RSSI_Low 5G->2G) Status: start.

10.03.2023 23:41:57 OWL-(SuperWifi Keuken)IFk5G] STA_MAC(16:48:E5:B8:89:A2) is connected to AP_MAC(6A:86:60:64:27:41) status: connected.

10.03.2023 23:41:26 OWL-(SuperWifi Keuken)IFk5G] (BTM) STA_MAC(B2:D1:15:50:37:5B) form Original MAC(6A:86:60:64:27:41) to Target MAC(6A:86:60:64:27:41) Reason:(RSSI_Low AP_ROAM) Status: finish.

@Leines1234 , ik was me al zorgen aan het maken dat je van het krukje was gevallen bij het reiken naar die vervelende superwifi. Inmiddels heb ik een zijstraat genomen in de analyse omdat ik daar een hele goede aanleiding voor had. Ik heb superwifi nu al twee nachten op kanaal 52 in de lucht. Weet eindelijk nagenoeg zeker wat er aan de hand is.

Ik zie weer hetzelfde patroon. Sync en leave rond 03:00.

Lees even de laatste pagina van de post van Harry met daarin wat posts van mij met ergens een hele lange instructie.

En die ga jij ook doen 

Maar eerst: wil je even kijken bij: network - LAN - LAN DHCP. Klik daar op de knop “add”.

Je ziet daar een lijst waar je ook doorheen kunt scrollen. Je ziet daar ook superwifi staan met als host name SWP2-54D0A1. Zie je daar superwifi onder hetzelfde Mac adres terugkomen met meerdere verschillende IP’s? Zoals het hieronder uitziet.

Dan even cancelen en niet opslaan. Wil je er een screenshot van maken en dan posten.

Je gaat dan je eerste IP reservering in je leven maken. No worries, we loodsen je er doorheen. Dit is een workaround die je mag laten staan. Als morgen mijn superwifi nog draait waar ik bijna zeker van ben, dan zal ik de moderator informeren over het waarom. Harry is het vandaag ook gelukt en die heeft morgen en de komende dagen wellicht ook witte rook.
 

Update:

Superwifi liet me in de steek. En weer rond 03:00 maar nu in de derde nacht.

12.03.2023 03:05:04 OWL-SWP2-Bovenverdieping(C8:99:B2:54:D0:A1) leave topology
12.03.2023 03:04:44 OWL-(VRV9517)IF[5G] STA_MAC(1E:7F:FA:06:D3:05) is connected to AP_MAC(94:6A:B0:DA:5F:07) status: connected.
12.03.2023 03:04:29 OWL-Sync config success
 

Ik zie wel nog steeds en zoals verwacht maar 1 entry in de DHCP tabel met het reserved IP. De DHCP situatie was niet goed maar kennelijk was het niet de oorzaak van het verlaten van superwifi uit de mesh. 1 probleem minder maar het probleem waarmee het begon is er nog steeds.

Verder met de test “auto zonder weer” en weer monitoren.

De actieve kanalen. 2G auto en 5G op auto,geen weer.

RSSI: 0 dBm    SNR: 0 dB    noise: -92 dBm    Channel: 11
RSSI: 0 dBm    SNR: 0 dB    noise: -87 dBm    Channel: 52

Wat zorgt er voor dat superwifi disconnect…

Systeemlog rond verbroken superwifi

Mar 12 01:43:42 VRV9517 daemon.info dhcpd: Information-request message from fe80::101c:22d6:6d0a:2044 port 546, transaction ID 0x49156C00
Mar 12 01:43:42 VRV9517 daemon.info dhcpd: Sending Reply to fe80::101c:22d6:6d0a:2044 port 546
Mar 12 02:50:53 VRV9517 daemon.err wlan_monitor[4841]: start_monitor:[260] wl0 phy_ed_thresh = [-45 ]
Mar 12 03:04:18 VRV9517 daemon.err wlan_monitor[4841]: start_monitor:[247] Check wireless function done.
Mar 12 03:05:10 VRV9517 daemon.info dhcpd: DHCPDISCOVER from c4:93:00:22:97:60 (smile22975e) via br0

Na wat nadenken (en veel lezen) over deze puzzel de voorlopige conclusie en gedachte:

• De v10a en DHCP kent wat problemen. Met name superwifi zorgt voor onwenselijke dubbele entries in de DHCP tabel. Niet alleen bij mij maar aantoonbaar bij meerdere mensen. De oplossing als workaround is reserved IP voor superwifi. Andere devices veroorzaken dit niet bij mij maar dat kan anders zijn bij anderen. Heeft aandacht nodig.
• Hoe meer ik lees over interferentie op de 5Ghz band, hoe meer ik twijfel of de auto channel optie de beste is. Ik haal tot nu toe de meest stabiele situatie op kanaal 36. Radar interferentie flauwekul? Nee dat denk ik niet. Ik heb in de omgeving voldoende van deze factoren.
• Superwifi bekabeld aansluiten? Als het even kan wel. Maar de realiteit is dat veel mensen juist superwifi hebben/willen omdat er geen kabels liggen. Ik ook. Wifi backhaul moet wel stabiel zijn en zo niet dan levert dat haperende superwifi op lijkt mij. Wat er rond 03:00 een mesh sync config veroorzaakt is me nog niet duidelijk. Meest waarschijnlijke lijkt de auto channel functionaliteit. Bij veel anderen komt dit tijdstip terug als oorzaak bij een leave topology.
• De documentatie in de modem mag wel wat uitgebreider. Ik mis wat uitleg over wat opties zoals de “geen weer” optie bij de kanaalkeuze. De kanaalkeuze blijft gelijk merk ik maar wat doet deze optie dan exact op de achtergrond.
• De v10a is wifi5, box10 is WiFi6. Superwifi is wifi6 en tri band(dat klopt?). Als ik me goed ingelezen heb maakt de backhaul gebruik van een extra 5Ghz band. In wifi6 hoeft het zendvermogen bij bounding channels niet gedeeld te worden als ik het goed begrijp. Potentieel lijkt dit goed. Maar op WiFi5 kan het ook zorgen voor meer ruis en interferentie. De v10a is WiFi5. Misschien is het ook nog de moeite waard om de standaard bandbreedte van 80Mhz een terug te zetten naar bijvoorbeeld een bandbreedte van 40Mhz met minder ruis en interferentie, lees meer stabiliteit in ruil voor minder snelheid. Met een abo van 100mbps is het minder relevant om tot de max te gaan lijkt mij. Doel bij mij is wireless tv+ aansluiten en daarvoor is dadelijk met HD+ zenders 14mbps per stream nodig. En wat surfen ernaast zal dan ook nog wel lukken. Kan voor iemand anders niet gelden natuurlijk maar misschien is hier less is more wel het credo. Ik ga de lagere bandbreedte ook nog testen in mijn gevecht voor een stabiele superwifi.

Ik ben zeker geen WiFi specialist maar lees er momenteel veel over om dit probleem op te lossen. Maak ik een fout in de redenatie dan hoor ik dat graag. Learning on the job!

Voor de liefhebbers nog een stukje log aangaande de DHCP problematiek van superwifi voordat ik besloot tot reserved IP:

Mar  8 21:14:53 VRV9517 daemon.info dhcpd: DHCPNAK on 192.168.2.135 to c8:99:b2:54:d0:a1 via br0
Mar  8 21:14:53 VRV9517 daemon.info dhcpd: DHCPDISCOVER from c8:99:b2:54:d0:a1 (SWP2-54D0A1) via br0
Mar  8 21:14:53 VRV9517 daemon.debug dhcpd: ICMP Echo reply while lease 192.168.2.135 valid.
Mar  8 21:14:53 VRV9517 daemon.err dhcpd: Abandoning IP address 192.168.2.135: pinged before offer
Mar  8 21:14:57 VRV9517 daemon.err dhcpd: Error on ARPING request: Interrupted system call
Mar  8 21:14:57 VRV9517 daemon.info dhcpd: DHCPDISCOVER from c8:99:b2:54:d0:a1 via br0
Mar  8 21:14:57 VRV9517 daemon.info dhcpd: DHCPOFFER on 192.168.2.136 to c8:99:b2:54:d0:a1 (SWP2-54D0A1) via br0
Mar  8 21:14:57 VRV9517 daemon.info dhcpd: Reclaiming not used lease 192.168.2.136.
Mar  8 21:14:57 VRV9517 daemon.info dhcpd: DHCPREQUEST for 192.168.2.136 (192.168.2.254) from c8:99:b2:54:d0:a1 (SWP2-54D0A1) via br0
 

Hier zie je het 135 adres dat superwifi had vervangen wordt door 136. Daarvoor in de log continu dit gedrag met als gevolg een DHCP tabel met veel entries voor hetzelfde device Mac (superwifi). Dit gedrag niet waargenomen voor andere devices.

Ik ben eigenwijs en heb toch nog een wijziging gemaakt. De overwegingen staan hierboven en hier:

Ik heb voor de 5G band kanaal 36 geconfigureerd en bandbreedte 20MHz. De gedachte is dat ik bandbreedte inlever maar wel minder interferentie en ruis heb (geen channel compounding) en bij wifi5 (v10a modem) meer zendvermogen per kanaal.

Ik neem voor nu even aan dat deze settings ook gelden voor de backhaul, dus de verbinding tussen superwifi en de modem. Dat lijkt er wel op want in het topology overzicht die ik bij het lijntje de snelheid ineens terugvallen naar 250mbps. Dat was eerder 850mbps. Nadeel is wel dat ook de lijntjes van bijvoorbeeld mijn iPad terugvallen naar 70mbps. Maar dat zou ook voor tv+ met streams van 7mbps nog ruim voldoende moeten zijn. Ik trek usenet toch niet leeg.

Kortom: dit is mijn inziens de meest conservatieve setting die ik kan maken voor de 5G band. Als dan de verbinding tussen superwifi en v10a niet overeind blijft dan is er mogelijk toch een firmware probleem en minder een lokaal interferentie probleem.

Superwifi gaat nacht 2 in met deze settings:

• Reserved IP
• Kanaal 36
• 5G bandbreedte naar 20MHz

Je ziet duidelijk dat de 5GHz wireless backhaul terugvalt in snelheid (was op 80Mhz bandbreedte rond de 850Mbps) naar rond de 200Mbps. De modemsettings gelden kennelijk dus ook voor de backhaul (en heeft dus geen standaard) en dat is exact wat ik wil bereiken. Met lage bandbreedte minder interferentie en ruis dan bij compounding channels. Er hoeft ook niet gewacht te worden tot alle kanalen vrij zijn zodra data verzonden wordt aldus de theorie. De backhaul moet stabiel zijn uiteraard. En meer zendvermogen voor het overgebleven kanaal aldus de theorie. Modem v10a is een Wifi5 modem… En geen box12 die ontworpen is voor Wifi6

Kortom: inleveren van bandbreedte/snelheid als uitruil en hopelijk een stabiele(re) draadloze verbinding tussen Superwifi en de V10a.

• Bij mij was het reserveren van IP en de auto optie op kanaal 52 niet afdoende maar mogelijk speelt bij mij interferentie een grote rol. Iemand anders draait met reserved IP met de auto optie op kanaal 52 en tot nu toe blijft Superwifi daar online. Kan bij mij dus EN EN zijn.
• Als bij mij deze settings wel resultaat opleveren dan vervolgens:
  • Verhogen bandbreedte naar 40Mhz voor meer snelheid. Dan is mijn abo weer de beperkende factor.
  • De auto optie met kanaal 52 met bandbreedte 40Mhz. Daarmee kan ik aantonen dat niet interferentie maar de bandbreedte het probleem is.

Eerst maar eens van mijn TV+ genieten vanavond. Natuurlijk draadloos via Superwifi 

Chapeau voor uitgebreidheid en doorzettingsvermogen  in de gepleegde onderzoeken. Het leest als een verhaal waarbij je iedere keer wilt weten wat het volgende hoofdstuk .

Dat dhcp probleem met meerdere ip adressen is zeker niet ok. Het is koffiedik kijken wat er precies mis gaat maar die abandon melding slaat vanuit het gezichtspunt van de v10a op het feit dat deze een aanvraag voor een dhcp ip adres ziet komen. Vlak voordat deze gegeven wordt voert de v10a een pingtest uit om te achterhalen of het gevraagde adres actief is. Vervolgens komt er dus reactie hierop en concludeert de v10a dat deze dus actief is en doet dus een abandon naar een volgend adres.  Er lijken dus naar mijn mening situaties te zijn waarbij de superwifi dhcp discoveries de deur uitgooit terwijl de laatst actieve dhcp binding op de superwifi nog steeds actief is en antwoord geeft op de ping van v10a. 

Blijkbaar houdt die situatie enige tijd stand waardoor er ondertussen dus een hele serie dhcp reserveringen worden gemaakt ten onrechte.

Nu is het zo dat superwifis bij een netwerkwijziging (lees een ethernet kabel erin of eruit maar ook een backhaul stap naar 2.4ghz of bv een radar event)direct beginnen met het zenden van dhcp discovery frames om daarna te luisteren op welke interface (lees welke richting) er een antwoord terugkomt. Waar het antwoord van terugkomt daar kan dan geconcludeerd worden dat het modem zich bevindt. Dit is noodzakelijk om binnen dit soort mesh netwerken te snappen wat het upstream en downstream pad is. De superwifi behoort hierbij 2 zaken in acht te nemen. De eerste is dat de dhcp discoveries alleen verstuurd als er geen actieve binding meer is en de superwifi ook niet meer in de renew fase zit. Ten tweede de superwifi dient de dhcp verzoeken iedere keer te versturen met gebruikmaking van hetzelfde mac adres. Anders ziet de v10a het elke keer als een ander apparaat voorbij schuiven.

E.e.a. zal duidelijk moeten worden middels wireshark traces om het echt te weten.

Dan het verhaal over de kanalen en de auto kanaal selectie. Dit zag ik eerder door iemand aangehaald worden. Zodra de optie auto channel aanstaat is dit slechts een instelling die automatisch gesynchroniseerd wordt naar alle superwifis. Echter elke superwifi blijft een zelfstandig werkend wifi acces punt die zijn eigen actie moet kunnen uitvoeren in het geval van radarsignalen. M.a.w. binnen 1 mesh netwerk kan de ene superwifi een radar zien terwijl de andere door een fysiek andere lokatie dit signaal nooit heeft opgepikt. Toch zal die geraakte superwifi direct moeten wegbewegen van dat 5ghz kanaal.  Tevens zal de wegbewegende superwifi een signaal moeten geven om de andere te informeren over de kanaal change. Als dit niet goed doorkomt dan is er een kanaalverschil en krijgt de superwifi connect problemen.

De witte superwifis hadden een instelling acs interval wat in de nachtelijke uren automatisch een nieuwe kanaalselectie opstart. Als dat mechanisme nog steeds aanstaat dan gaat de superwifi dus los van de v10a een eigen kanaalkeuze maken die mogelijk op dat moment niet gesynchroniseerd wordt in het hele mesh netwerk. Gevolg superwifi valt eruit. Na een herstart scant de superwifi de omgeving opnieuw en maakt weer verbinding op basis van de backhaul instellingen.

De zwarte superwifis hebben die optie niet.