Software

Firmware 0.7.3-beta2

Umschalten
Firmware 0.7.3-beta2
Antwort
06.11.15 20:24
Es ist eine neue Beta draußen und es sind ein paar Dinge aufgefallen.

1 x TP-Link WDR4300 - automatisch aktualisiert
2 x TP-Link WR841ND - manuell über SSH aktualisiert

Der Mesh-VPN Router spricht jetzt mit Gateway 1 und nicht mehr mit Gateway 2 wie es noch mit 0.7.3-beta1 war
Der Freifunk ist wieder flott, vorher Downloadspeed von max 200KB/s, jetzt 800 - 900KB/s
vorher Namensauflösung ca. 2s - 4s, jetzt unter 1s

Was sagt denn der Experte, welche Änderungen vorgenommen wurden?

RE: Firmware 0.7.3-beta2
Antwort
06.11.15 21:21 als Antwort auf Johannes Grimm.
Die Beta2 hat keine wirklich relevanten Änderungen:
https://github.com/ffggrz/site-ffggrz/releases/tag/0.7.3-beta2

Ich hab die Beta nur noch eingeschoben, weil sich auch bei geringen Änderungen mal Fehler einschleichen können. Und ich habe keine Lust, dann 50 Router per Hand upzudaten emoticon

Die von Dir festgestellten Änderungen liegen nicht an der Firmware, sondern am Gateway. Und das wird vom Router mehr oder weniger zufällig gewählt.
Gateway 1 läuft als virtuelle Maschine auf einem sonst recht wenig ausgelasteten Root-Server in Deutschland (bei Hetzner). Hat eine Anbindung mit 1Gbit/s, der Internet-Exit läuft über den Berliner Freifunk-Verein.
Dagegen läuft Gateway 3 direkt auf der Hardware eines mit Atom N2800 ausgestatteten Rootservers in Frankreich. Der ist mit 100MBit/s angebunden. Internet-Exit ist derzeit ein VPN nach Schweden, weil Berlin nicht funktioniert. Da sind wir gerade dran.

Du könntest den Router mehrmals neu starten, vielleicht verbindet er sich dann mit einem anderen Gateway - meist aber nicht. Man kann im Router auch einzelne Gateways deaktivieren, das verrate ich hier aber nicht emoticon
Ziel ist nämlich schon, daß sich die Router auf den Gateways verteilen und wir die Gateways optimieren. Dafür sind solche Rückmeldungen wie Deine sehr nützlich.

RE: Firmware 0.7.3-beta2
Antwort
07.11.15 03:06 als Antwort auf Johannes Grimm.
Hi!

Danke erstmal für deinen Hinweis auf dieses Problem emoticon

Gateway2 war bisher über die USA mit über 300ms Latenz verbunden und hatte Freitag zwischen 17 Uhr und 19 Uhr ein paar schwerwiegende Probleme gehabt (mein Fehler). Mittlerweile nutze ich aber ebenfalls Freifunk-Berlin (seit 5.11 ca. 16 Uhr) und leite zusätzlich zeitkrittische Dienste direkt aus was zu Latenzen von weit unter unter 60ms führt. 

Ping-Zeiten von meiner Internetleitung aus über meinen Node (Client direkt am LAN-Port angeschlossen):
GW1: 56ms
GW2: 61ms
GW3: 89ms

Latenz abzüglich der 33ms für den Weg vom GW2 durch Berlin und dem direkten Ping von meiner Leitung mit 25ms komme ich auf 3ms Latenz innerhalb des Servers. Wenn ich jetzt noch das Jitter von 5ms bis 10ms einbeziehe dann komme ich auf realen <1ms Latenz. 

GW2 -> GW1
traceroute to gw1.freifunk-gera-greiz.de (148.251.158.22), 30 hops max, 60 byte packets
 1  185.16.108.1 (185.16.108.1)  0.801 ms  0.794 ms  0.714 ms
 2  5.175.255.9 (5.175.255.9)  0.689 ms  0.686 ms  0.678 ms
 3  decix-gw.hetzner.de (80.81.192.164)  4.334 ms  4.331 ms  4.225 ms
 4  core1.hetzner.de (213.239.245.6)  0.718 ms  0.722 ms  0.707 ms
 5  juniper2.rz21.hetzner.de (213.239.203.154)  5.487 ms  5.483 ms  5.478 ms
 6  ex9k1.rz21.hetzner.de (213.239.203.174)  5.471 ms  5.493 ms  5.429 ms
 7  server1.unitas-network.de (148.251.152.51)  5.380 ms  5.338 ms  5.396 ms
 8  gw1.freifunk-gera-greiz.de (148.251.158.22)  5.354 ms  5.394 ms  5.433 ms

Die Latenz in der Namensauflösung kann ich aber nicht nachvollziehen, dazu müsste ich wissen wie du das gemessen hast. Namensauflösung leite ich direkt aus falls diese nicht an den Server selbst gerichtet sind, von daher hätte es nie ein Problem damit geben müssen.
Und wenn du pech hattest warst du nichtmal mit GW2 verbunden da batman-adv manchmal die Angewohnheit hat die Daten einfach an einen anderen GW zu schicken als der Node mit fastd verbunden war; Damit würden sich vielleicht auch die langen Namensauflösungen erklären.

"Gefühle Geschwindigkeit" bei WLAN spiegelt sich nie in einem richtigen Test wieder. Mir würde es sehr helfen wenn du beim nächsten Mal auf 1 Meter entfernung zum Router mit Programmen wie ping und traceroute misst. Falls es ein echtes Problem gibt welches ich dauerhaft übersehe wäre das sehr hilfreich emoticon.



Würde mich freuen wenn du beim nächsten Problem folgendes machst:
1. ping 8.8.8.8 (den ersten Ping verwerfen und den zweiten verwenden)
2. traceroute 8.8.8.8
3. Auf http://www.wieistmeineip.de/ gehen um die ausgehende IP-Adresse zu sehen
4. http://speedcheck.lab.vodafone.de/100M herunterladen (20 Sekunden Download reicht zur Not)
5. http://10.181.0.12/100M herunterladen
6. Optional: über ssh auf den Node "batctl gwl" ausführen
7. ganz wichtig: Uhrzeit+Datum

Damit könnten wir vielleicht die Ursache für das Problem finden.



Ich führe Statistiken über Latenzen zwischen den GWs, zu verschiedenen Hosts im Internet und der Latenz über die VPN-Verbindungen und konnte bisher keine ungewöhnlichen Probleme feststellen. Wahrscheinlicher ist dass es an den VPN-Verbindungen selbst liegt die den Traffic an recht stark ausgelasteten "Proxy-Server" weiterleiten, von daher bin ich froh nicht mehr auf die USA angewiesen zu sein. 

Was auch ein echtes Problem ist wenn die Nodes über WLAN-Mesh miteinenader verbunden sind. Die Route wird von batman-adv immer mal gewechselt und kann auch zwischendrinn unnötig schlecht sein. Habe das Mesh bei mir mittlerweile mit LAN aber musste dennoch das WLAN-Mesh abschalten damit die Routen nicht den schlechteren Weg über das WLAN gehen. Sowas sieht man sehr gut wenn man einen Ping recht lange laufe lässst, da sind immer mal spontane "Ausreißer" dabei. Bei einen Paket pro Sekunde kein Problem ... bei hunderten kann ein Download stark schwanken und erreicht nie die maximale Geschwindigkeit.
Das gleiche Problem besteht auch an den Clients die nicht immer den besten Node verwenden da dahinter keine Intelligenz steht. Echtes WLAN-Roaming kostet unglaublich viel Geld; Damit wird von zentralen Servern regelmäßig die Verbindungsqualität zwischen den Nodes und Clients geprüft und "setzt" aktiv den Client zuden nächst besseren Node - dadurch sind dann auch unterschiedliche WLAN-Kanäle möglich. Die Clients können sowas nicht da diese nicht wissen können dass der nächst bessere Node auch das gleiche Netz zu verfügung stellt.

Wie du siehst gibts richtig viele Gründe wieso eine WLAN-Verbindung einfach "kacke" ist obwohl eigentlich alles stimmen müsste.

Ich hoffe ich konnte etwas für Aufklärung sorgen und würde mir wünschen das nächste Mal nicht einfach alleine auf meinen Gateway abszuschieben :-D

Lg, Marcus

RE: Firmware 0.7.3-beta2
Antwort
07.11.15 07:34 als Antwort auf Marcus.
Ich danke dir. Deine Anleitung und Informationen können teilweise wirklich ins Wiki zur Fehleranalyse im Freifunk-Netz.

Da momentan die Sache wieder flott läuft werde ich mich hoffentlich beim nächsten mal wieder daran erinnern und ein paar gute Auswertungen fahren können.

Ich hoffe allerdings, dass Du den Google-DNS nur zum Testen verwendest ;-)

RE: Firmware 0.7.3-beta2
Antwort
07.11.15 13:25 als Antwort auf Johannes Grimm.
Ich werde heute mal einen Wiki-Artikel dazu schreiben, würde mich über Feedback dazu sehr freuen emoticon

Ich verwende den Google-DNS da die IP recht einfach zu merken ist und schnell getippt ist. Da dieser auch hoch verfügbar ist und eine sehr geringe Latenzzeit hat hat sich dieser bei mir eingebürgert.

Auf meinen Gatway verwende ich (in dieser Reihenfolge):

193.28.153.254 (DNS des Serveranbieters)
213.73.91.35 (Chaos Computer Club berlin)
8.8.8.8 (Google DNS-Server)
8.8.4.4 (Google DNS-Server)

Die Google DNS-Server sind also nur für den höchsten Notfall emoticon

Über DHCP und Router Advertisement verteile ich folgende Liste:

dhcp-option=option:dns-server,10.181.0.12,10.181.0.11,10.181.0.13,8.8.8.8
dhcp-option=tag:v6,option6:dns-server,[fdb5:78b:64cc::12],[fdb5:78b:64cc::11],[fdb5:78b:64cc::13],[2001:4860:4860::8888]

Es werden also erst alle Gatway gefragt bis der Google-DNS-Server genutzt wird. Falls du einen besseren hochverfügbaren aber dafür weniger "datenkrakenartigen" DNS kennst wäre ich da sehr dankbar, würde das dann gerne ändern wollen emoticon

Lg

RE: Firmware 0.7.3-beta2
Antwort
07.11.15 13:43 als Antwort auf Marcus.
Hallo Marcus,

ich setze auch zeitweilig die DNS-Server von Google ein. Wenn es mal wieder Probleme gibt mit denen von Kabel Deutschland oder ähnlich. Ich hab auch schon mal länger im Netz gesucht und leider finde ich grade zu den Servern vom CCC bzw FoeBud unterschiedliche IP-Adressen. Hier eine schöne und auch internationale Liste mit DNS-Servern ohne dass ich allerdings Aussagen zu den einzelnen Servern liefern kann.
http://www.dns-liste.de/ und noch http://public-dns.tk/nameserver/de.html
auf der zweiten Liste sind spannende Server wie ein 100% verfügbarer Server des Klinikums rechts der Isar in München (141.39.169.5 ) oder der Uni in Leipzig (139.18.25.33; gate.ipv6.uni-leipzig.de)

Der Jo

RE: Firmware 0.7.3-beta2
Antwort
07.11.15 14:09 als Antwort auf Johannes Grimm.
Oh, sehe gerade dass die eine Seite ja Identisch ist mit der die ich schon kannte :-D


Danke für die zwei Seiten, die kannte ich bisher noch gar nicht.
Hatte bisher die Seite genutzt:

https://wikileaks.org/wiki/Alternative_DNS/de

Soweit ich weiß hatte der DNS vom CCC in Vergangenheit ein paar Probleme, finde diesen aber vom "Gefühl" her sympathisch :-D
Zu den DNS-Servern von Kabel-Deutschland habe ich recht wenig vertrauen und die von der Telekom machen für mein Gefühl ein wenig zu viel da diese auch DNS-Anfragen auflösen die nicht existieren um den "einfachen" Kunden darauf hinweisen zu können.

Beim Schreiben des Artikels habe ich überlegt dass der übliche Freifunk-Benutzer sich kaum mit der Eingabeaufforderung im Windows auseinandersetzen möchte und überlege ein CGI-Programm zu schreiben welches einfach über den Browser aufrufbar ist und Informationen über Gatewaywahl, Route und Latenz anzeigen kann.
Da die Gateways kaum auswertbare Daten loggen ist es echt schwer nachträglich eine Diagnose zu stellen, dies lässt sich auch nicht ändern da es gegen der Freifunk-Philosophie spricht.

RE: Firmware 0.7.3-beta2
Antwort
07.11.15 16:46 als Antwort auf Marcus.
Hallo Marcus,
Ich ein Skript ist eine echt spannende Angelegenheit. Ich sehe dafür vor Allem 2 Hauptanwendergruppen. Technisch interessierte Anwender die sic gerne mal ihre Verbindung anschauen und solche, die auch aktiv nach Fehlern suchen. Weiterhin ließe sich dein Skript als Dienst für .ffggrz anbieten. Netzwerkcheck/ping/tracert/etc für das Freifunknetz. 
Wenn du so was erstellen kannst - Hut ab. 
Dennoch befürchte ich dass wir uns für die Inbetriebnahme eines solchen Tools auch mit der Meinung der auseinanderzusetzen haben die in zu großer Transparenz ein Sicherheitsrisiko sehen. Also besser noch einen Captcha oder ähnliche Maßnahmen gegen Missbräuchliche Benutzung einbauen.

Aber Definitiv ist so ein Tool dann auch einen eigenen Menueintrag a der Homepage wert.
Der Jo

RE: Firmware 0.7.3-beta2
Antwort
07.11.15 16:53 als Antwort auf Johannes Grimm.
Bin schon dabei emoticon


http://10.181.0.12/

Leider ist das noch nicht sehr Benutzerfreundlich aber es zeigt alle wesentlichen Informationen an die ich von meinen Gateway heraus erfassen kann. Leider lässt sich damit nicht die Verbindungsqualität zum Internet testen.
Eine Domaine dafür richte ich nachher noch ein. Was hällst du von http://test.ffggrz ? 
Was hällt du davon es in zwei Bereiche einteilen, einen für die normalen Benutzer und einen für die Technik-Freaks mit den größt möglichen Details?

RE: Firmware 0.7.3-beta2
Antwort
10.11.15 13:49 als Antwort auf Marcus.
Ich bin momentan nicht im Freifunknetz unterwegs. Bei meinen Schwiegereltern ist di Frefunkdichte noch bei NULL. Daher kommt meine Anregung zum Tool noch an dieser Stelle. Gedulde dich noch bis heute abend.

So eine Art Verbose- oder Debugschalter auf dem "Nur für Nerds" steht und durch jenen eine Detailierte Ausgabe angezeigt wird. Sonst hast du unter Umständen immer 2 Tools zu pflegen - aber ich merke, wie ich schon wieder Dinge fordere die ich niemals sel so umsetzen könnte. Daher is das alles kein Befehl sondern ein kreativer Austausch.

Update vom 10.11.2015
Das skript ist schon gewachsen und ich finde es gut, dass du die verwendeten Skripte mit verlinkst. Allerdings zeigt mir die Infobox zum Mesh-Netzwerk einen Fehler:
123456789101112131415161718192021222324
Client-IP : 10.181.6.119 GW3-Adressbereich
Client-DNS: A75M.ffggrz
Client-MAC: 48:51:b7:d3:cb:10
Node-MAC  : c2:4e:00:ac:8e:b4
Node-Name : RC-Krummer-Weg-001a.1
Hops:
    de:ad:be:ef:02:02 [Gateway 2]
    de:ad:be:ef:03:04 [gw3.1]   13.3 ms
    c2:4e:00:ac:8e:b4 [RC-Krummer-Weg-001a.1]   49.4 ms
    48:51:b7:d3:cb:10 [Client]
Gateway Route: Gateway 3
Latenzzeit (von Gateway 2 bis Client):
    Minimal:       0.0 ms
    Durchschnitt:       0.0 ms
    Maximal:       0.0 ms
    Streuung:       0.0 ms
<h1>Software error:</h1>
<pre>Illegal division by zero at /var/www/html/diag.pl line 124.
</pre>
<p>
For help, please send mail to this site's webmaster, giving this error message
and the time and date of the error.

</p>

RE: Firmware 0.7.3-beta2
Antwort
11.11.15 19:24 als Antwort auf Johannes Grimm.
Danke für den Hinweis emoticon


Der Fehler tritt auf wenn ICMP vom Client geblockt wird. Habe jetzt eine Prüfung hinzugefügt, lösen tut das eigentliche Problem aber nicht. Ich muss mal schauen wieso die Windows-Firewall bei der Einstellung "Öffentliches Netzwerk" so restriktiv ist und ob ein TCP-Ping nicht besser wäre.

Die meiste Arbeit habe ich jetzt in http://test.ffggrz/diag_json.pl gesteckt, dies soll dann (von Eric entwickelt) auf http://start.ffggrz/ kommen.

Lg

RE: Firmware 0.7.3-beta2
Antwort
11.11.15 19:57 als Antwort auf Marcus.
Ich bin auf jeden Fall dein Testkanditat wenn Du Feedback brauchst. Sag bescheid.

Zum Thema http://start.ffggrz bin ich ja mal gespannt. Ich habe schon über dessen Existenz gelesen aber noch hüllt sich Eric in der Öffentlichkeit in Schweigen ;-)

Der Jo

RE: Firmware 0.7.3-beta2
Antwort
12.11.15 11:00 als Antwort auf Johannes Grimm.
naja, da es zur Zeit noch, neben unter anderem unserer Homepage-Neugestaltung, in der Entwicklung ist, wollte ich es noch nicht so "breit treten" und am Ende geht es dann nicht ganz so wie ich mir das vorgestellt habe.

Wenn allerdings mal jmd gucken möchte ...
wenn mein Rechner an ist und ich Internet habe kann man entweder unter vpn.anoy.ffggrz/ffggrz (wenn ich über meinen OVPN drin bin) oder unter wifi.anoy.ffggrz/ffggrz (wenn ich im Freifunk-WLAN bin) mal vorbei gucken und mich vllt sogar live beim entwickeln beobachten emoticon

Einige Infos zu den Projekten sind in den README.md Dokumenten in den meisten Ordnern zu finden emoticon

RE: Firmware 0.7.3-beta2
Antwort
12.11.15 13:39 als Antwort auf Eric.
Tut mir Leid wenn ich dich dadurch übergangen habe und das ohne deinen Wunsch schon ausgeplaudert habe ... ich frage dich das nächste Mal vorher emoticon