Unit test `send_recv` fails

[BRM-Code]

Using Debian WSL.
To reproduce:

1. Clone repo
2. install libasound2-dev
3. run cargo test -j1 -- --test-threads=1

Output:

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running tests/test_serialstream.rs (target/debug/deps/test_serialstream-459d942c9283aa2b)

running 1 test
test send_recv ... FAILED

failures:

---- send_recv stdout ----
thread 'send_recv' panicked at tests/test_serialstream.rs:91:10:
unable to open serial port: Error { kind: Unknown, description: "Not a typewriter" }
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace


failures:
    send_recv

test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out; finished in 2.07s

error: test failed, to rerun pass `--test test_serialstream`

[BRM-Code]

From this comment in serialport-4.7.0\src\posix\tty.rs
// Ignore setting DTR for pseudo terminals (indicated by baud_rate == 0).

I found that setting the baud_rate to 0 on 89&92 @ test_serialstream.rs causes the test to pass.

I do intend to investigate this further and I'll make a branch.

[DownD]

From this comment in serialport-4.7.0\src\posix\tty.rs // Ignore setting DTR for pseudo terminals (indicated by baud_rate == 0).

I found that setting the baud_rate to 0 on 89&92 @ test_serialstream.rs causes the test to pass.

I do intend to investigate this further and I'll make a branch.

I was having the same problem and this solved my issue. Thanks a lot.
But i'm still wondering why this issue only popped now. I have a few tests using socat for setting a pseudo terminal and connecting to it, the tests have been working fine with a baud rate of 115200 for months... until a few days ago where the connection started returning an error (ENOTTY).
I don't remember of doing any crate updates that could cause this issue.

[mgonzalezperna]

I don't know if this is still relevant for you'all, but if you call preserve_dtr_on_open() on your serial port builder, it will set the dtr_on_open to None and you could restore the older behavior.

Seems like the change on setting dtr_on_open to true by default have consequences in the PTY creation for test cases.

[mgonzalezperna]

More on:
https://github.com/serialport/serialport-rs/blame/4f8e46b3b4c956a0945f76def83d84cc28ac5360/src/lib.rs#L858
https://github.com/serialport/serialport-rs/blame/58703446cdcbf082fee50063442b41e0e3d28612/src/posix/tty.rs#L195

[karalabe]

For what it's worth, hit a similar weird issue myself today:

• On macos, running a virtual serial port via socat, setting any baud rate apart of 0 results in not a typewriter error (both with and without preserve_dtr_on_open).
• On linux, running a live serial via USB g_serial, setting a 0 baud rate results in an invalid baud rate error (or something along those lines). Setting 9600 (or any valid baud rate) results in not a typewriter error. IF I specify preserve_dtr_on_open, zero still fails with an invalid baud rate but 9600 and co works.

Thus it seems there's a wonkier deeper issue. On Linux with the g_serial driver, I have to use preserve_dtr_on_open, otherwise it blows up. I'd say that's probably a bug.