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