[Berlin-wireless] Puh...!

[Patrick]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Am 12.04.14 21:14, schrieb Bastian:
> 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.
Teile von deinem tc script müsten in dem olsrd hotplug script aufgerufen werden.
https://github.com/openwrt-routing/packages/blob/master/olsrd/files/olsrd.hotplug.sh
 
>> 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.

Das kommt als Abhängigkeit von kmod-ipt-nat mit.
Eventuell hilft udp portforwarding auf dem vdsl router.
Ich hab da auch schon seltsame Erfahrungen gemacht mit ovpn clients
hinter nat routern.

> 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.
am-dach-rt1 ist momentan ein schwarzes ip6 loch.
Ich habe olsr6 auf diesem interface aus gemacht.
Geht erstmal wieder.

 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

Gruss
         Patrick


-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlNJoo8ACgkQr9m0OkMZoqRNLQCglOY7UQLdJ8c2nBX445OT9NQg
mWYAn0gCu400eegIBGJ07+68CwmS1oLK
=P/uP
-----END PGP SIGNATURE-----