[Berlin-wireless] f2a-core-rt GW anscheinend kaputt

Sa Mär 5 00:27:38 CET 2016

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