The documentation says that the OpenPort 2.0 is not supported currently. What would be needed in order to add support for it? Shouldn't the J2534 code support it?

I have an OpenPort 2.0 that I'd be willing to test with, and I could probably help with development if I had some idea where to start.

The OpenPort 2.0 interface claims to be J2534-compliant, so it should work indeed.
Make sure you have installed the latest interface drivers (J2534 library).
The interface should then be found by FreeSSM and show up in the preferences.
If it doesn't show up or communication fails:
Compile the sources as 'debug', start the software from the terminal and send me the debug output.

OK, I installed https://github.com/NikolaKozina/j2534 (I hope that's the correct driver) using sudo make install and then re-built FreeSSM:

and ran the generated FreeSSM from the current directory (didn't bother installing it) and it does show SAE J2534 Pass-Through in the Interface-Type options, but the Interface-Name drop-down is empty and disabled, and the Test Diagnostic Interface button is disabled.

Here's the debug output:

Also, for reference, this is what happens in dmesg when I plug in the OpenPort 2.0:

Ahh, you are trying to uses this interface on Unix ? Interesting !
AFAIK Tactrix only provides a J2534-library for Windows and I wasn't aware of any 3rd party J2534 library.
Let's find out if it works..

On non-Windows systems (only), an additional configuration file is used: 'definitions/J2534libs.xml'.
If you didn't install the J2534-library to the FreeSSM working directory, you have to edit the library path in this file.
The rest is already suitable for the OpenPort 2.0.
As soon the path is correct, the interface will show up in the preferences.

Looks like NikolaKozinas library accesses the interface using 'libusb'.
Most Distros install this library by default these days.

Yes, sorry, I should have probably specified that.. I'm running Manjaro Linux (kernel 4.9.87) and I definitely have libusb installed. (/usr/lib/libusb-0.1.so.4.4.4)

I'll try editing the XML file and see if that fixes it.

Also, in the future it might make sense to detect the install path of libj2534.so using pkgconfig, since https://github.com/NikolaKozina/j2534 installs with a j2534.pc file. If this fixes things, I might work on that later.

OK, I ended up just copying libj2534.so into the FreeSSM directory, and running the app from there. That complained about permissions on the USB device, so rather than fight with udev rules right now, I just ran it with sudo. This worked to get it to the point of showing libj2534.so as the Interface-Name.

However, when I tried clicking Test Diagnostic Interface, it brought up the Testing interface.. Please wait! dialog, and then just sat there forever. There was no way to cancel or close the app aside from Ctrl+C on the command line or killing it.

Here's the debug output:

It got to that point within seconds of hitting the Test Diagnostic Interface button, and then didn't produce any more output until I killed the app. (I tried it twice for good measure, after unplugging the OpenPort and plugging it back in) Generals contra 009 download.

Looks good so far. Interface sends the test message, a valid reply from the ECU is received.

The infinite blocking seems to be a bug in the J2534 library:
PassThruReadMsgs() doesn't handle timeout=0 correctly.
As a workaround for testing, you can change the timeout value in line 520 of J2534DiagInterface.cpp from 0 to 1.

Using pkg-config doesn't make things easier.
J2534 libraries are device specific. So each interface uses it's own library.
Hence, even the library names differ.

For Windows, SAE-J2534 specifies registry keys, which are used to register and find all J2534-libraries.
Unfortunately, the spec creators didn't care about any other OS (yet ?). :(

For Windows, SAE-J2534 specifies registry keys, which are used to register and find all J2534-libraries.
Unfortunately, the spec creators didn't care about any other OS (yet ?). :(

Sounds like ODBC. ;)

I tried changing the timeout value to 1, and now the log looks like this:

It repeats those last lines constantly until I kill the app.

Also, if I try skipping the test and instead attempt to open any of the Control Units on the main window of the app, it gives me the error Couldn't open the diagnostic interface! Maybe the device is already in use by another application. and displays just the following line in the terminal:

Should I open a bug on https://github.com/NikolaKozina/j2534 ?

Looks like another bug in the library.
The ECU always sends 1 reply only, but PassThruReadMsgs() returns the last received message again and again..
The PassThruOpen() error is very likely caused by killing the app, so nothing to worry about.

Looking deeper into the code, there seem to be more issues..
Time to create a bug report.

Done: NikolaKozina/j2534#3

Thanks!

I wrote my driver to support RomRaider (and my standalone OpenGL logger) logging under Linux. Patches are always welcome though. I don't have my Subaru with me to test at the moment.

I wrote my driver to support RomRaider (and my standalone OpenGL logger) logging under Linux. Patches are always welcome though. I don't have my Subaru with me to test at the moment.

Well, AFAICS the 2nd issue is relevant for RomRaider, too.

Anyway, of course we can't force you to fix it.
I really appreciate your efforts to create such a library.
So thank you so far, it's at least a good starting point.

David, thank you testing !
From the applications point of view, there is really nothing we can do, sorry.
Someone needs to fix/improve the library.