TCP: Verbindung aufbauen

[Martin (Gast)]

Hallo an alle,

ich programmiere gerade eine TCP/IP Stack und versuche eine TCP 
Verbindung aufzubauen. Meine Hardware spielt dabei den Server. Als 
Testanwendung nutze ich Telnet.

Vom Client aus starte ich Telnet, das ein SYN-Paket an den Server 
sendet. Mein Server antwortet mit SYN+ACK. Doch der Client erkennt es 
nicht und sendet nach einem Timeout erneut ein SYN-Paket mit der selben 
Seq-Nummer wie beim ersten Versuch, anstatt mit ein ACK zu senden.

Folgenden Mitschnitt habe ich mit Wireshark gemacht:

No.     Time        Source                Destination           Protocol Info
      1 0.000000    192.168.1.139         192.168.1.222         TCP      daishi > telnet [SYN] Seq=0 Win=16384 Len=0 MSS=1460

Frame 1 (62 bytes on wire, 62 bytes captured)
Ethernet II, Src: GemtekTe_07:06:81 (00:1a:73:07:06:81), Dst: 34:12:78:56:34:12 (34:12:78:56:34:12)
    Destination: 34:12:78:56:34:12 (34:12:78:56:34:12)
    Source: GemtekTe_07:06:81 (00:1a:73:07:06:81)
    Type: IP (0x0800)
Internet Protocol, Src: 192.168.1.139 (192.168.1.139), Dst: 192.168.1.222 (192.168.1.222)
Transmission Control Protocol, Src Port: daishi (2870), Dst Port: telnet (23), Seq: 0, Len: 0
    Source port: daishi (2870)
    Destination port: telnet (23)
    [Stream index: 0]
    Sequence number: 0    (relative sequence number)
    Header length: 28 bytes
    Flags: 0x02 (SYN)
    Window size: 16384
    Checksum: 0x1cec [validation disabled]
    Options: (8 bytes)

No.     Time        Source                Destination           Protocol Info
      2 0.001834    192.168.1.222         192.168.1.139         TCP      telnet > daishi [SYN, ACK] Seq=0 Ack=1 Win=1446 Len=0 MSS=1024

Frame 2 (60 bytes on wire, 60 bytes captured)
Ethernet II, Src: 34:12:78:56:34:12 (34:12:78:56:34:12), Dst: GemtekTe_07:06:81 (00:1a:73:07:06:81)
    Destination: GemtekTe_07:06:81 (00:1a:73:07:06:81)
    Source: 34:12:78:56:34:12 (34:12:78:56:34:12)
    Type: IP (0x0800)
    Trailer: 0000
Internet Protocol, Src: 192.168.1.222 (192.168.1.222), Dst: 192.168.1.139 (192.168.1.139)
Transmission Control Protocol, Src Port: telnet (23), Dst Port: daishi (2870), Seq: 0, Ack: 1, Len: 0
    Source port: telnet (23)
    Destination port: daishi (2870)
    [Stream index: 0]
    Sequence number: 0    (relative sequence number)
    Acknowledgement number: 1    (relative ack number)
    Header length: 24 bytes
    Flags: 0x12 (SYN, ACK)
    Window size: 1446
    Checksum: 0x65f8 [validation disabled]
    Options: (4 bytes)
    [SEQ/ACK analysis]

No.     Time        Source                Destination           Protocol Info
      3 2.999384    192.168.1.139         192.168.1.222         TCP      daishi > telnet [SYN] Seq=0 Win=16384 Len=0 MSS=1460

Frame 3 (62 bytes on wire, 62 bytes captured)
Ethernet II, Src: GemtekTe_07:06:81 (00:1a:73:07:06:81), Dst: 34:12:78:56:34:12 (34:12:78:56:34:12)
    Destination: 34:12:78:56:34:12 (34:12:78:56:34:12)
    Source: GemtekTe_07:06:81 (00:1a:73:07:06:81)
    Type: IP (0x0800)
Internet Protocol, Src: 192.168.1.139 (192.168.1.139), Dst: 192.168.1.222 (192.168.1.222)
Transmission Control Protocol, Src Port: daishi (2870), Dst Port: telnet (23), Seq: 0, Len: 0
    Source port: daishi (2870)
    Destination port: telnet (23)
    [Stream index: 0]
    Sequence number: 0    (relative sequence number)
    Header length: 28 bytes
    Flags: 0x02 (SYN)
    Window size: 16384
    Checksum: 0x1cec [validation disabled]
    Options: (8 bytes)

Hat jemand eine Idee, warum der Client hier nicht mit einem ACK 
antwortet?
Ich sehe leider keinen Fehler mehr :(

Danke im Voraus
mfg Martin

[Martin (Gast)]

Falsches Forum, bitte verschieben!!

[(prx) A. K. (prx)]

Wenn man die checksum validation ausschalten kann, dann kann man sie 
wahrscheinlich auch irgendwo einschalten. Und wenn das bedeutet, eine 
heute oft von der Netzwerkkarte selbst implementierte checksum dort 
abzuschalten.

Normalerweise zeigt der Wireshark sowohl farblich als auch im Detail an, 
wenn irgendwo der Wurm drin ist.

[Simon K. (simon)]

Das kann auch an deinem Stack liegen, aber wer soll die Frage so schon 
beantworten.

[(prx) A. K. (prx)]

Sein Stack ist doch der Server und der Wireshark sitzt folglich auf 
dem Client. Wenn sein Stack also Mist baut, dann muss dieser Mist in den 
protokollierten Daten drinstehen.

[Martin (Gast)]

Hallo,

Der Tipp mit der Checksum Validation war es. Keine Ahnung warum 
Wireshark es ausgeschalten hat defaultmäßig. Dadurch wurde die falsche 
Checksumme als richtige dargestellt.

Beim berechnen der Checksumme hatte ich die Länge des TCP Headers falsch 
gehabt.

Danke!!

lg Martin

[Simon K. (simon)]

Achso, das habe ich nicht richtig gesehen. Aber letztendlich hatte ich 
doch recht. Aber was soll es auch anderes gewesen sein :D

[(prx) A. K. (prx)]

Martin schrieb:

> Keine Ahnung warum Wireshark es ausgeschalten hat defaultmäßig.

Chips für Gigabit-Ethernet berechnen die Checksum oft selbst, was dann 
zur Folge hat, dass der sie davor abfangende Wireshark die ausgehenden 
Frames mit Checksum-Fehler protokolliert.