Fragmented IP protocol / Packetanalyse

Hallo liebe Leute,

ich habe gemäß FAQ:428 MTU (1464) und TcpWindowSize/ GlobalMaxTcpWindowSize (363120) bestimmt und gesetzt. Tcp1323Opts = 1 und SackOpts = 1 gesetzt.
ping -f -l 1436 geht noch, mit 1437 nicht mehr, weil fragmentiert werden müßte.
Nun habe ich per Ethereal aber Packete „Fragmented IP protocol“ abgefangen. Wie kann das sein? Ich verstehe einfach nicht warum der Client immer diese Packete (in Mengen) verschickt und warum noch etwas fragmented sein soll. Kann mir jemand erklären, was mir das Packet zu sagen hat und wie ich es abstelle? Oder habe ich was falsch gemacht? Ich blicke es einfach nicht. (Bin auch kein „IP-Vollprofi“.) Die Zieladresse 224.77.1.1 der Problempackete scheint eine Multicastadresse zu sein. Wie der Client auf die kommt ist mir auch ein Rätsel.

Es folgt zunächst die Ausgabe von Ethereal am Beispiel eines „Problempacketes“ und anschließend die Ausgabe für die funktionierende ping -f -l 1436 Anfrage.
Danke für die Hilfe.

No. Time Source Destination Protocol Info
1 0.000000 192.168.1.18 224.77.1.1 IP Fragmented IP protocol (proto=UDP 0x11, off=0) [Reassembled in #27]

Frame 1 (1474 bytes on wire, 1474 bytes captured)
Arrival Time: May 19, 2006 17:56:58.264290000
Time delta from previous packet: 0.000000000 seconds
Time since reference or first frame: 0.000000000 seconds
Frame Number: 1
Packet Length: 1474 bytes
Capture Length: 1474 bytes
Protocols in frame: eth:ip:data
Ethernet II, Src: CameoCom_62:4c:94 (00:40:f4:62:4c:94), Dst: 01:00:5e:4d:01:01 (01:00:5e:4d:01:01)
Destination: 01:00:5e:4d:01:01 (01:00:5e:4d:01:01)
Source: CameoCom_62:4c:94 (00:40:f4:62:4c:94)
Type: IP (0x0800)
Internet Protocol, Src: 192.168.1.18 (192.168.1.18), Dst: 224.77.1.1 (224.77.1.1)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00… = Differentiated Services Codepoint: Default (0x00)
… …0. = ECN-Capable Transport (ECT): 0
… …0 = ECN-CE: 0
Total Length: 1460
Identification: 0x2f72 (12146)
Flags: 0x02 (More Fragments)
0… = Reserved bit: Not set
.0… = Don’t fragment: Not set
…1. = More fragments: Set
Fragment offset: 0
Time to live: 1
Protocol: UDP (0x11)
Header checksum: 0xc1be [correct]
Good: True
Bad : False
Source: 192.168.1.18 (192.168.1.18)
Destination: 224.77.1.1 (224.77.1.1)
Reassembled IP in frame: 27

No. Time Source Destination Protocol Info
28 4.684902 192.168.1.18 62.153.159.92 ICMP Echo (ping) request

Frame 28 (1478 bytes on wire, 1478 bytes captured)
Arrival Time: May 19, 2006 17:57:02.949192000
Time delta from previous packet: 4.681844000 seconds
Time since reference or first frame: 4.684902000 seconds
Frame Number: 28
Packet Length: 1478 bytes
Capture Length: 1478 bytes
Protocols in frame: eth:ip:icmp:data
Ethernet II, Src: CameoCom_62:4c:94 (00:40:f4:62:4c:94), Dst: Zioncom_8f:af:3c (00:0e:e8:8f:af:3c)
Destination: Zioncom_8f:af:3c (00:0e:e8:8f:af:3c)
Source: CameoCom_62:4c:94 (00:40:f4:62:4c:94)
Type: IP (0x0800)
Internet Protocol, Src: 192.168.1.18 (192.168.1.18), Dst: 62.153.159.92 (62.153.159.92)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00… = Differentiated Services Codepoint: Default (0x00)
… …0. = ECN-Capable Transport (ECT): 0
… …0 = ECN-CE: 0
Total Length: 1464
Identification: 0x2f73 (12147)
Flags: 0x04 (Don’t Fragment)
0… = Reserved bit: Not set
.1… = Don’t fragment: Set
…0. = More fragments: Not set
Fragment offset: 0
Time to live: 128
Protocol: ICMP (0x01)
Header checksum: 0x2622 [correct]
Good: True
Bad : False
Source: 192.168.1.18 (192.168.1.18)
Destination: 62.153.159.92 (62.153.159.92)
Internet Control Message Protocol
Type: 8 (Echo (ping) request)
Code: 0
Checksum: 0xea05 [correct]
Identifier: 0x0200
Sequence number: 0x1700
Data (1436 bytes)

Hallo Carsten, dumme aber einfache moeglichkeit, schon mal den Rechner durchgescannt ?? Desweiteren empfehle ich dir diese Frage bei www.rootforum.de zu erstellen. Da hast du wesentlich mehr Netzwerk Experten als hier. Sorry wer-weiss-was.de Team to say that but its true.

[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]

Hallo,

Time to live: 1

Das kommt mir doch sehr merkwürdig vor. Diese Pakete überleben den nächsten Router nicht.

Gruß

Fritze

Hallo,

ich habe gemäß FAQ:428 MTU (1464) und TcpWindowSize/
GlobalMaxTcpWindowSize (363120) bestimmt und gesetzt.
Tcp1323Opts = 1 und SackOpts = 1 gesetzt.

Das ist Windows-Kram und ich habe keine Anhung, was das Kauderelsch bedeutet.

Wo genau und für welche Interfaces hast Du das denn eingestellt?

Nun habe ich per Ethereal aber Packete „Fragmented IP
protocol“ abgefangen. Wie kann das sein?

Es wird halt fragmentiert :smile: Wo ist das Problem?

Ich verstehe einfach
nicht warum der Client immer diese Packete (in Mengen)
verschickt und warum noch etwas fragmented sein soll.

Vermutlich will das Programm mehr Daten senden als in einen Frame passen. Das kann ja mal sinnvoll sein. Was für ein Programm sendet denn diese Pakete?

Kann mir
jemand erklären, was mir das Packet zu sagen hat und wie ich
es abstelle?

Welches Problem konkret möchtest Du eigentlich lösen?

Es folgt zunächst die Ausgabe von Ethereal

Auf welchem Rechner läuft das? Wie siet überhaupt etwa das Netzwerk aus?

Time to live: 1

Darüber hat sich Fritze ja bereits gewundert …

Gruß,

Sebastian

Wo genau und für welche Interfaces hast Du das denn
eingestellt?

Für das LAN-Interface an Server und Client, sowie für das Internetinterface am Server.

Nun habe ich per Ethereal aber Packete „Fragmented IP
protocol“ abgefangen. Wie kann das sein?

Es wird halt fragmentiert :smile: Wo ist das Problem?

Es werden viele Packete verschickt, ohne mir einleuchtenden Grund. Diese Packete verursachen hoffentlich vermeidbare Netzwerklast.

Ich verstehe einfach
nicht warum der Client immer diese Packete (in Mengen)
verschickt und warum noch etwas fragmented sein soll.

Vermutlich will das Programm mehr Daten senden als in einen
Frame passen. Das kann ja mal sinnvoll sein. Was für ein
Programm sendet denn diese Pakete?

Keine sichere Erkenntnis dazu. Ich vermute Windows oder einen seiner Dienste als Verursacher (Windows-Auto-Update??), weil die Packete auch kommen, wenn ich kein Fenster offen habe. Werde morgen mal nachschauen (im Büro), ob ich dazu per netstat mehr Info gewinnen kann.

Kann mir
jemand erklären, was mir das Packet zu sagen hat und wie ich
es abstelle?

Welches Problem konkret möchtest Du eigentlich lösen?

  1. Optimale Packetgröße bis zum ISP einstellen für maximale IP-Performance und zur Verhinderung von Packetzerlegungsaktionen im Router. Der stürzt dann nämlich ab…
    … und der Hersteller findet das wenig besorgniserregend, weil man durch Einstellung die Fragmentierungsarbeit des Routers verhindern/verringern kann… :frowning:
  2. Den Verursacher bewegen weniger Netzlast zu produzieren.

Es folgt zunächst die Ausgabe von Ethereal

Auf welchem Rechner läuft das? Wie siet überhaupt etwa das
Netzwerk aus?

Ethereal läuft auf dem Server und greift die Packete an der Lan-Schnittstelle im promis. Mode ab. Dort hängt der Client über einen Switch dran (LAN-Testinstallation 100Mbit Ethernet). Eine zweite Netzkarte im Server geht über Router und DSL ins Internet.

Time to live: 1

Darüber hat sich Fritze ja bereits gewundert …

Das macht die Packete um so sinnloser. Daher meine Bemühungen sie loszuwerden.

Gruß

Carsten

Hallo Carsten, dumme aber einfache moeglichkeit, schon mal den
Rechner durchgescannt ??

Malware ist als Verursacher sehr unwahrscheinlich weil

  • Neuinstallation
  • Kompletter Virenscannerlauf mit aktueller Signatur ohne Befund
  • Microdoofs Tool gegen bösartige Software ohne Befund

Desweiteren empfehle ich dir diese
Frage bei www.rootforum.de zu erstellen.
Da hast du wesentlich
mehr Netzwerk Experten als hier.

Danke für den Hinweis. Bei Erfolglosigkeit werde ich mal ein anderes Forum dazu befragen.

Sorry wer-weiss-was.de Team
to say that but its true.

Warum denn in Englisch?

Wo genau und für welche Interfaces hast Du das denn
eingestellt?

Für das LAN-Interface an Server und Client,

Okay.

sowie für das
Internetinterface am Server.

Du meinst ppp0 (und nicht eth_x_?

Was für ein
Programm sendet denn diese Pakete?

Keine sichere Erkenntnis dazu. Ich vermute Windows oder einen
seiner Dienste als Verursacher (Windows-Auto-Update??), weil
die Packete auch kommen, wenn ich kein Fenster offen habe.
Werde morgen mal nachschauen (im Büro), ob ich dazu per
netstat mehr Info gewinnen kann.

Oder per Ethereal? Bei mir zeigt ethereal ziemlich viel an, oft kann man am Inhalt der Pakete erahnen, was da passiert. Wie soieht es eigentlich mit den verwendeten Ports aus? Die Adresse passt zwar nicht zu UPnP, aber ansonsten wäre das IMHO nicht so abwegig.

Gruß,

Sebastian

Erledigt
http://www.wer-weiss-was.de/cgi-bin/forum/showarchiv…

ergab brauchbare Hinweise nach dem Verursacher. „Problempacketphänomen“ ist damit geklärt. Danke für alle Hinweise und Ideen.

Hallo Carsten,

sorry habe es falsch gelesen gehabt. Deine MTU ist ja 1464 bytes gross. 28Bytes werden fuer den IP Header genutzt also 1464 - 28 == 1436. Da sollte zumindest die Antwort fuer die Paketgroesse sein. In english ist es fuer mich manchmal einfacher da ich wahrscheinlich momentan nicht so viel Deutsch wie du spreche.

[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]

In english ist es fuer mich manchmal
einfacher da ich wahrscheinlich momentan nicht so viel Deutsch
wie du spreche.

Sorry, ich habe nicht in die Visitenkarte geschaut. Asche auf mein Haupt.

Gruß
Carsten