[Wien] Knoten Gatt12 / Brenner

Sa Jul 25 16:15:07 CEST 2015

Hallo!

Am 2015-07-25 um 15:45 schrieb Mike B. Kerber:
> 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!
Daran bin ich schuld ;-)
Ich habe aber mittlerweile keinen Zugriff mehr und ich weiß nicht, ob 
Akku das aktuell hält - zumal das Settings waren, die man z.T. nicht 
über das Webinterface setzen konnte, sondern nur via Shell - was Akku 
nicht gerne tut.

Grund war, dass der Brenner wegen diverser Probleme damals 
Spezialeinstellungen bekommen hat, die Akku dokumentiert haben wollte.

> Sollte man eigentlich generell so sein ;)
Ja, das finde ich auch.
> 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.
Hört bitte auf, mit der MTU "herumzuspielen". Das habe ich einmal bei 
den Knoten Zelter und Brenner gemacht, als es ganz schlimm war, aber 
davon sollte man die Finger lassen. Man heimst sich damit (insbesondere 
seit IPv6) nur Probleme damit ein.
Wenn überhaupt, dann ändert man WLAN-seitig die 
"WLAN-Paktet-Fragmentgröße", aber auch das brauchen wir in der Regel 
nicht. Die Defaults 2346 und 1500 sind aufeinander abgestimmt. Die 
Änderung des Einen bringt Performance- und Connectivityprobleme auf der 
anderen.

Was den Tunnel anbelangt, so kann die Ursache überall auf der Strecke 
zum Tunnelserver passieren. Sehr gerne sind das DSL-Strecken (diverse 
"ISPA-Kunden"), oder NAT-Trunks beim Mobilinternet.
Bei DSL passiert das wegen der PPTP-Tunnel über ATM (1492 Bit und je 
nach sonstigen Settings 1464, 1462, 1454, 1452 Bit im Download und 
1420-1428 Bit im Upload). Eine Firewall, die ICMP gänzlich blockt, 
verhindert das Funktionieren der MTU Path Discovery. Dasselbe gilt idR 
für NAT-Trunks ([mehrfach] geNATtetes NAT).

Aus diesem Grund, sollte man die MTU-Settings immer auf 1500 lassen (die 
Zeiten, wo wir mit Analog-Modems MTU-Hacks gebraucht haben, sind lange 
vorbei) und die Tunnelfragmente (auf beiden Seiten) entsprechend klein 
wählen. 1280 ist das Minimum, wenn IPv6 verwendet wird, was derzeit beim 
0xFF-Tunnelserver nicht passiert (- bin ich da noch auf dem aktuellen 
Stand?).
>   
> Erichs tipp klingt interessant... der verdacht auf eine fragmentierung
> beim tunnel ist möglich...
Z.T. gibt Tracepath Auskunft.
>
> danke für das testen!
>
> -mike
WLAN-seitig sollte immer RTS/CTS aktiviert sein. Regelfall 2346, bei 
Nutzung von OLSR 250-300 und bei argen Problemen ausnahmsweise "1".
Gerade, dann, wenn wie am Brenner die Gefahr besteht, dass es Hidden 
Stations gibt ist RTS/CTS die einzige Hoffnung.

LG
Erich
>>   
>> *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
>
>
>
> --
> Wien mailing list
> (spam-protected)
> https://lists.funkfeuer.at/mailman/listinfo/wien

-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://lists.funkfeuer.at/pipermail/wien/attachments/20150725/b3fe0c69/attachment.htm>