Re: Ein wenig Internet "geht nicht"

On Wed, Nov 27, 2013 at 09:35:37AM +1100, Peter Ross wrote:
> On Tue, 26 Nov 2013, Bernd Walter wrote:
>
> >On Tue, Nov 26, 2013 at 04:37:41PM +1100, Peter Ross wrote:
> >>
> >>Interessant, daß mein traceroute für ICMP problemlos ankommt (und ping
> >>geht), nicht aber Port 80-Pakete:
> >>
> >># traceroute -I www.zeit.de
> >>traceroute to www.zeit.de (217.13.68.220), 64 hops max, 72 byte packets
> >> 8 dtag.gaertner.de (80.150.168.230) 353.579 ms 354.360 ms 354.330 ms
> >> 9 www.zeit.de (217.13.68.220) 355.478 ms 355.685 ms 358.413 ms
> >>
> >># traceroute -P tcp -p 80 www.zeit.de
> >>traceroute to www.zeit.de (217.13.68.220), 64 hops max, 64 byte packets
> >> 8 dtag.gaertner.de (80.150.168.230) 354.517 ms 353.234 ms 355.168 ms
> >> 9 * * *
> >>10 * * *
> >>11 * * *
> >>12 * * *
> >>13 * * *
> >
> >Das ist vollkommen normal.
> >Der Traceroute geht bis zu der Stelle, die der Administration vom
> >Server unterliegt.
> >Die haben dort halt eine Firewall stehen, die deine Port 80 Packete
> >nicht direkt durch leiten will, weil eben keine richtige Verbindung.
>
> Ja, das stimmt.
>
> Also, als Update und Klarstellung: die 502/504 sind die Fehlermeldungen
> von meinem Squid, nicht von dem Webserver remote.
>
> Vom Webserver (www.zeit.de) kommen lediglich Zero-Length-Pakete zurück.
>
> Von vielen anderen Servern kommt eine ordentliche Antwort zurück (es gibt
> aber Ausnahmen, www.zeit.de ist nicht das einzige Problem)
>
> Der Squid oder Firewall haben damit nichts zu tun: das Resultat ist mit
> direkt angeschlossenem Rechner das gleiche.
>
> Wenn ich die selben Anfragen über die andere Leitung schicke, bekomme ich
> auch von www.zeit.de ordentliche HTML-Seiten.
>
> Die Route zu www.zeit.de scheint zu funktionieren, ping geht, auch
> Port-80-Pakete scheinen dahin geroutet zu werden.
>
> Was könnte den Webserver www.zeit.de dazu veranlassen, keine
> "ordentlichen" Pakete zurückzuschicken?
>
> Oder werden die auf dem Rückweg verstümmelt?
>
> Für den Verschwörungstheoretiker: die alte Route geht über die USA,
> die neue über Singapur.
>
> Ich finde das mysteriös, und ärgerlicher, eine "geht meistens"-Verbindung
> kann ich nicht nutzen.
>
> Ich schicke weiter unten einen tcpdump.. falls jemand neugierig ist und
> irgendwas findet.. für mich sind die Antworten Zero-Byte-Pakete, mehr kann
> ich da nicht rauslesen, es ist das Resultat eines Browser-Requests für
> http://www.zeit.de.
>
> Es grüßt
> Peter
>
> # tcpdump -i igb0 -n host 217.13.68.220

Ich mache mal die unsäglichen Zeilenumbrüche raus und kommentiere die
wesentlichen ersten Zeilen.

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.
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

Hier versucht dein Server dann einen retransmit der Daten, diesmal nur das
erste Packet, weil der sich vorsichtig rantastet.
Dass dein Rechner das 12-Byte receive window ignoriert und trotzdem noch
ein großes Packet sended sollte so nicht sein, aber da gibt es auch
diverse mögliche Gründe vor, die ich jetzt im Detail nicht erleutern will
09:16:16.392692 IP 115.186.196.106.25818 > 217.13.68.220.80: Flags [.], seq 1:1437, ack 1, win 1032, options [nop,nop,TS val 639104297 ecr 76215168], length 1436

Und noch ein Versuch:
09:16:18.734693 IP 115.186.196.106.25818 > 217.13.68.220.80: Flags [.], seq 1:1437, ack 1, win 1032, options [nop,nop,TS val 639106639 ecr 76215168], length 1436

Hier gibt der Server dann auf und sagt, wenn du nix willst kannste gehn.
09:16:20.576000 IP 217.13.68.220.80 > 115.186.196.106.25818: Flags [F.], seq 1, ack 1, win 12, options [nop,nop,TS val 76215676 ecr 639103026,nop,nop,sack 1 {1437:1782}], length 0

Danach noch di gegenseitige Bestätigung des Verbindungsabbaus und es
wiederholt sich das ganze mit zwei weiteren Verbindungen.

Um das zusammen zu fassen:
Dein 1436 Bytes Packet kommt scheinbar beim Server nicht an.
Der Server ist in der Lage dir Packete zu schicken, ohne den Empfang
darin zu bestätigen, d.h. es ist nicht so, dass das Ack vom Server
ausbleibt, sondern dein Datenpacket.
Ob das zweite kleine ankommt weiß man bei TCP leider nicht, weil das
erst bestätigt werden kann, wenn das davor da ist.
Warum das 1476 Bytes große Packet nicht ankommt kann ich nicht sagen.

Ich würde mal nach der Einwahl die MTU vom DSL-Interface runter drehen
und schauen, ob das was verändert.
Dein Rechner sollte mit kleinerer Interface-MTU kleinere Packete senden.

-- 
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