Der uplink Router Tierheim-07 wird nur als Node im Graph angezeigt.
siehe graph
root@FF-Gelsenkirchen-Tierheim-07:~# ifconfig|grep -A6 eth1|grep RX\ bytes
RX bytes:560953 (547.8 KiB) TX bytes:636514 (621.5 KiB)
Bist Du sicher, dort bei der Einrichtung
a) meshvpn aktiviert zu haben
b) den Key/Node auch angemeldet zu haben?
Schau doch mal, was der fastd im Logread so meldet (nach einem reboot)
Entwarnung. Die Störgung/der Fehler lag beim Node-Einrichter: Key war nicht auf den Register-Server geladen worden.
(Betreff des Threads also etwas irreführend.)
Ich würde aber schon gerne einen Sammel-Strang mit Fehlern (von mir aus auch „Fehlern“) und Störungen einrichten. Ich glaube, dass es mir und anderen Laien auf die Sprünge hilft … 
ich habe dann mal umbenannt in ein unspezifisches „Sammelthread: Störungsmeldungen und Netzprobleme“.
Ist dann immer wieder nutzbar (und braucht nicht gleich geschlossen zu werden.)
1 „Gefällt mir“
Einige Uplinks werden nun wieder nicht als solche angezeigt bzw. es werden uplinks angezeigt, die keine sind:
FF-Gelsenkirchen-Abrazo ist kein uplink, wird aber so angezeigt
FF-Gelsenkirchen-Tierheim-07 ist ein uplink, wird aber nicht angezeigt
FF-Gelsenkirchen-Maravilla sollte ein uplink sein, läuft als Knoten
Yang ist verschwunden - ich kann nicht feststellen ob der Stecker gezogen wurde oder das mit den mal wieder vermehrt auftretenden Ups und Downs hier zu tun hat.
Nicht dass Du mich den falschen yang hast löschen lassen?
der GROß geschriebene sollte weg also YANG nicht Yang
Nachtrag: ich versuche heraus zu bekommen, ob er vom Netz getrennt wurde (was ich aber nicht glaube)
Yang war am Stromnetz - auch nach dem rebooten bleibt die Verbindung tot.
Abrazo ist kein uplink, Tierheim-07 sehr wohl, Maravilla ist bzw. sollte ein uplink sein…
Yang ist wieder hergestellt. Für mein Verständnis wäre eine Info darüber was schief lief, hilfreich.
Vielleicht taucht Tierheim-07 auch wieder als uplink auf? 
Da war leider wohl der falsche Router gelöscht worden beim Aufräumen auf dem fastd-server.
Ich habe den Router mit dem alten Key jetzt erneut registriert.
Dec 30 04:55:25 FF-Gelsenkirchen-Tierheim-07 daemon.info fastd[1617]: 37.252.124.177:10000 authorized as <mesh_vpn_backbone_peer_ruhrgebiet3>
Dec 30 04:55:25 FF-Gelsenkirchen-Tierheim-07 daemon.info fastd[1617]: new session with <mesh_vpn_backbone_peer_ruhrgebiet3> established using method `salsa2012+gmac'.
Fein. Und ich hatte zum Nachbarn des Knotenbetreibers Yang einen Austauschrouter gebracht - nachdem ich ihn abgeliefert hatte, wurde Yang auf dem Server wieder eingerichtet. Nun steht dort der Austauschrouter den der Nachbar dem Knotenbetreiber gebracht hatte, als der nach Hause kam - war ja niemandem klar, dass Yang wieder funktionieren würde, während ich mit dem Auto unterwegs war.
Also muss ich erneut hin usw. usw. - hach … ich liebe die Freuden eines Hüters einer Freifunkknotenherde und kenne nun mehrere Gründe, warum das eine never ending Story ist und nicht jeder den Langmut eines Schäfers hat 
Wäre interessant zu wissen, wie der nun auf dem Server heißt bzw. geschrieben steht… Falls demnächst mal wieder Doppelte gelöscht werden müssen.
Der Knoten „Abrazo“ wird immer noch als Uplink angezeigt - kann es sein, dass da wieder das Problem der zu ähnlichen MAC Adresse greift? Vor einiger Zeit wurde ein uplink nicht angezeigt, weil die MAC Adresse des Routers einem anderen Gerät zu ähnlich war. Vielleicht ist es nun umgekehrt? Ich kann es nicht wissen…
Eigentlich sollte das mit dem upgrade von 0.5 auf 0.5.3 aber gelöst sein. Also muss es etwas anderes sein… aber was?
Hat das Upgrade 0.5 auf 0.5.3 Mac Adressen geändert? Ich denke nicht, oder?
Das Problem war doch die Map, die bei zu ähnlichen Mac Adressen aus dem tritt kam, und dort ist noch nichts geändert worden?
Beide Fragen kann ich ausnahmsweise mit einem absoluten, unbedingten, deutlichen und klarem ICH WEIß ES NICHT beantworten.
Bleibt immer noch der Knoten im Graph, der nach den Neuanmeldungen anderer Knoten (Tierheim) sich nun als Uplink aufspielt, obwohl er nur im Netz herum hängt. 
Der Abrazo
(FF-Gelsenkirchen-Abrazo/2a02:f98:0:26:ea94:f6ff:fe29:ff96/e8:94:f6:29:ff:96) hat keine connected fastd-peers, hat „kein Internet“ am br-wan, und auch keinen Link am WAN.
Er selbst glaubt also auch nicht, meshvpn aktiv zu haben.
Warum die ffmap das so darstellt: Keine Ahnung.
/lib/gluon/announce/announce.lua nodeinfo
{"node_id":"e894f629ff96","network":{"mac":"e8:94:f6:29:ff:96","addresses":["2a02:f98:0:26:ea94:f6ff:fe29:ff96","fda0:747e:ab29:cafe:ea94:f6ff:fe29:ff96","fe80::ea94:f6ff:fe29:ff96"],"mesh_interfaces":["ea:94:f6:29:ff:96","ea:94:f6:2a:ff:96"]},"hostname":"FF-Gelsenkirchen-Abrazo","location":{"longitude":7.096328,"latitude":51.5121175},"owner":{"contact":"xxxxxxxxxxxxxxxx"},"software":{"fastd":{"enabled":true,"version":"v14"},"autoupdater":{"enabled":true,"branch":"stable"},"batman-adv":{"version":"2013.4.0"},"firmware":{"base":"gluon-v2014.3","release":"0.5.3"}},"hardware":{"model":"TP-Link TL-WR841N/ND v9"}}
/lib/gluon/announce/announce.lua statistics
{"traffic":{"tx":{"packets":930,"dropped":9,"bytes":147393},"rx":{"bytes":2531750,"packets":30494},"forward":{"bytes":92099,"packets":454},"mgmt_tx":{"bytes":2372897,"packets":11579},"mgmt_rx":{"bytes":4024843,"packets":19638}},"memory":{"cached":4008,"total":29212,"buffers":1596,"free":6556},"uptime":630.27,"idletime":426.3,"gateway":"04:bf:ef:ca:fe:4d","node_id":"e894f629ff96","processes":{"total":51,"running":1},"loadavg":3.06}Vermutlich wieder zu ähnliche MAC Adresse, wie beim letzten Mal?
Die Router wurden nicht ausgetauscht. Einzig die Registrierung und die Säuberung der Registrierten sind Aktionen die etwas damit zu tun haben können. Abgesehen von den Geschichten die ich als Unwissender eh nicht mitbekomme
Das hat alles keinen Einfluss auf die Mac Adressen, die sind dann immer noch wie gehabt…