mikrocontroller.net

Forum: Markt TCP: Verbindung aufbauen


Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falsches Forum, bitte verschieben!!

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Simon K. (simon) Benutzerseite
Datum:

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

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Simon K. (simon) Benutzerseite
Datum:

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

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht 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.

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail, Yahoo oder Facebook? Keine Anmeldung erforderlich!
Mit Google-Account einloggen | Mit Facebook-Account einloggen
Noch kein Account? Hier anmelden.