TCP: Verbindung aufbauen

Martin Gast 29.08.2009 18:44 #1393332

Lesenswert?

•

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

Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Beitrag melden

Martin Gast 29.08.2009 18:45 #1393334

Lesenswert?

•

▲
▼

Falsches Forum, bitte verschieben!!

Antwort Zitieren Bearbeiten Löschen Beitrag melden

(prx) A. K. (prx) 29.08.2009 19:15 #1393374

Lesenswert?

•

▲
▼

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.

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Simon K. (simon) 29.08.2009 19:51 #1393405

Lesenswert?

•

▲
▼

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

Antwort Zitieren Bearbeiten Löschen Beitrag melden

(prx) A. K. (prx) 29.08.2009 20:01 #1393415

Lesenswert?

•

▲
▼

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.

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Martin Gast 29.08.2009 20:57 #1393482

Lesenswert?

•

▲
▼

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

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Simon K. (simon) 29.08.2009 22:58 #1393602

Lesenswert?

•

▲
▼

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

Antwort Zitieren Bearbeiten Löschen Beitrag melden

(prx) A. K. (prx) 29.08.2009 23:28 #1393620

Lesenswert?

•

▲
▼

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.

Antwort Zitieren Bearbeiten Löschen Beitrag melden

TCP: Verbindung aufbauen

Antwort schreiben