olsrd_dyn_gw.so.0.5 funktioniert glaub ich nicht wirklich
Christian Dresel
fff at chrisi01.de
Mo Okt 12 10:43:12 CEST 2015
Guten Morgen
Ich hab mich jetzt testweise auch mal an die Version von Michael ran
getraut und installiert. Hier startet Olsrd aber irgendwie nicht richtig
durch:
---
********** /etc/olsrd # /etc/init.d/olsrd start
Starting olsrd:
*** olsr.org -
0.6.8.1-git_0000000-hash_88868cc56cd56d8c72f1bf61728e50bf ***
Build date: 2015-10-09 19:45:00 on fff-wue1
http://www.olsr.org
Parsing file: "/etc/olsrd/olsrd.conf"
Debug level: 0
IPv4 broadcast: 255.255.255.255
HELLO interval: 6.00
HELLO validity: 600.00
TC interval: 0.50
TC validity: 300.00
MID interval: 10.00
MID validity: 300.00
HNA interval: 10.00
HNA validity: 300.00
Interface DefaultsLink quality fish eye 1
IpVersion: 4
Clear screen enabled
HNA IPv4 entry: 10.50.32.0/21
Noint set to 1
Willingness: 3
IPC host: 127.0.0.1
Hysteresis disabled
Link quality level 2
Pollrate 0.10
TC redundancy 2
MPR coverage 5
Plugin: olsrd_httpinfo.so.0.1
Plugin param key:"Port" val: "8080"
Plugin param key:"Net" val: "0.0.0.0 0.0.0.0"
Plugin: olsrd_dyn_gw.so.0.5
Plugin param key:"Interval" val: "5"
Plugin param key:"Ping" val: "8.8.8.8"
Plugin param key:"Ping" val: "82.165.230.17"
Plugin param key:"pingcmd" val: "ping -c 1 -q -I tun0 %s"
Plugin: olsrd_dot_draw.so.0.3
RtProto: 8
RtTable: 10
RtTableDefault: 10
RtTableTunnel: 10
Queuing if kleeV2
Queuing if has2
Queuing if fff-gw-m1
Queuing if fff-pi-cd1
Warning, setting a table for tunnels without SmartGW does not make sense.
IPv4 broadcast/multicast : 255.255.255.255
Mode : mesh (d)
IPv6 multicast : ff02::6d
HELLO emission/validity : 6.00 (d)/600.00 (d)
TC emission/validity : 0.50 (d)/300.00 (d)
MID emission/validity : 10.00 (d)/300.00 (d)
HNA emission/validity : 10.00 (d)/300.00 (d)
Autodetect changes : yes
IPv4 broadcast/multicast : AUTO
Mode : mesh
IPv6 multicast : ::
HELLO emission/validity : 0.00/0.00
TC emission/validity : 0.00/0.00
MID emission/validity : 0.00/0.00
HNA emission/validity : 0.00/0.00
Autodetect changes : no
IPv4 broadcast/multicast : AUTO
Mode : mesh
IPv6 multicast : ::
HELLO emission/validity : 0.00/0.00
TC emission/validity : 0.00/0.00
MID emission/validity : 0.00/0.00
HNA emission/validity : 0.00/0.00
Autodetect changes : no
IPv4 broadcast/multicast : AUTO
Mode : mesh
IPv6 multicast : ::
HELLO emission/validity : 0.00/0.00
TC emission/validity : 0.00/0.00
MID emission/validity : 0.00/0.00
HNA emission/validity : 0.00/0.00
Autodetect changes : no
IPv4 broadcast/multicast : AUTO
Mode : mesh
IPv6 multicast : ::
HELLO emission/validity : 0.00/0.00
TC emission/validity : 0.00/0.00
MID emission/validity : 0.00/0.00
HNA emission/validity : 0.00/0.00
Autodetect changes : no
olsr.org - 0.6.8.1-git_0000000-hash_88868cc56cd56d8c72f1bf61728e50bf
detaching from the current process...
---
und dann bleibt er "hängen" ich kann nur noch mit STRG+C abbrechen. Ein
pgrep auf einer weiteren Konsole zeigt das Olsr ansich läuft aber ich
komm weder per Port 8080 an das Webinterface ran noch werden
irgendwelche routen übertragen. EIn debuglevel 9 bringt leider auch
keine weiteren Infos, er zeigt da genau das gleiche an. Die Ausgabe
scheint exakt gleich zu der von 0.6.6.2 zu sein mit der Ausname der
geänderten Versionsnummer und das er eben stecken bleibt. Bei 0.6.6.2
kommt danach noch eine Zeile "olsrd." und dann läuft olsrd fehlerfrei.
Bevor ich jetzt lang rumprobiere/Fehler suche frag ich gleich mal in die
Runde ob das Problem schon jemand hatte, ihr probiert da ja schon länger
rum als ich ;)?
ein apt-get remove olsrd und neu installieren aus den Debian
Paketquellen mit der alten Version funktionierte einwandfrei und Olsr
läuft sofort wieder so (fehlerhaft) wie man es gewohnt ist (configs
bleiben anscheinend jederzeit erhalten, ich hab sie mal zur Sicherheit
gesichert musste sie aber nie zurück spielen).
mfg
Christian
--
Kontaktmöglichkeiten ChristianD (Christian Dresel):
Jabber: christian at jabber.community
E-Mail: fff at chrisi01.de
Facebook: https://www.facebook.com/christian.chili
Handy/Whatsapp & Festnetz: auf Nachfrage
Am 09.10.2015 um 20:03 schrieb Michael Fritscher:
> Hi,
>
> ich habe testweise mal 0.6.8.1 gebaut und unter
> http://mifritscher.de/austausch/olsrd hochgeladen. Das Umschalten scheint
> zumindest insofern zu funktionieren, als dass beim killen vom VPN-Tunnel
> ein anderes Standard-Gateway verwendet wird. Wenn ich openvpn wieder
> starte merkt olsrd davon aber anscheinend nichts, sodass ich 2
> defaultrouten habe (eine Richtung VPN, eine Richtung anderen freifunk-GW).
> Die Statistik tut in dieser Version.
>
> Viele Grüße,
> Michael
>
>
>
>> Hallo,
>>
>> Also hab mal von ca. 14:15 bis 15:05 Uhr den openvpn tunnel ins Internet
>> für kleev2 gekillt.
>>
>> Im Ergebnis:
>>
>> * Leitet den Traffic von kleev2 über nue1 nach Berlin
>> * rödelt bei 100% Prozessorlast (!)
>> * Wechselt kurzzeitig von nue1 auf cdfue1 -> Eingehender Traffic von
>> cdfue1 ?
>> * Durchsatz nach nue1 deutlich unter Normal verglichen zu dem, was
>> sonst durch den Tunnel geht. 220MB vs. 1..2 GB
>> * Stellt nach Wiederbeleben des openVPN-Tunnels die reguläre
>> Verbindung wieder her.
>>
>> Plots / Statistiken:
>> Übersicht: http://10.50.32.7/mrtg/
>> Traffic Tunnel:
>> http://10.50.32.7/vnstat/index.php?if=tun0&graph=large&style=light&page=h
>> Traffic Nue1:
>> http://10.50.32.7/vnstat/index.php?if=nue1&graph=large&style=light&page=h
>> Traffic cdfue1:
>> http://10.50.32.7/vnstat/index.php?if=cdfue1&graph=large&style=light&page=h
>>
>> Wen es interessiert.
>>
>> OLSR: olsr.org -
>> 0.9.0.3-git_0000000-hash_309bb6eddd252f7728c49630bf2a9650 (built on
>> 2015-10-09 07:01:46 on KleeV2)
>>
>> Gruß
>> Torben
>>
>> On 09.10.2015 12:24, Tom Green wrote:
>>> Hi,
>>>
>>> sehr sehr geil. es klappt.
>>>
>>> gerade den openvpn gekillt. neue default route in der fff-Tabelle: nue1.
>>> Das Standard-GW aus der HNA Tabelle ausgetragen.
>>>
>>> Und der Traffic geht über nue1 auch raus:
>>> traceroute to web.de (82.165.230.17), 30 hops max, 60 byte packets
>>> 1 10.50.32.7 (10.50.32.7) 49.031 ms 58.299 ms 58.704 ms
>>> 2 10.50.32.2 (10.50.32.2) 52.360 ms 56.693 ms 57.065 ms
>>> 3 * * *
>>> 4 bgp02.berlin.freifunk.net (77.87.49.65) 71.193 ms 72.389 ms
>>> 73.993 ms
>>> 5 syseleven-k15.bcix.de (193.178.185.48) 77.885 ms 80.462 ms 81.308
>>> ms
>>> 6 ae0-0.bki1-r2.syseleven.net (77.247.83.197) 82.286 ms 61.621 ms
>>> 55.522 ms
>>> 7 xe-1-0-0-0.bgr1-r1.syseleven.net (37.49.152.237) 67.371 ms 67.859
>>> ms 83.447 ms
>>> 8 amsix.bb-c.nkf.ams.nl.oneandone.net (80.249.208.220) 86.577 ms
>>> 90.020 ms 91.124 ms
>>> 9 ae-6.bb-c.act.fra.de.oneandone.net (212.227.120.130) 92.113 ms
>>> 92.755 ms 96.683 ms
>>> 10 ae-11.bb-c.bs.kae.de.oneandone.net (212.227.120.18) 102.691 ms
>>> 103.886 ms 93.043 ms
>>> 11 ae-3.bb-c.bap.rhr.de.oneandone.net (212.227.120.71) 82.322 ms
>>> 100.314 ms 100.898 ms
>>> 12 ae-4.gw-diste-a.bap.rhr.de.oneandone.net (212.227.121.161) 209.359
>>> ms 207.703 ms 203.049 ms
>>> 13 bap.web.de (82.165.230.17) 94.552 ms 98.365 ms 98.422 ms
>>>
>>> allein der squid auf kleeV2 blockiert den Mechanismus z.Zt. noch. ohne
>>> klappt es.
>>>
>>> openvpn tunnel wieder gestartet: beide GWs als default eingetragen
>>> root at KleeV2:~# ip route show table fff | grep default
>>> default via 10.8.8.29 dev tun0
>>> default via 10.50.252.19 dev nue1 proto gated metric 2 onlink
>>>
>>> Dank der besseren Metric routet er wieder über den VPN Tunnel:
>>> traceroute to web.de (82.165.230.17), 30 hops max, 60 byte packets
>>> 1 10.50.32.7 (10.50.32.7) 54.452 ms 58.998 ms 59.876 ms
>>> 2 * * *
>>> 3 po66.evo-hv15.leaseweb.com (95.211.205.126) 76.840 ms 80.600 ms
>>> 80.931 ms
>>> 4 xe-2-2-2.evo-hvc2.leaseweb.net (81.17.33.58) 81.881 ms
>>> xe-4-0-0.evo-hvc1.leaseweb.net (81.17.33.44) 88.665 ms
>>> xe-3-0-3.evo-hvc1.leaseweb.net (81.17.33.46) 89.921 ms
>>> 5 tengige0-2-0-2.bb03.ams-01.leaseweb.net (31.31.38.16) 90.643 ms
>>> tengige0-2-0-3.bb03.ams-01.leaseweb.net (31.31.38.18) 92.004 ms
>>> tengige0-0-0-6.bb03.ams-01.leaseweb.net (31.31.38.32) 92.765 ms
>>> 6 amsix.bb-c.nkf.ams.nl.oneandone.net (80.249.208.220) 102.124 ms
>>> 58.475 ms 58.718 ms
>>> 7 ae-6.bb-c.act.fra.de.oneandone.net (212.227.120.130) 70.568 ms
>>> 71.178 ms 72.433 ms
>>> 8 ae-11.bb-c.bs.kae.de.oneandone.net (212.227.120.18) 83.909 ms
>>> 93.405 ms 96.000 ms
>>> 9 ae-3.bb-c.bap.rhr.de.oneandone.net (212.227.120.71) 86.480 ms
>>> 87.068 ms 92.271 ms
>>> 10 ae-5.gw-diste-a.bap.rhr.de.oneandone.net (212.227.122.1) 101.313
>>> ms 92.526 ms 62.426 ms
>>> 11 bap.web.de (82.165.230.17) 64.141 ms 67.265 ms 69.874 ms
>>>
>>>
>>> Sehr schön. Danke Tobias, Christian, Jan & Michael :)
>>>
>>> sieht erstmal nicht verkehrt aus....
>>>
>>> Gruß
>>> Torben
>>>
>>> On 09.10.2015 10:36, Michael Fritscher wrote:
>>>> Hi,
>>>>> "Eigentlich" "müsste" wahrscheinlich "nur mal" "jemand" "schnell" das
>>>>> obere repository bauen.
>>>> Erledigt :-) Eine 0.9.0.3 gibts unter
>>>> https://mifritscher.de/austausch/olsrd/ . Das bauen war sehr einfach,
>>>> weil
>>>> die debian-buildscripte schon existierten. Ich musste nur die
>>>> Changelog-Datei ergänzen, damit das Buildsystem weiß, dass es die
>>>> 0.9.0.3
>>>> ist (sonst wäre ein Paket rausgekommen, wo zwar 0.6.6.2-1 draufsteht,
>>>> aber
>>>> 0.9.0.3 drin ist^^)
>>>>
>>>> Ist völlig ungetestet und derzeit nur 64 Bit. Auf Anfrage kompiliere
>>>> ich
>>>> aber auch x86 32 Bit. Ich werde es heute Abend mal kurzzeitig auf
>>>> meinem
>>>> Gateway hauen und schauen, ob es funktioniert - und ob es mit der 0.6er
>>>> Version kompatibel ist.
>>>>
>>>> Viele Grüße,
>>>> Michael
>>>>
>>>>
>
Mehr Informationen über die Mailingliste franken-dev