Meshviewer: seltsame Verbindung a0:f3:c1:a6:88:41 zu e8🇩🇪27:ce:bd:d4

Hallo zusammen,

der Meshviewer zeigt für „meine“ Node FF-DO-Detmar4_Innenhof_v2 (a0:f3:c1:a6:88:41) zwei streckenmäßig rekordverdächtige Verbindungen zu FF-HA-Eilper86-Volme (e8:de:27:ce:bd:d4) bzw.FF-HA-Eilper86-vorn (68:72:51:20:a7:d4).

Schaut zwar nett aus, entspricht aber nicht den Tatsachen. Woher kommt’s? Wie geht’s weg?

GrĂĽĂźe

der Matze

Das frag ich mich auch gerade. Die beiden Router sind meine und nur per MeshOnLan mit FF-HA-Eilper86 verbunden, der keinen Geotag hat. Ob das damit zu tun hat?

Auf die betreffende Node hatte ich zunächst die von Dir freundlicherweise zur Verfügung gestellte Firmware geflasht. Kann es sein, dass in der Firmware irgendwelche Daten Deiner Node enthalten waren, evtl. der Name der Node? Vielleicht hat sich so ein doppeltes Lottchen in die Meshviewer-Datenbank eingeschlichen und nun sieht es für ihn so aus, als ob da zwei 18-Kilometer-Verbindungen vorhanden wären.

In völliger Unkenntnis der Mechanik hinter dem Meshviewer: vermutlich wird der betreffende Admin das manuell wieder herauspulen müssen.

Naja, ist ja nicht tragisch :smile:

Ich kann hier nicht mehr nachvollziehen, ob und falls ja welche Änderungen ich an den originalen site.* vorgenommen habe vor dem Build. „Eigentlich“ sollte das unverändert sein…

Inzwischen gibt es doch einen offiziellen Build von unseren Admins, das auch beim nächsten Update zuverlässig mitspielen sollte, was ich bei meinem Build nicht erwarte.

Vielleicht sollten wir beide auf die offizielle Version umflashen.

Hab’ das offizielle Build direkt nach der Bereitstellung auf die Node geflasht. Die 18-km-Verbindung hat’s überlebt…

Initialisiere das Gerät Mal mit firstboot. Das normale flashen soll doch explizit nicht alle Einstellungen überschreiben.

Firstboot erschien mir ebenfalls aussichtsreich – gestern durchgeführt, Node neu aufgesetzt. Die Pseudo-Verbindung bleibt. Sehr hartnäckig, das Ding.

Das kann ja irgendwo nicht sein. Firstboot schmeiĂźt wirklich alles runter, denke dann ist es ein Problem mit der Karte.

Habt ihr mal die Ausgabe von batadv-vis -f json und batctl tg fĂĽr das Mesh?

Vom FF-HA-Eilper86 : https://drive.google.com/file/d/0B_lU3OVPLmYtRWVfemJDRWNoQXc/view?usp=sharing

Ist da noch andere Software als ffmap-backend involviert?

Ich hätte noch gerne ein ip a vom Knoten FF-DO-Detmar4_Innenhof_v2. Dort ist irgendwas komisch, denn er gibt an die MAC von FF-HA-Eilper86 zu nutzen. Dadurch werden beide Knoten zu einem zusammengefasst.

Hier die Infos. batadv-vis -f json bleibt auf meiner Node jedoch leer.

batadv_batctl_ip.zip (70.8 KB)

Problem gefunden: Beide Knoten sind WDR4900 und machen wahrschenlich mesh über Kabel. Dort gab es den Bug, dass eth0 auf allen WDR4900 die gleiche ist und somit die Knoten vereint werden. Dadurch dürfte auch das meshen über das Kabel beeinträchtigt werden. Ihr könntet manuell die richtige MAC setzen und den Fehler mit euren Firmwaremaintainern klären, ob es schon eine gepatchte Firmwareversion gibt und ob das Image noch mit BROKEN=1 gebaut wurde. Der WDR4900 wird noch garnicht so lange unterstützt.

Ihr solltet auf jedenfall erstmal mesh on WAN deaktivieren um das Netz nicht weiter zu stören.

Im Git steht beim Tag 2014.4 nichts von BROKEN. Das war die Quelle fĂĽr meinen Build.
Was ĂĽbersehe ich da?
Link: gluon/profiles.mk at v2014.4 · freifunk-gluon/gluon · GitHub

@pberndro , du hast den aktuellen Build fĂĽr das Ruhrgebiet gebaut. Was tun?

Also wenn ich dich, @tcatm, richtig verstanden habe, funktioniert das auslesen der MAC nicht, daher wird einfach ĂĽberall dieselbe verwendet?

Welche MAC wo auf welchen Wert setzen? Reicht es aus, die MAC des WAN-Interfaces mit uci set network.wan.macaddr="aa.bb.cc.dd.ee.ff" zu ändern?

Ja, das könnte so funktionieren (bin mir gerade nicht sicher ob der Befehl richtig ist).

Scheint ja nun behoben. Habe eth0 auf meiner Node eine andere MAC verpasst.

@Freigraf: Was hast Du an Deiner Node geändert?

FYI: Wir haben nun ein Issue in Gluon dazu.