Unable to establish SSL connection to windows Upsd

[bitmk2]

Windows upsd.exe output

C:\Program Files (x86)\NUT\sbin>upsd -DDDDDDDDD Network UPS Tools upsd Windows-v2.6.5-5-7-g72f380c 0.000000 listen_add: added 0.0.0.0:3493 0.000000 setuptcp: try to bind to 0.0.0.0 port 3493 0.000000 listening on 0.0.0.0 port 3493 0.125129 Connected to UPS [Apc550]: usbhid-ups-Apc550 0.125129 user_add_action: adding 'login' for slaveuser 0.125129 user_add_action: adding 'login' for masteruser 0.125129 user_add_action: adding 'master' for masteruser 0.125129 user_add_action: adding 'fsd' for masteruser 0.125129 mainloop: wait for 3 filedescriptors 0.125129 mainloop: wait for 3 filedescriptors 0.125129 mainloop: wait for 3 filedescriptors 0.141139 mainloop: wait for 3 filedescriptors 0.141139 mainloop: wait for 3 filedescriptors 0.141139 UPS [Apc550]: dump is done 0.141139 mainloop: wait for 3 filedescriptors 2.156285 mainloop: no data available 2.156285 mainloop: wait for 3 filedescriptors 4.031593 Connect from 192.168.12.8 4.031593 mainloop: wait for 4 filedescriptors 4.031593 write: [destfd=388] [len=12] [OK STARTTLS] 4.031593 Unknown return value from SSL_accept: No error [A non-blocking socket operation could not be completed immediately. ] 4.031593 ssl_error() ret=-1 SSL_ERROR_WANT_READ 4.031593 mainloop: wait for 4 filedescriptors 4.031593 Disconnect 192.168.12.8 (read failure): No error [The system cannot find the file specified. ] 4.046593 Disconnect from 192.168.12.8 4.046593 mainloop: wait for 3 filedescriptors 6.046647 mainloop: no data available 6.046647 Pinging UPS [Apc550] 6.046647 mainloop: wait for 3 filedescriptors 6.046647 Got PONG from UPS [Apc550] 6.046647 mainloop: wait for 3 filedescriptors

Windows upsmon.exe output

C:\Program Files (x86)\NUT\bin>..\sbin\upsmon.exe -D Network UPS Tools upsmon Windows-v2.6.5-5-7-g72f380c 0.000000 UPS: Apc550@sisifos.upsd.bit.space (master) (power value 1) 0.015642 Using power down flag file C:\killpower 0.015642 debug level is '1' 0.156602 Trying to connect to UPS [Apc550@sisifos.upsd.bit.space] Unknown return value from SSL_connect -1: No error [An established connection was aborted by the software in your host machine. ] ssl_error() ret=-1 SSL_ERROR_SYSCALL Can not connect to sisifos.upsd.bit.space in SSL, disconnect 0.187432 UPS [Apc550@sisifos.upsd.bit.space]: connect failed: SSL error: peer disconnected 0.187432 Communications with UPS Apc550@sisifos.upsd.bit.space lost 5.203132 Trying to connect to UPS [Apc550@sisifos.upsd.bit.space]

Linux upsmon.exe output

[root@fedora ups]# upsmon -DD Network UPS Tools upsmon 2.7.4 0.000000 fopen /var/run/nut/upsmon.pid: No such file or directory 0.000624 Using power down flag file /etc/killpower 0.001082 UPS: Apc550@sisifos.upsd.bit.space (master) (power value 1) 0.001502 debug level is '2' 0.004422 Trying to connect to UPS [Apc550@sisifos.upsd.bit.space] 0.016949 Unknown return value from SSL_connect -1: Connection reset by peer 0.017390 ssl_error() ret=-1 SSL_ERROR_SYSCALL 0.017717 Can not connect to sisifos.upsd.bit.space in SSL, disconnect 0.018116 UPS [Apc550@sisifos.upsd.bit.space]: connect failed: SSL error: error:1409E0E5:SSL routines:ssl3_write_bytes:ssl handshake failure 0.018461 do_notify: ntype 0x0005 (COMMBAD) 0.018790 Communications with UPS Apc550@sisifos.upsd.bit.space lost ^C 2.162006 Signal 2: exiting 2.162659 Dropping connection to UPS [Apc550@sisifos.upsd.bit.space]

ups.conf

maxretry = 1

[Apc550]
driver = usbhid-ups
port = auto
desc = "Apc 550"

nut.conf MODE=netserver

upsd.conf

LISTEN 0.0.0.0 3493
CERTFILE "C:\\1\\upsd.pem"

upsd.pem is the standard pem file as described in http://networkupstools.org/docs/user-manual.chunked/ar01s09.html

-----BEGIN CERTIFICATE-----
.....
...
.
-----END CERTIFICATE-----
-----BEGIN PRIVATE KEY-----
.....
...
.
-----END PRIVATE KEY-----

If I use the exact same configuration & certificate files on a linux upsd installation both linux & windows upsmon clients work fine. If I comment-out the CERTFILE line inside the upsd.conf and the CERTVERIFY/FORCESSL in upsmon.conf then I can also connect.

So this must be a upsd SSL related bug. I used the process monitor application to investigate the "The system cannot find the file specified" error message of upsd, but could not find anything interesting.

Regards, George

[clepple]

Probably needs this commit: https://github.com/networkupstools/nut/commit/f098486803921b8899d4172fff97846428d82c12

However, the Windows port is not exactly maintained - note that it is based on NUT v2.6.5, and the current release for other platforms is v2.7.4. See issues linked from here for status: https://github.com/networkupstools/nut/issues/5

[bitmk2]

I hoped that somebody would have tested the windows port with SSL and I was the one doing something wrong. I assume it wasn't really stable and fully tested when the windows port was published.

I would really like to apply the patch and retest. Last week I recompiled rpm for fedora with NSS support. I have no idea how to do that for the windows platform. Any guidelines available?

[clepple]

This is the only information I can find: http://lists.alioth.debian.org/pipermail/nut-upsuser/2012-March/007532.html

@bohe-eaton any other Windows build information?

[bitmk2]

I managed to successfully build 2.6.5 with usb and ssl support, but Upsd crashes when netssl.c::ssl_init() executes SSL_library_init()

(gdb) run Starting program: C:\MinGW\msys\1.0\nut-windows_port/server/upsd.exe [New Thread 2020.0xde8] [New Thread 2020.0x15e4] Network UPS Tools upsd 2.6.5 listening on 0.0.0.0 port 3493 Program received signal SIGSEGV, Segmentation fault. 0x6085da66 in strsep () from C:\MinGW\msys\1.0\nut-windows_port\server\msys-1.0.dll (gdb) where

0 0x6085da66 in strsep () from C:\MinGW\msys\1.0\nut-windows_port\server\msys-1.0.dll

1 0x6082d5e7 in msys-1.0!calloc () from C:\MinGW\msys\1.0\nut-windows_port\server\msys-1.0.dll

2 0x6088d381 in strftime () from C:\MinGW\msys\1.0\nut-windows_port\server\msys-1.0.dll

3 0x6082d2e0 in msys-1.0!malloc () from C:\MinGW\msys\1.0\nut-windows_port\server\msys-1.0.dll

4 0x62a02057 in msys-crypto-1.0.0!CRYPTO_malloc ()

from C:\MinGW\msys\1.0\nut-windows_port\server\msys-crypto-1.0.0.dll

5 0x00000060 in ?? ()

6 0x62b0a988 in msys-crypto-1.0.0!lh_version ()

from C:\MinGW\msys\1.0\nut-windows_port\server\msys-crypto-1.0.0.dll

7 0x00000077 in ?? ()

8 0x62aea348 in x509_dir_lookup () from C:\MinGW\msys\1.0\nut-windows_port\server\msys-crypto-1.0.0.dll

9 0x00000000 in ?? ()

[clepple]

I'm not sure what the proper debug flags are for MinGW, but can you recompile and link with debug information? It would be something like -ggdb for *nix.

The backtrace has a few bad addresses (see "??") but that looks like it is deep in OpenSSL code. Do you know the exact version of OpenSSL?

[bitmk2]

I finally got it to compile with "-lssleay32 -llibeay32" instead of "-lssl -lcrypto". I just manually modified the configure file. Then I applied the patch you suggested and got a successful SSL connection with certificate verification.

I still get a "ssl_error() ret=-1 SSL_ERROR_WANT_READ" error message, but I will try to figure it out tomorrow.

[bitmk2]

"ssl_error() ret=-1 SSL_ERROR_WANT_READ" is just a debug message, which is operationally ignored. Too much logging is a problem because I intend to use the daemon in debug mode. So I upgraded the debug level for this specific log.

I would like to put the effort to merge the 3years old windows-port with master. Conflicts are not severe. Do you see any obvious reason that this will not work? Any critical dependency added since then which is not available on mingw platform?

[clepple]

I would like to put the effort to merge the 3years old windows-port with master. Conflicts are not too severe. Do you see any obvious reason that this will not work?

https://github.com/networkupstools/nut/issues/5#issuecomment-217636422

The rest of the thread is also good for context, but I have stared at the branch history long enough to know that it will be an absolute nightmare from a maintenance standpoint. I do not want duplicate copies of every trunk/master commit that was made during the development of windows-port.

[bitmk2]

I absolutely understand that, but it is a lot easier to do once every month instead of once every 5 years. Extensive automated tests should help a lot. In the near feature "Windows Subsystem for Linux" will have USB support so problem will be easily solved running linux builds on windows systems.

[clepple]

I'm not sure I explained the merge issue properly. Due to imprecise specification of the merge points (the Windows port was done when we were using SVN), there are copies of trunk/master commits on the Windows port branch. If we merge those two branches, we get those copies in the master branch, and then we have to sift through those when bisecting to find regressions. This is independent of any automated tests that we might do - it is a basic code quality issue.

[bitmk2]

Git will take care of these issues. Parts which have been modified both in master and windows-branch and differ, will be marked as a conflict. I have already done that and now I have to manually resolve 30 files, which is feasible. Maybe I do not fully understand what you are talking about.

[clepple]

Git will take care of these issues only if the history is sound. If not, it will effectively revert master commits that happened while each of the trunk-to-windows merges were being sorted out. I forget whether the SVN merge revprop was not available at the time, or if the metadata was not accurate, but either way, we gave up on trying to fix the windows-port branches during the reposurgeon Git conversion because we could not determine the extent of the history damage, and the rest of the project needed to move on.

You mentioned automated testing. What would be helpful is to grab a list of the packages that you used to successfully compile, so that we can set up something to build the existing Windows branch automatically. Then we can use that setup to also build and test a new Windows branch that is unencumbered by the broken history. Several people have also proposed new approaches, such as the abstraction layer mentioned in #5, and making the code compile for both 32-bit and 64-bit Windows. Could you please post your build environment details on issue #5?