Irgendwas läuft bei mir nicht rund mit der Firmware. Manchmal kann ich meine Knoten anpingen, manchmal nicht. Manchmal komme ich per SSH drauf, dann wieder nicht. Manchmal wenn ich eingeloggt bin, hängt die SSH-Session, und nach Minuten geht es weiter.
Sieht für mich nach den klassischen Symptomen eines MTU Problems aus…
Bisher (2 Tage) ist keiner meiner Knoten hängen geblieben … das ist erfreulich. Es gab einmal einen Knoten, der für ein paar Stunden keine Verbindung hatte, der hat sich aber wieder gefunden. Ein kleiner hat einmal neu gestartet. Das ist aber nicht so ungewöhnlich.
Also bisher bin ich sehr zufrieden. So gut lief es seit längerem bei mir nicht. Teilweise musste ich mehrmals am Tag Stecker ziehen.
Das Knoten hängen oder abstürzen hatte ich jetzt eigenlich auch nicht, aber irgendwie habe ich immer wieder total schlechte Surf-Performance. Einen Fehler hat @NurticVibe neulich schon gefixt, aber ich habe das Gefühl, da ist noch mehr kaputt.
Eben konnte ich praktisch nicht im Freifunk Netz arbeiten, DNS-Anfragen an 10.142.53.4 haben teilweise 15 Sekunden gedauert. Ich habe das mal mit Wireshark mitgeloggt. Ich konnte das auf der Konsole auch eine Zeit lang reproduzieren, aber jetzt scheint wieder alles ok zu sein.
[Edit] Problem ist wieder da, aber scheinbar kein Fehler in der Firmware, daher habe ich einen neuen Thread aufgemacht: DNS Problem 10.142.53.4
Also das WIFI-Problem besteht weiter …
Ich bin immer noch nicht dazu gekommen die Seriellen Adapter anzulöten … muss ich endlich machen.
Ich hab zum Test den Offloader weggemacht und einen meiner 1043 direkt als Uplink angeschlossen. Das Ergebnis ist das gleiche:
Der Knoten hängt im Netz und ist über seine IPV6 erreichbar. Er macht auch Mesh-LAN für einen anderen Knoten, der weiter erreichbar ist. Aber das WLAN und WLAN-Mesh reagiert dann nicht mehr.
Ein einfaches “wifi” auf der Konsole behebt das Problem. Sekunden danach mesht er wieder und ist auch bereit Clients anzunehmen.
Nach dem Upgrade auf die 1.1.0 hat es zwei, fast drei Tage funktioniert. Jetzt hängt er sich wieder 1-2 Mal am Tag ab.
Ich habe ein Mesh-Netz aus 3 Knoten (841N) daheim, nur einer davon ist ein Uplink. Es lief alles stabil, bis ich einen der Knoten auf experimental geflashed habe. Seit dem steigt der Uplink regelmäßig aus und muss neu gestartet werden, obwohl die Last als Clients gering ist. Da der Stable-Knoten und nicht der Experimental aussteigt, ist das eher ein Problem von Stable und in meinen Augen unkritisch. Durch den Autoupdater sollten alle Knoten es Meshs auch zeitnah die 1.1.0 bekommen und das Problem sollte nicht gravierend sein. Wollte es trotzdem mal berichten und davor warnen aktuell »gemischte« Meshs zu bauen. Und die WR841N einzusetzen! ;)
Habe gestern die beiden anderen Knoten auch auf Experimental aktualisiert, stürzt immer noch ab. Die Warnung bezüglich gemischter Meshs dürfte daher hinfällig sein. Ich werde morgen mal eine Serielle Schnittstelle an den Uplink basteln und schauen, was da passiert
Auch ich habe manchmal seltsame Phänomene, die ich aber selten gut zuordnen kann. Die 841er sind ja benkanntermaßen instabil, und da ich teilweise Wired-Mesh benutze, bin ich vielleicht auch davon betroffen:
(Achtung: der zitierte 842N V2 hat auch nur 32MB RAM - nicht mit den aktuelleren 842 verwechseln!)
Der mit Uplink hat eine deutlich höhere Speicherauslastung… Hast Du IPv4 und IPv6 am Uplink? Ggf. mal IPv6 deaktivieren? Als “Mini-Offloader” setze ich die 841er mittlerweile gar nicht mehr ein, nur als “Endgeräte” (also entweder isolierter Knoten mit eigenem Uplink oder als Knoten, der per Mesh on LAN/WAN versorgt wird).
Uplink + Mesh on LAN + Client LAN/WLAN ist vielleicht einfach zu viel :-(
Der Autoupdater braucht dann auch noch regelmäßig Speicher - vielleicht den erstmal deaktivieren.
Ich habe mittlerweile vier 841’er auf die neue Firmware 1.1.0-20170829 aktualisiert.
Hierzu habe ich einfach folgendes ausgeführt:
uci set autoupdater.settings.branch=experimental
autoupdater -f
(Den Trick, nichtuci commit autoupdater zu schreiben, damit die Knoten nach dem reboot nur automatische Updates zur nächsten Stable tun werden, habe ich natürlich erst beim letzten Knoten herausgefunden ; )
Die Hardware-Revisionen der 841er sind v7, v10 und v11.
Bei einem hat der Reboot sehr lange gedauert (ich hatte schon gedacht, ich muss den Power Cycle durchführen, vor dem mich @Cheatha gewarnt hat), aber sie kamen alle wieder aus eigener Kraft hoch.
Alle meine manuellen Sonder-Konfigurationen (hierzu folgt ein anderer Thread) sind auch erhalten geblieben, bis auf den Funkkanal. @NurticVibe ist es Absicht oder ein Bug, dass ein geänderter Funkkanal auf ‘6’ zurückgestellt wird?
Ansonsten kann ich nur das Feedback geben, dass IPv6-Verbindungen signifikant besser laufen als vorher – es scheint, dass die VPN-MTU-Änderungen greifen. Allerdings hat es hierfür gereicht, den (VM-)Offloader zu aktualisieren, die Nicht-Selbst-VPN-Verbindungs-Herstellenden-Clients konnten die Pakete auch mit der alten Firmware problemlos weiterleiten bzw. zustellen.
Nochmal einen großen Dank für das sehr virtualisierungs-freundliche amd64 image, welches wunderbar mit der VirtIO-Netzwerkkarte klarkommt.
Ich habe heute meinen dauer-crashenden 841N gegen einen 1043ND getauscht. Beim Aufhängen viel mir auf, dass ich (parallel zum Upgrade auf Experimental, mit dem die Probleme begonnen) auch kürzlich meinen Ubiquiti Unifi AP Pro an die Wand gehängt habe und der aktuell nur ~50cm von den Antennen des 841N entfernt ist. Da fiel mir @tobox Hinweis zur höheren Load wieder ein: Wenn die beiden APs näher beieinander hängen, hat der 841N vermutlich mehr »Störungen«, mit denen er ja klarkommen muss, und das führt sicher irgendwann zum Crash im Treiber.
Die Lösung mit den zwei APs nebeneinander ist nicht dauerhaft geplant und mir war bewusst, dass das Probleme machen könnte. Aber trotzdem würde mich interessieren, woher die plötzlichen Abstürze kommen, weil ganz so krass hätte ich das nicht vermutet
So ein Setup kann Probleme machen benzüglich der Empfangsqualität, sollte aber bei geschickter Kanalwahl nicht passieren, und selbst wenn, darf erstmal nichts abstürzen.
Wenn Du beide Access Points mit 20MHz Bandbreite betreibst, den 841er auf 6 lässt und den UBNT auf 1 oder 11 machst, sollten sie sich eigentlich nicht stören.
Ich bekomme auf einem AP mit veralteter Firmware (0.7.1-20170415 / experimental?) die Meldung
# autoupdater http://fw.ffrn.de/stable.110/sysupgrade/
Downloading 'http://fw.ffrn.de/stable.110/sysupgrade/stable.manifest'
Connecting to 2a01:4f8:10a:f225::6:80
Writing to stdout
- 100% |*******************************| 65006 0:00:00 ETA
Download completed (65006 bytes)
Not enough valid signatures!
No usable mirror found.
Habe auch beta und experimental versucht - das ändert nichts.
Habe mir mit einem Hack beholfen und den Signatur-Check in /usr/sbin/autoupdater auskommentiert - es gibt also kein grundsätzliches Problem mit der Firmware.
Gibt es eine Erklärung und könnten das auch die knapp 50 Geräte betreffen, die noch nicht auf 1.1.0 sind?