Re: Ein wenig Internet "geht nicht"

On Wed, Nov 27, 2013 at 02:35:35PM +1100, Peter Ross wrote:
> Hi Bernd,
>
> danke. Ich muß bei TCP viel nachgucken. Ich habe es mal gelernt aber nicht
> unbedingt parat und gut die Hälfte vergessen. Ich gucke auf der Ebene zu
> selten hin.
>
> Ein paar kurze Fragen:
>
> >Ich mache mal die unsäglichen Zeilenumbrüche raus und kommentiere die
> >wesentlichen ersten Zeilen.
>
> Sorry.. Cut&paste.
>
> >Verbindungsaufbau von deiner Seite initiiert, receive window auf 64k
> >MSS auf 1448 - recht klein, aber wohl wegen DSL gleich runter gesetzt.
> >MSS ist die TCP-Packetgröße, die dein System verarbeiten kann, aber
> >das wird als Workaround für die path-MTU genutzt.
> >09:16:14.766313 IP 115.186.196.106.25818 > 217.13.68.220.80: Flags [S],
> >seq 1941116519, win 65535, options [mss 1448,nop,wscale 6,sackOK,TS val
> >639102670 ecr 0], length 0
> >
> >Bestätigung der Verbindung von der Gegenseite, receive window auf recht
> >kleine 5792, was aber Ok ist wenn man nicht viel zum Server schicken will
> >Zeitabstand ist schon relativ groß, aber du kommst ja auch von weit her.
> >MSS ist 1460 - mit 40 Bytes Header sind das volle 1500.
> >Das sagt aus, dass dein DSL Router keinen MSS Hack für kaput-konfiguriertes
> >Path MTU hat.
>
> Was heißt das?

MSS ist die maximale Payloadgröße, die ein TCP-Empfänger verarbeiten kann.
Normalerweise sollte der Path MTU discovery dafür sorgen, dass eine kleinere
MTU auf dem Transportwege erkannt wird.
Du schickst ein großes Packet los und der Router mit der Engstelle verwirft
das Packet, weil zu groß, dabei sended er an den Absender ein Infopacket
warum das verworfen wurde und wie groß das maximal sein darf.
Der Sender merkt sich das und sended das dann im Restransmit kleiner.
Wenn jetzt ein Webserver mit MTU 1500 ein Packt an einen DSL-Kunden schickt
wird der Router beim DSL-Provider an den Webserver so eine Information
schicken.
Da aber ICMP ja grundsätzlich böse ist (Seufz) kommt das oftmals nicht durch
die Firewall vom Webserver und der Webserver wird beim Retransmit wieder ein
1500'er Packet senden.
Daher hat man als Dirty Workaround auf den DSL-Routern üblicherweise einen
Hack laufen, der bei vorbeikommenden TCP-Packeten das MSS-Feld runter
dreht, sodass der Webserver gar nicht erst auf die Idee kommt ein zu großes
Packet zu senden.
Das funktioniert natürlich nur für TCP und sorgt dafür, dass die Server-
betreiber mit den kaputten Filtern sich immer noch nicht eine funktionierende
MTU-Discovery kümmern.

> Nebenbei.. ich glaube nicht, daß sich "mein" Rechner jemals verrechnet
> hat: Meine Pakete passen alle in die MTU von 1492, wie beim Interface des
> FreeBSD-Rechners angegeben (und abgesprochen mit dem ISP, der das Modem
> stellt - darauf habe ich keinen Zugriff).

Verstehe ich nicht.
Bei PPP handelt man die MTU mit der Gegenseite automatisch aus.
Die Geräte dahinter sollten per PMTU automatisch erfahren, wenn es einen
Abschnitt mit kleinerer MTU gibt.
Was ist das für ein Aufbau?
Bei klassischen PPPoE mit DSL-Modem hast du auf dem Ethernet-Interface
zum Modem natürlich eine 1500'er MTU - erst das PPP-Interface hat eine
kleinere MTU, weil er das mit PPP-Overhead in 1500 unter bringen muss.
Wenn du dem auf dem Ethernet zum Modem die MTU runter schraubst wird der
PPP sein Packet zum Modem nicht mehr los.

> >09:16:15.121678 IP 217.13.68.220.80 > 115.186.196.106.25818: Flags [S.],
> >seq 1647088676, ack 1941116520, win 5792, options [mss 1460,sackOK,TS val
> >76214678 ecr 639102670,nop,wscale 9], length 0
> >
> >Hir bestätigst du lediglich dem Empfang des Sync Ack vom Webserver und
> >setzt dein Window auf 1032, was schon extrem klein ist, zumal du empfangen
> >willst, aber das mag temprär so klein sein.
> >09:16:15.121822 IP 115.186.196.106.25818 > 217.13.68.220.80: Flags [.],
> >ack 1, win 1032, options [nop,nop,TS val 639103026 ecr 76214678], length 0
> >
> >Hier schickst du nun Daten zum Server, vermutlich der erste Teil.
> >Das Packet hat 1437 Bytes Payload, plus 40 Bytes Header, also 1476
> >Bytes groß.
> >09:16:15.121931 IP 115.186.196.106.25818 > 217.13.68.220.80: Flags [.],
> >seq 1:1437, ack 1, win 1032, options [nop,nop,TS val 639103026 ecr
> >76214678], length 1436
> >
> >Hier ist der zweite Teil dazu, gleich zusammen, wohl weil dein System
> >das erste Packet bei 1436 Maximalgröße ausgelegt hat.
> >09:16:15.121946 IP 115.186.196.106.25818 > 217.13.68.220.80: Flags [P.],
> >seq 1437:1782, ack 1, win 1032, options [nop,nop,TS val 639103026 ecr
> >76214678], length 345
> >
> >Hier kommt der Server um die Ecke.
> >Er hat keine Daten für dich, weil er keinen Request hat.
> >Er bestätigt (ack 1) auch keinen Empfang von deinen gesendeten 1781 Bytes.
> >Ohne Request hat der nichts zu senden, der fragt einfach nur doff nach was
> >nun los ist.
> >Man sieht auch anhand der Zeit, dass das nicht unmittelbar danach passiert.
> >Spannenderweise dreht der dir das receive window auf 12 Bytes runter, was
> >schon ziemlich frech ist.
> >09:16:15.495657 IP 217.13.68.220.80 > 115.186.196.106.25818: Flags [.],
> >ack 1, win 12, options [nop,nop,TS val 76215168 ecr 639103026,nop,nop,sack
> >1 {1437:1782}], length 0
>
> Sack und {1437:1782} - das heißt doch, das zweite Paket hat er bekommen?

Das mag sein.
SACK habe ich nicht so viel Ahnung von.

-- 
B.Walter <bernd@bwct.de> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message