On linux with udev, port whithout a parent should not be filtered out of available_ports

[dzamlo]

As discussed in #245, port whithout a parent value are filtered out durin enumeration with udev

That should likely not be the case.

[sirhcel]

Thank you for opening this issue @dzamlo! Quoting from the original discussion in #245:

I found out that the reason is that during the enumeration device without a parent are filtered out, and rfcomm (Bluetooth serial on Linux) device don't have a parent.

They seem to be the first of its kind without a parent device. Checking for the presence of a parent device has been the criterion for quite a while.

Looking at the udev information from #245, additionally checking whether the device's sysname starts with rfcomm looks like the way to go for these devices. I did a first shot on enumerating RFCOMM devices and tracing enumeration in test/enumeration-tracing/b157b7e. Could you please give it a spin with your RFCOMM setup?

Could you please also check what the enumeration without libudev does for RFCOMM devices? Does your device in question show up with:

$ export RUST_LOG=trace
$ cargo run --no-default-features --example list_ports

If not, is there a hint in the tracing output? And is the RFCOMM device referenced from /sys/class/tty/?

[dzamlo]

Could you please give it a spin with your RFCOMM setup?

The port is correctly listed. The type is Unknown and maybe should be Bluetooth.

cargo run --no-default-features --example list_ports

Only my USB serial port are listed.
the relevant tracing output is :

2025-02-16T12:59:48.539047Z DEBUG available_ports:path{path=Ok(DirEntry("/sys/class/tty/rfcomm0"))}: serialport::posix::enumerate: rejected cause="no device dir"

Note that most port listed with udev are also not listed without it, for either the same no device dir reason or for the no port type reason.

additionally checking whether the device's sysname starts with rfcomm looks like the way to go for these devices.

What I don't understand is why filter device without a parent except for historical reason?

[sirhcel]

The port is correctly listed. The type is Unknown and maybe should be Bluetooth.

Great. I finally got a Bluetooth dongle and a Bluetooth serial adapter for checking this out and with sirhcel@rfcomm-enumeration/sirhcel@6469fa6 there is an updated variant of the enumeration available which reports RFCOMM devices as BluetoothPort. With and without libudev. Could you please give it a spin?

$ cargo run --example list_ports
$ cargo run --no-default-features --example list_ports

Both enumeration variants should produce the same output.

cargo run --no-default-features --example list_ports

Only my USB serial port are listed.

Are there serial ports besides RFCOMM missing?

Note that most port listed with udev are also not listed without it, for either the same no device dir reason or for the no port type reason.

I'm seeing exactly the same output from list_ports with or without libudev. Which ports are you missing? What kind of machine are you using? Is this more of an embedded or desktop setup?

What I don't understand is why filter device without a parent except for historical reason?

Me neither. But this criterion is there "forever" and filters out a whole bunch of TTY devices which aren't actual serial ports on my machine.

[sirhcel]

My Bluetooth serial setup is a TP Link UB500 dongle and a HC-05 Bluetooth serial module. The latter runs at its default speed of 9,600 Baud.

When running the tests from serialport, there are errors from clearing the input/output buffers of the RFCOMM device. They appear spuriously and it looks like the underlying tcflush returns -1 in case they fail.

There are more issues related to baud rate changes which I'm ignoring in the first place.

Does Bluetooth serial communication work reliably in your case? Which hardware are you using? Are you able to run serialport's test in your setup? Like:

$ export RUST_BACKTRACE=1
$ export SERIALPORT_TEST_PORT_1 /dev/rfcomm0
$ export SERIALPORT_TEST_PORT_2 /dev/ttyUSB0
$ cargo test --test test_baudrate

[dzamlo]

The ports missing without udev are tty starting with /dev/ttyS. In retrospect, I believe they should not be listed as they are not actual serial ports.

Does Bluetooth serial communication work reliably in your case? Which hardware are you using? Are you able to run serialport's test in your setup? Like:

I'm using an ESP32 using the BluetoothSerial > SerialtoSerialBT Arduino example.

The communication works reliably and the test_baudratetest run successfully.

It seems that the baud rate on the Bluetooth serial connection is ignored.

EDIT: the test_timeout test fails: https://gist.github.com/dzamlo/b8d6864203c27ebf28a2bc1f8193de28