Kommunikation über Ethernet-Schnittstelle

Böckle schrieb:
> Meine Frage: Ist es möglich mit dem Gerät per Ethernet-Schnittstelle zu
> kommunizieren? Wenn ja, wie?

steht doch alles in der doku


Dieser UDP-Port darf zur Kommunikation nicht durch eine Firewall 
geblockt werden.
Der Standard UDP-Port im Auslieferungszustand ist im DIGIFORCE sowie im 
DigiControl 9310 der
Port 8364.


Wie das Protokoll aussieht, konnte ich auf die schnelle nicht finden.

War Hyperterminal nicht ein Programm für die serielle Schnittstelle ? 
Bei irgendwas über Netzwerk hätte ich jetzt ein Programm wie Putty 
erwartet.

Oh D. schrieb:
> Putty ist eher fuer FTP.

ganz bestimmt nicht.

Erstmal vielen Dank für die vielen und schnellen Antworten!
Ich habe es jetzt mit einem anderen (offenen) Port probiert, wie es 
Peter vorgeschlagen hat, aber leider ohne Erfolg.

Alex T. schrieb:
> Als aller erste würde ich ein Oszilloskop an Bus anschließen und die
> Signale bzw. Protokoll überprüfen:
> -Wie sehen Signale in beide Richtungen beim Ping aus
> -Was wird bei der Übertragung über Hyperterminal gesendet.

Ich werde es jetzt mal über Bus probieren. Den RS232 wollte ich nicht 
benutzen...

Böckle schrieb:
> Port probiert, wie es
> Peter vorgeschlagen hat, aber leider ohne Erfolg.

wie hast du es probiert? auch beachtet das es UDP ist?

Alex T. schrieb:
> Es ist alles Bus: sowohl RS232 als auch Ethernet ;)
> Und bei beiden würde ich zuerst mit dem Oszilloskop

Ethernet mit dem Scope? Respekt, für Gigabit musst du ja ein feines Teil 
haben

MfG Klaus

Peter II schrieb:
> wie hast du es probiert? auch beachtet das es UDP ist?

Bei meinem PC blockiert die Firewall keine Ports, von daher hätte es 
auch mit dem Standardport funktionieren müssen.

Alex T. schrieb:
> Es ist alles Bus: sowohl RS232 als auch Ethernet ;)
> Und bei beiden würde ich zuerst mit dem Oszilloskop oder Busmonitor
> arbeiten. So ist es einfacher.

Ok, bin noch nicht so erfahren mit Hardware ^^' bin im 1. Semester 
(Technische Informatik) und habe bis jetzt nur programmiert.

Mein Ausbilder hat mir eben noch Wireshark ans Herz gelegt.
Er fande die Idee mit dem Oszilloskop gut, aber bisschen viel und ich 
soll schauen, ob es eine einfachere Lösung gibt.

Alex T. schrieb:
> Ok, für Ethernet ein Busmonitor verwenden.

Das Debuggen von TCP/IP, insbesondere wenn man die Gegenstelle schon mal 
pingen kann, spielt sich auf einer ganz anderen Ebene ab. Da braucht man 
sowas wie Wireshark und TCP Knowhow, aber weniger einen Busmonitor. 
RS232 und Ethernet mit TCP/IP in einen Topf zu werfen ist nicht 
zielfördernd.

MfG Klaus

Mit Putty, Hyperterm o.ä. kannst Du nur über TCP kommunizieren.
Handelt es sich um einen UDP-Port, brauchst Du schon einen passenden 
Client, der genau für diese Hardware gedacht ist.

Brummbär schrieb:
> Mit Putty, Hyperterm o.ä. kannst Du nur über TCP kommunizieren.
> Handelt es sich um einen UDP-Port, brauchst Du schon einen passenden
> Client, der genau für diese Hardware gedacht ist.

Ich hatte mir erhofft, dass mich da die besagt Software DigiControl von 
burster weiterbringt.
Kennst du sonst noch andere Software für meinen Fall?

Klaus schrieb:
> Das Debuggen von TCP/IP, insbesondere wenn man die Gegenstelle schon mal
> pingen kann, spielt sich auf einer ganz anderen Ebene ab. Da braucht man
> sowas wie Wireshark und TCP Knowhow, aber weniger einen Busmonitor.
> RS232 und Ethernet mit TCP/IP in einen Topf zu werfen ist nicht
> zielfördernd.

Danke für den Tipp Klaus :) versuche mich gerade in die Funktionsweise 
rein zu fitzen...

Ich habe jetzt bei dem Filter in Wireshark die IP des Gerätes eingegeben 
mit
Match destination: ip.dst == x.x.x.x
leider kam dabei aber nichts mehr raus... bin gerade hilflos

Alex T. schrieb:
> Ich habe gedacht, dass Wireshark ein Bus-Monitor-Programm ist.
> Vielleicht irre ich mich.

Nein, du irrst dich nicht. Aber so gings los

Klaus schrieb:
> Alex T. schrieb:
>> Es ist alles Bus: sowohl RS232 als auch Ethernet ;)
>> Und bei beiden würde ich zuerst mit dem Oszilloskop
>
> Ethernet mit dem Scope? Respekt, für Gigabit musst du ja ein feines Teil
> haben

Und ein Bus-Monitor-Programm, das keine extra Hardware braucht sondern 
auf dem eigen Rechner mitläuft, mit einem Scope in einen Topf zu werfen 
ist einfach daneben.

MfG Klaus

Alex T. schrieb:
> Ne blöde Frage: ist Wireshark für UDP geeignet (weiß ich wirklich nicht)
>
> Vielleicht lohnt es sich selbst eine einfachen UDP-Client zu schreiben?
> Z.B. in C#, C++ oder LabVIEW??

Bei deiner Frage kann ich dir leider auch nicht helfen, werde mir jetzt 
einen eigenen Client bauen.

Alex T. schrieb:
> Ja stimmt... jemand muss was senden, also ohne eigenen UDP-Client wird
> es gar nichts gehen.

Mal mit netcat und Freunden probieren. Tools für TCP/IP gibts ja zu 
Hauf, ist ja die Basis für alle heutigen Netzwerke.

MfG Klaus

Alex T. schrieb:
> Meine Fehler: 1) ich habe an die hohe Frequenzen von Ethernet nicht
> gedacht
> 2) Nach dem Wort "Busmonitor" musste ich das Wort "Programm" schreiben.
>
> Gebe ich zu.

[Klugscheißermodus]

Die Frequenzen sind nicht das wirkliche Problem, eher die Kodierung der 
Signale.

Für RS232 ist ein Scope (oder LA) mit einem Protokolldecoder schon die 
richtige Wahl

[/Klugscheißermodus]

MfG Klaus

Dergute W. schrieb:
> Alex T. schrieb:
>> Ne blöde Frage: ist Wireshark für UDP geeignet (weiß ich wirklich nicht)
>
> Ja. Aber wenn das Geraet von sich aus nichts sendet, kann wireshark auch
> nix mitsniffen.

Ich konnte mit Wireshark einige Pakete abfangen von dem Gerät, indem ich 
über Digicontrol den Port des Gerätes zur Laufzeit geändert habe.

1.) Der UDP-Client den ich habe funktioniert, aber leider wird nichts 
vom Digiforce empfangen da...
2.) ... die Nachrichten vom Digiforce verschlüsselt sind.

Hat zufällig jemand Erfahrung mit verschlüsselten Paketen? In der Doku 
steht, dass man dies über die Konfig ändern kann. Geht es auch ohne?

Böckle schrieb:
> Ich konnte mit Wireshark einige Pakete abfangen von dem Gerät, indem ich
> über Digicontrol den Port des Gerätes zur Laufzeit geändert habe.

dann zeige sie doch mal.

> Hat zufällig jemand Erfahrung mit verschlüsselten Paketen?
ich glaube nicht das sie verschlüsselt sind, vermutlich sieht du nur 
nicht den unterschied zwischen eine Binären Übertragung und einer 
wirklichen Verschlüsselung.

Peter II schrieb:
> dann zeige sie doch mal.

0020                                 02 30 2c 32 2c 30   .< ..... 
...0,2,0
0030  2c 30 2c 39 33 31 30 2c  56 32 30 31 30 30 32 2c   ,0,9310, 
V201002,
0040  33 36 37 39 39 37 20 20  20 20 2c 32 32 2e 30 36   367997 
,22.06
0050  2e 32 30 31 31 2c 30 30  30 30 30 30 30 30 30 31   .2011,00 
00000001
0060  2c 30 2c 33 2c 31 32 2c  30 2c 30 2c 30 2c 30 2c   ,0,3,12, 
0,0,0,0,
0070  66 66 66 66 30 30 30 30  2c 61 30 31 63 38 64 63   ffff0000 
,a01c8dc
0080  2c 56 32 30 31 30 30 30  2c 30 2c 30 30 2d 34 30   ,V201000 
,0,00-40
0090  2d 39 64 2d 33 66 2d 61  65 2d 32 66 2c 30 2c 30   -9d-3f-a 
e-2f,0,0
00a0  2c 30 2c 30 2c 30 2c 30  03 f5                     ,0,0,0,0 ..

Das sind die Daten aus dem 2. Paket von dem Gerät. Hoffe du/ihr 
kannst/könnt damit mehr anfangen als ich.

Peter II schrieb:
> ich glaube nicht das sie verschlüsselt sind, vermutlich sieht du nur
> nicht den unterschied zwischen eine Binären Übertragung und einer
> wirklichen Verschlüsselung.

Ich erkenne da schon einen Unterschied, sieht mehr nach Hex aus. Aber 
warum zeigt der UDP-Client keine Kommunikation mit dem Gerät an, 
funktioniert aber z.B. an meinem PC?

Böckle schrieb:
> Das sind die Daten aus dem 2. Paket von dem Gerät. Hoffe du/ihr
> kannst/könnt damit mehr anfangen als ich.

nicht wirklich weil ich das gerät nicht kennen, und keine Ahnung was es 
macht.

Aber die Übertragung sieht doch überhaupt nicht verschlüsselt aus, ist 
doch alles Klartext.

du musst nur den Rechten Rand beachten, die Hexzahlen in der Mitte sind 
nur eine andere Darstellung davon.

Peter II schrieb:
> Aber die Übertragung sieht doch überhaupt nicht verschlüsselt aus, ist
> doch alles Klartext.
>
> du musst nur den Rechten Rand beachten, die Hexzahlen in der Mitte sind
> nur eine andere Darstellung davon.

Danke, dass hilft mir schon einmal weiter. Ich verstehe aber nicht ganz, 
was sie bedeuten sollen. In der Doku stehen unter dem Punkt "Aufbau und 
Fragmentierung von UDP-Telegrammen" nur:
Format mit Daten (Wenn Antwort auf Befehl mit Frageform)
<STX>Schlüssel,Kennung,Status,Nummer,Daten<Endezeichen>Blockcheck
Format ohne Daten (Wenn Fehler oder auf Befehl ohne Frageform)
<STX>Schlüssel,Kennung,Status,Nummer,<Endezeichen>Blockcheck

Zudem ist der Status laut Doku nur so gekennzeichnet:
Status: 0: alles o.k.
1: NAK
2: nicht benutzt
3: Timeout auf serieller Schnittstelle
4: STX nicht erkannt
5: Kennung nicht erkannt
6: ETX nicht erkannt
7: Checksummenfehler
8: Keine Antwort
9: unknown error
A: Messung läuft
B: Unerlaubte Host-IP-Adresse (statisch)
C: Unverschlüsselte Nachricht empfangen, obwohl nicht erlaubt
D: Ungültige Schlüssel Kennung
E: Gerät wurde von einem anderen Master gesperrt (MAST! Befehl)

Im Protokoll stehen aber andere Buchstaben und Symbole.

Böckle schrieb:
> Im Protokoll stehen aber andere Buchstaben und Symbole.

welche meinst du, zeige es ein genaues Beispiel.

Peter II schrieb:
> welche meinst du, zeige es ein genaues Beispiel.

Zum Beispiel an dem Paket welches ich vorns geschickt habe: die ganzen 
Punkte bzw. Kommas, Bindestriche/Minuszeichen, die Buchstaben V und f

Böckle schrieb:
> Zum Beispiel an dem Paket welches ich vorns geschickt habe: die ganzen
> Punkte bzw. Kommas, Bindestriche/Minuszeichen, die Buchstaben V und f

dafür müsste man wissen, wo du nutzdaten vom UDP anfangen, es könnte 
sein das das noch reste vom UDP und IP Header sind.

Eventuell mal screenshot vom Wireshark zeigen


Du hast du das Protokoll:

<STX>Schlüssel,Kennung,Status,Nummer,<Endezeichen>Blockcheck

Was ist der Blockcheck?

.0,2,0,0,9310, V201002,367997    ,22.06.2011,00 00000001,0,3,12, 
0,0,0,0,ffff0000 ,a01c8dc,v201000 ,0,00-40-9d-3f-a e-2f,0,0,0,0,0,0 ..

9310 ist das Gerät
22.06.2011 ist das Herstellungsdatum
00000001 ist der Name des Gerät
v201002 ist die Version und 367997 ist die Seriennummer

Peter II schrieb:
> Was ist der Blockcheck?

Blockcheck (nur bei serieller PC-Schnittstelle)
Zur Vermeidung von Übertragungsfehlern aktivieren Sie Blockcheck!
Diese Einstellung ist nur bei Datenformaten mit 8 Datenbits möglich.

Ist aber standardmäßig ausgeschalten.

.0,2,0,0,9310, V201002,367997    ,22.06.2011,00 00000001,0,3,12,
0,0,0,0,ffff0000 ,a01c8dc,v201000 ,0,00-40-9d-3f-a e-2f,0,0,0,0,0,0 ..

Also gehe wir davon aus, dass:
   ->.0,2,0,0 den Status und den angibt
   ->9310, V201002,367997    ,22.06.2011,00 00000001 die Kennung ist

dann würde noch das übrig bleiben:

0,3,12,0,0,0,0,ffff0000 ,a01c8dc,v201000 ,0,00-40-9d-3f-a 
e-2f,0,0,0,0,0,0

0 steht für alles o.k. und 3 für Timeout auf serieller Schnittstelle 
(stimmt theoretisch auch, Anbindung ist nur über Ethernet). Wofür steht 
dann aber die 12?

Böckle schrieb:
> Also gehe wir davon aus, dass:
>    ->.0,2,0,0 den Status und den angibt

Fehler von meiner Seite. Meinte STX und Schlüssel.

Alex T. schrieb:
> Es ist doch alles gut: das Gerät sendet ein Info-String, wie es auch
> sein soll.
>
> Also, die Kommunikation wurde aufgebaut.

Ja ich bin auch schon glücklich, dass mir das Gerät überhaupt etwas 
mitteilt.
Ich kann aber über hyperterminal trotzdem keine Verbindung finden. Ich 
möchte ja die Befehle finden, auf die das Gerät reagiert, z.B. einen 
Test starten oder ein Ergebnis bzw. den Status holen.

Soll ich das Gerät direkt per Ethernet an meinen PC anschließen oder 
gibt das keinen Unterschied im Vergleich zum Netzwerk?

Alex T. schrieb:
> Nochmal: ich habe Zweifel, dass es über Hyperterminal etwas gehen wird.
> Ich vermute, dass der Hyperterminal kein UDP-Protokol unterstützt. Und
> ich denke, dass UDP ein anderen Header hat als TCP, deswegen werden
> wahrscheinlich deine UDP-Packete vom Gerät einfach nicht erkannt.

Sorry, du hast natürlich recht. Hterm arbeitet wenn dann mit TCP/IP...

Alex T. schrieb:
> Danach kannst Du dien UDP-Client an das Gerät entsprechend anpassen.

Den Client hatte ich mir gestern noch gebaut (in C#). Ich schau mal, ob 
ich meinen Fehler finde oder ob ich noch was anpassen muss. Die 
Kommunikation zwischen Client und Server am PC funktioniert ja schon 
mal.

Danke euch für die Mühe :-)

Dirk B. schrieb:
> Echt. Wusste ich gar nicht.
>
> Ist dir der Unterschied zwischen TCP und UDP bekannt?
> Nicht alle Programme, die Unterstützung für TCP/IP bieten, haben auch
> UDP.

Ja hab ich doch gesagt, dass Hterm UDP nicht anbietet, aber TCP/IP 
schon.

Ist jetzt auch egal, ich kann über meinen UDP-Client als Sender und mit 
Wireshark als Listener mit dem Digiforce kommunizieren. Problem ist also 
gelöst.
Danke nochmal an alle :)