[Wien] Knoten Gatt12 / Brenner

Sa Jul 25 15:45:08 CEST 2015

On 2015-07-25 13:04, gerhard poller wrote:
> auf allen schnittstellen auch lan hab ich das gesetzt
> testet mal  die anderen folgen nach test 
>  
> *Gesendet:* Samstag, 25. Juli 2015 um 12:59 Uhr
> *Von:* "gerhard poller" <(spam-protected)>
> *An:* "Mike B. Kerber" <(spam-protected)>
> *Cc:* (spam-protected)
> *Betreff:* Re: [Wien] Knoten Gatt12 / Brenner
> brenner west NUN  frag 1400 und mtu 1400 
>  
> *RTS  bitte alle auf 250 oder 300 setzen ist auch am brenner so  gesetzt *
>  
> hf akku
Hallo akku!

Danke für die info. RTS habe ich gemäß "notice" eintrag auf der contact
page auf 250 gesetzt. Finde ich übrigens super, dass dort solche daten
stehen!
Sollte man eigentlich generell so sein ;)
Ich habe jetzt mal die MTU bei mir wieder auf default gesetzt und das
hat nach wie vor das alte ergebnis. im tracepath konnte ich gerade jetzt
auch keine mtu änderung sehen im tracepath.

Erichs tipp klingt interessant... der verdacht auf eine fragmentierung
beim tunnel ist möglich...

danke für das testen!

-mike
>  
> *Gesendet:* Samstag, 25. Juli 2015 um 12:49 Uhr
> *Von:* "Mike B. Kerber" <(spam-protected)>
> *An:* (spam-protected)
> *Betreff:* Re: [Wien] Knoten Gatt12 / Brenner
> Hallo!
>
> Ja ich meine den brenner uplink. Ich hab das auch angeschaut, als der
> tunnel zuletzt mal weg war und über andere Knoten geroutet werden. Dann
> ist MTU 1500 ok.
>
> Ich habe die IP genommen die der speed test ansteuert und die bei
> aktiven brenner uplink tunnel mit mtu 1500 nicht antwortet.
>
> MTU=1500 =>
>
> (spam-protected):~$ tracepath 68.232.34.237
> 1?: [LOCALHOST]
> pmtu 1500
> 1: 192.168.30.1
> 14.484ms
> 1: 192.168.30.1
> 15.233ms
> 2: NanoM2.lan
> 14.832ms
> 3: westM.brenner.wien.funkfeuer.at
> 17.336ms
> 4: brenner-link.tunnel.wien.funkfeuer.at
> 20.714ms
> 5: subway.funkfeuer.at
> 49.012ms
> 6: 81.16.148.145
> 15.750ms
> 7: ae6-996.r06.uni.vie.at.nextlayer.net
> 15.074ms asymm 8
> 8: 193.203.0.184
> 31.522ms
>
> (spam-protected):~$ ping -M do -s $((1400-27)) 68.232.34.237
> PING 68.232.34.237 (68.232.34.237) 1373(1401) bytes of data.
> ping: local error: Message too long, mtu=1400
> ping: local error: Message too long, mtu=1400
> ping: local error: Message too long, mtu=1400
> ^C
> --- 68.232.34.237 ping statistics ---
> 3 packets transmitted, 0 received, +3 errors, 100% packet loss, time
> 2016ms
>
> ***************************************
>
> (spam-protected):~$ ping -M do -s $((1400-28)) 68.232.34.237
> PING 68.232.34.237 (68.232.34.237) 1372(1400) bytes of data.
> 1380 bytes from 68.232.34.237: icmp_seq=1 ttl=56 time=22.2 ms
> 1380 bytes from 68.232.34.237: icmp_seq=2 ttl=56 time=21.3 ms
> ^C
> --- 68.232.34.237 ping statistics ---
> 2 packets transmitted, 2 received, 0% packet loss, time 1001ms
> rtt min/avg/max/mdev = 21.371/21.791/22.212/0.445 ms
>
> ************************************
> Das passt mit dem "manuellen" test mit webbrowser bei dem bei MTU 1400
> die Probleme nicht beobachtet werden. 1400 wird auch öfter als passender
> VPN wert angegeben wegen des zusätzlichen Paketoverheads.
> Bei mir gehts sowohl bei MTU setting am rechner als auch für alle
> rechner mit default MTU wenn ich es am 0xff interface am router setze.
>
> Seltsam bei Fabian war halt, das es bei ihm nur gegangen ist wenn man
> die MTU am Rechner gesetzt hat und ein MTU wechsel im AirOS nicht.
>
> Ist bei der config am brenner die von Erich angegeben Frag schwelle
> gesetzt? MTU müsste eigentlich 1500 sein (nach zb tracepath).
>
> mlg
> -mike
>
> PS.: soweit ich gesehen habe verwendet Airos einen kernel 2.6.32.60,
> Openwrt ist 3.10.49..
>
> On 2015-07-25 12:00, (spam-protected) wrote:
> > Date: Fri, 24 Jul 2015 19:14:12 +0200
> > From: Clemens Hopfer <(spam-protected)>
> > To: (spam-protected)
> > Subject: Re: [Wien] Knoten Gatt12 / Brenner
> > Message-ID: <(spam-protected)>
> > Content-Type: text/plain; charset="iso-8859-1"
> >
> > Hallo Mike,
> >
> > ich nehme an, du meinst den Brenner Tunnel?
> >
> > Es ist möglich, dass wir dort ein MTU Problem haben, kannst du
> probieren, ab
> > welcher MTU die Probleme auftreten?
> >
> > Lg,
> > Clemens
> >
> > Am Freitag, 24. Juli 2015, 12:02:18 schrieb Mike B. Kerber:
> >> > Hallo!
> >> >
> >> > Fabians knoten Gatt12 ist voll online und funktioniert recht gut.
> Fabian
> >> > hat die config noch selbst hingebracht (das NAT hat gefehlt) und
> es geht
> >> > soweit gut.
> >> > Jedoch hat er das gleiche Problem wie ich seit dem neuen Tunnelsetup.
> >> > Einige wenige seiten hängen... Gut reproduzierbar ist speedof.me dort
> >> > hängt er beim abruf einer cloudfrontseite bzw macht nur den
> latenztest
> >> > und der download läuft dann in ein timeout.
> >> > Ich habe bei mir festgestellt, dass alles geht, wenn ich die mtu
> >> > runtersetze (zb auf 1400). Ich habe dann auf der nanostation bei mir
> >> > (knoten: brambiE) im openwrt die mtu auf 1400 gesetzt und alles geht.
> >> > Machen wir das im AirOS der Nanobeam bei Fabian (gatt12) ist der
> effekt
> >> > nicht da. Es treten andere lustige meldungen auf (zb bei einigen
> seiten
> >> > - ua derstandard) kommt die meldung, dass der compression header
> invalid
> >> > ist etc.
> >> > Setzt man die MTU am PC direkt hinunter geht wieder alles.
> >> >
> >> > Tracepath zeigt die Änderungen ok an.
> >> >
> >> > Hat jemand eine idee?
> >> > Gibt es einen Vorschlag was man beim AirOS noch einstellen kann damit
> >> > Fabian nicht auf jedem endgerät die MTU anpassen muss?
> >> > Hat jemand eine erklärung warum das neue Tunnelsetup etwas anders ist
> >> > als das alte (an dem reduzierten HOP liegt es ja nicht)
> >> >
> >> >
> >> > mlg
> >> > -mike
> >> >
> >> >
> >> >
> >> > --
> >> > Wien mailing list
> >> > (spam-protected)
> >> > https://lists.funkfeuer.at/mailman/listinfo/wien
> > -- | Clemens Hopfer | PGP pubkey: 5EBA9D09 |
> > xmpp://datacop@jabber.ccc.de --
>
>
> --
> Wien mailing list
> (spam-protected)
> https://lists.funkfeuer.at/mailman/listinfo/wien
> -- Wien mailing list (spam-protected)
> https://lists.funkfeuer.at/mailman/listinfo/wien

-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 181 bytes
Beschreibung: OpenPGP digital signature
URL         : <http://lists.funkfeuer.at/pipermail/wien/attachments/20150725/b6ba166a/attachment.sig>