Hier geht´s ja weniger drum irgendwas zu unterstellen.
Aber wir hatten ja schon den ein oder anderen Vorfall wo einzelne Geräte den Betrieb gestört haben.
Das wird mit Wachstum und auch Bekanntheit (als „Spielziel“) nicht weniger werden.
Insofern eher Lernkurve, als dass Nadesha´s zur Exekution gebeten werden. 
Bislang hatten wir im Ruhrgebiet immer Glück das es immer Router mit eigenem VPN Tunnel waren, die darüber dann gesperrt werden konnten.
Ich will mich da ggf. gern zum Henker aufschwingen…
Sprich: auf den nadeshda-nodes könnte ich beliebige Dinge per ebtables anstellen und den Oekoma-Node sollten wir in Zugriff bekommen können (wahlweise hat @pixelistik da ssh-zugang oder irgendwer läuft einfach in den Laden und überzeugt die Anwesenden von der Notwendigkeit „entweder… oder alle kein Freifunk mehr“)
Solange jemand da sicher Auftritt kommt man an allen Mitarbeitern vorbei.
„Guten Tag, mein Name ist … Und komme von Freifunk … Ich/Wir müssten einmal an den Freifunkrouter um Sicherheitsupdates einzuspielen. Wo haben Sie denn den Router angeschlossen?“
Also die von der Ökoma kennen mich. Deren Node (freifunk-oekoma) durfte ich im Büro des Ladens aufstellen. Die anderen Nodes sind allesamt älter.
Vielleicht wurde ja mal eine Node mit damals bereits nicht mehr ganz frischer Firmware aufgestellt, die lediglich im Wifi-Mesh, ohne VPN-Tunnel eingebunden werden sollte. Und diese hat jemand kürzlich an den nächstbesten DSL-Anschluss gepackt. Ich vermute, dass es sich da um den Anschluss im ersten Stock des Vereinshauses handelt.
@pixelistik, gehst Du bitte da bei Gelegenheit mal schauen? Das Büro mit dem Anschluss ist der erste Raum im ersten Stock und gehörte einmal zwei Vereinen, die dort eingemietet waren. Wie das aktuell aussieht, weiß ich nicht. Aber wenn es so angeschlossen ist, wie ich vermute, dann ist der DSL-Anschluss zumindest noch aktiv.
Ich würde jetzt das natürliche (begründete) Mistrauen von Autonomen nicht unterschätzen.
Mit Hilfe von sehr hilfsbereiten Niemandsland-Menschen habe ich den Node gefunden und erstmal mitgenommen. Wie @nomaster vermutete, hat jemand das Gerät per Kabel ins Netzwerk gehängt, um Zugriff auf einen Netzwerkdrucker zu bekommen o.ä.
Werde die aktuelle Firmware flashen und den Node im Laufe der nächsten Tage wieder im Niemandsland platzieren. Um die restlichen Nodes, die noch mit alter Firmware unterwegs sind, kümmere ich mich dann nach und nach.
Hallo,
ich glaube das Problem ist so, oder so ähnlich wieder vorhanden.
IPv6 hat momentan sehr hohe Paketverluste und ein Traceroute in Richtung Internet landet teilweise bei 2003:4c:6f7f:d4af:d621:22ff:fe1b:b5f1 als ersten Hop. Dieser Host bietet eine Weboberfläche per HTTP an und dort begrüst einen ein Speedport W 724V mit Seriennummer J420005012 und konfiguriertem WLAN mit SSID „NIEMANDSLAND“.
Kann da mal jemand nachsehen? @pixelistik?
Bist du über die SSID „NIEMANDSLAND“ verbunden?
Kannst du ein Mesh-Netzwerk finden?
Geh’ mal auf http://www.telekom.de/privatkunden, steht links dort etwas bei E-Mail-Adresse/Zugangsnummer?
Nein, ich komme aus dem Freifunk Netz. Von dort aus kann man auch diesen Speedport per IP ansprechen und die oben genannten Informationen auslesen. Ins Internet kommt man darüber aber nicht. Das ganze stört auch nur IPv6 und das kann www.telekom.de anscheinend auch nicht. Meine Pakete kommen aber eh mit der Freifunk IPv6 Adresse dort an…
Au weia,
Das scheint ja wirklich ein Fass ohne Boden zu sein.
Ich denke mal, wir brauchen doch eine Blacklist im Batman. (vpn-keys zu sperren Reich bei den grossen Wolken schlicht nicht)
Ich glaube das hier sollte nicht sein.
Auf meinem Freifunk Router:
# ip -f inet6 route
…
default from fda0:747e:ab29:cafe::/64 via fe80::1 dev br-client metric 512
default from fda0:747e:ab29:cafe::/64 via fe80::1 dev br-client metric 1024
Und im Freifunk-LAN sieht man Router Advertisements von 14:cc:20:6f:a4:04 für das Prefix fda0:747e:ab29:cafe::/64
Was sagt denn
batctl gwlIch denke das sieht OK aus:
Gateway (#/255) Nexthop [outgoingIF]: gw_class ... [B.A.T.M.A.N. adv 2013.4.0, MainIF/MAC: eth0.1/c4:6e:1f:fe:f7:34 (bat0)]
04:be:ef:ca:fe:05 (225) 04:be:ef:ca:fe:01 [ mesh-vpn]: 215 - 96MBit/96MBit
04:be:ef:ca:fe:04 (225) 04:be:ef:ca:fe:01 [ mesh-vpn]: 215 - 96MBit/96MBit
04:be:ef:ca:fe:06 (225) 04:be:ef:ca:fe:01 [ mesh-vpn]: 215 - 96MBit/96MBit
06:be:ef:ca:fe:03 (225) 04:be:ef:ca:fe:01 [ mesh-vpn]: 215 - 96MBit/96MBit
=> 06:be:ef:ca:fe:01 (255) 04:be:ef:ca:fe:01 [ mesh-vpn]: 215 - 96MBit/96MBit
Du gehst trotzdem über den Telekom Router online?
Also durch den VPN Tunnel zum Supernode von dort durch einen weiteren VPN Tunnel zum in die Niemandsland Wolke und von dort dann ins Internet?
Ja so sieht das für mich aus. Wenn ich von meinem Rechner im Freifunk ein Traceroute mit MTR z.B. nach heise.de mache sehe ich abwechselnd entweder 2a03:2260:40::1 oder eben 2003:4c:6f7f:d4af:d621:22ff:fe1b:b5f1 als ersten Hop.
Ich denke die erste Adresse wäre korrekt, die zweite gehört allerdings zur DTAG. Durch das Wechseln kommt es dann wohl zu den Paketverlusten im IPv6 in Richtung Internet, ich komme ja beim Speedport mit der Freifunk IPv6 Adresse an und vermutlich routet dieser nur DTAG Adressen weiter bzw. filtert andere raus.
In der Zeit wo 2a03:2260:40::1 genutzt wird funktioniert es dann wieder kurz.
Hab es mir angeschaut. Hier hat jemand einen Router umplatziert und dann versucht das Internet vom Speedport „weiterzugeben“ - dabei aber offenbar an einen der 4 Ethernet-Ports angeschlossen. Hab die Verbindung korrekt auf den WAN-Port gesteckt und das VPN ordentlich konfiguriert.
Statt Störquelle müssten wir nun also einen weiteren Uplink haben.
Hey, vielen Dank. Die Probleme sind auch seit ca. 10 Minuten weg 
Das in einer lokalen Wolke der vorhandene Ausgang verwendet wird kann ich ja verstehen, aber warum passiert das hier?
Wird er mit einer höheren Bandbreite angegeben als die 96MBit/96MBit der Supernodes oder gibt es zwischen den Supernodes Paketverluste?