[Berlin-wireless] Puh...!

[Patrick]

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

PS: 
Ich hab den #heartbleed ausgelöst. ;-)

https://github.com/freifunk/firmware-berlin/commits/master/patches/aa-package-openssl-broken.patch
ls -lc sagt Mar 10 17:27
git 2014-03-30 14:43:22


Am 12.04.14 22:31, schrieb Patrick:
> 
> 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/

iEYEARECAAYFAlNJ+2EACgkQr9m0OkMZoqR5fQCdHIAIpcoL4zOjuaTzxLB29aLO
BWgAoMJ8c1k522kDZqlOmkPvMz9aTmJW
=DCmx
-----END PGP SIGNATURE-----