Re: UMTS - nur ping möglich

Benjamin Thelen <bt(at)ccgis.de> wrote:
> Aber kurz vorweg. Ein wirklich großen Schritt bin ich dadurch
> weitergekommen, dass ich nun andere Nameserver verwende. Jetzt
> funktioniert die Namensauflösung.

Vergiß das erstmal. Solange noch keine grundlegende Kommu-
nikation funktioniert, würde ich mich gar nicht bemühen,
DNS zum Laufen zu kriegen. Zum Debuggen und Experimentie-
ren solltest Du nur numerische IP-Adressen verwenden, um
Namensauflösung als Fehlerquelle erstmal grundsätzlich aus-
zuschließen.

> Die Werte mtu/mru max und mrru mit jeweils 296 (minimaler Wert) zu
> verwenden oder nicht, macht bisher keinen Unteschied.

Fummle an denen am besten gar nicht herum. Belaß es bei
den Default-Werten. Laut PPP-Spezifikation _muß_ ein
Empfänger 1500 als Paketgröße akzeptieren (MRU), und 296
ist die kleinstmögliche MTU. Beide werden zwischen den
Partner bei Aufnahme der Verbindung ausgehandelt.

Es gibt keinen Grund, eine kleinere MTU zu erzwingen, es
sei denn, man leidet unter einer wirklich schlechten Ver-
bindung -- in dem Fall kann eine kleine MTU den Packet-
loss ein wenig reduzieren (weil dann im Schnitt weniger
Daten von einem »Glitch« betroffen sind und die Retrans-
mission kleiner ist). Wenn man grundlos eine kleinere MTU
erzwingt, bewirkt das nichts weiter, als daß man sich die
Bandbreite reduziert, da der Paket-overhead zunimmt.

> Die maximale Paketgröße liegt so umd die 220.

Das glaube ich Dir nicht. Das erlaubt die PPP-Spezifika-
tion überhaupt nicht.

> Was bedeutet das aber nun für mich? Eigentlich würde ich daraus
> schließen, dass ich in der ppp.conf den mtu-Wert auf 220 setze,

Nein. Das geht gar nicht. Außerdem hat das keinen Ein-
fluß auf den Wert, der mit dem Partner ausgehandelt wird,
da man damit nur den _Mindestwert_ für die MTU festlegt
(und 296 ist eh das Minimum).

> Ich habe deshalb mit "ifconfig tun0 mtu 200" den Wert von 1500 runter
> gesetzt und die große Überraschung erlebt.

Es ist generell keine gute Idee, die MTU mit ifconfig zu
modifizieren, weil der Partner davon nichts mitbekommt.
Du solltest Dich schon an die MTU halten, die mit dem
Partner beim Verbindungsaufbau ausgehandelt wurde (anhand
der Werte aus Deiner PPP-Konfiguration).

Das gilt insbesondere beim Erhöhen der MTU. Ein Herabset-
zen unter den vom Partner erwarteten Wert sollte theore-
tisch nicht schaden, außer daß der Paket-overhead zunimmt,
worunter die Bandbreite leidet (s.o.). Allerdings werden
dann Pakete fragmentiert, die eigentlich in die ausgehan-
delte MTU passen würden, was möglicherweise den Partner
irritiert, da er dies nicht erwartet. Wenn die Gegenseite
strikt filtert (was durchaus möglich ist, da es einige be-
kanne DoS-Angriffe gibt, die auf ungewöhnliche Fragmenie-
rungen aufbauen), kann das zu undefiniertem Verhalten füh-
ren.

Kurz und gut: Mit MRU und MTU sollte man eigentlich nicht
herumfummeln, da man damit eher neue Probleme erzeugt als
bestehende Probleme zu lösen. Insbesondere wenn man die
ganzen Auswirkungen nicht überblickt, was mir hier der Fall
zu sein scheint. ;-)

Hast Du mal nachgeguckt, auf welchen Wert MTU/MRU ausgehan-
delt werden, wenn Du _nichts_ vorgibst? Was wird dann von
den beiden Seiten negotiated? Und was ergibt Dein ping-
Test in diesem Fall?

Wenn Du wirklich nur maximal 220 Bytes große Pakete durch-
bekommst, muß da noch etwas ganz anderes faul sein. Viel-
leicht muß am Interface selbst (also an der Hardware) noch
etwas korrekt konfiguriert werden. Äußerst seltsam finde
ich auch die Tatsache, daß tcpdump bei Dir nicht richtig zu
funktionieren scheint. Das kann mit der MTU/MRU gar nichts
zu tun haben.

Übrigens: Das, was Du bei der Option -s bei ping angibst,
ist die Größe der Nutzdaten. Dazu kommen nochmal 8 Bytes
für den ICMP-Header und 20 Bytes für den IP-Header. Wenn
Du Deine MTU auf einen bestimmten Wert n zwingst, kannst
Du also maximal n-28 bei ping -s angeben, ohne daß die Pa-
kete fragmentiert werden. Wenn der Partner grundsätzlich
keine Fragmentierung mag (s.o.), wäre es durchaus vorstell-
bar, daß der Durchsatz in den Keller geht, sobald fragmen-
tiert werden muß.

Gruß
   Olli

-- 
Oliver Fromme,  secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing
Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd
Any opinions expressed in this message may be personal to the author
and may not necessarily reflect the opinions of secnetix in any way.
One Unix to rule them all, One Resolver to find them,
One IP to bring them all and in the zone to bind them.
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message