nutdrv_qx (Megatec) errors out after reading UPS data on Windows over USB CDC/COM

[gfechine]

When using the nutdrv_qx driver with the megatec protocol on Windows (via a USB CDC/COM serial connection), the driver successfully reads exactly 47 bytes of data sent by the UPS in response to Q1. However, immediately after reading the 47th byte, it hangs for exactly 1 second, resulting in an I/O error (err 0) and a failure to preprocess the answer.

My hypothesis is that the Win32 serial wrapper (w32_serial_read) might be failing to correctly catch the \r terminator to close the read operation early, or there is an issue with the buffer/timeout configurations on Windows compared to Linux.

To Reproduce

Steps to reproduce the behavior:

1. Run NUT 2.8.5 on Windows.
2. Connect a UPS using the Megatec protocol over a virtual serial port (USB CDC/COM).
3. Execute the driver directly with maximum debug level:
   .\nutdrv_qx -a tsshara -DDDD
4. Observe the log where it reads exactly 47 bytes, waits exactly 1 second, and throws a timeout/I/O error.

Expected behavior

The read operation should complete successfully upon receiving the \r terminator (the 47th byte) and pass the buffer to qx_process without hitting the 1-second timeout.

Logs

   1.435648     [D3:tsshara] send: 'Q1'
   1.435839     [D4:tsshara] w32_serial_read : ulen 511, vmin_ -1, vtime_ 0, hEvent 0000000000000118
[...]
   1.639599     [D4:tsshara] w32_serial_read : total characters read = 46
   1.643466     [D4:tsshara] w32_serial_read : characters are available on input buffer
   1.643553     [D4:tsshara] w32_serial_read : Reading 1 characters
   1.643579     [D4:tsshara] w32_serial_read : total characters read = 47
   2.643838     [D4:tsshara] w32_serial_read : err 0
   2.644013     [D3:tsshara] read: Input/output error (-1)
   2.644143     [D4:tsshara] qx_process: failed to preprocess answer [input.voltage]

Environment / Desktop

• OS: Windows (x86_64)
• NUT Version: 2.8.5 (64-bit build for x86_64, built with gcc from MSYS2)
• Installation method: Windows binaries
• Device: TS Shara UPS via Serial (USB CDC/COM mapped to \\.\COM3)
• Driver / Protocol: nutdrv_qx / megatec

Additional context

• The same problem does not happen on Ubuntu, where I tested with the same configs.
• By using PuTTY to connect directly to COM3 and sending Q1\r, the UPS responds immediately with:
  (231.0 231.0 116.0 011 60.0 27.2 41.0 00001000. This string length is exactly 46 characters + \r (47 bytes). The driver log clearly shows it successfully reading byte by byte up to that exact 47th byte (at 1.643s), at which point it halts and times out exactly 1.000 second later (at 2.643s).

Disclaimer: I have used AI to help me write this issue, since is my ever first issue and english is not my main language.

[gfechine]

Additional Investigation (via GitHub Copilot)

Disclaimer: I don't have deep knowledge of C or the Win32 API, so I decided to feed my logs and the repository's code into GitHub Copilot to see if it could pinpoint the issue. I am sharing its analysis here in case it helps point the maintainers in the right direction!

According to the AI's analysis, the bug seems to be a chain of three issues located inside wincompat.c:

1. The \r terminator is ignored: When the driver sets tio.c_cc[VEOL] = '\r', the Windows tcsetattr function silently discards it. The Windows compatibility layer never stores the end-of-line character.
2. No EOL stopping condition: Because it doesn't know it should stop at \r, the loop just keeps reading 1 byte at a time until the UPS stops sending data.
3. The fatal flaw (Missing break): After reading all 47 bytes, the buffer is empty, so it waits 1 second and hits a WAIT_TIMEOUT. However, inside the switch statement for the timeout, if tot > 0 (which is true, since it read 47 bytes), there is a missing break. It falls through to default: and hits goto err;. This purges the port, throws an EIO error, and throws away the 47 perfectly valid bytes.

Copilot's suggested approach to fix it:

• Modify serial_handler_t (in common.h) and tcsetattr (in wincompat.c) to actually store the c_cc[VEOL] character.
• Fix the WAIT_TIMEOUT case in wincompat.c so that if tot > 0, it returns the bytes already read instead of falling through to the error handler.
• Add a quick scan inside the read loop to check for the EOL character and return immediately, preventing the 1-second timeout entirely.

I hope this AI analysis is useful to whoever takes a look at this bug! Let me know if I can provide any more logs or tests.

[jimklimov]

Thanks, the logs and analysis look relevant.

Also note there are some known missing bits in the POSIX to Windows conversion (many #ifdef WIN32 blocks are involved, and a few are stubs still without code in them - most are tagged with NUT_WIN32_INCOMPLETE in comments or one of logging macros named like that). Can you ask AI to check if there's something like that near the suspected faulty code path?

Also quite a few issues are still open with https://github.com/networkupstools/nut/issues?q=is%3Aissue%20state%3Aopen%20label%3AWindows-not-on-par-with-POSIX label - maybe this one would help close some of that.

I am on a conference this weekend, so if you are open to practical experimentation, and have some time (and disk space), you can set up the MSYS2 environment locally to builds and try the fixes proposed above. See the build prerequisites at https://networkupstools.org/docs/qa-guide.chunked/_prerequisites_for_building_nut_on_different_oses.html#windows-with-msys2 - or perhaps a more concise version used by CI spelled out at https://github.com/networkupstools/nut/blob/master/appveyor.yml. After those are installed, ./ci_build.sh should take care of the most common-case scenario. Sadly, the Windows-POSIX emulation is somewhat slow (or maybe the shell scripting and massive process spawning involved in both autotools and make parts of the routine are "expensive" on the platform) so expect tens of minutes, maybe about an hour, for the configuration/build to complete.