Linux Enhancement request: Include symlinks in GetCommPorts return

[newHeiko]

Hello and thanks for this piece of software!

We recently switched JMRI: https://jmri.org over from PureJavaComm to jSerialComm to future-proof it.

One issue we are just now running into: Since Linux re-enumerates USB-Serial-Adapters depending on the order of plugging them in, some of our Linux users use udev-generated symlinks to tell multiple different USB->Serial adapters apart. For example, what could today be:

/dev/PR3Adapter -> /dev/ttyUSB0
/dev/NCEAdapter -> /dev/ttyUSB1
/dev/LokProgrammer -> /dev/ttyACM4

might tomorrow or after a couple of unplugging/replugging cycles look like:

/dev/PR3Adapter -> /dev/ttyUSB1
/dev/NCEAdapter -> /dev/ttyUSB0
/dev/LokProgrammer -> /dev/ttyACM2

We'd love to have the return value of GetCommPorts include those symlinks. Would you accept a PR that adds to

jSerialComm/src/main/c/Posix/PosixHelperFunctions.c

Line 649 in a8a307d

directoryIterator = opendir("/dev/");

another iteration through /dev, looking for symlinks to ports already in the vector and adding the symlinks to the comPorts vector? (Would that even work if they refer to the same physical port but show up twice in the result?)

If not, I'll give our port selector another deep look.

Thanks,
Heiko

[danielb987]

I'm not sure I understand the code in searchForComPorts() but it looks to me that what's needed is:

if (isPtyDevice(fileName))
	pushBack(comPorts, fileName, "PTY Device", "Pseudo-Terminal Device", "0-0", "Unknown", "Unknown", -1, -1);
else if (isTtyDevice(fileName))    // These two lines are added to handle symlinks by udev.
	pushBack(comPorts, fileName, "TTY Device", "Pseudo-Terminal Device", "0-0", "Unknown", "Unknown", -1, -1);
else if (isBluetoothDevice(fileName))
	pushBack(comPorts, fileName, "Bluetooth Device", "Bluetooth Device", "0-0", "Unknown", "Unknown", -1, -1);

at lines 665-668 and that the method isTtyDevice() is added.

[newHeiko]

That would be an option, certainly.

I guess it would be cleaner to add another loop, so it could just check any symlink in /dev/ if it links against a file already in the comPorts-Vector.

And probably copy the properties of the device it links to, instead of just filling it with "Unknown", "Unknown".

Heiko

edit: But let's wait for comments from the maintainer(s) of this library before discussing implementation details...

[hedgecrw]

Absolutely. I will try to get this implemented for the next release.

[hedgecrw]

I was able to get this implemented relatively quickly, and it's available now in the latest SNAPSHOT release. Please test and let me know if it works for you. All symlinked ports should now show up in the typical getCommPorts() enumeration; additionally, there is a new method called isSymlink() that you can call on the serial port object to determine whether or not it was represented by a symlink (in case that matters to you).

[newHeiko]

Thank you! I hope to get this tested some time next week and will let you know.

From looking at the code, I can see an issue with a symlink to a bluetooth device or PTY device that comes after the symlink in the directory iterator, because then in

jSerialComm/src/main/c/Posix/PosixHelperFunctions.c

Line 769 in ceb28d0

const serialPort *port = fetchPort(comPorts, symlink);

the port is not yet in the comPorts vector.

But it should work for "normal" serial ports and I'm not sure at the moment if symlinks to bluetooth or PTY devices even make sense. I'll let you know once I've tested.

Heiko

[hedgecrw]

Thank you! Regarding the PTY and Bluetooth devices, the search for PTY devices already explicitly includes symlinks so that one should be fine. You're right that Bluetooth device symlinks wouldn't work, but I'm also not sure that it makes sense for them to? Is it possible to dynamically create a Bluetooth device symlink that changes at boot time? (I'm actually asking...I have no idea.) If so, I can definitely add a fix (was just trying to avoid looping through the /dev structure twice if possible).

[newHeiko]

I don't know either, but I'll try to find out :)

[newHeiko]

I have checked a little more into the Bluetooth device name situation. In fact, there are Bluetooth serial devices (/dev/rfcommX), which trigger udev rules, which can create symlinks. I'm not sure how many such devices there are, but they do exist.

That being said, I believe we at JMRI don't support any Bluetooth serial devices. The only Bluetooth device we support is the MGP Smartphone Interface by Möllehem Gårdsproduktion: http://www.mollehem.se/index.php/en/loconet-components/electronic/smartphoninterface-detail - and that's not a Bluetooth serial device but uses some other access method through a library called bluecove, if I'm not mistaken. (@danielb987 might correct me here, as far as I know he is using one?) So unless Daniel objects, we don't need to detect symlinks to Bluetooth serial devices for our application.

More importantly, I downloaded your latest SNAPSHOT jSerialComm-2.12.0-20251107.134933-4.jar from https://central.sonatype.com/repository/maven-snapshots/com/fazecast/jSerialComm/2.12.0-SNAPSHOT/jSerialComm-2.12.0-20251107.134933-4.jar - hope that's the correct one - and it does not work.

I'm pretty much at a loss of how to debug this at the moment, but this is what I have - a single USB device with three symlinks to it:

heiko@x220:~$ ls -l /dev/ | grep ttyUSB0
lrwxrwxrwx   1 root  root             7 Nov 16 22:00 DCC2 -> ttyUSB0
lrwxrwxrwx   1 root  root             7 Nov 16 22:00 DCCEX -> ttyUSB0
lrwxrwxrwx   1 root  root             7 Nov 16 20:56 ttyDCCEX -> ttyUSB0
crw-rw----   1 root  dialout   188,   0 Nov 16 22:15 ttyUSB0
heiko@x220:~$

Created a little test program:

public class Test
{
    public static void main(java.lang.String[] args)
    {
        java.util.Vector<java.lang.String> portNameVector = new java.util.Vector<java.lang.String>();

        com.fazecast.jSerialComm.SerialPort[] ports = com.fazecast.jSerialComm.SerialPort.getCommPorts();

        for (com.fazecast.jSerialComm.SerialPort port : ports)
            {
                System.out.println(port);
                System.out.println(port.getSystemPortName());
            }
    }
}

Compiled and run with:

javac -cp lib/jSerialComm-2.12.0-20251107.134933-4.jar Test.java 
java -cp ".:lib/jSerialComm-2.12.0-20251107.134933-4.jar" Test

Output is:

FT232R USB UART
ttyUSB0

No sign of those symlinks in the output.

I tried to follow the code flow through getCommPorts -> getCommPortsNative -> Java_com_fazecast_jSerialComm_SerialPort_getCommPortsNative -> enumeratePorts -> searchForComPorts but can't find any obvious logical errors.

Any thoughts? I currently can't figure out how to build the entire library from source (no docker here and gradle or maven pull in a lot of AndroidPort stuff that I don't know where to find) but I'd be happy to test a version with tons of debugging output or similar.

Thank you for your support,
Heiko

[newHeiko]

Thinking a little more about this over night, I'll try and cut down PosixHelperFunctions.c to a point where I can compile and run it stand-alone as a C program and see if that one works here.

I'll get back to you with the results.

Heiko

[hedgecrw]

Thank you! By the way, there's already a test file under src/test/c/testEnumeratePosix.c and associated Makefile that you might be able to use without too much modification.

[newHeiko]

Thank you for pointing me towards the tests! I chose testPollPosix.c which I had to modify to compile, see #615 .

I found the cause of my issue: The code handles only absolute links:

heiko@x220:/dev$ ls -l DCCEX3 
lrwxrwxrwx 1 root root 12 Nov 17 21:49 DCCEX3 -> /dev/ttyUSB0

not relative links like I originally used:

heiko@x220:/dev$ ls -l DCCEX
lrwxrwxrwx 1 root root 7 Nov 16 22:00 DCCEX -> ttyUSB0

I'll propose a PR to fix this (I have it working, but littered with debugging printf's and wrong indentation - and it's 10pm here and my boss expects me at work tomorrow, so cleanup will have to wait :D)

Heiko

[danielb987]

@hedgecrw
Thank you for your work on this!

@newHeiko wrote:

That being said, I believe we at JMRI don't support any Bluetooth serial devices. The only Bluetooth device we support is the MGP Smartphone Interface by Möllehem Gårdsproduktion: http://www.mollehem.se/index.php/en/loconet-components/electronic/smartphoninterface-detail - and that's not a Bluetooth serial device but uses some other access method through a library called bluecove, if I'm not mistaken. (@danielb987 might correct me here, as far as I know he is using one?) So unless Daniel objects, we don't need to detect symlinks to Bluetooth serial devices for our application.

I have tested the SNAPSHOT version of jSerialComm with the MGP Smartphone Interface and it works fine! See PR JMRI/JMRI#14615 where the description of the PR has some information about how to configure JMRI to use the bluetooth serial port, including how to setup the udev rule.

So once the jSerialComm has been released with this change and is available to Maven, we can include this version into JMRI.