[Berlin-wireless] Puh...!

Sa Apr 12 20:02:35 CEST 2014

Hey,

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:

[root at pcexo sven-ola]# tracepath -b 8.8.8.8
 1?: [LOCALHOST]                                         pmtu 1500
 1:  sven-ola-tp65.olsr (192.168.108.1)                    0.837ms 
 1:  sven-ola-tp65.olsr (192.168.108.1)                    0.697ms 
 2:  sven-ola-wap.olsr (104.198.65.97)                     3.520ms 
 3:  GEK-Mod77-Arena.olsr (104.130.77.80)                 19.920ms 
 4:  martin-luther-no.olsr (104.206.1.17)                 39.851ms 
 5:  mid1.martin-luther-core.olsr (104.206.1.14)          26.990ms 
 6:  mid2.f2a-core-rt.olsr (104.131.7.30)                 27.160ms 
 7:  172.31.240.1 (172.31.240.1)                         114.421ms 
 8:  bgp01.berlin.freifunk.net (77.87.48.1)               68.603ms 
 9:  vlan935.sepia.in-berlin.de (217.197.91.131)         144.867ms 
10:  vlan84.octalus.in-berlin.de (192.109.82.65)          78.353ms 
^C

Node 104.130.130.130: Topologisch wäre eine Strecke über die Zwingli
günstiger. Zwischen Bockis 2. Router auf Kanal 9 und der Zwingli ist
aber 104.130.130.130 aufgetaucht. Ab und zu geht es direkt über Bocki2
<--> Zwingli, aber hin und wieder meint OLSR diese Verbindung muss über
104.130.130.130. Wäre ja nicht schlimm, aber dieses Gerät (Ubiquiti)
fährt offenbar was selbstgebasteltes (nur SSH und Port 2006), was mir
bei laufender TCP-Verbindung sofort ein TCP-RST einschleift ->
SSH-Session fliegt weg. Scheint auf dem Ding ein Firewallquirks zu sein.
Bin gespannt ob der Node-Owner sich auf die Anfrage in der IP-Verwaltung
meldet.

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.

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:

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...?

Node 104.131.99.20: Das ist k9-bbb-rt1.olsr. Das ist auch ab und zu der
Ausgang. Jedenfalls bei Route über die Zwingli. Da geht es direkt ins
Internet. Ist ja erstmal prima, nur hat das bei der Gateway-Umschalterei
den gravierenden Nachteil, dass die VPN03-kennt-die-Rückroute-Geschichte
dann natürlich nicht greifen kann und alle laufenden Verbindungen schon
wieder wegfliegen.

Node 104.0.2.201: Guck' ich wegen QoS für Zwingli auf die Emma. "tc
qdisc show" und "tc filter show dev wlan0-1". Oops. Das zeigt nicht
genug an. Offenbar funzt mein QoS-Hack in /etc/rc.local auch nicht immer
zuverlässig. Grmbl.

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.

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...!

// Sven-Ola

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