[Berlin-wireless] f2a-core-rt GW anscheinend kaputt! Smartgateway Schuld!?
Faustus
freifunk at faust2k.net
Di Mär 8 20:06:50 CET 2016
Tja - dass ein reboot selten Probleme löst ist klar. Aber dass
es nun nichtmal 24h gehalten hat, erstaunt mich nun schon - heute
wieder das selbe Problem.
Ein init.d/olsrd restart reicht nicht aus! Erst nach einem reboot
rollt der Tunnel wieder.
Ideen? Ggf. wechsel ich mal die Firmware/OLSR Version auf blöd.
Wer sich das Problem vorort ansehen möchte ist natürlich dazu
eingeladen -> einfach SSH Key mitteilen.
Lg
Faustus
On Sun, Mar 06, 2016 at 02:40:27AM +0100, Faustus wrote:
> Ja, SmartGW war schuld... :-(
>
> Ich hab letzte Nacht den f2a-core-rt neugestartet, zumindest von
> d81-sued-2ghz läuft der Tunnel nun wieder.
>
> @Neels: sorry, ich hatte in meiner ersten Mail nur von Standorten
> gecheckt bei den SmartGW schon abgeschaltet war. Hab ich erst
> danach gemerkt.
>
> Es ist schon seltsam, mein Core ist relativ einfach konfiguriert:
> keine Firewall, kein Policyrouting, statische IP+Gateway auf dem
> "WAN"-Interface. Den Gateway hat er hin und wieder vergessen,
> warum auch immer. Das hab ich aber mittlerweile in Griff bekommen
> mit einem Hotplug-Script in /etc/hotplug.d/iface/ das bei
> ifdown/ifup den GW nochmal setzt.
>
> Keine Ahnung also warum der Tunnel plötzlich aussetzte. Hier
> läuft Kathleen 0.2.0 mit OLSR 0.9.0.3... werd mir das nächste mal
> mehr Zeit nehmen für die Fehlersuche...
>
> Und ja - ich fände es super genial, wenn es eine simple
> Möglichkeit gäbe einen Satz von SmartGWs/ipip-Tunnel einfach im
> Frontend zu "pinnen", die dann nach Verfügbarkeit und Priorität
> vorzugsweise benutzt werden. Auf meinem
> "produktiv-bastel-Debian-DSL-Router" klappt das ja prima, wenn
> auch etwas gefrickelt: kleiner Cronjob checkt sehr regelmäßig
> mehrere Tunnel/Gateways (ping $remote+8.8.8.8). Funzt das, wird
> neben dem default DSL-Gateway (metric 1) der Tunnel als weiterer,
> Fallback-Gateway (metric >1) angelegt, in meinem Fall also zu
> l9-core, wg1337...
>
> Und da bspw. L9 in Pberg mit 100/12 MBits nen super Uplink bietet
> und mein Freifunk dorthin richtig performant ist, macht es schon
> fast Spass wenn Telekom VDSL 50/10 in Fhain mal wieder aussetzt
> -> Internet ist dann schneller. :-P
>
> Deswegen kann Freifunka auch SmartGW mögen... ;-)
>
> Lg
> Faustus
>
>
> On Sat, Mar 05, 2016 at 02:35:07AM +0100, Bastian wrote:
> > smartgateway abschalten?
> >
> > Wir prüfen ja schon auf "richtiges" announcen eines default-route HNA
> > dank eine reinzigen super special IP.
> > Aber dank policy-routing(!) und multiple routing tables, iptables und
> > was sonst noch wird damit keinerlei Corner-Case abgedeckt...
> >
> > Wie wäre es denn mit prüfen auf working default-route/smartgw-selection?
> >
> > Smart gateway selection?
> >
> > On 03/05/2016 12:27 AM, Thomas Arden wrote:
> > > Moin;
> > > Habe das gleiche mit einem anderen Router hier im Pberg getestet um auch zu
> > > verifizieren ob dies auch tatsächlch ein Issue von f2a-core ist:
> > > Router: duncker4connect.olsr
> > > olsrd neustart:
> > > ip tun
> > > tnl_0a1f3005: ip/ip remote 10.31.48.5 local any ttl 64
> > > tunl0: ip/ip remote any local any ttl inherit nopmtudisc
> > >
> > > ping 8.8.8.8
> > > PING 8.8.8.8 (8.8.8.8): 56 data bytes
> > > 64 bytes from 8.8.8.8: seq=0 ttl=51 time=58.552 ms
> > > 64 bytes from 8.8.8.8: seq=1 ttl=51 time=11.851 ms
> > > 64 bytes from 8.8.8.8: seq=2 ttl=51 time=14.035 ms
> > > ^C
> > > --- 8.8.8.8 ping statistics ---
> > > 3 packets transmitted, 3 packets received, 0% packet loss
> > >
> > > Nach einer Weile hat er das Gateway auf
> > > @duncker4connect:~# ip tun
> > > tunl0: ip/ip remote any local any ttl inherit nopmtudisc
> > > tnl_0a1f022d: ip/ip remote 10.31.2.45 local any ttl 64
> > >
> > > gewechselt und es ging Nix mehr.
> > >
> > > t at duncker4connect:~# ping 8.8.8.8
> > > PING 8.8.8.8 (8.8.8.8): 56 data bytes
> > > ^C
> > > --- 8.8.8.8 ping statistics ---
> > > 7 packets transmitted, 0 packets received, 100% packet loss
> > >
> > >
> > > Am Freitag, 4. März 2016, 23:52:42 CET schrieb Thomas Arden:
> > >> My god;
> > >> habe hier Stunden damit zu gebracht:
> > >> habe heute hier im Pberg festgestellt dass die AP's seit einer Woche ohne
> > >> Gateway waren. Siehe Monitoring. Ein Neustart des olsrd half meistens nur
> > >> kurz bis das SMARTGAteway das Gateway wechselte. Danach ging nix mehr.
> > >> Habe mir Hilfe ( Mister P) geholt und mit 4 Augen konnte man sehen zuerst
> > >> samoa4 als Gateway fungierte und danach zu10.31.2.45 wechselte. Aber durch
> > >> diesen tunnel kam nix zurück...... NIX...Also gar NIX.
> > >> Hier der OUTPUT:
> > >> #####
> > >> ip tun
> > >> tunl0: ip/ip remote any local any ttl inherit nopmtudisc
> > >> tnl_0a1f022d: ip/ip remote 10.31.2.45 local any ttl 64
> > >> #####
> > >> ip r s t olsr-tunnel
> > >> default dev tnl_0a1f022d metric 2
> > >> #####
> > >> ping 8.8.8.8
> > >> PING 8.8.8.8 (8.8.8.8): 56 data bytes
> > >> ^C
> > >> --- 8.8.8.8 ping statistics ---
> > >> 7 packets transmitted, 0 packets received, 100% packet loss
> > >> PLEASE FAUSTUS SCHAU MAL IN DEN TUNNEL
> > >>
> > >> CIAO Tomaggio
> > >>
> > >> Am Freitag, 4. März 2016, 01:03:27 CET schrieb Neels Hofmeyr:
> > >>> On Thu, Mar 03, 2016 at 08:10:22PM +0100, Faustus wrote:
> > >>>> Eigenartig. Die 10.31.2.45 ist das Interface in Richtung
> > >>>> Segenskirche auf f2a-core - von der Segen aus betrachtet sieht
> > >>>> aber alles prima aus:
> > >>>>
> > >>>> root at segen-core:~# mtr -r -c1 8.8.8.8
> > >>>> Start: Thu Mar 3 19:53:24 2016
> > >>>> HOST: segen-core Loss% Snt Last Avg Best Wrst
> > >>>> StDev>
> > >>>>
> > >>>> 1.|-- 10.31.2.45 0.0% 1 1.0 1.0 1.0 1.0
> > >>>> 0.0
> > >>>> 2.|-- 10.31.2.2 0.0% 1 1.6 1.6 1.6 1.6
> > >>>> 0.0
> > >>>> 3.|-- 217.5.98.18 0.0% 1 22.5 22.5 22.5 22.5
> > >>>> 0.0
> > >>>> 4.|-- 217.237.153.6 0.0% 1 21.9 21.9 21.9 21.9
> > >>>> 0.0
> > >>>> 5.|-- 80.150.170.98 0.0% 1 35.3 35.3 35.3 35.3
> > >>>> 0.0
> > >>>> 6.|-- 72.14.233.114 0.0% 1 27.9 27.9 27.9 27.9
> > >>>> 0.0
> > >>>> 7.|-- google-public-dns-a.googl 0.0% 1 27.6 27.6 27.6 27.6
> > >>>> 0.0
> > >>>>
> > >>>> root at segen-core:~#
> > >>>>
> > >>>> Auch das Rathaus Neukölln und Martin Luther werfen hier gerade
> > >>>> Traffic ab - die letzten Tage waren das immer ~150 GB/Tag.
> > >>>>
> > >>>> Vielleicht ein temporärer Schluckauf?
> > >>>
> > >>> Hmm. Das geht jetzt schon seit ca. einer Woche so, und ich habe 6 router
> > >>> die dasselbe Problem unabhängig voneinander zeigen.
> > >>>
> > >>> Zwei von denen sind mit M5 am rhnk angebunden, und vier via emma.
> > >>>
> > >>> Ich bin ziemlich sicher dass ich nicht auf allen sechs was kaputtgemacht
> > >>> hab, und da die verschieden funken und alle dasselbe Problem zeigen
> > >>> rätselt
> > >>> es mich dass es von woanders geht...
> > >>>
> > >>> Einer davon ist ein ArcherC5 und die anderen sind alles WR841N; alle
> > >>> laufen mit backbone image, die WR841Ns mit dem 4mb-backbone image.
> > >>>
> > >>> Wenn ich die tunnel route lösche und das netz geht, dann geht der traffic
> > >>> interessanterweise trotzdem durch f2a (siehe traceroute unten) aber halt
> > >>> nicht durch den tunnel.
> > >>>
> > >>> Also der f2a traffic geht, nur der tunnel failt. Weiß jemand warum der
> > >>> tunnel failen könnte?? Wie kann ich eigentlich den tunnel analysieren,
> > >>> gibts da kluge methoden?
> > >>>
> > >>> Das Netz durch den tunnel geht problemlos sobald der smartgw irgendein
> > >>> anderes gw außer eben 10.31.2.45 auswählt. Scheint also doch irgendwie mit
> > >>> dem f2a tunnel "ausgang" zu tun zu haben.
> > >>>
> > >>> (v6 ist von alldem natürlich gänzlich unbeeindruckt und läuft einfach.)
> > >>>
> > >>> Ein paar details...
> > >>> Wenn f2a als smartgw ausgewählt ist sieht's so aus:
> > >>>
> > >>>
> > >>> root at archie:~# ip r show table olsr-tunnel
> > >>> default dev tnl_0a1f022d metric 2
> > >>>
> > >>> root at archie:~# traceroute 10.31.2.45
> > >>> traceroute to 10.31.2.45 (10.31.2.45), 30 hops max, 38 byte packets
> > >>>
> > >>> 1 mid13.rhnk-core.olsr (10.230.3.10) 1.130 ms 0.871 ms 1.054 ms
> > >>> 2 f2a-core-rt.olsr (10.31.2.45) 8.346 ms 5.325 ms 5.012 ms
> > >>>
> > >>> root at archie:~# traceroute freifunk.net
> > >>> traceroute to freifunk.net (176.28.11.93), 30 hops max, 38 byte packets
> > >>>
> > >>> 1 * * *
> > >>> 2 * * *
> > >>> 3 * * *
> > >>> 4^C
> > >>>
> > >>> root at archie:~# ping freifunk.net
> > >>> PING freifunk.net (176.28.11.93): 56 data bytes
> > >>> <idle idle idle>
> > >>> ^C
> > >>> --- freifunk.net ping statistics ---
> > >>> 29 packets transmitted, 0 packets received, 100% packet loss
> > >>>
> > >>>
> > >>>
> > >>>
> > >>> Wenn ich dann die route lösche siehts so aus:
> > >>>
> > >>>
> > >>> root at archie:~# ip r del default dev tnl_0a1f022d metric 2 table
> > >>> olsr-tunnel
> > >>> root at archie:~# ip r show table olsr-tunnel
> > >>> <nix>
> > >>>
> > >>> root at archie:~# traceroute 10.31.2.45
> > >>> traceroute to 10.31.2.45 (10.31.2.45), 30 hops max, 38 byte packets
> > >>>
> > >>> 1 mid13.rhnk-core.olsr (10.230.3.10) 1.257 ms 1.824 ms 1.873 ms
> > >>> 2 f2a-core-rt.olsr (10.31.2.45) 2.488 ms 2.505 ms 3.761 ms
> > >>>
> > >>> root at archie:~# traceroute freifunk.net
> > >>> traceroute to freifunk.net (176.28.11.93), 30 hops max, 38 byte packets
> > >>>
> > >>> 1 mid13.rhnk-core.olsr (10.230.3.10) 0.926 ms 1.693 ms 1.104 ms
> > >>> 2 mid4.f2a-core-rt.olsr (10.31.2.33) 6.303 ms 6.583 ms 4.607 ms
> > >>> 3 10.31.2.2 (10.31.2.2) 7.036 ms 8.824 ms 6.968 ms
> > >>> 4 217.5.98.18 (217.5.98.18) 25.047 ms 26.685 ms 26.094 ms
> > >>> 5 217.237.153.6 (217.237.153.6) 30.791 ms 29.298 ms 30.614 ms
> > >>> 6 d-ed1-i.D.DE.NET.DTAG.DE (62.154.15.230) 30.985 ms 217.239.50.86
> > >>>
> > >>> (217.239.50.86) 31.488 ms d-ed1-i.D.DE.NET.DTAG.DE (62.154.15.226)
> > >>> 31.304 ms 7 62.157.250.114 (62.157.250.114) 32.677 ms 42.532 ms 35.534
> > >>> ms 8 xe-0-3-0.dr-master.r2.cgn3.he-core.de (176.28.4.54) 33.736 ms
> > >>> 39.165 ms 86.440 ms 9 * * *
> > >>> 10 lvps176-28-11-93.dedicated.hosteurope.de (176.28.11.93) 50.358 ms
> > >>> 37.433 ms 37.115 ms
> > >>>
> > >>> root at archie:~# ping freifunk.net
> > >>> PING freifunk.net (176.28.11.93): 56 data bytes
> > >>> 64 bytes from 176.28.11.93: seq=0 ttl=55 time=41.508 ms
> > >>> 64 bytes from 176.28.11.93: seq=1 ttl=55 time=42.981 ms
> > >>> 64 bytes from 176.28.11.93: seq=2 ttl=55 time=31.535 ms
> > >>> 64 bytes from 176.28.11.93: seq=3 ttl=55 time=29.499 ms
> > >>> 64 bytes from 176.28.11.93: seq=4 ttl=55 time=35.311 ms
> > >>> 64 bytes from 176.28.11.93: seq=5 ttl=55 time=32.603 ms
> > >>> 64 bytes from 176.28.11.93: seq=6 ttl=55 time=40.650 ms
> > >>> 64 bytes from 176.28.11.93: seq=7 ttl=55 time=36.346 ms
> > >>> ^C
> > >>> --- freifunk.net ping statistics ---
> > >>> 8 packets transmitted, 8 packets received, 0% packet loss
> > >>> round-trip min/avg/max = 29.499/36.304/42.981 ms
> > >>>
> > >>>
> > >>> Wenn ich noch irgendwelche commands oder logs checken kann immer her mit
> > >>> den kommandozeilen...
> > >>>
> > >>> ~Neels
> > >>
> > >> _______________________________________________
> > >> Berlin mailing list
> > >> Berlin at berlin.freifunk.net
> > >> http://lists.berlin.freifunk.net/cgi-bin/mailman/listinfo/berlin
> > >> Diese Mailingliste besitzt ein ffentlich einsehbares Archiv
> > >
> > > _______________________________________________
> > > Berlin mailing list
> > > Berlin at berlin.freifunk.net
> > > http://lists.berlin.freifunk.net/cgi-bin/mailman/listinfo/berlin
> > > Diese Mailingliste besitzt ein ffentlich einsehbares Archiv
> > >
> >
> >
>
>
>
>
> > _______________________________________________
> > Berlin mailing list
> > Berlin at berlin.freifunk.net
> > http://lists.berlin.freifunk.net/cgi-bin/mailman/listinfo/berlin
> > Diese Mailingliste besitzt ein ?ffentlich einsehbares Archiv
>
>
> --
> Freifunk ist politisch.
> _______________________________________________
> Berlin mailing list
> Berlin at berlin.freifunk.net
> http://lists.berlin.freifunk.net/cgi-bin/mailman/listinfo/berlin
> Diese Mailingliste besitzt ein ?ffentlich einsehbares Archiv
--
Freifunk ist politisch.
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname : signature.asc
Dateityp : application/pgp-signature
Dateigröße : 181 bytes
Beschreibung: Digital signature
URL : <https://lists.berlin.freifunk.net/pipermail/berlin/attachments/20160308/cd5e82f2/attachment.sig>
Mehr Informationen über die Mailingliste Berlin