Socketcan J2534 device support

[jakka351]

Hi,

A feature suggestion, add compatibility for J2534 devices, they are widely used in the automotive industry, and I believe the API is portable to linux.

Sure others would be be keen too.

Thanks

[derek-will]

Unfortunately, there is no official specification for the J2534 API on Linux. The J2534 API currently is only supported on 32-bit Windows and as of January 2022 on 64-bit Windows as well via J2534-5. There are also two current versions of the API - 04.04 and 05.00 which are fundamentally different.

Are you suggesting adding a J2534 API facade? Where J2534 API functions wrap an underlying SocketCAN socket?

If so, there are some significant differences between SocketCAN and J2534. For one such example, in J2534-2 04.04 the pins (6 & 14, 3 & 11, etc.) on the tool interface are selectable via a call to PassThruIoctl for the CAN_PS and ISO15765_PS protocol channels. To my knowledge, no such parallel feature exists in SocketCAN for selecting pins on the tool interface. An analysis could be done to see where all the incompatibilities exist and I think it would be a cool project.

I guess the bonus here would be that all SocketCAN tools would automatically have J2534 support on Linux, but again only unofficially (and that distinction matters here). OEMs and other software vendors that support the J2534 API in their applications are likely not willing to compile their applications for Linux especially when some of these application may not have been designed to be cross-platform and the cost to make them cross-platform would be quite high.

What sort of upside do you forsee?

[jakka351]

Thanks for your response. Yes, I am referring to adding faux-support as J2534 is not made for linux. I think that trying to get OEM's to port their diagnostic softwares to linux would be a pointless excersize. The pass-thru functionality is what I would be interested in seeing, so that you just use a J2534 device with your standard candump cansend cangen uses of can-utils.

I would expect some of the upsides to include a larger possible user base of socketcan, from a much more diverse group of people and in the context of Right to repair, it may even go so much as to form a base for official linux support for J2534. It may even draw development support from OEM's, as Volkswagen did for the creation of socketcan.

Windows now has the subsystem for linux, so there is precedent for cooperation between the windows/linux camps.

[olerem]

I feel like here is some confusion about meaning of J2534. @derek-will talks about J2534 software API. @jakka351 talks about J2534 branded devices to work with SocketCan. Correct? So, it is not a task to create SocketCan to J2534 API library. It is about writing more kernel drivers for SocketCan. Or use existing HW with working drivers.

[jakka351]

Yes - that seems accurate. I refer to the actual J2534 devices being able to be used with socketcan, rather than using socketcan to reprogram an ECU via the J2534 protocol.

[olerem]

To make sure, you do not fight against windmills. Providing support for many different adapters may take a long time (nothing against it, it is important job as well :)).
But you can use, for example: OBD-II to DB9 Cable (make sure it has proper pin layout):
https://www.antratek.de/obd2-to-db9-cable

• some well supported CAN controller. For example candleLight:
  https://linux-automation.com/en/products/candlelight.html

In case you wont to try ELM327 based adapter, you can take a loot to this driver:
https://github.com/norly/elmcan

[jakka351]

I usually use a raspberry pi with SPI-CAN interface, yes thanks for that, but I was posting about J2534 tools as they are what the automotive industry uses.

[olerem]

Heh, I assume with "automotive industry" you mean, the car repair industry or community. Because things like RPi + SPI-CAN is exactly what car making industry is using on MCU side :)
In any case, J2534 API is provided by the drivers not actual adapters:
OBD-II < black box adapter > -- some interfaces <-- driver -> J2534 API <-- windows tool using this API. If you will take a look to the SAE J2534 documentation, you'll see snippets of windows API like:
extern “C” long WINAPI PassThruReadMsgs
(
unsigned long ChannelID,
PASSTHRU_MSG *pMsg,
unsigned long *pNumMsgs,
unsigned long Timeout
)

even worse, this specification requires Windows as part of standard (at least the old version of it):
"6.1 PC Requirements
Generic PC running a Win32 Operating System (e.g., Windows 95/Windows 98/Windows NT/Windows Millennium Edition, Windows 2000, Windows XP, …). The PC should be capable of connection to the Internet."

[jakka351]

Thanks guys