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" <akk...@gmx.at>
*An:* "Mike B. Kerber" <michael.ker...@univie.ac.at>
*Cc:* wien@lists.funkfeuer.at
*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" <michael.ker...@univie.ac.at>
*An:* wien@lists.funkfeuer.at
*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, wien-requ...@lists.funkfeuer.at wrote:
Date: Fri, 24 Jul 2015 19:14:12 +0200
From: Clemens Hopfer <data...@wireloss.net>
To: wien@lists.funkfeuer.at
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
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
Wien@lists.funkfeuer.at
https://lists.funkfeuer.at/mailman/listinfo/wien
-- | Clemens Hopfer | PGP pubkey: 5EBA9D09 |
xmpp://data...@jabber.ccc.de --
--
Wien mailing list
Wien@lists.funkfeuer.at
https://lists.funkfeuer.at/mailman/listinfo/wien
-- Wien mailing list Wien@lists.funkfeuer.at
https://lists.funkfeuer.at/mailman/listinfo/wien
--
Wien mailing list
Wien@lists.funkfeuer.at
https://lists.funkfeuer.at/mailman/listinfo/wien
--
Wien mailing list
Wien@lists.funkfeuer.at
https://lists.funkfeuer.at/mailman/listinfo/wien
