drivers: nhs_ser: do not force CRTSCTS (breaks CDC-ACM and 3-wire ser…

[jpastoreli]

Disables the hardcoded CRTSCTS in nhs_ser openfd(), which blocks
communication on NHS UPSes with no RTS/CTS lines (USB/CDC-ACM and the
official 3-wire serial cable).

Full diagnosis, raw packet captures and device details: Refs #3510

[github-actions]

A ZIP file with standard source tarball and another tarball with pre-built docs for commit 58af3b7 is temporarily available: NUT-tarballs-PR-3511.zip.

[AppVeyorBot]

✅ Build nut 2.8.5.4900-master completed (commit 24cb2b67bf by @jpastoreli)

• artifacts
• A 7-zip archive with built NUT for Windows debug binaries is temporarily available: NUT-for-Windows-x86_64-SNAPSHOT-2.8.5.4900-master.7z

[AppVeyorBot]

✅ Build nut 2.8.5.4901-master completed (commit d41946991b by @jpastoreli)

• artifacts
• A 7-zip archive with built NUT for Windows debug binaries is temporarily available: NUT-for-Windows-x86_64-SNAPSHOT-2.8.5.4901-master.7z

[jimklimov]

Generally looks reasonable; deferring to @Challado as original author per #2692 to make sure it works with the model it was originally posted for too.

The PR would benefit from also a note in NEWS.adoc about the driver update, and a DRIVER_VERSION number bump.

[Challado]

Generally looks reasonable; deferring to @Challado as original author per #2692 to make sure it works with the model it was originally posted for too.

The PR would benefit from also a note in NEWS.adoc about the driver update, and a DRIVER_VERSION number bump.

As expected, testing on 3 units that I know the problem appears fail on communication.

[Challado]

Re-tested with other 2 units, same problem @jimklimov. I'll see that I can make something about these code and commit a more elegant solution.

[Challado]

@jimklimov
Quick update: I reworked the proposed fix into a more general nhs_ser change instead of just removing CRTSCTS unconditionally.

The current implementation keeps the existing driver behavior as the default, but makes the relevant serial communication settings configurable from ups.conf.

Default behavior is intentionally preserved:

• baud = 2400
• serial_data_bits = 8
• serial_parity = none
• serial_stop_bits = 1
• serial_flow_control = hardware
• serial_read_timeout_ms = 100
• serial_send_pace_us = 0

So existing installations should continue to behave as before, including the historical RTS/CTS default.

For the NHS Mini Gamer / CDC-ACM case described in this issue, the fix is now simply:

serial_flow_control = none

I also changed the implementation to use the standard NUT serial helpers instead of keeping direct serial I/O paths in the driver:

• TYPE_FD_SER
• ser_open_nf()
• ser_set_speed_nf()
• ser_close()
• ser_get_char()
• ser_send_buf()
• ser_send_buf_pace()
• ser_flush_io()

The driver now only keeps local termios handling for the settings not covered directly by those helpers: data bits, parity, stop bits and flow control.

I deliberately reduced the scope after testing the first approach. The earlier version exposed too many low-level termios and Linux-specific details, so I removed those and kept only conventional serial-port options which are useful for this driver:

• baud rate
• data bits
• parity
• stop bits
• flow control
• per-byte read timeout
• optional transmit pacing

I also removed the Linux-specific TIOCGSERIAL / TIOCSSERIAL handling from the proposed change. That does not help CDC-ACM devices and seemed unnecessary for solving this issue.

All new options are registered with addvar(VAR_VALUE, ...) and validated through getval() during driver initialization. Invalid values fail early with a clear configuration error instead of being silently accepted.

The NHS packet protocol handling itself is unchanged: DATA/HWINFO framing, checksums, packet decoding, status handling and reconnect logic remain the same.

I have built the updated driver successfully. My next step is to test it on the affected NHS Mini Gamer device with:

serial_flow_control = none

and also verify that the default configuration still behaves the same on devices which worked with the previous hardcoded RTS/CTS behavior.

[jimklimov]

@Challado @jpastoreli : was the updated fix pushed anywhere and posted as a PR?

[Challado]

Hi Jim, Yes, I pushed the updated implementation to my fork: https://github.com/Challado/nut The latest commit contains the corrected and simplified implementation: Challado@eb0465d The preceding commit (`ae8fc51`) was the first implementation and contained unnecessary complexity; it is corrected by the latest commit. The final branch state is the intended version. The change preserves the historical `nhs_ser` serial defaults, but allows devices which do not use RTS/CTS to configure: serial_flow_control = none It also migrates the serial-port lifecycle and data transfer to the standard NUT serial helper functions. I have not opened a separate Pull Request for this implementation yet. The current comparison against the upstream master branch is available here: master...Challado:master I will be away on vacation for a few days, but I will review any additional feedback or necessary adjustments when I return. Best regards, Lucas

…

On Fri, 17 Jul 2026 08:37:49 -0700, Jim Klimov ***@***.***> wrote: jimklimov left a comment [(networkupstools/nut#3511)](#3511 (comment)) ***@***.***(https://github.com/Challado) ***@***.***(https://github.com/jpastoreli) : was the updated fix pushed anywhere and posted as a PR? — Reply to this email directly, [view it on GitHub](#3511?email_source=notifications&email_token=AFQ3CA3SOIF6N7OHJHKV2FT5FJB43A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMBQGQ4TAMBZGQ3KM4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-5004900946), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AFQ3CA34RPUCYITMXWTPN2T5FJB43AVCNFSNUABDKJSXA33TNF2G64TZHM4DCMRZGI2TOO2JONZXKZJ3GQ3TMMZZGIZTIMRTUF3AE). You are receiving this because you were mentioned.

[jimklimov]

Thanks, i'll take a look - and gave a good vacation!