[Ixam97]

Hallo allesamt,

heute möchte ich euch gerne mal ein kleines Nebenprojekt vorstellen, dass ich diesen Nachmittag mal eben zusammen geschustert habe (in Vorbereitung auf meine "Einführung in das Programmieren"-Klausur ). Wie der Titel schon sagt handelt es sich um einen bequemen CAN-Monitor für Windows (ein dickes Sorry an die UNIX-Nutzer unter uns, aber damit kenne ich mich leider nicht so sehr aus ops:), der die UDP-Pakete aus dem Netzwerk fischt und etwas aufbereitet darstellt. Aber seht selbst:



Natürlich wird dafür ein CAN zu UDP Interface benötigt. Das Programm hört einfach den entsprechenden Port ab und stellt das ganze dann für den Menschen leserlich dar. Zusätzlich werden die CAN-Frames in einer Log-Datei abgelegt, die Erklärungen dazu jedoch (noch) nicht.
Das ganze ist noch im Anfangsstadium (Arbeit von einem Nachmittag ) und nur einige wenige Befehle sind in so ausführlicher Erläuterung einprogrammiert wie auf dem Screenshot. Aber das kommt alles noch mit der Zeit.

Falls ihr den Monitor mal selber ausprobieren wollt, hier könnt ihr es euch herunterladen: CAN-UDP-Monitor. Um einen Trace in die Zwischenablage zu kopieren müsst ihr oben auf den Fensterrahmen einen Rechtsklick machen und [Bearbeiten] > [Markieren] auswählen. Dann könnt ihr mit der linken Maustaste den gewünschten Text markieren und mit einem Rechtsklick wird das Markierte in die Zwischenablage kopiert.

Falls ihr noch irgendwelche Ideen, Vorschläge oder Wünsche habt bin ich wie immer für alles offen

[st-oldie]

Hi Maxi,

Zitat von Ixam97

---

heute möchte ich euch gerne mal ein kleines Nebenprojekt vorstellen, dass ich diesen Nachmittag mal eben zusammen geschustert habe (in Vorbereitung auf meine "Einführung in das Programmieren"-Klausur ). Wie der Titel schon sagt handelt es sich um einen bequemen CAN-Monitor für Windows der die UDP-Pakete aus dem Netzwerk fischt und etwas aufbereitet darstellt.

---

Schön. Solche Traces für den CAN Bus und für die Kommunikation innerhalb meiner Software hab ich auch bei mir integriert. Das ist für Fehlersuche oder Verfolgen des Ablaus sehr praktisch.

Zitat von Ixam97

---

ein dickes Sorry an die UNIX-Nutzer unter uns, aber damit kenne ich mich leider nicht so sehr aus

---

Das wäre kein Problem. Mit dem bei mir vorhandenen Code kann ich bei Bedarf recht schnell ein ähnliches Programm für Linux erstellen. Alle Teilprobleme sind ja in meinem Softwarepaket schon vorhanden. Als wenn Interesse besteht, bitte Bescheid geben. Dann bau ich auch einen Trace für Ethernet zusammen.

Zitat von Ixam97

---

Natürlich wird dafür ein CAN zu UDP Interface benötigt. Ich verwende dafür einen BananaPi mit Gerds Software, aber das sollte auch genauso gut mit einer CS2 funktionieren.

---

Das ganze sollte auch mit meiner Software laufen. Es wird ja nur der Netzwerk Traffic getract.

Zitat von Ixam97

---

Zu beachten beim Betrieb mit der CS2.exe: Ein gleichzeitiger Betrieb von beidem ist nur möglich, wenn unterschiedliche Ports verwendet werden. Ich habe das so gelöst, dass ich auf dem BananaPi einfach ms2wifi mit dem voreingestellten Port 7655 benutze und diesen dann für den Monitor verwende.

---

Hast du mal getestet (mit einer CS2, nicht mt Gerds Software), ob du bei einer TCP Verbindung alle Ethernet Frames der anderen Ethernet Clients bekommst? Dann würde es reichen, eine TCP Verbindung zu öffnen und es könnten CS2.exe und der Trace parallel laufen.

Tschüß
Michael

[bertr2d2]

Hallo,

Zitat von Ixam97

---

heute möchte ich euch gerne mal ein kleines Nebenprojekt vorstellen, dass ich diesen Nachmittag mal eben zusammen geschustert habe (in Vorbereitung auf meine "Einführung in das Programmieren"-Klausur ). Wie der Titel schon sagt handelt es sich um einen bequemen CAN-Monitor für Windows der die UDP-Pakete aus dem Netzwerk fischt und etwas aufbereitet darstellt.

---

Respekt, was Du wieder in der kurzen Zeit gezaubert hast

Zitat von st-oldie

---

Zitat von Ixam97

---

Zu beachten beim Betrieb mit der CS2.exe: Ein gleichzeitiger Betrieb von beidem ist nur möglich, wenn unterschiedliche Ports verwendet werden. Ich habe das so gelöst, dass ich auf dem BananaPi einfach ms2wifi mit dem voreingestellten Port 7655 benutze und diesen dann für den Monitor verwende.

---

Hast du mal getestet (mit einer CS2, nicht mit Gerds Software), ob du bei einer TCP Verbindung alle Ethernet Frames der anderen Ethernet Clients bekommst? Dann würde es reichen, eine TCP Verbindung zu öffnen und es könnten CS2.exe und der Trace parallel laufen.

---

IMHO ist die Idee von Michael wirklich gut: Über TCP sollten nahezu alle Frames sichtbar sein.
Aber nicht nur die CS2 beherrscht TCP - can2lan hat seit ca. 1 1/2 Jahren folgende Kommunikations-Matrix (TCP Port ist 15731 - TCP-Port 15732 ist nicht eingezeichnet):


Die Kommunikationsstruktur sollte damit der realen CS2 entsprechen.

Zitat von st-oldie

---

Zitat

---

ein dickes Sorry an die UNIX-Nutzer unter uns, aber damit kenne ich mich leider nicht so sehr aus

---

Das wäre kein Problem. Mit dem bei mir vorhandenen Code kann ich bei Bedarf recht schnell ein ähnliches Programm für Linux erstellen. Alle Teilprobleme sind ja in meinem Softwarepaket schon vorhanden. Als wenn Interesse besteht, bitte Bescheid geben. Dann bau ich auch einen Trace für Ethernet zusammen.

---

Noch cooler als einen Me-Too Unix-Client fände ich einen Tshark/Wireshark Dissector. Damit könnte man alle Betriebssysteme abdecken und alles bequem über die GUI anschauen bzw. mit tshark auf der Console. BTW: Tshark/Wireshark beherrschen natürlich auch SocketCAN


Gruß

Gerd

[st-oldie]

Hallo,

Zitat von bertr2d2

---

Zitat von st-oldie

---

Das wäre kein Problem. Mit dem bei mir vorhandenen Code kann ich bei Bedarf recht schnell ein ähnliches Programm für Linux erstellen...

---

Noch cooler als einen Me-Too Unix-Client fände ich einen Tshark/Wireshark Dissector. Damit könnte man alle Betriebssysteme abdecken und alles bequem über die GUI anschauen bzw. mit tshark auf der Console.

---

Ok, war auch nur ein Angebot, weil ich das sehr schnell realisieren könnte.

Aber die Idee mit dem Wireshark Dissector ist natürlich richtig cool. Da gerate ich tatsächlich in Versuchung, mir das mal anzuschauen.

Tschüß
Michael

[bertr2d2]

Hallo Michael,

Zitat von st-oldie

---

Zitat von bertr2d2

---

Zitat von st-oldie

---

Das wäre kein Problem. Mit dem bei mir vorhandenen Code kann ich bei Bedarf recht schnell ein ähnliches Programm für Linux erstellen...

---

Noch cooler als einen Me-Too Unix-Client fände ich einen Tshark/Wireshark Dissector. Damit könnte man alle Betriebssysteme abdecken und alles bequem über die GUI anschauen bzw. mit tshark auf der Console.

---

Ok, war auch nur ein Angebot, weil ich das sehr schnell realisieren könnte.

---

Ich will da nicht den Stecker ziehen, aber ...

Zitat

---

Aber die Idee mit dem Wireshark Dissector ist natürlich richtig cool. Da gerate ich tatsächlich in Versuchung, mir das mal anzuschauen.

---

das halte ich für besser (da MultiOS Unterstützung) und mind. 10x mal cooler Zumal das auch in die offizielle Wireshark-Version einfließen kann, wenn Du willst. Ich denke, Du hast ja schon alles mehr oder minder zusammen und die Umsetzung sollte für einen Profi wie Dich kein Problem darstellen

Ich sehe es schon bildlich vor mir: Wireshark 2.0.5 mit Märklin CAN Unterstützung

Gruß

Gerd

[st-oldie]

Hallo Gerd,

Zitat von bertr2d2

---

das halte ich für besser (da MultiOS Unterstützung) und mind. 10x mal cooler Zumal das auch in die offizielle Wireshark-Version einfließen kann, wenn Du willst. Ich denke, Du hast ja schon alles mehr oder minder zusammen und die Umsetzung sollte für einen Profi wie Dich kein Problem darstellen

---

Mehr oder weniger zusammen stimmt, deshalb kam ja mein Angebot, das bei Bedarf auf Linux umzusetzen. Eine Umsetzung auf ein Wireshark Plugin halte ich jetzt auch nicht für so schwer.

Ich hab jetzt noch nie ein Plugin für Wireshark geschrieben. Wenn ich das richtig sehe, kann man das in C machen. Aber dann muß man wieder für die verschiedenene OSe compilieren. Das wäre dann wohl die richtige Wahl, wenn es in die offizielle Wireshak Version einfließen soll. Man kann das wohl auch in Lua programmieren, was dann die bessere Wahl wäre, wenn man das Plugin selbst verteilt.

Ich schau mir das mal genauer an.

Tschüß
Michael

[bertr2d2]

Hallo Michael,

Zitat von st-oldie

---

Ich hab jetzt noch nie ein Plugin für Wireshark geschrieben. Wenn ich das richtig sehe, kann man das in C machen. Aber dann muß man wieder für die verschiedenene OSe compilieren. Das wäre dann wohl die richtige Wahl, wenn es in die offizielle Wireshak Version einfließen soll. Man kann das wohl auch in Lua programmieren, was dann die bessere Wahl wäre, wenn man das Plugin selbst verteilt.

Ich schau mir das mal genauer an.

---

ich geb es zu ops: - ich konnte die Finger nicht davon lassen: Lua Skript. Das tirvial.lua ist ein Pfundstück aus dem Internet, das ich als Vorlage genommen habe.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
 

# 192.168.0.182  BPi + can2lan
# 192.168.0.143  CS2.exe
 
tshark -X lua_script:maerklin.lua -r ../maerklin.pcap | grep -i Maerklin
  0.000000 192.168.0.143 -> 255.255.255.255 UDP Maerklin CAN (Software Version, Ping 0x31)
  3.213104 192.168.0.143 -> 192.168.0.182 TCP Maerklin CAN (S88 Event   0x22)
  3.213174 192.168.0.182 -> 192.168.0.143 TCP Maerklin CAN (Software Version, Ping 0x30)
  3.214476 192.168.0.143 -> 192.168.0.182 TCP Maerklin CAN (Bootloader CAN   0x36)
  3.254266 192.168.0.182 -> 192.168.0.143 TCP Maerklin CAN (Bootloader CAN   0x37)
  3.254344 192.168.0.182 -> 192.168.0.143 TCP Maerklin CAN (System  0x01)
  3.254417 192.168.0.182 -> 192.168.0.143 TCP Maerklin CAN (Software Version, Ping 0x31)
  3.303704 192.168.0.143 -> 192.168.0.182 TCP Maerklin CAN (Software Version, Ping 0x31)
  3.304165 192.168.0.143 -> 192.168.0.182 TCP Maerklin CAN (Bootloader CAN   0x36)
  4.227273 192.168.0.143 -> 192.168.0.182 TCP Maerklin CAN (Status Config  0x3a)
  6.239444 192.168.0.143 -> 192.168.0.182 TCP Maerklin CAN (System  0x00)
  6.239844 192.168.0.182 -> 192.168.0.143 TCP Maerklin CAN (System  0x01)
  6.240026 192.168.0.143 -> 192.168.0.182 TCP Maerklin CAN (System  0x00)
  6.270112 192.168.0.182 -> 192.168.0.143 TCP Maerklin CAN (System  0x01)
  6.270169 192.168.0.182 -> 192.168.0.143 TCP Maerklin CAN (Loco Direction 0x0b)
  6.270243 192.168.0.182 -> 192.168.0.143 TCP Maerklin CAN (Loco Velocity  0x09)
  6.271958 192.168.0.143 -> 192.168.0.182 TCP Maerklin CAN (Loco Function  0x0c)
  6.280223 192.168.0.182 -> 192.168.0.143 TCP Maerklin CAN (Loco Function  0x0d)
  6.283304 192.168.0.143 -> 192.168.0.182 TCP Maerklin CAN (Start Automatic 0x61)
  6.321094 192.168.0.143 -> 192.168.0.182 TCP Maerklin CAN (Start Automatic 0x61)
  6.331268 192.168.0.182 -> 192.168.0.143 TCP Maerklin CAN (Software Version, Ping 0x31)
  6.815662 192.168.0.143 -> 192.168.0.182 TCP Maerklin CAN (Status Config  0x3a)
  8.827629 192.168.0.143 -> 192.168.0.182 TCP Maerklin CAN (Status Config  0x3a)
 
 

Das Lua-Skript ist längst noch nicht fertig und Bedarf noch reichlich Arbeit. Von Berufswegen wollte ich das aber immer schon mal machen. Aber IMHO ist Deine/Eure Expertise in Bezug auf die Dekodierung hier willkommen.

Vielleicht hilft das Lua-Skript auch einfach zum Start in die Eigenentwicklung ...

Gruß

Gerd

[Ixam97]

Hallo Michael, hallo Gerd,

hm, war mir schon irgendwie klar, dass man hier mit euch rechnen kann

Das ganze über Wireshark zu lösen ist sicherlich auch ein guter Ansatz, bin gespannt, was da am Ende bei raus kommt.
Zur Dekodierung: Was ich für sehr wichtig halte ist zu sehen, ob das Paket jetzt eine Anfrage/ein Befehl ist, oder ob das die Antwort ist, also ob das Response-Bit gesetzt ist. Dadurch kann man auf einem Blick sehen, ob auf einen Frame geantwortet wird. Und worauf ich bei meinem Programm ein Augenmerk gelegt habe: Man sieht auch sofort, was da eigentlich transportiert wird. Also nicht nur "Lok Richtung", sondern auch um welche Lok es sich handelt und in welche Richtung sie fahren soll. Grade für die Leute hier, die sich nicht so intensiv mit der Doku von Tante M auseinandergesetzt haben, sind die bisherigen Möglichkeiten, Traces zu erstellen, wohl eher eine Reihe von unübersichtlichen Hex-Zahlen. Und ich denke auch für Leute wie uns ist sowas eine immense erleichterung . Z.B. habe ich erst durch mein Programm wirklich realisiert, dass beim Einschalten der Gleisspannung auch jedes mal erneut die Gleisprotokolle freigegeben werden.

Aber was mein Progrämmchen angeht, so werde ich vermutlich bei UDP bleiben. Und das hat auch einen ganz einfachen Grund: In erster Linie habe ich das als eine Art Debugger für meine CAN-UDP-Bridge vorgesehen. An die kann man zwar an beiden Enden auch einen seriellen Monitor dranhängen, allerdings sehe ich dadurch nicht, was tatsächlich transportiert wird und was verschluckt wird (was leider immer noch manchmal vorkommt ... ). Daher so zu sagen eine "Mautstation" auf der Mitte der Brücke . Dazu bringe ich das Programm noch dazu, auf zwei Ports gleichzeitig zuzuhören und anzuzeigen, ob das Paketvon der Zentrale oder von der MS2 selber kommt.

[st-oldie]

Hallo Gerd,

Zitat von bertr2d2

---

ich geb es zu ops: - ich konnte die Finger nicht davon lassen: Lua Skript. Das tirvial.lua ist ein Pfundstück aus dem Internet, das ich als Vorlage genommen habe.
...
Das Lua-Skript ist längst noch nicht fertig und Bedarf noch reichlich Arbeit. Von Berufswegen wollte ich das aber immer schon mal machen. Aber IMHO ist Deine/Eure Expertise in Bezug auf die Dekodierung hier willkommen.

Vielleicht hilft das Lua-Skript auch einfach zum Start in die Eigenentwicklung ...

---

Hast du Langeweile?

Nö, etwas ernster. Ich hatte noch ein paar andere Dinge zu erledigen und bei mir bleibt eher der Abend für sowas übrig. Und ich bin deshalb erst dazu gekommen, nach ein paar Beispielen zu suchen. Ich bin dann doch immer etwsa überrascht, wieviel 'Zeit andere dann doch einsetzen können.

Eigentlich könnte man jetzt meine Decodierung aus dem client_logms2 mit der Trace Funktion meiner CAN lib mit deinem Rumpf verheiraten. Und schon hat man eine fast volständige Decodierung.

Tschüß
Michael

[st-oldie]

Hallo Maxi,

Zitat von Ixam97

---

hm, war mir schon irgendwie klar, dass man hier mit euch rechnen kann

---

Du kannst uns auch direkt ansprechen, statt zu versuchen etwas in den Raum zu stellen und zu schauen, ob jemand reagiert.

Zitat von Ixam97

---

Das ganze über Wireshark zu lösen ist sicherlich auch ein guter Ansatz, bin gespannt, was da am Ende bei raus kommt.

---

Letztendlich kann sowas rauskommen, was du für Win gemacht hast oder ich für den CAN Teil. Keine Ahnung ob Gerd schon weitermacht, oder ob ich meine Dekodierung hinzufügen kann. Das hängt wohl auch davon ab, wie schnell Gerd weitermachen möchte.

Zitat von Ixam97

---

Zur Dekodierung: Was ich für sehr wichtig halte ist zu sehen, ob das Paket jetzt eine Anfrage/ein Befehl ist, oder ob das die Antwort ist, also ob das Response-Bit gesetzt ist. ...

---

Also eigentlich eine vollständige Dekodierung der Message ID. Genau das, was ich bei mir auch eingebaut hab. Auch deshalb, um das verfolgen zu können. Und diese Infos kann man gut als Baum unter der Decodierung in Wireshark abbilden.

Zitat von Ixam97

---

Aber was mein Progrämmchen angeht, so werde ich vermutlich bei UDP bleiben. ...

---

Das war auch nur eine Überlegung von mir. Letztendlich ist es immer die Frage, wozu man das Programm braucht.

Tschüß
Michael

[bertr2d2]

Hallo Michael,

Zitat von st-oldie

---

Letztendlich kann sowas rauskommen, was du für Win gemacht hast oder ich für den CAN Teil. Keine Ahnung ob Gerd schon weitermacht, oder ob ich meine Dekodierung hinzufügen kann. Das hängt wohl auch davon ab, wie schnell Gerd weitermachen möchte.

---

vor einiger Zeit hätte ich das Know-How für einen Dissector gut gebrauchen können - beim Märklin Protokoll war es nur ein Test, wie man so etwas prinzipiell machen könnte. Ich werde jetzt etwas anderes basteln, z.B. die Kopierfunktion via Taste habe ich noch nicht fertig. Oder den CAN-Start-Stop Buzzer mit LED-Rückmeldung, mal sehen

Du kannst "übernehmen" wenn Du möchtest - ohne Gefahr zu laufen, doppelte Arbeit gemacht zu haben. Natürlich nur bei Interesse ...

Gruß

Gerd

[neo_02]

Vielen Dank für die Software, ich finde sie sehr praktisch. Die Anzeige an der Lok ist sehr cool, wenn es das Ganze noch mit DCC und Signalen geben würde, wäre das nochmal eine Spur hilfreicher für mein Vorhaben
Du hast es in C# implementiert? Muss ich beim Komplilieren irgend etwas beachten?

[Ixam97]

Hallo,

Zitat von neo_02

---

Vielen Dank für die Software, ich finde sie sehr praktisch. Die Anzeige an der Lok ist sehr cool, wenn es das Ganze noch mit DCC und Signalen geben würde, wäre das nochmal eine Spur hilfreicher für mein Vorhaben
Du hast es in C# implementiert? Muss ich beim Komplilieren irgend etwas beachten?

---

Was ist denn dein Vorhaben wenn ich fragen darf? Das Programm erkennt automatisch, ob eine Lok oder ein Zubehörartikel per Motorola oder DCC angesteuert wird und stellt das dementsprechend auch dar. Ob es sich bei einem Zubehörartikel nun aber um eine Weiche, eine Leuchte oder ein Signal handelt, ist aus den übermittelten Daten natürlich nicht ersichtlich. Allerdings ist die derzeitig herunterladbare Version etwas veraltet. Sobald ich wieder Zuhause bin werde ich mal die aktuelle Version hochladen.
Geschrieben ist das ganze in C#, richtig. Ob das auch auf anderen Rechnern problemlos kompiliert werden kann, kann ich dir nicht sagen, das musst du einfach mal ausprobieren. Aber die fertige exe steht ja auch zur Verfügung.

[neo_02]

Richtig, die grundsätzliche Anzeige funktioniert auch problemos. Ich hätte mir eine Anzeige im Stil der Lokanzeige gewünscht. Also z.B. "DCC Adresse XY Ausgang Z auf XX schalten" gewünscht. Mir geht es darum, die Funktionsweise des DCC Protokolls beim Schalten eines (Licht-)Signals nachzuvollziehen, da ich mir für die Lichtsignale einen DCC Signaldekoder mittels Arudinos (bzw. ATmega328P) bauen möchte. Natürlich kann ich das auch online nachlesen und in skizzieren, wie das angesteuert wird, nur fand ich das bisher sehr kompliziert und das Programm ist da eine wunderbare Erleichterung.

[Ixam97]

Hallo Daniel,

Zitat von neo_02

---

Richtig, die grundsätzliche Anzeige funktioniert auch problemos. Ich hätte mir eine Anzeige im Stil der Lokanzeige gewünscht. Also z.B. "DCC Adresse XY Ausgang Z auf XX schalten" gewünscht. Mir geht es darum, die Funktionsweise des DCC Protokolls beim Schalten eines (Licht-)Signals nachzuvollziehen, da ich mir für die Lichtsignale einen DCC Signaldekoder mittels Arudinos (bzw. ATmega328P) bauen möchte. Natürlich kann ich das auch online nachlesen und in skizzieren, wie das angesteuert wird, nur fand ich das bisher sehr kompliziert und das Programm ist da eine wunderbare Erleichterung.

---

Das ist in der aktuellsten Version schon inbegriffen. Heute Abend komme ich wieder nach Hause, dann werde ich die mal hochladen.
Soll der Signaldecoder denn per DCC oder über den CAN-Bus angesteuert werden? Mein Programm schlüsselt ja nur die CAN-Frames auf, nicht aber das DCC-Protokoll an sich. Mit den gängigen Digitalprotokollen kennen ich mich selber nicht aus, lediglich mit dem Märklin-CAN-Bus.

[Ixam97]

Unter dem Link in meinem ersten Beitrag ist jetzt die aktuelle Version zu finden.

[lachmichkaputt]

So einen UPD-CAN-Monitor zum CAN-Bus von Märklin hat Rainer Serwe schon vor längerer Zeit programmiert und unter www.r-serwe.de mitsamt Quellcode veröffentlicht. Das ist vom Ansatz her ganz gut gemacht und detailliert aufgeschlüsselt. Man sieht wer Befehle schickt und wer antwortet (response-Bit). Man sieht die Prio, den Befehl selber, den Hash, die UID bzw Loc-ID, die Datenlänge und auch die Daten selbst sind bei den wichtigsten Befehlen dem Protokoll entsprechend entschlüsselt. Man kann sogar testweise mit dieser Software selber Fahren und Schalten und sieht die dazugehörigen CAN-Frames gelistet. Alles lässt sich zusätzlich in einer Datei abspeichern.

Meine Wenigkeit hat sich erlaubt, diesen Monitor zu erweitern und kleinere Bugs zu entfernen. Die Erweiterung umfasst nun neben der UPD Schnittstelle per Winsock zur CS2, umschaltbar auch eine serielle Schnittstelle (RS232-FTDI bzw. USB) für die CC-Schnitte von Thorsten Mumm zur Verbindung mit einer Gleisbox.

Darauf aufbauend ist meine eigene Software-Zentrale, beruhend auf der Märklin-Gleisbox entstanden. Fahren mit MM2/DCC/MFX und Schalten mit MM, so wie das bei Märklin eben vorgesehen ist. Solcherart wird auch die Anzeige einer nebenbei angeschlossenen MS2 aktualisiert (sollte einmal erwähnt werden). Dies nur so nebenbei. Nun meine Frage:

Hat schon Jemand den Datenverkehr zwischen mehreren MS2 untereinander mit einem (seinem) CAN-Monitor analysiert? Ich meine die gegenseitige Übernahme von Loklisten, Symbolen etc. ohne CS2?

[DiegoGarcia]

Evtl. hilft das hier weiter: http://mbernstein.de/modellbahn/can/bem.htm

[st-oldie]

Hallo,

Zitat

---

Evtl. hilft das hier weiter: http://mbernstein.de/modellbahn/can/bem.htm

---

Auch mein Sourcecode könnte da helfen. Wenn die mfx Anmeldung von der MS2 gemacht wird, dann holt meine Software für BBB/BPi zuerst die Loknamen und dann die Infos zu jeder Lok ab. Ich vermute mal, daß das auch von den MS2 untereinander so gemacht wird. Der relevante Code ist im client_zentrale in states.c

Im Prinzip hast du wohl das, was ich erstellt hab, nochmals nachgebaut.

Tschüß
Michael

[mra]

Hi Maxi,

Zitat

---

Wie der Titel schon sagt handelt es sich um einen bequemen CAN-Monitor für Windows (ein dickes Sorry an die UNIX-Nutzer unter uns, aber damit kenne ich mich leider nicht so sehr aus ops:), der die UDP-Pakete aus dem Netzwerk fischt und etwas aufbereitet darstellt. Aber seht selbst:

---

Aaalso ... ich habs auf dem Mac (Unix!) zum Laufen bekommen ...
Unter Linux gehts sicher auch ...

Auch, wenn ich nicht so verstehe, warum Du in einem C#-Programm so mit Pointern und Referenzen rumwirbelst

Zitat

---

Falls ihr noch irgendwelche Ideen, Vorschläge oder Wünsche habt bin ich wie immer für alles offen

---

Ja - nicht nur per localhost auf CAN, sondern gleich übers Netz, bspw. an die CS2/CS3, aber das könnte ich ja auch selbst (mal) machen ...

Gr.,
Martin

[bertr2d2]

Hallo Zusammen,

im meiner can2udp Sammlung steckt auch ein can-monitor
der neben dem CAN Interface auch PCAP Dateien lesen kann, d.h. Aufzeichnungen die per tcpdump oder Wireshark gemacht wurden.

Gruß

Gerd

[vikr]

Hallo Gerd,

Zitat

---

im meiner can2udp Sammlung steckt auch ein can-monitor
der neben dem CAN Interface auch PCAP Dateien lesen kann, d.h. Aufzeichnungen die per tcpdump oder Wireshark gemacht wurden.

---

schön, dass Du wieder mitmischt

MfG

vik

[Rainer Müller]

Hallo Mittester,

Zitat

---

im meiner can2udp Sammlung steckt auch ein can-monitor
der neben dem CAN Interface auch PCAP Dateien lesen kann, d.h. Aufzeichnungen die per tcpdump oder Wireshark gemacht wurden.

---

von mir noch ein paar Bemerkungen zum Betrieb des genannten CAN-Monitors im "PCAP-Modus".

Da ich die Aufzeichnungen normalerweise mit Wireshark auf dem Desktop mache, wollte ich mir den Transfer zur CAN-Analyse auf den BananaPi sparen und habe deshalb mal den CAN-Monitor auf meinem Desktop-Ubuntu ausprobiert. Also can-monitor.c und can-monitor.h dorthin transferiert und compiliert:

1
 

gcc -o can-monitor can-monitor.c -lpcap
 

Das im Originalmakefile angegebene crc-ccitt braucht man nicht, dagegen muss man wenn "nicht gefunden"-Fehler auftauchen, evtl. noch das Paket libpcap0.8-dev nachinstallieren. Nun ist eine problemlose CAN-Analyse von PCAP-Aufzeichnungen auf dem Desktop möglich - allerdings sollte man beim Wireshark kein Interface auwählen, das mit "Linux cooked capture" aufzeichnet, dieses Format versteht der CAN-Monitor (noch ?) nicht.

Deutlich sperriger wird die Aufgabe für den Windows-Desktop. Dort fehlen viele der benötigten Headerdateien oder sind anders; dass man nur den Teil für die PCAP-Analyse betreiben will und nicht das CAN-Capture macht es wieder etwas einfacher. Aber es gibt diverse Hürden:
- die der libpcap entsprechende wpcap.dll hat ein Generationenproblem, sie versteht nur das pcap-Format und nicht das WS-favorisierte pcapng-Format (ng = new generation).
- der MS-Compiler (aus VS17) interpretiert manche Datenstrukturen anders als der gcc, das erfordert Nacharbeiten in den Headerdateien.
- wann die Einfärbecodes interpretiert oder als Text ausgegeben werden scheint noch ein Geheimnis von Windows zu sein.
Jedoch ist die Hoffnung da, dass das noch irgendwann was wird.

Zur Steigerung der Nutzerfreundlichkeit habe ich unlängst bei Gerd noch einen Änderungswunsch eingeworfen, in jeder Zeile das letzte Octett der Sender-IP anzugeben, um im Nicht-Verbose-Modus den Quellrechner aufzuzeigen. Der Vorschlag war leider, wie ich jetzt bemerkt habe, unvollständig: nicht nur bei UDP und TCP wäre mE. das sinnvoll, sondern auch bei HTTP.
Durch mein schlechtes Aufzeichnungsspezifizieren beim Wireshark bin ich auf einen zusätzlichen Wunsch gestoßen: eine neue Option -s, die bewirkt, dass nur Pakete angezeigt werden, bei denen Sender und Empfänger im gleichen Subnetz sind. Damit könnte man den CAN-Monitor dazu bringen, nicht zu versuchen, ungewollte Nach-Hause-Rufe seltsamer SW zu decodieren.


Gruß
Rainer

[bertr2d2]

Hallo Rainer,
[quote="Rainer Müller" post_id=1869656 time=1536166329 user_id=1332]
Hallo Mittester,

Zitat

---

im meiner can2udp Sammlung steckt auch ein can-monitor
der neben dem CAN Interface auch PCAP Dateien lesen kann, d.h. Aufzeichnungen die per tcpdump oder Wireshark gemacht wurden.

---

von mir noch ein paar Bemerkungen zum Betrieb des genannten CAN-Monitors im "PCAP-Modus".

Da ich die Aufzeichnungen normalerweise mit Wireshark auf dem Desktop mache, wollte ich mir den Transfer zur CAN-Analyse auf den BananaPi sparen und habe deshalb mal den CAN-Monitor auf meinem Desktop-Ubuntu ausprobiert. Also can-monitor.c und can-monitor.h dorthin transferiert und compiliert:

1
 

gcc -o can-monitor can-monitor.c -lpcap
 

Das im Originalmakefile angegebene crc-ccitt braucht man nicht, dagegen muss man wenn "nicht gefunden"-Fehler auftauchen, evtl. noch das Paket libpcap0.8-dev nachinstallieren. Nun ist eine problemlose CAN-Analyse von PCAP-Aufzeichnungen auf dem Desktop möglich - allerdings sollte man beim Wireshark kein Interface auwählen, das mit "Linux cooked capture" aufzeichnet, dieses Format versteht der CAN-Monitor (noch ?) nicht.
[/quote]das Makefile sollte eigentlich funktionieren. Hier die Vorgehensweise, die gehen sollte:

1
2
3
4
5
6
7
8
 

sudo apt-get install build-essential git libpcap-dev
cd
git clone https://github.com/GBert/railroad.git
cd railroad/can2udp/src
# Alte gcc's verstehen nicht alle pedantischen Schalter
sed 's/-fstack-protector-strong //' -i Makefile 
sed 's/-Wdate-time//' -i Makefile
make
 

CRC-CCITT ist gedacht um die CRCs der übertragenen Files zu überprüfen. Habe ich aber (noch) nicht implementiert.

"Linux cooked capture" höre ich zum ersten mal. Schaue ich mir mal an.

Zitat

---

Deutlich sperriger wird die Aufgabe für den Windows-Desktop. Dort fehlen viele der benötigten Headerdateien oder sind anders; dass man nur den Teil für die PCAP-Analyse betreiben will und nicht das CAN-Capture macht es wieder etwas einfacher. Aber es gibt diverse Hürden:
- die der libpcap entsprechende wpcap.dll hat ein Generationenproblem, sie versteht nur das pcap-Format und nicht das WS-favorisierte pcapng-Format (ng = new generation).
- der MS-Compiler (aus VS17) interpretiert manche Datenstrukturen anders als der gcc, das erfordert Nacharbeiten in den Headerdateien.
- wann die Einfärbecodes interpretiert oder als Text ausgegeben werden scheint noch ein Geheimnis von Windows zu sein.
Jedoch ist die Hoffnung da, dass das noch irgendwann was wird.

---

Der Königsweg wäre eigentlich die Integration in Wireshark. Ich habe mal ein wenig mit Lua gespielt:
https://github.com/GBert/railroad/tree/m...an2udp/src/dump

Zitat

---

Zur Steigerung der Nutzerfreundlichkeit habe ich unlängst bei Gerd noch einen Änderungswunsch eingeworfen, in jeder Zeile das letzte Octett der Sender-IP anzugeben, um im Nicht-Verbose-Modus den Quellrechner aufzuzeigen. Der Vorschlag war leider, wie ich jetzt bemerkt habe, unvollständig: nicht nur bei UDP und TCP wäre mE. das sinnvoll, sondern auch bei HTTP.
Durch mein schlechtes Aufzeichnungsspezifizieren beim Wireshark bin ich auf einen zusätzlichen Wunsch gestoßen: eine neue Option -s, die bewirkt, dass nur Pakete angezeigt werden, bei denen Sender und Empfänger im gleichen Subnetz sind. Damit könnte man den CAN-Monitor dazu bringen, nicht zu versuchen, ungewollte Nach-Hause-Rufe seltsamer SW zu decodieren.

---

Deine Vorschläge nehme ich gerne mit auf. Gib mir noch etwas Zeit - bin gerade mit ein paar anderen Sachen beschäftigt. Commits nehme ich natürlich auch

Gruß

Gerd

[Rainer Müller]

Hallo Gerd,

Zitat

---

Hallo Rainer,
das Makefile sollte eigentlich funktionieren. Hier die Vorgehensweise, die gehen sollte:
...

---

klar tut das, aber ich wollte auf dem Desktoprechner nur den CAN-Monitor. Den Rest lasse ich lieber auf dem BaPi.

Zitat

---

CRC-CCITT ist gedacht um die CRCs der übertragenen Files zu überprüfen. Habe ich aber (noch) nicht implementiert.

---

So was in der Richtung habe ich mir gedacht ...

Zitat

---

"Linux cooked capture" höre ich zum ersten mal. Schaue ich mir mal an.

---

So gings mir auch. Ich habe einmal beim Wireshark falsch geklicht und hinterher fand der CAN-Monitor nichts Brauchbares in der pcap-Datei, obwohl die Aufzeichnung im WS gut aussah. Die Analyse zeigte dann, dass der EthernetType zwei Bytes weiter hinten stand. Das wäre vermutlich einfach zu berücksichtigen, wenn man wüsste wie man erkennt, dass mit LCC-Aufzeichnung gearbeitet wurde. Aber das Feature braucht man nicht wirklich: aufpassen beim Klicken reicht auch.

Zitat

---

[quote="Rainer Müller" post_id=1869656 time=1536166329 user_id=1332]
Deutlich sperriger wird die Aufgabe für den Windows-Desktop.

---

Der Königsweg wäre eigentlich die Integration in Wireshark. Ich habe mal ein wenig mit Lua gespielt:
https://github.com/GBert/railroad/tree/m...an2udp/src/dump
[/quote]
Das ist natürlich auch schön - aber eine Riesenarbeit: Du musst die Decodierung usw. alles doppelt in unterschiedliche Sprachen codieren, einmal in C für die CAN-Liveanlyse und einmal als Lua-Script. Jede neue Erkenntnis zweimal einarbeiten ...
Meine Idee war da bescheidener: möglichst EIN Quelltext, der (mit ein paar #ifdef ...) alle Plattformen abdeckt. Insgesamt also eine Abwägung zwischen Schönheit und Aufwand.

Zitat

---

Deine Vorschläge nehme ich gerne mit auf. Gib mir noch etwas Zeit - bin gerade mit ein paar anderen Sachen beschäftigt. Commits nehme ich natürlich auch

Gruß

Gerd

---

Nur keine Eile. Ich kann meine Änderungsvorschläge ja demnächst in den Quelltext einbringen und dir zur Verfügung stellen. Aber du solltest dir die Änderungen dann ansehen, nicht dass ich zuviel übersehe.

Gruß
Rainer