[Berlin-wireless] Puh...!

Sa Apr 12 21:14:16 CEST 2014

Hallo Sven-Ola,

echt traurige Geschichte - man sollte ja meinen mit den ganzen tollen
neuen Standorten sollte sich die Situation verbessert haben.
Aber deine systematischen Ansätze zum Debuggen finde ich sehr konstruktiv!

On 04/12/2014 08:02 PM, Sven-Ola Tuecke wrote:
> ich muss mal jammern. Ich wollte heute mal herausfinden, warum mein Inet
> in letzter Zeit so hakt. Wie ihr vllt wisst, hab' ich zuhause kein DSL
> und hänge über meinen Balkon an der Modersohn77. Da war bis letzten
> Monat dann mein Ausgang über Bocki's Alice. Jetzt ist das anders und es
> läuft -mmh- bescheiden. Das hat viele Gründe und ich schreib's mir hier
> einfach mal auf.
> 
> Eine halbwegs funkende Strecke ist: Balkon - Modersohn77 - MLK - Faustus
> - Vpn03 - Inet, in Zahlen:

Ach der Umweg über Neukölln... Sollte vorbei sein wenn in der Zwingli
die für Neukölln vorgesehene NanoStation wieder frei ist und auch
wirklich nach Neukölln funkt. Ansonsten macht natürlich ein "Umweg" über
Neukölln wenig Sinn.

> Node 104.130.10.9: Dass überhaupt umgeschaltet wird liegt wahrscheinlich
> am fehlenden Traffic-Prio für OLSR. Sobald ein bissi Last auf einer
> Datenstrecke liegt misst OLSR eine andere Packetloss -> Route schaltet
> 130.130.130 -> boinks. Stabilere Routen hatte ich damals mit "tc"
> erhalten, einfach eine absolute Priorität auf OLSR-Broadcasts. Die
> entsprechenden "tc qdisc"  und "tc filter" fehlen aber in der PBerg-FW
> und in Folge damit auf der Zwingli.

Auf der Zwingli steht eigentlich schon wieder ein Firmware-Wechsel an.
Wir hatten "damals" bzw. vor nicht allzulanger Zeit erst von Uralt-AA
auf Bleeding-Edge BB gewechselt, wegen batman-adv 2014 und so. Das
fliegt uns jetzt natürlich um die Ohren, sobald man Kernel-Module (z.B.
kmod-ipip) nachinstallieren möchte :/
Es wird bei nächster Gelegenheit auf das Meshkit-AA geflasht, das
scheint bisher ganz stabil zu sein.
Falls sich "tc filter" auf der Zwingli noch einrichten lässt, darfst du
das gerne probieren. Klingt aber so als hättest du das schon versucht
und an den kmods gescheitert.

> Node 104.206.1.19: So ganz verstehe ich nicht, warum die MLK nicht über
> die Fulda52 'raus geht sondern bei Faustus. Zwischen der .19 und der
> 104.196.0.23 gibt es ein ETX von 1.1. Offenbar funktionieren die
> Ethernet-Links nicht...? Ab und zu klappt es offenbar doch, jedenfalls
> sehe ich auf dem VPN03 die Gatewayumschaltungen. Wenigstens das scheint
> halbwegs zu laufen:

Alle wollen bei Faustus' VDSL raus, und Faustus sammelt bestimmt gerne
reichlich viele Linkstrecken auf seinem Dach. Ist doch klar das es da
früher oder später seltsame Umwege geben muss...

> sven-ola at vpn03:~$ grep 104.198.0.108 /tmp/learn-address.txt |tail -n 4
> 16:16:05: openvpn-learn-address update 104.198.0.108 freifunk_fulda52
> 16:43:46: openvpn-learn-address update 104.198.0.108 freifunk_berlin-finow2a
> 18:40:09: openvpn-learn-address update 104.198.0.108 freifunk_fulda52
> 19:00:37: openvpn-learn-address update 104.198.0.108 freifunk_berlin-finow2a
> 
> Node 104.131.7.30: Achja. Faustus' GW. Das OpenVPN da drauf ist
> irgendwie unzuverlässig. Alle paar Stunden hakt es. Typische Meldung
> "TCP/UDP: Incoming packet rejected from [AF_INET]104.131.7.1:1194[2],
> expected peer address: [AF_INET]77.87.48.10:1194". Irgend ein
> Default-Gateway-hat-seltsames-NAT-Schluckauf zu sein. Wie kommt es, dass
> eine 104 VPN-UDP sendet anstatt das originale VPN03...?

Connection-Tracking schon abgeschaltet? Bis auf die schönen bunten
Graphen von collectd-mod-conntrack sehe ich keinen Nutzen auf einem
VPN03-Node.

> Node VPN03: Achja. Ist mir jetzt schon öfter passiert. Ich mach das WLAN
> von meinem Mobiltelefon an. Berlin.freifunk.net von meinem Zimmer-Router
> vergibt 6.x.x.x. Leider pingt es nicht ins Internet. Ich guck auf VPN03
> und sehe die ICMP's vom meinem Telefon auf dem Tunnel ankommen. Es gibt
> aber keine Rückroute. Nanu - sollte das etwa auch kaputt sein? Erstmal
> Debug in /tmp/learn-address.txt (s.o grep) eingebaut. Scheint etwas zu
> sein, wenn da mehr als 1200 Auto-Rückrouten drauf sind. Gmbl.

Das batman-adv Setup bei Emma/Zwingli/E-LOK sieht z.Z. folgend aus:

Emma, Zwingli und E-LOK sind Gateway.
DHCP-Ranges:
* Emma: 104.0.200.0/24 (?) mit Emma-Core als Gateway, also Routen via
OLSR und Endpunkt höchst wahrscheinlich VPN03
* Zwingli: 6.23.16.0 - 6.23.18.254 / Gateway 6.23.16.1 also Routen via
OLSR und Endpunkt höchst wahrscheinlich VPN03
* E-LOK:  6.23.19.0/24 / Gateway 6.23.19.1 *ohne* VPN03

> Ach. Und bei Rumgucken aufgefallen. Eine PBergFW zeigt auf folgenden
> Link nur Timeout an: wget -O -
> http://104.x.x.x/cgi-bin/luci/freifunk/olsr/routes. Ich kann also nicht
> sehen, was für Routen es gerade hat. Dabei hab' ich mit IPv6 noch gar
> nicht angefangen...!

Ja, das scheint u.a. ein inzwischen gefixter Bug im Luci zu sein. Die
Zwingli hat diesen Bug aber noch bis zum nächsten Firmware-Wechsel,
außer es findet sich ein Hotfix/Workaround. Nervt mich auch tierisch!

IPv6 scheint z.Z. auch mal wieder br0ken zu sein:
root at RAW-Core:~# mtr -r -c 1 -6 heise.de
HOST: RAW-Core                    Loss%   Snt   Last   Avg  Best
  1.|-- Zwingli-Core.olsr          0.0%     1    1.0   1.0   1.0
  2.|-- mid10.rhxb-rt1.olsr        0.0%     1    7.2   7.2   7.2
  3.|-- 2001:470:5038:5469::1      0.0%     1   19.8  19.8  19.8
  4.|-- pre1.zoofenster27.olsr     0.0%     1    9.0   9.0   9.0
  5.|-- ???                       100.0     1    0.0   0.0   0.0

Könnte am am-dach-rt1 Router liegen... oder an diesen HE.NET Tunneln. Da
müssen wir uns eh bald mal ein neues frisches ordentliches Konzept
überlegen, um unsere eigenen IPv6 Adressen sauber im BBB zu verteilen
aber gleichzeitig noch sauberes Multi-Gateway (z.B. via HE.NET) zu behalten.

Gruß
Bastian

-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 538 bytes
Beschreibung: OpenPGP digital signature
URL         : <http://lists.berlin.freifunk.net/pipermail/berlin/attachments/20140412/382706d6/attachment.pgp>