Max. MTU bei PPTP

[lordpeng]

lieber hard(i|y|liner)

dass was du bez. linux und freeze geschrieben hast, ist a bissl a blödsinn, wenn sich unter linux ein prozess nicht mehr killen lässt, dann liegt gröber was im argen, vielleicht mal chkrootkit drüber laufen lassen ...

ich weiss nicht wieviele linux adsl gateways ich schon in betrieb genommen hab (keine fertige router distribution sondern selber zusammengestellt) aber derartige probleme konnte ich eigentlich nie beobachten ...

ich bin mir zwar sicher, dass du auf diesen beitrag sicher auch irgendwas gscheites antworten wirst bzw. willst, aber ich behaupte mal, dass ich derjenige mit der grösseren linux erfahrung von uns beiden bin ...

und bevor du fragst: nein ich bin kein langhaariger birkenstockschlapfenträger ...

[Air20]

und bevor du fragst: nein ich bin kein langhaariger birkenstockschlapfenträger ...

ach nein und ich dachte das immer... SCNR

[superracer]

dass was du bez. linux und freeze geschrieben hast, ist a bissl a blödsinn, wenn sich unter linux ein prozess nicht mehr killen lässt, dann liegt gröber was im argen, vielleicht mal chkrootkit drüber laufen lassen ...

ich glaub eher, der gute hat einfach null plan davon, was es eigentlich heißt, einen prozess zu killen...

[lordpeng]

@Air20
>ach nein und ich dachte das immer... SCNR
nur in hardy's wildesten träumen

@superracer
>ich glaub eher, der gute hat einfach null plan davon, was es eigentlich heißt, einen prozess zu killen...
ich lass das mal so im raum stehen ...

[medice]

Der "Task" wo PPTP läuft, ließ sich nich mehr killen!

kill -9 <pid>
(vorbehaltlich, dass du als User drin bist, der die Rechte dazu hat, was z.B. root in der Regel haben sollte)
Grüße von nem Linux-Anfänger

[cremor]

Hab einen dedizierten NAT-Firewall-Rechner (WinXP) der die "Einwahl" via PPTP tätigt.!
Funzt zuverlässiger als jeder externe Router. Hab damit auch keine Probs mit den Sessionlimits!
Ohne MTU 1400 funktioniert der UpLoad nicht! Auch bei den Clients!
H.

Hast du schonmal versucht die MTU der NICs nur bei den Clients auf 1400 zu setzten, am NAT-Rechner aber auf 1500 zu lassen?
Damit sollte das Problem eigentlich gelöst werden.
1.) Der NAT-Rechner braucht die Pakete der Clients nicht fragmentieren, da sie schon klein genug kommen.
2.) Der NAT-Rechner braucht die Pakete (sowohl die der Clients als auch die von ihm) nicht fragmentieren, weil sie auch mit einer Größe von 1440 Byte noch hinauskönnen.

Das wäre dann genau die Lösung, die man auch bei einem Router hat. Also die Ethernet-NICs aller Clients auf die gleiche MTU setzen wie die (virtuelle) PPTP-NIC des Routers. Denn auch bei "normalen" Routern vermindert man nur den MTU-Wert der (virtuellen) PPTP-NIC, nicht die der Ethernet-NIC.

Hat der NAT-Rechner 2 NICs geht es noch besser:
LAN-NIC auf 1400 damit alle LAN-PCs die gleiche MTU haben.
WAN-NIC auf 1500 damit nichts fragmentiert wird.

mfg cremor

[superracer]

Hast du schonmal versucht die MTU der NICs nur bei den Clients auf 1400 zu setzten, am NAT-Rechner aber auf 1500 zu lassen?

und was passiert dann mit den 1500-bytes paketen, die der nat-rechner an die clients schicken will?

die ganze mtu-herumstellerei ist eigentlich völlig pervers. ethernet hat eine mtu von 1500, punkt aus. da sollte man _nie_ irgendwas verstellen müssen, vor allem nicht nach unten. eigentlich wär's nicht ganz verkehrt, wenn das OS es nichtmal zulassen würde, da was dran zu ändern.

[hardliner]

Der Vorschlag von cremor hat schon was an sich:
Über die DSL-NIC könne ja nur Pakete mit max. 1372 Payload kommen.
H.

[cremor]

und was passiert dann mit den 1500-bytes paketen, die der nat-rechner an die clients schicken will?

Vom Internet kommen eh nur Pakete mit max 1400 Byte.
Nur wenn der Rechner selbst ein Paket an einen Client schickt könnte es ein Problem geben. Aber im LAN sollte PMTU-D ja problemlos funktionieren, oder?

die ganze mtu-herumstellerei ist eigentlich völlig pervers. ethernet hat eine mtu von 1500, punkt aus. da sollte man _nie_ irgendwas verstellen müssen, vor allem nicht nach unten. eigentlich wär's nicht ganz verkehrt, wenn das OS es nichtmal zulassen würde, da was dran zu ändern.

Dann müssten aber entweder die falsch konfigurierten Paketfilter richtig konfiguriert werden oder jeder Router (bzw. Routing-Software) müsste MSS-Clamping können.

mfg cremor

[superracer]

Nur wenn der Rechner selbst ein Paket an einen Client schickt könnte es ein Problem geben.

genau darauf wollt ich raus.
kann aber auch beim routen von paketen passieren, und zwar wenn der rechner selbstständig fragment reassembly macht, zb um die zuverlässigkeit von firewall-regeln zu machen (linux bietet diese option zb). szenario: großes udp-paket (insgesamt 1600 bytes) kommt rein, in zwei stücken (1400 + 220 bytes). rechner macht reassembly, analysiert das paket und schickt es dann ins lan weiter, wodurch es fragmentiert werden muß. mtu ist 1500, also wird ein 1500- und ein 120-byte paket verschickt. was da wohl passiert?

Aber im LAN sollte PMTU-D ja problemlos funktionieren, oder?

ähm... gerade im lan kann pmtu-d überhaupt nicht funktionieren. wer sollte denn die unreachables schicken?

Dann müssten aber entweder die falsch konfigurierten Paketfilter richtig konfiguriert werden oder jeder Router (bzw. Routing-Software) müsste MSS-Clamping können.

ähm... was haben paketfilter und mss clamping damit zu tun? die einzige voraussetzung ist, daß jeder routende ip-stack auch weiß, was fragmentieren bedeutet, so wie es sich gehört.

[cremor]

rechner macht reassembly, analysiert das paket und schickt es dann ins lan weiter, wodurch es fragmentiert werden muß. mtu ist 1500, also wird ein 1500- und ein 120-byte paket verschickt. was da wohl passiert?
[...]
ähm... gerade im lan kann pmtu-d überhaupt nicht funktionieren. wer sollte denn die unreachables schicken?

Machen das die PCs denn nicht?

ähm... was haben paketfilter und mss clamping damit zu tun? die einzige voraussetzung ist, daß jeder routende ip-stack auch weiß, was fragmentieren bedeutet, so wie es sich gehört.

Naja, würde es keine Paketfilter geben, die ICMP-Pakete rausfiltern, bräuchten wir auch unsere MTU nicht zu verkleinern, weil dann PMTU-D immer funktionieren würde.
Alternative:
Der Router macht MSS-Clamping. Auch dann brauchen wir unsere MTU nicht verkleinern.

mfg cremor

[superracer]

Machen das die PCs denn nicht?

unreachables verschicken ist einzig und allein aufgabe des ip-stacks eines routers. aber in diesem fall würden die pakete gar nicht mal bis zum ip-stack kommen (mal abgesehen davon, daß in diesem fall nicht geroutet wird). immerhin ist MTU ja ein parameter auf layer 2. da kommt also ein ethernet-frame auf der netzwerkkarte rein, mit 1500 bytes payload. der ethernet-treiber schaut sich das an und denkt sich "ohhh meine MTU ist na nur 1400 bytes, das frame ist ja viel zu groß, da kann was nicht stimmen!" und haut's still und leise weg. (machen vielleicht nicht alle treiber so, aber sie dürfen.) mal abgesehen davon, daß die karte selbst solche frames schon droppen darf, wenn sie will, ohne daß der treiber sie je zu gesicht bekommt. in beiden fällen bleibt der ip-stack unwissend aussen vor.

Naja, würde es keine Paketfilter geben, die ICMP-Pakete rausfiltern, bräuchten wir auch unsere MTU nicht zu verkleinern, weil dann PMTU-D immer funktionieren würde.
Alternative:
Der Router macht MSS-Clamping. Auch dann brauchen wir unsere MTU nicht verkleinern.

falsch. mss clamping gibt es nur, weil pmtu discovery in der praxis nicht immer gut funktioniert (eben wegen kaputter firewalls), bzw pmtu discovery nicht von allen devices unterstützt wird. weiters gibt es pmtu discovery nur, um unnötige fragmentation auf der strecke zu verhindern. weiters heißt das, daß ohne pmtu discovery pakete im falle des falles eben unnötig fragmentiert werden. daraus folgt: mss clamping ist nur sinnvoll, wenn pmtu discovery versagt. pmtu discovery ist aber optional, somit ist auch mss clamping optional. einzige voraussetzung, die der logik nach übrig bleibt, ist eine funktionierende fragmentierung.

oder anders (kürzer) ausgedrückt: mss clamping ist ein workaround für nicht funktionierende pmtu discovery (welcher im übrigen nur für tcp-connections funktioniert). pmtu discovery ist aber KEIN workaround für nicht funktionierende fragmentierung, sondern NUR ein performance-tweak, und genau deswegen auch optional (kannst du in deinem OS deiner wahl auch abschalten, wodurch mss clamping auch obsolet wird). funktionierende fragmentierung ist daher _essentiell_ für jeden router; jeder, der das nicht macht, gehört ausnahmslos eingestanzt.

[cremor]

unreachables verschicken ist einzig und allein aufgabe des ip-stacks eines routers. aber in diesem fall würden die pakete gar nicht mal bis zum ip-stack kommen (mal abgesehen davon, daß in diesem fall nicht geroutet wird). immerhin ist MTU ja ein parameter auf layer 2. da kommt also ein ethernet-frame auf der netzwerkkarte rein, mit 1500 bytes payload. der ethernet-treiber schaut sich das an und denkt sich "ohhh meine MTU ist na nur 1400 bytes, das frame ist ja viel zu groß, da kann was nicht stimmen!" und haut's still und leise weg. (machen vielleicht nicht alle treiber so, aber sie dürfen.) mal abgesehen davon, daß die karte selbst solche frames schon droppen darf, wenn sie will, ohne daß der treiber sie je zu gesicht bekommt. in beiden fällen bleibt der ip-stack unwissend aussen vor.

OK, das heißt meinen Vorschlag darf man nur anwenden, wenn man 2 NICs im NAT-Rechner hat.

[...]
oder anders (kürzer) ausgedrückt: mss clamping ist ein workaround für nicht funktionierende pmtu discovery (welcher im übrigen nur für tcp-connections funktioniert).

Das war mir eh alles klar.

pmtu discovery ist aber KEIN workaround für nicht funktionierende fragmentierung, sondern NUR ein performance-tweak, und genau deswegen auch optional (kannst du in deinem OS deiner wahl auch abschalten, wodurch mss clamping auch obsolet wird). funktionierende fragmentierung ist daher _essentiell_ für jeden router; jeder, der das nicht macht, gehört ausnahmslos eingestanzt.

Ist natürlich richtig.
Ich wollte zwar auf etwas anderes hinaus, aber egal. Anscheinend reden wir aneinander vorbei

mfg cremor

[cremor]

So, eine letzte Anmerkung:

Ich habe jetzt mal den Traffic zwischen meinem D-Link DI-604 und dem Modem mitgesnifft.
IP-Optionen setzt der DI-604 keine. Soweit also alles super.

Etwas komisch finde ich es nur, dass er den PPP-Header nur 2 Byte groß macht
In seinen PPP-Headern findet man nur das Protokoll-Feld. Das Adressen- und das Control-Feld fehlen. Bei Antworten sind die beiden Felder aber enthalten, der PPP-Header von ankommenden Traffic hat also ganz normal 4 Byte.

mfg cremor

[superracer]

Etwas komisch finde ich es nur, dass er den PPP-Header nur 2 Byte groß macht
In seinen PPP-Headern findet man nur das Protokoll-Feld. Das Adressen- und das Control-Feld fehlen. Bei Antworten sind die beiden Felder aber enthalten, der PPP-Header von ankommenden Traffic hat also ganz normal 4 Byte.

das ist afaik in der pptp-rfc nicht genau definiert. die rede ist von einem "ppp packet" als payload, da ppp aber ursprünglich für serielle verbindungen gedacht war und es somit immer in hdlc-artigen frames verpackt worden ist, ist nicht ganz klar, ab wo das eigentliche "ppp packet" jetzt beginnt. der originale windows pptp-client hat jedenfalls die beiden address- und control-bytes im header inkludiert, somit ist das der de-facto standard.

pppoe hat dieses problem übrigens nicht - hier ist genau definiert, was auf den pppoe-header zu folgen hat.

was uns wiederrum zwei sachen zeigt: 1) wie schlampig router-hersteller sind, und 2) daß pppoe auch hier pptp überlegen ist.