Wer vermasselt diese TCP-Verbindung?

Ich bin verantwortlich für einige eingebettete Software, die mit einer proprietären TCP-Schnittstelle des Kunden arbeiten muss (auch eingebettet, aber unter einem bekannten und angesehenen RTOS), aber es kommt nicht durch den Drei-Wege-Handshake, obwohl die HTTP-Schnittstelle usw., alles funktioniert gut, und ich kann mit dem benutzerdefinierten Protokoll mit einem Programm auf meinem PC kommunizieren.Wer vermasselt diese TCP-Verbindung?

Betrachtet man die WireShark-Captures, initiiert seine Seite durch Senden eines SYN, ich sende ein SYN-ACK, und dann sendet er sofort eine RST, also sieht es so aus, als wäre das Problem an seinem Ende. Ist meine Analyse korrekt?

Hier ist ein typisches 3-Paket-Beispiel des Problems, mit den anonymisierten MAC-IDs (die tatsächlichen MAC-IDs sind gültig). Tut mir leid, dass ich das rohe Hex einfügen kann. Wenn jemand eine bessere Vorstellung davon hat, wie wir die WireShark-Capture einsetzen können, bin ich sicherlich zugänglich.

63 2009-06-29 13:07:49.685057 10.13.91.2 10.13.92.3 TCP 1024 > 49151 [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=0 TSV=194 TSER=0 

0000 f1 f1 f1 00 03 09 ab ab ab 60 10 89 08 00 45 00 
0010 00 3c 00 68 40 00 40 06 6f 35 0a 0d 5b 02 0a 0d 
0020 5c 03 04 00 bf ff 7d b3 81 44 00 00 00 00 a0 02 
0030 20 00 9c 2f 00 00 02 04 05 b4 01 03 03 00 01 01 
0040 08 0a 00 00 00 c2 00 00 00 00 

64 2009-06-29 13:07:49.685375 10.13.92.3 10.13.91.2 TCP 49151 > 1024 [SYN, ACK] Seq=0 Ack=1 Win=1460 Len=0 

0000 ab ab ab 60 10 89 f1 f1 f1 00 03 09 08 00 45 00 
0010 00 28 00 02 00 00 64 06 8b af 0a 0d 5c 03 0a 0d 
0020 5b 02 bf ff 04 00 d4 ff ff ff 7d b3 81 45 50 12 
0030 05 b4 47 07 00 00 00 00 00 00 00 00 

65 2009-06-29 13:07:49.685549 10.13.91.2 10.13.92.3 TCP 1024 > 49151 [RST] Seq=1 Win=0 Len=0 

0000 f1 f1 f1 00 03 09 ab ab ab 60 10 89 08 00 45 00 
0010 00 28 00 6a 00 00 40 06 af 47 0a 0d 5b 02 0a 0d 
0020 5c 03 04 00 bf ff 7d b3 81 45 00 00 00 00 50 04 
0030 00 00 21 c9 00 00 00 00 00 00 00 00

Quelle

2009-06-30 Sam Skuce

Sie konnten die Wireshark Capture-Datei auf einige Web-Server stellen für uns Download. –

Wenn Sie beide Standard-RTOS-Implementierungen verwenden, ist es unwahrscheinlich, dass der TCP-Stack ein Problem hat. Oder haben Sie gesagt, dass TCP lokal implementiert ist?

Wenn sein Client sendet ein SYN richtig, und Sie können mit einem SYN+ACK, antworten
es scheint, dass entweder Ihre SYN+ACK nicht gut
gebildet (aber ich kann nichts noch sehen), oder,
wie Sie vermuten, sein TCP-Stack hat die SYN+ACK nicht richtig akzeptiert.
Wenn dies jedoch Standardimplementierungen sind, ist das unwahrscheinlich.

Was können Sie noch tun?

Da es der TCP-Handshake Wir prüfen ist, können Sie ihn einfach an Ihrem Ende zu einer anderen Maschine machen verbinden, die
- Dies prüft seine Implementierung auf dem gewünscht Port abhört (sein gut, wenn der 3-Weg abgeschlossen ist).
Sie können Ihre TCP-Stack überprüfen mit einem TELNET an den Port von einem anderen lokalen Rechner verbinden
- Dies wird überprüfen Sie Ihre Implementierung (gut, wenn 3-Wege abgeschlossen).
Wenn diese beiden Dinge in Ordnung sind, müssen wir
- Zum Beispiel den Netzwerkpfad vermuten, könnte es sein, einige Firewall die Kommunikation nicht erlaubt und aktiv nach einer RST an Sie senden?

Quelle

2009-06-30 16:28:59 nik

Meine Seite ist ein "Bare Metal" -Gerät ohne RTOS, aber wir verwenden einen Open-Source-TCP-Stack, der schon eine Weile existiert, und wie ich schon sagte, es funktioniert mit anderen Maschinen und anderen Protokollen, nur nicht mit diesem Rechner mit diesem Protokoll. Ich habe gerade mit meinem Gerät mit Telnet verbunden, und es hat funktioniert. Es sollte nichts im Netzwerk sein, das mit uns schraubt - das einzige, was zwischen ihm und mir ist, ist ein Windows-PC mit zwei NICs, überbrückt, damit wir ihn benutzen können, um den Verkehr zu schnüffeln, was uns keine Probleme mit anderen Geräten gibt. Ich werde darüber nachdenken, eine PC-basierte Implementierung des Protokolls für ihn zu testen. –

Nun, wenn der TCP-3-Wege-Handshake für ihn nicht funktioniert, ist er weit von Protokolltests entfernt. Sie sollten nur einen TELNET-Server auf dem erwarteten Protokoll-Port auf einem PC für ihn ausführen. Oder nehmen Sie vielleicht ein TCP ECHO Server-Sample von einem beliebigen Ort und riggen Sie es am gewünschten Port am PC an. – nik

Schreiben einer Implementierung des Protokolls auf einem PC unter Verwendung von z. Die .NET TCP-Sockets-API ermöglicht es ihm, seine Verbindung zu testen und das Protokoll zu testen. Es ist schwieriger für ihn, unter die Haube seines Geräts zu kommen - er hat die Firmware für sein Gerät nicht entwickelt, er schreibt nur Anwendungen, die darauf laufen, in einer proprietären Sprache. Das bedeutet, dass ich an alles denken muss, was ich kann, um meine begrenzte Fähigkeit zu nutzen, die Variablen in diesem Puzzle zu ändern/zu eliminieren. –

Zunächst sind das keine gültigen MAC-Adressen; ein höherwertiges Byte & 0x1 bedeutet, es ist ein Multicast-MAC. Siehe http://en.wikipedia.org/wiki/MAC_address

Quelle

2009-06-30 15:57:47 user47559

Ich vermute, sskuce hat die MACs geschrubbt – nik

In einer eingebetteten Umgebung, ich denke, es ist möglich, dass er willkürlich gewählte "zufällige" MACs, die ihm Probleme verursachen. Zumindest ist das hier passiert und führte zu der Regel, dass das höherwertige Byte in erfundenen MACs 0 sein soll :) – user47559

Woops, ich habe vergessen zu erwähnen, dass ich die MACs geschrubbt habe. Beide Seiten haben ihre eigenen OUIs, also wollte ich nicht, dass sie identifizierbar sind. –

Wenn Sie nicht fancy Sachen auf Ihrer Seite wie benutzerdefinierte tcp-Stack oder rohe Sockets verwenden, würde ich die "proprietäre TCP-Schnittstelle" vermuten.

Hat das jemals mit diesem Client funktioniert? Funktioniert es mit anderen Clients?

Quelle

2009-06-30 16:05:17 Eric

Ich betreibe einen Webserver, der funktioniert, zumindest mit allen Browsern, mit denen ich es probiert habe, und einigen .NET-Programmen, die direkt mit Port 80 kommunizieren. –

Antwort

Verwandte Themen