<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Hallo!<br>
<br>
Am 2015-07-25 um 15:45 schrieb Mike B. Kerber:<br>
</div>
<blockquote cite="mid:55B392E4.5060201@univie.ac.at" type="cite">
<pre wrap="">On 2015-07-25 13:04, gerhard poller wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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" <a class="moz-txt-link-rfc2396E" href="mailto:akku99@gmx.at"><akku99@gmx.at></a>
*An:* "Mike B. Kerber" <a class="moz-txt-link-rfc2396E" href="mailto:michael.kerber@univie.ac.at"><michael.kerber@univie.ac.at></a>
*Cc:* <a class="moz-txt-link-abbreviated" href="mailto:wien@lists.funkfeuer.at">wien@lists.funkfeuer.at</a>
*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
</pre>
</blockquote>
<pre wrap="">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!</pre>
</blockquote>
Daran bin ich schuld ;-)<br>
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.<br>
<br>
Grund war, dass der Brenner wegen diverser Probleme damals
Spezialeinstellungen bekommen hat, die Akku dokumentiert haben
wollte.<br>
<br>
<blockquote cite="mid:55B392E4.5060201@univie.ac.at" type="cite">
<pre wrap="">
Sollte man eigentlich generell so sein ;)</pre>
</blockquote>
Ja, das finde ich auch.<br>
<blockquote cite="mid:55B392E4.5060201@univie.ac.at" type="cite">
<pre wrap="">
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.</pre>
</blockquote>
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.<br>
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.<br>
<br>
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.<br>
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).<br>
<br>
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?).<br>
<blockquote cite="mid:55B392E4.5060201@univie.ac.at" type="cite">
<pre wrap="">
Erichs tipp klingt interessant... der verdacht auf eine fragmentierung
beim tunnel ist möglich...</pre>
</blockquote>
Z.T. gibt Tracepath Auskunft.<br>
<blockquote cite="mid:55B392E4.5060201@univie.ac.at" type="cite">
<pre wrap="">
danke für das testen!
-mike</pre>
</blockquote>
WLAN-seitig sollte immer RTS/CTS aktiviert sein. Regelfall 2346, bei
Nutzung von OLSR 250-300 und bei argen Problemen ausnahmsweise "1".<br>
Gerade, dann, wenn wie am Brenner die Gefahr besteht, dass es Hidden
Stations gibt ist RTS/CTS die einzige Hoffnung.<br>
<br>
<br>
LG<br>
Erich<br>
<blockquote cite="mid:55B392E4.5060201@univie.ac.at" type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">
*Gesendet:* Samstag, 25. Juli 2015 um 12:49 Uhr
*Von:* "Mike B. Kerber" <a class="moz-txt-link-rfc2396E" href="mailto:michael.kerber@univie.ac.at"><michael.kerber@univie.ac.at></a>
*An:* <a class="moz-txt-link-abbreviated" href="mailto:wien@lists.funkfeuer.at">wien@lists.funkfeuer.at</a>
*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 =>
user@host:~$ 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
user@host:~$ 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
***************************************
user@host:~$ 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, <a class="moz-txt-link-abbreviated" href="mailto:wien-request@lists.funkfeuer.at">wien-request@lists.funkfeuer.at</a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Date: Fri, 24 Jul 2015 19:14:12 +0200
From: Clemens Hopfer <a class="moz-txt-link-rfc2396E" href="mailto:datacop@wireloss.net"><datacop@wireloss.net></a>
To: <a class="moz-txt-link-abbreviated" href="mailto:wien@lists.funkfeuer.at">wien@lists.funkfeuer.at</a>
Subject: Re: [Wien] Knoten Gatt12 / Brenner
Message-ID: <1562947.ySpTyutCYJ@datacop-desktop>
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
</pre>
</blockquote>
<pre wrap="">probieren, ab
</pre>
<blockquote type="cite">
<pre wrap="">welcher MTU die Probleme auftreten?
Lg,
Clemens
Am Freitag, 24. Juli 2015, 12:02:18 schrieb Mike B. Kerber:
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">Hallo!
Fabians knoten Gatt12 ist voll online und funktioniert recht gut.
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">Fabian
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">hat die config noch selbst hingebracht (das NAT hat gefehlt) und
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">es geht
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">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
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">latenztest
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">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
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">effekt
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">nicht da. Es treten andere lustige meldungen auf (zb bei einigen
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">seiten
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">- ua derstandard) kommt die meldung, dass der compression header
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">invalid
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">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
<a class="moz-txt-link-abbreviated" href="mailto:Wien@lists.funkfeuer.at">Wien@lists.funkfeuer.at</a>
<a class="moz-txt-link-freetext" href="https://lists.funkfeuer.at/mailman/listinfo/wien">https://lists.funkfeuer.at/mailman/listinfo/wien</a>
</pre>
</blockquote>
</blockquote>
<pre wrap="">-- | Clemens Hopfer | PGP pubkey: 5EBA9D09 |
<a class="moz-txt-link-abbreviated" href="mailto:xmpp://datacop@jabber.ccc.de">xmpp://datacop@jabber.ccc.de</a> --
</pre>
</blockquote>
<pre wrap="">
--
Wien mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Wien@lists.funkfeuer.at">Wien@lists.funkfeuer.at</a>
<a class="moz-txt-link-freetext" href="https://lists.funkfeuer.at/mailman/listinfo/wien">https://lists.funkfeuer.at/mailman/listinfo/wien</a>
-- Wien mailing list <a class="moz-txt-link-abbreviated" href="mailto:Wien@lists.funkfeuer.at">Wien@lists.funkfeuer.at</a>
<a class="moz-txt-link-freetext" href="https://lists.funkfeuer.at/mailman/listinfo/wien">https://lists.funkfeuer.at/mailman/listinfo/wien</a>
</pre>
</blockquote>
<pre wrap="">
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">--
Wien mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Wien@lists.funkfeuer.at">Wien@lists.funkfeuer.at</a>
<a class="moz-txt-link-freetext" href="https://lists.funkfeuer.at/mailman/listinfo/wien">https://lists.funkfeuer.at/mailman/listinfo/wien</a></pre>
</blockquote>
<br>
</body>
</html>