"Lauschangriff" am CAN-Bus - Theorie und Praxis

[Rudi Ratlos]

Das klingt interessant, und mit dem Datenformat hätte ich keine Probleme. Mein "ELM 327 mini" BT funktioniert prächtig mit Torque auch am Silence, aber ich weiß nicht, wie der da initialisiert wird. Mit "Serial Bluetooth Terminal 1.40" kann ich mich zwar mit dem Dongle verbinden, aber es kommen keine Daten, ich schätze da fehlt einfach was an Mitteilungen an den Adapter

Versuch's zunächst mal mit folgenden Befehlen, die der ELM327 jeweils mit OK quittieren sollte:

AT WS (Warmstart des Adapters)
AT E1 (lokales Echo an)
AT L1 (sende LF nach jeder Zeile)
AT H1 (Header einschalten)
AT AL (erlaube lange Antworten)
AT SP 0 (automatische Protokollwahl) oder
AT SP 8 (explizit ISO15765-4 CAN (11 bit, 250 kbaud))
AT CAF 1 (automatische CAN Formatierung ein)
AT V 1 (variable Datenlänge
AT MA (Monitor all messages)

siehst du jetzt was?

[Pfriemler]

Woher weiß man denn denn sowas?

Tatsächlich reagiert der Adapter wie gewünscht

Code: Alles auswählen

AT WS > ELM327 v1.5
AT E1 > OK
AT L1 > OK
AT H1 > OK
AT SP8 > OK
13:22:24.897 
AT CAF1 > OK
AT V1 > OK
AT MA...

dann kommen erst mal fleißig Daten, aber schließlich BUFFER FULL...

Code: Alles auswählen

13:23:08.617 280 28 00 00 00 
13:23:08.617 401 00 00 00 00 00 
13:23:08.692 421 00 00 
13:23:08.692 280 28 00 00 00 
13:23:08.736 401 00 00 00 00 00 
13:23:08.736 421 00 00 
13:23:08.736 184 03 80 40 00 
13:23:08.736 191 003 02 00 00 00 
13:23:08.861 280 28 00 00 00 
13:23:08.861 401 00 00 00 00 00 
13:23:08.861 421 00 00 
13:23:08.861 280 28 00 00 00 
13:23:08.861 401 00 00 00 00 00 
13:23:08.861 421 00 00 
13:23:08.861 280 28 00 00 00 
13:23:08.861 182 00 
13:23:09.080 301 E6 00 D2 00 50 00 <DATA ERROR
13:23:09.
080 401 00 00 00 00 00 
13:23:09.080 421 00 00 
13:23:09.080 280 28 00 00 00 
13:23:09.080 401 00 00 00 00 00 
13:23:09.080 421 00 00 
13:23:09.080 1AC 21 5D 83 B5 01 00 00 00 
13:23:09.080 197 B8 0E FF FF 12 0C 39 64 <DATA ERROR
13:23:09.080 BUFFER FULL

"AT MA" kann ich jetzt noch ein paar mal absetzen, je öfter, je mehr Daten. Bei zu schnell sah ich auch mal kurz "buffer underrun" oder sowas.
Jedenfalls keine kontinuierliche Anlieferung, wie sie mit dem Arduino+MCP2515 problemlos funktioniert.
Solche Zeilen mag er gar nicht:

Code: Alles auswählen

13:23:23.966 185 69 0E 6C 0E 6A 0E 6C 0E <DATA ERROR
13:23:23.966 186 69 0E 6D 0E 6B 0E 6C 0E <DATA ERROR
13:23:23.966 187 6D 0E 6A 0E 6A 0E 6B 0E <DATA ERROR
13:23:23.966 188 6E 0E 69 0E 00 00 <DATA ERROR

was aber alles gültige Zellspannungen der 14 Zellstufen sind. An der Länge liegt es nicht - es kommen auch Meldungen mit 8 Nutzbytes sonst unbemeckert durch.

[Rudi Ratlos]

Woher weiß man denn denn sowas?

Guggstu hier:

https://www.scantool.net/scantool/downl ... 327dsh.pdf

[Rudi Ratlos]

Frage an die anderen CAN-Bus-Lauscher:

Die IDs 0x185 bis 0x188 stellen ja scheinbar die Spannung der 14 (Einzel)zellen mit nominal 3,7V (3700mV) dar. Zumindest bei mir tritt jedoch die ID 0x185 in jeder Scan-Situation mindestens 10 x so oft auf wie die die 0x186 und 0x187. Am seltensten meldet sich die 0x188. Hat von euch jemand eine Ahnung, was es damit auf sich hat?

Gruß Rudi

[Pfriemler]

Nicht nur scheinbar - bei mir sind die Werte absolut plausibel.
Bei mir nicht ganz so extrem, aber vom Prinzip her gleich. Ich kenne mich mit CAN nicht so aus, vor allem nicht wie genau die Kollisionskontrolle funktioniert, aber ich vermute (!), dass das BMS die vier IDs am Stück sendet und immer mal irgendein anderes Gerät "dazwischenfunkt". Zumindest fällt auf, dass das BMS teilweise im 5 ms-Takt Nachrichten schicken will und in fast genau das Raster andere dazwischenquatschen.

[Gerold]

Bei Kurzzeitscans von ein bis zwei Minuten direkt nach Einschalten des Rollers treten die großen Unterschiede in der Verteilung der ID's auch bei mir auf. Bei längeren Scans (>10min) relativieren die sich aber. Man könnte mal einen Scan für den Zeitraum von etwa 10min 5 Minuten nach dem Einschalten starten, um zu sehen, ob die Ungleichverteilung nur ein Einschalteffekt oder generell vorhanden ist.

[Rudi Ratlos]

Bei Kurzzeitscans von ein bis zwei Minuten direkt nach Einschalten des Rollers treten die großen Unterschiede in der Verteilung der ID's auch bei mir auf.

Danke für die Idee - möglich:

Ein Beispielscan von mir startete zwar gleich mit dem Einschalten des Rollers, unmittelbar danach bin ich aber ca. 25 Min. gefahren; insgesamt wurden 89342 Ereignisse aufgezeichnet - davon 2603 * 0x185, 192 * 0x186, 195 * 0x187 und 149 * 0x188. Demnächst werde ich mal einen Scan starten, nachdem der Mo schon einmige Minuten eingeschaltet ist.

[Rudi Ratlos]

Tatsächlich reagiert der Adapter wie gewünscht
dann kommen erst mal fleißig Daten, aber schließlich BUFFER FULL...
...
und
...
13:23:23.966 188 6E 0E 69 0E 00 00 <DATA ERROR

was aber alles gültige Zellspannungen der 14 Zellstufen sind. An der Länge liegt es nicht - es kommen auch Meldungen mit 8 Nutzbytes sonst unbemeckert durch.

Die Zeitangaben kommen wohl aus deinem Terminalprogramm, oder?
Ich habe auch einen Billig-Chinesenadapter, da passiert das gleiche. Mein OBDLinkLX hingegen hat wohl mehr Pufferspeicher, deshalb kommt es dort nicht zur Meldung BUFFER FULL.

Der "<DATA ERROR" tritt auch beim OBDLink auf und besagt, dass der CRC innerhalb der CAN Message fehlerhaft ist. Ganz interessant: Bei mir tritt der CRC-Fehler nicht nur bei den IDs 185-189 auf, dafür bei diesen IDs aber IMMER... Hmmm, komisch.

[Pfriemler]

Ja, beide Apps liefern die Zeitstempel, sehr hilfreich für die Analyse.
Anscheinend geht die Hardware sehr unterschiedlich mit der Datenmenge um. Tasmota pollt und kommt mit der schieren Menge nicht hinterher und ignoriert offenbar in großem Stil, Arduino reagiert auf Interrupt vom MCP2515 und liefert problemlos weit mehr ohne Fehler - ob auch da was "unter den Tisch fällt", weiß ich natürlich nicht...

[Rudi Ratlos]

Arduino reagiert auf Interrupt vom MCP2515 und liefert problemlos weit mehr ohne Fehler - ob auch da was "unter den Tisch fällt", weiß ich natürlich nicht...

Anscheinend fällt da auch so einiges hinten runter, zumindest dann, wenn der Arduino (Nano-Clone) auch noch die Datensätze auf SD-Karte schreiben soll... Beim Durchsehen meiner Logs, die ich mir einem Raspberry mit PiCAN gemacht habe, fällt mir auf, dass z.B. die ID 0x31c (VIN) immer mehrere Telegramme schnell nacheinander sendet, die die gesamte VIN enthalten. Meine o.g. Arduino-Mimik erhält aber immer nur den ersten Frame mit den ersten 7 Stellen der VIN und "überhört" die nachfolgenden. Vermutlich passiert genau das, was du vermutest - das wird alles gesendet aber mangels Performance nur ein Teil empfangen.

Jetzt bin ich mal gespannt, wie der OBDLink sich verhält - das teste ich die Tage.