"Lauschangriff" am CAN-Bus - Theorie und Praxis

[Pfriemler]

Ixxat ist ja u.a. das offizielle Tool für Silence-Werkstätten, das dockt ja unterm Sitz an der OBD an. Wenn man dessen Verkehr mitlauschen will, braucht man nur irgendein anderes hinreichend schnelles Tool parallel am Bus, das sich auf 250kbit konfigurieren lässt und an dem eine lauschende Software hängt, dafür taugt jede Lösung die wir hier im Thread für die Privatspionne hatten. Für OBD baut man sich eine Weiche nur mit den wichtigsten Leitungen (12V, GND, CANH CANL). Gibt's vll sogar fertig zu kaufen.

[Gerold]

Eine kleine Korrektur zu dem Post:

Nein, weiß ich leider nicht. Ich bin mir auch nicht sicher, ob das Astra Modul Zeit/Datumsinfos über den CAN-Bus sendet. In den Datensätzen, die das Modul an meinen Server sendet, sind die gesendeten Zeiten nämlich immer korrekt, während bei meinem Roller die BMS-Uhr ständig nachgeht.

Das Astra Modul sendet Zeitinformationen mit der ID 0x20B über den CAN-Bus in den Bytes 2-4. Allerdings nur, während der Roller eingeschaltet ist, also nicht beim Laden des Akkus. Die Zeit wird nicht in MEZ sondern in GMT Normalzeit ausgegeben, Sommer/Winterzeitumstellung wird nicht berücksichtigt.

Ich habe nun in mein Zusatzdisplay https://www.elektroroller-forum.de/view ... 75#p270575 diese ID verwendet, um die BMS-Zeit einmalig beim Start des Rollers zu korrigieren. Dazu wird die GMT Zeit auf MEZ umgerechnet und auch die Sommerzeit wird berücksichtigt. Somit wird im Display jetzt immer die korrekt Zeit angezeigt.

[Pfriemler]

Ich hoffe, dass ein Arduino-Sniffer eine bessere Trefferrate erzielt, wenn man sich nur auf bestimmte CAN-IDs konzentriert. (Das mit dem Blinker nur beim Fahren klappt schon mal einwandfrei).
Ich programmierte mir also mal kurz hart drei weitere IDs zum Scan ein: 0x20B kann ich aber leider nirgends finden, auch zuvor hatte ich es in keinem einzigen meiner Mitschnitte zufällig erwischt. FW ist 71.
Gerold, wann bzw. unter welchen Umständen empfängt Deine Zauberkiste das?
0x200 (BMS an Display) empfange ich fortlaufend ca 3-4x je Sekunde als Dezimalziffern (03 hh mm ss DD MM YY).
0x201 (Display an BMS nach dem Stellen der Uhrzeit über das Display) empfange ich 3x.

[Gerold]

Die 0x20B sind deutlich seltener als die 0x200. Dazu kommt. das in den ersten 0x20B Frames die Zeitinformazion noch nicht enthalten ist. Stattdessen wird in den Bytes 2-4 ein 0xFF gesendet. Ich hänge hier noch ein Logfile von heute an, der nur die Frames 0x200 und 0x20B enthält. Aus dem ist die Zeitabfolge der beiden Frames ganz gut erkennbar.

200+20A.csv

(220.33 KiB) 25-mal heruntergeladen

[Pfriemler]

Also wenn ich das richtig interpretiere, kommt der 0x20B schon fast jede Sekunde, liefert aber die ersten Nutzdaten mehr als eine halbe Stunde nach dem ersten Auftreten eines FF FF FF. Zwischen 14:46 und 15:11 ist zudem ein Loch im Log. Hier gibt es überhaupt keine 0x20B. Seltsam.

[Gerold]

Warum das da so lange gedauert hat, weiß ich auch nicht. Normalerweise erscheinen die Nutzdaten nach etwa einer halben Minute.

[patba]

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.

Ich habe mich jetzt auch mal an das Belauschen des CAN-Bus gemacht.
Nachdem ich sowieso einen OBDlink LX fürs Auto habe, war es nur logisch, das als erstes auszuprobieren.
Wie @Pfriemler bekomme ich jedoch nach spätestens 3-4 sek. "BUFFER FULL".

Verwendete Software wie Pfriemler "Serial Bluetooth Terminal", jedoch in der aktuellen V. 1.48, Android.

Bei Dir, @Rudi Ratlos, scheint es ja mit dem OBDlink LX zu funktionieren, aber wenn ich das richtig interpretiere, verwendest Du ein anderes Terminal-Programm? Darf man fragen, welches?
Serial Bluetooth Terminal erkennt die Situation übrigens und schlägt vor, den Buffer in den Einstellungen vom Terminalprogramm zu erhöhen, aber das bringt nicht wirklich was.
Evtl. ist auch die Geschwindigkeit ab der Übertragung zum Smartphone das limitierende?

Patrick

[Rudi Ratlos]

Bei Dir, @Rudi Ratlos, scheint es ja mit dem OBDlink LX zu funktionieren, aber wenn ich das richtig interpretiere, verwendest Du ein anderes Terminal-Programm? Darf man fragen, welches?

Ich habs gestern sicherheitshalber noch mal geprüft - bei mir treten keine Fehler oder Pufferüberläufe auf; und zwar weder unter Serial Bluetooth Terminal 1.49 (Android) noch unter einem ollen Windows Hyperterm. Ich vermute entweder, dass deine Hardware nicht performant genug ist oder eher, dass du den OBDLink nicht korrekt initialisierst. Ich empfehle als Initialisierungssequenz:

ATWS
ATE1
ATL1
ATH1
ATD1
ATAL
STP35
STPO
STCMM0
ATCAF0
ATCFC0

Die Firmware des OBDLink bei mir ist die aktuelle Version 5.6.19; dann kann ich mit STMA auf dem Can-Bus mitlesen - ohne Fehler, ich habs mehrere Minuten getestet.

Viel Erfolg wünscht

Rudi Ratlos

[patba]

Ich vermute entweder, dass deine Hardware nicht performant genug ist oder eher, dass du den OBDLink nicht korrekt initialisierst. Ich empfehle als Initialisierungssequenz:

Danke, das werde ich ausprobieren.

Wie schon angedeutet, verwende ich auch den OBDlink LX mit der aktuellen Firmware, deshalb hoffe ich, dass man das zum Laufen bringen wird. Bisher habe ich die Initialisierung wie hier viewtopic.php?p=290599#p290599 beschrieben verwendet.

Ich habe gestern schon ein wenig recherchiert und bin auf den Hinweis im allgemeinen ODBlink-manual (https://www.scantool.net/downloads/98/s ... Hd7gHmuIOr) gestoßen, man solle bei „buffer full“ die baud rate adapter-intern erhöhen. Dazu gibt es einige Befehle (u.a. „STSBR“).

Die default baud rate kann man mit „ATPPS“ auslesen. Im Register „0C“ steht dann der baud rate divisor (4000000 / baud rate divisor = baud rate). Der ODBlink LX ist laut Hersteller standardmäßig auf 115 kbps eingestellt, dementsprechend ist der divisor 23 (in HEX!), so ist es auch bei mir.
Es wäre interessant, was da Dein OBDlink eingestellt hat. Es ist offensichtlich, dass zu viel Verkehr auf dem CAN mit 250 kbps den buffer vollwerden lässt, wenn es danach nur mit 115 kbps weitergeht… Ich habs auch am PKW probiert, wo der CAN mit 500 kbps läuft, und da ist entsprechend noch schneller Ende.

Mir ist im Moment aber unklar, ob man die baud rate beim LX überhaupt verstellen kann. Das manual bleibt dazu uneindeutig, bzw. an mancher Stelle liest es sich wie „nein“. Ich probier jetzt erst mal die neue Initialiserung, und dann ggf. das Höherstellen der baud rate.

Die buffer-Größe beim originalen ELM327 ist nur 256 byte. Im obig verlinkten manual für den OBDlink-Chip steht nur „much larger“. An anderer, inoffizieller Stelle findet man 1 kB buffer, bzw. 8 kB gesamtes RAM, was natürlich ggf. auch recht schnell voll ist. Bei voller Last beträgt die Differenz zw. CAN-speed und UART-speed immerhin 135 kbps = gut 16 kB/s.

Patrick

[patba]

So, habe ein paar Tests gemacht.
So wie es aussieht, ist es tatsächlich v.a. ein Hardware-Performanzproblem.
Auf dem Smartphone (Samsung S20FE) mit Serial Bluetooth Terminal V 1.48 (hast Du tatsächlich 1.49? die bekomme ich im play store nicht angeboten) bekomme ich "buffer full", und zwar sowohl mit der alten als auch mit der neuen Initialisierung. Erstaunlich war nur, dass ich heute regelmäßig 10-15s lang mitlesen konnte, während es gestern max. 4s waren.
Mit dem Laptop und hterm bekomme ich mit beiden Initialiserungen keine Abbrüche. Zumindest in den je ca. 1-2 min Testzeit. Die mittlere Datenrate lag da bei ca. 96.000 kbps, also etwas unter den nominelle 115.200, aber durchaus knapp werdend.
Ich werde demnächst mal noch mit dem Smartphone meiner Frau testen, die hat was leistungsfähigeres.

Das Ändern der internen baud rate mit STSBR klappt, gestestet bis hoch auf 500.000, zumindest kommt keine Fehlermeldung, sondern OK. Leider kann man aber nicht nachprüfen/abrufen, welche Datenrate dann tatsächlich vorliegt. Dies brachte allerdings auf dem Handy keine Verbessung.
Am Golf habe ich es auch noch getestet. Da bekomme ich auch mit dem Laptop "buffer full". Baud rate am CAN bei VW ist 500.000. Mir gelang es aber nicht, eine stabile serielle Verbindung mit hterm zum Adapter mit mehr als 350.000 herzustellen. Die jeweils abrufbare Datenmenge bis zum "buffer full" war aber unabhängig von der eingestellten baud rate immer gleich. Es bleiben also grundsätzliche Fragezeichen. Beim Golf ist es aber eh komisch, es kommt nämlich immer nur der selbe frame. Kenne mich aber gar nicht aus, was hier normal wäre.

Patrick