Securing connections with SSL not working on Solaris 10 x86

[tmcneill30]

I have compiled versions 2.6.5, 2.7.1 & 2.7.3 and have been unable to implement ssl encryption between upsd and the other processes such as upsmon etc on Solaris 10.

My target machine and build server are running Solaris 10/08 running in 32 bit mode. Both servers are recently patched. All other nut functionality is working fine on target server. I am compiling with gcc, gmake, etc.

My configure command is:

./configure  --with-ssl --with-openssl --with-wrap --with-logfacility=LOG_DAEMON \
    --with-openssl-includes=-I/usr/include:/usr/local/ssl/include/openssl \
    --with-openssl-libs='-L/usr/lib:/usr/sfw/lib:/usr/local/ssl/lib -lssl -lcrypto' \
    --with-group=ups --with-user=root \
    --with-snmp-libs=/usr/sfw/lib --with-snmp=no --with-usb=no

make && make install

Configure reports that all ssl libraries are found. /usr/local/ssl contains a build of openssl 1.0.1p. My openssl was used to create the certificate and works well with other packages I have on the system such as ntp and ssh.

I have followed the instructions in the documentation in section 9.5 "Configuring SSL". I created upsd.pem and a certificate using instructions in documentation.

I changed the following configuration entries

upsd.conf: CERTFILE /usr/local/ups/etc/upsd.pem
upsmon.conf: CERTPATH /usr/local/ups/etc/certs
upsmon.conf: FORCESSL 1

I also compiled and made a 2.7.3 and 2.7.1 nut package for RHEL 6. When I change above config settings and use the exact same cert and key, the upsmon to upsd connection is encrypted!! I verified this thru packet sniffing and upmon itself now states it is using ssl. So I know my Solaris problem is not with the certficate files nor with my understanding of how to configure NUT.

ldd on upsd on rhel6 and solaris both list ssl shared objects as dependencies.

upsmon and upsd debugging show that upsmon says hello and upsd does not understand the hello. It should say hello back and then send its certificate. This occurs on RHEL6 but the ssl handshake fails immediately on Solaris 10/08.

UPS: power0@localhost (master) (power value 1)
   0.000207     UPS: ups0@localhost (master) (power value 1)
   0.000572     Using power down flag file /var/state/ups/killpower
   0.001068     debug level is '2'
   0.008958     Trying to connect to UPS [power0@localhost]
   0.011489     SSL_connect do not accept handshake.: Error 0
   0.011585     ssl_error() EOF from client
   0.011617     Can not connect to localhost in SSL, disconnect
   0.011825     UPS [power0@localhost]: connect failed: SSL error: error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure
   0.011876     do_notify: ntype 0x0005 (COMMBAD)
   0.011899     Communications with UPS power0@localhost lost
   0.013125     Trying to connect to UPS [ups0@localhost]
   0.015265     SSL_connect do not accept handshake.: Error 0
   0.015355     ssl_error() EOF from client
   0.015379     Can not connect to localhost in SSL, disconnect

Open config.txt in wordpad or vi. This is config.log.

[tmcneill30]

config.txt

[clepple]

So is the problem limited to a Solaris upsmon talking to a Solaris upsd, or are there issues interoperating between Solaris and RHEL as well? The version of OpenSSL on RHEL might be useful as well.

Also, if you are debugging the SSL handshake, upsc might be easier than upsmon to debug, although I don't think it enforces SSL since it is not sending passwords.

I'm wondering if TLSv1_server_method() is not compatible with the defaults in newer OpenSSL. Ideally, we would use TLS_server_method(), but that isn't available until OpenSSL 1.1.0. What if you change it to TLSv1_2_server_method() in https://github.com/networkupstools/nut/blob/v2.7.3/server/netssl.c#L392 ?

[tmcneill30]

HI Charles,

Thanks for your response. I haven’t had time yet to test/research some of your questions. I haven’t tried connecting to a Solaris upsmon to a RHEL upsd. We are not interested in doing that but I will try it for your troubleshooting benefit.

I can tell you Solaris upsc also fails to connect to Solaris upsmon. It fails in the same way, with a failed ssl handshake. Once again upsd fails to recognize its an ssl connection and throws its fails to send back a server hello and its certificate.

The openssl version on my RHEL system is 1.0.1e. It is the latest ssl package provided by Red Hat ( or was a couple months ago). On the solaris side we have 1.01.f. I hope to get back to you on Tuesday with more info. Would love to figure this out. We are a defense contractor and this is an security item that our client want us to fix.

(trimmed)

[clepple]

Thanks for your response. I haven’t had time yet to test/research some of your questions. I haven’t tried connecting to a Solaris upsmon to a RHEL upsd. We are not interested in doing that but I will try it for your troubleshooting benefit.

Understood that it is not the deliverable configuration, but it is a good consistency check. A quicker test is to just run the RHEL upsc against the Solaris upsd - no extra configuration needed. Solaris upsc to RHEL upsd might also shed some light on the SSL handshake issue.

For future reference, this is how cURL handles things: https://github.com/bagder/curl/blob/master/lib/vtls/openssl.c#L1670

I can tell you Solaris upsc also fails to connect to Solaris upsmon. It fails in the same way, with a failed ssl handshake. Once again upsd fails to recognize its an ssl connection and throws its fails to send back a server hello and its certificate.

Thanks for confirming that.

The openssl version on my RHEL system is 1.0.1e. It is the latest ssl package provided by Red Hat ( or was a couple months ago). On the solaris side we have 1.01.f. I hope to get back to you on Tuesday with more info. Would love to figure this out. We are a defense contractor and this is an security item that our client want us to fix.

Is NSS/NSPR a viable alternative to OpenSSL in your application?

A bit of background: NUT has had OpenSSL-based SSL support in the source code for years, but due to some licensing complications https://people.gnome.org/~markmc/openssl-and-the-gpl.html, it didn't make it into many packaging systems. Eventually, NSS-based SSL support was added as an option, and that's what goes into the Debian/Ubuntu packages (and probably others). The OpenSSL code in NUT still compiles, but it was written for a much older version of OpenSSL, and it is not exercised often.

(I am not a lawyer; views are my own and not necessarily my employer's; etc.)

[tmcneill30]

Sorry about the delay. I’m the usual almost overwhelmed systems engineer.

With certificates enabled, I ran a Solaris upsc against a RHEL upsd. I did not receive a handshake failure. Rather it said connected with ssl.

I then ran a RHEL upsc against a Solaris upsd and received the usual ssl handshake failure. Once again, the handshake blows up right away. The server receives the hello and throws an error. It never sends a hello or the certificate back.

I recompiled 2.7.3 with the change you suggested in netssl.c. Change TLSv1 to TLSv2 in:

if ((ssl_method = TLSv1_server_method()) == NULL)

This failed to compile. It wasn’t able to identify the function TLSv2_server_method.

/bin/sh ../libtool  --tag=CC    --mode=link gcc -I../include  -I/usr/include:/usr/local/ssl/include/openssl -g -O2 -Wall -Wsign-compare -D_REENTRANT    -o upsd upsd.o user.o conf.o  netssl.o sstate.o desc.o  netget.o netmisc.o netlist.o  netuser.o netset.o netinstcmd.o ../common/libcommon.la ../common/libparseconf.la   -lnsl  -lwrap -L/usr/lib:/usr/sfw/lib:/usr/local/ssl/lib -lssl -lcrypto -lrt -lsocket -lnsl
libtool: link: gcc -I../include -I/usr/include:/usr/local/ssl/include/openssl -g -O2 -Wall -Wsign-compare -D_REENTRANT -o upsd upsd.o user.o conf.o netssl.o sstate.o desc.o netget.o netmisc.o netlist.o netuser.o netset.o netinstcmd.o  ../common/.libs/libcommon.a ../common/.libs/libparseconf.a -lwrap -L/usr/lib:/usr/sfw/lib:/usr/local/ssl/lib -lssl -lcrypto -lrt -lsocket -lnsl
Undefined                       first referenced
symbol                             in file
TLSv2_server_method                 netssl.o
ld: fatal: symbol referencing errors. No output written to upsd

I am wondering if NUT is linking to the older ssl system libraries that are present on my system. Openssl 1.0.1p is installed in /usr/local/ssl. As you can see that path is what is referenced in the failing libtool command.

Yet when I perform on ldd on successfully compiled upsd, I get

-bash-3.2$ ldd upsd
        libwrap.so.1 =>  /usr/sfw/lib/libwrap.so.1
        libssl.so.0.9.7 =>       /usr/sfw/lib/libssl.so.0.9.7
        libcrypto.so.0.9.7 =>    /usr/sfw/lib/libcrypto.so.0.9.7
        librt.so.1 =>    /usr/lib/librt.so.1
        libsocket.so.1 =>        /usr/lib/libsocket.so.1
        libnsl.so.1 =>   /usr/lib/libnsl.so.1
        libc.so.1 =>     /usr/lib/libc.so.1
        libaio.so.1 =>   /usr/lib/libaio.so.1
        libmd.so.1 =>    /usr/lib/libmd.so.1
        libmp.so.2 =>    /usr/lib/libmp.so.2
        libscf.so.1 =>   /usr/lib/libscf.so.1
        libdoor.so.1 =>  /usr/lib/libdoor.so.1
        libuutil.so.1 =>         /usr/lib/libuutil.so.1
        libgen.so.1 =>   /usr/lib/libgen.so.1
        libssl_extra.so.0.9.7 =>         /usr/sfw/lib/libssl_extra.so.0.9.7
        libcrypto_extra.so.0.9.7 =>      /usr/sfw/lib/libcrypto_extra.so.0.9.7
        libm.so.2 =>     /usr/lib/libm.so.2

I’m expecting references to /usr/local/ssl not usr/lib. At every turn, I’ve taken care to specify the ssl path as /usr/local/ssl.

I have the following ssl packages on my system. I’m hesitant to remove the system ones.

pkginfo |grep -i ssl
application OpenSSL_1-0-1p-fips209           OpenSSL
system      SUNWopenssl-commands             OpenSSL Commands (Usr)
system      SUNWopenssl-include              OpenSSL Header Files
system      SUNWopenssl-libraries            OpenSSL Libraries (Usr)
system      SUNWopenssl-man                  OpenSSL Manual Pages
system      SUNWopensslr                     OpenSSL (Root)

If this is the issue, I don’t know who to fix it. My configure command uses the ssl flags to tell it where to find it (as evidenced above). My PKG_CONFIG_PATH has /usr/local/ssl first.

I do note that the nss package is installed on our working RHEL server. Whereas nss is not installed on the Solaris side. Our IA guy, says that installing nss is not an acceptable solution.

(trimmed)

[clepple]

With certificates enabled, I ran a Solaris upsc against a RHEL upsd. I did not receive a handshake failure. Rather it said connected with ssl.

Thanks, this is a good sanity check on the client side of the Solaris SSL library.

I recompiled 2.7.3 with the change you suggested in netssl.c. Change TLSv1 to TLSv2 in: if ((ssl_method = TLSv1_server_method()) == NULL) This failed to compile. It wasn’t able to identify the function TLSv2_server_method.

Not quite "TLSv2":

TLSv1_2_server_method()

The name "TLSv1_2" comes from "TLS v1.2", but it is munged into a C-compatible namespace.

libtool: link: gcc -I../include -I/usr/include:/usr/local/ssl/include/openssl -g -O2 -Wall -Wsign-compare -D_REENTRANT -o upsd upsd.o user.o conf.o netssl.o sstate.o desc.o netget.o netmisc.o netlist.o netuser.o netset.o netinstcmd.o ../common/.libs/libcommon.a ../common/.libs/libparseconf.a -lwrap -L/usr/lib:/usr/sfw/lib:/usr/local/ssl/lib -lssl -lcrypto -lrt -lsocket -lnsl [...]

I am wondering if NUT is linking to the older ssl system libraries that are present on my system. Openssl 1.0.1p is installed in /usr/local/ssl. As you can see that path is what is referenced in the failing libtool command.

It's been a while since I used the Solaris compiler/linker, but I think that the "-L" flags are parsed left-to-right (assuming they don't need to be split up into multiple -L arguments: "-L/usr/local/ssl/lib -L/usr/sfw/lib") so it might be searching /usr/sfw/lib first.

[clepple]

https://en.wikipedia.org/wiki/OpenSSL says that TLSv1.2 was introduced in 1.0.1, so if the /usr/sfw/lib version is older, that makes sense. You might not even need to change the TLSv1_2_server_method() call, just rearrange the library search order.

[tmcneill30]

Thanks.

I did figure out how to re-order the Linking directories as you can see below. Unfortunately the compile still fails in the same way.

libtool: link: gcc -I../include -I/usr/local/ssl/include/openssl:/usr/sfw/include/ssl:/usr/include -g -O2 -Wall -Wsign-compare -D_REENTRANT -o upsd upsd.o user.o conf.o netssl.o sstate.o desc.o netget.o netmisc.o netlist.o netuser.o netset.o netinstcmd.o  ../common/.libs/libcommon.a ../common/.libs/libparseconf.a -lwrap -L/usr/local/ssl/lib:/usr/lib:/usr/sfw/lib -lssl -lcrypto -lrt -lsocket -lnsl
Undefined                       first referenced
symbol                             in file
TLSv1_2_server_method               netssl.o
ld: fatal: symbol referencing errors. No output written to upsd
collect2: ld returned 1 exit status
**\* Error code 1
make: Fatal error: Command failed for target `upsd'
Current working directory /export/home/pkgbuild/src/nut/nut-2.7.3/server

This surprised me since it is suppose to be finding the newer version of openssl. I haven’t been able to locate any mechanism for it secretly looking elsewhere for header files and libraries.

I have also noticed that the upsd binary looks specifically for libcrypto.so.0.9.7 and libssl.so.0.9.7. Whereas the newer variants are in libcrypto.a and libssl.a located in /usr/local/ssl/lib. But it doesn’t want these. I have noticed it is not trying the /usr/local/ssl/lib path. This path is not getting hard coded into upsd. I have tried everything from environment variables to C flags to change this but with no luck. But I don’t think that is relevant at this point because its specifically wanting libcrypto.so.0.9.7.

ldd -s upsd|more

   find object=libwrap.so.1; required by upsd
    search path=/usr/ccs/lib:/lib:/usr/lib:/usr/sfw/lib:/usr/local/ssl/lib  (RUNPATH
/RPATH from file upsd)
    trying path=/usr/ccs/lib/libwrap.so.1
    trying path=/lib/libwrap.so.1
    trying path=/usr/lib/libwrap.so.1
    trying path=/usr/sfw/lib/libwrap.so.1
        libwrap.so.1 =>  /usr/sfw/lib/libwrap.so.1

   find object=libssl.so.0.9.7; required by upsd
    search path=/usr/ccs/lib:/lib:/usr/lib:/usr/sfw/lib:/usr/local/ssl/lib  (RUNPATH
/RPATH from file upsd)
    trying path=/usr/ccs/lib/libssl.so.0.9.7
    trying path=/lib/libssl.so.0.9.7
    trying path=/usr/lib/libssl.so.0.9.7
    trying path=/usr/sfw/lib/libssl.so.0.9.7
        libssl.so.0.9.7 =>       /usr/sfw/lib/libssl.so.0.9.7

   find object=libcrypto.so.0.9.7; required by upsd
    search path=/usr/ccs/lib:/lib:/usr/lib:/usr/sfw/lib:/usr/local/ssl/lib  (RUNPATH
/RPATH from file upsd)
    trying path=/usr/ccs/lib/libcrypto.so.0.9.7
    trying path=/lib/libcrypto.so.0.9.7
    trying path=/usr/lib/libcrypto.so.0.9.7
    trying path=/usr/sfw/lib/libcrypto.so.0.9.7
        libcrypto.so.0.9.7 =>    /usr/sfw/lib/libcrypto.so.0.9.7

So its clear that my upsd is using the 0.9.7 version of ssl. If this is the case, why is it failing if its meant to work with older versions of openssl?

I was wondering if the problem was that it was including header files from 1.0.1p and then trying to work with 0.9.7. So I stripped out every reference of /usr/local/ssl/lib from every flag and environment variable. I then installed my package with my certs. Sadly the upsc and upmon connections still failed. So this appears to not work with ssl 0.9.7 which would rule out the problem being with ssl being newer. Remember these are the very cert files and config file settings that succeed with my linux package.

(trimmed)

[clepple]

search path=/usr/ccs/lib:/lib:/usr/lib:/usr/sfw/lib:/usr/local/ssl/lib (RUNPATH /RPATH from file upsd)

Something is still putting /usr/sfw/lib first in RUNPATH/RPATH, though.

So its clear that my upsd is using the 0.9.7 version of ssl. If this is the case, why is it failing if its meant to work with older versions of openssl?

The problem is that while there is a window of OpenSSL versions where we can expect that things would work (i.e. NUT uses TLS v1.0 support, which apparently hasn't been deprecated in OpenSSL yet - but NUT's SSL code predates the introduction of TLS v1.2), that doesn't mean that it will automatically work once those conditions are satisfied.

I'm willing to believe that there is a bug in NUT's OpenSSL implementation (see also https://github.com/networkupstools/nut/issues/202), but it works in Linux, so I suspect a subtle difference in Solaris system call semantics (or possibly in the versions you are linking against - but I think we are close to pinning that down).

At this point, some more runtime log information would be helpful. I think you sent some client-side information: what about on the server side? Can you sanitize some of the packet captures?

[tmcneill30]

Here is the debug output from Solaris upsd when a connection is attempted by (.150) upsmon

./upsd -DD

25.954192 write: [destfd=6] [len=12] [OK STARTTLS] 25.956692 Unknown return value from SSL_accept: Resource temporarily unavailable 25.956883 ssl_error() ret=-1 SSL_ERROR_WANT_READ 25.957055 mainloop: polling 2 filedescriptors 25.957510 Disconnect 192.168.72.150 (read failure): No such file or directory 25.959629 Disconnect from 192.168.72.150

Debug output from upsmon trying to connect to upsd (.121)

./upsmon -DD

Network UPS Tools upsmon 2.7.3 kill: No such process 0.000000 UPS: power0@192.168.72.121 (master) (power value 1) 0.000117 Using power down flag file /usr/local/ups/etc/killpower 0.000126 Using power down flag file /var/state/ups/killpower 0.000258 debug level is '2' 0.012876 Trying to connect to UPS [power0@192.168.72.121] 0.014393 SSL_connect do not accept handshake.: Success 0.014408 ssl_error() EOF from client 0.014414 Can not connect to 192.168.72.121 in SSL, disconnect 0.014574 UPS [power0@192.168.72.121]: connect failed: SSL error: error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure 0.014587 do_notify: ntype 0x0005 (COMMBAD) 0.014592 Communications with UPS power0@192.168.72.121 lost

Attached are the 6 packets generated by upsmon’s attempt to connect with upsd. The packet sniffer on Solaris 10 is snoop which is a variant of tcpdump. The proper way to read the output is to save to a file and then read that file with the snoop program. I have outputted the payload of each packet to the attached txt and docx file. All the data (header and payload) are contained in the binary file. The file can be read in wireshark or if you have access to snoop or tcpdump. The snoop command is “snoop –i binary-version –x0” to read the payloads. Snoop –i binary-version –V – for headers.

Question: When my Linux upsmon is able to connect locally to upsd, why does it say Certificate Verification is Disabled?

0.003453 Trying to connect to UPS [power0@localhost] 0.019824 Connected to localhost in SSL 0.019845 Certificate verification is disabled 0.020491 Logged into UPS power0@localhost

As an additional help I’ve included the tcpdump file for the successful linux connection. Its upsmon connecting to upsd over 127.0.0.1:3493. Its called Linux-success. I can see the certificate being passed over. And my password no longer being visible.

Tcpdump file can be viewed in wireshark.

One final note: My Solaris upsmon is now failing to connect to the Linux upsd. However it gets a bit farther in the handshake.

./upsmon –D

0.014075 Trying to connect to UPS [power0@159.62.74.88] 0.022129 Unknown return value from SSL_connect -1: Error 0 0.023805 ssl_error() ret=-1 SSL_ERROR 1 0.025522 Can not connect to 159.62.74.88 in SSL, disconnect 0.027593 UPS [power0@159.62.74.88]: connect failed: SSL error: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed 0.029192 Communications with UPS power0@159.62.74.88 lost Broadcast Message from root (pts/5) on JRE-SVR10168 Wed Dec 23 23:29:16... Communications with UPS power0@159.62.74.88 lost 5.045691 Trying to connect to UPS [power0@159.62.74.88] 5.048924 Unknown return value from SSL_connect -1: Error 0 5.048998 ssl_error() ret=-1 SSL_ERROR 1 5.049106 Can not connect to 159.62.74.88 in SSL, disconnect 5.049581 UPS [power0@159.62.74.88]: connect failed: SSL error: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed 5.049649 UPS power0@159.62.74.88 is unavailable

./upsd -D

9.214212 SSL_accept do not accept handshake.: Success 9.214264 ssl_error() ret=0 SSL_ERROR 1 9.214288 ssl_debug: error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca

(trimmed)

1 0.00000 192.168.72.150 -> JRE-SVR10168 TCP D=3493 S=42979 Syn Seq=1048990410 Len=0 Win=14600 Options=<mss 1460,sackOK,tstamp 2517451091 0,nop,wscale 7>

   0: 0050 56b4 6f47 0050 56b4 542d 0800 4500    .PV.oG.PV.T-..E.
  16: 003c 1399 4000 4006 14c3 c0a8 4896 c0a8    .<..@.@.....H...
  32: 4879 a7e3 0da5 3e86 52ca 0000 0000 a002    Hy....>.R.......
  48: 3908 de5d 0000 0204 05b4 0402 080a 960d    9..]............
  64: 4153 0000 0000 0103 0307                   AS........

2 0.00030 192.168.72.150 -> JRE-SVR10168 TCP D=3493 S=42979 Ack=1553768145 Seq=1048990411 Len=0 Win=115 Options=<nop,nop,tstamp 2517451091 500688583>

   0: 0050 56b4 6f47 0050 56b4 542d 0800 4500    .PV.oG.PV.T-..E.
  16: 0034 139a 4000 4006 14ca c0a8 4896 c0a8    .4..@.@.....H...
  32: 4879 a7e3 0da5 3e86 52cb 5c9c 9ed1 8010    Hy....>.R.\.....
  48: 0073 45a2 0000 0101 080a 960d 4153 1dd7    .sE.........AS..
  64: e6c7                                       ..

3 0.00000 192.168.72.150 -> JRE-SVR10168 TCP D=3493 S=42979 Push Ack=1553768145 Seq=1048990411 Len=9 Win=115 Options=<nop,nop,tstamp 2517451091 500688583>

   0: 0050 56b4 6f47 0050 56b4 542d 0800 4500    .PV.oG.PV.T-..E.
  16: 003d 139b 4000 4006 14c0 c0a8 4896 c0a8    .=..@.@.....H...
  32: 4879 a7e3 0da5 3e86 52cb 5c9c 9ed1 8018    Hy....>.R.\.....
  48: 0073 0643 0000 0101 080a 960d 4153 1dd7    .s.C........AS..
  64: e6c7 5354 4152 5454 4c53 0a                ..STARTTLS.

4 0.00050 192.168.72.150 -> JRE-SVR10168 TCP D=3493 S=42979 Ack=1553768157 Seq=1048990420 Len=0 Win=115 Options=<nop,nop,tstamp 2517451092 500688584>

   0: 0050 56b4 6f47 0050 56b4 542d 0800 4500    .PV.oG.PV.T-..E.
  16: 0034 139c 4000 4006 14c8 c0a8 4896 c0a8    .4..@.@.....H...
  32: 4879 a7e3 0da5 3e86 52d4 5c9c 9edd 8010    Hy....>.R.\.....
  48: 0073 458b 0000 0101 080a 960d 4154 1dd7    .sE.........AT..
  64: e6c8                                       ..

5 0.00016 192.168.72.150 -> JRE-SVR10168 TCP D=3493 S=42979 Push Ack=1553768157 Seq=1048990420 Len=155 Win=115 Options=<nop,nop,tstamp 2517451092 500688584>

   0: 0050 56b4 6f47 0050 56b4 542d 0800 4500    .PV.oG.PV.T-..E.
  16: 00cf 139d 4000 4006 142c c0a8 4896 c0a8    ....@.@..,..H...
  32: 4879 a7e3 0da5 3e86 52d4 5c9c 9edd 8018    Hy....>.R.\.....
  48: 0073 7284 0000 0101 080a 960d 4154 1dd7    .sr.........AT..
  64: e6c8 1603 0100 9601 0000 9203 0156 7afa    .............Vz.
  80: 4f33 3a7d 40e3 eca9 7474 3731 b182 e52c    O3:}@...tt71...,
  96: c278 b9f2 62de b196 3974 fcb7 4800 004c    .x..b...9t..H..L
 112: c014 c00a 0039 0038 0088 0087 c00f c005    .....9.8........
 128: 0035 0084 c013 c009 0033 0032 c012 c008    .5.......3.2....
 144: 009a 0099 0045 0044 0016 0013 c00e c004    .....E.D........
 160: c00d c003 002f 0096 0041 000a 0007 c011    ...../...A......
 176: c007 c00c c002 0005 0004 00ff 0100 001d    ................
 192: 000b 0004 0300 0102 000a 0008 0006 0019    ................
 208: 0018 0017 0023 0000 000f 0001 01           .....#.......

6 0.00044 192.168.72.150 -> JRE-SVR10168 TCP D=3493 S=42979 Fin Ack=1553768158 Seq=1048990575 Len=0 Win=115 Options=<nop,nop,tstamp 2517451093 500688584>

   0: 0050 56b4 6f47 0050 56b4 542d 0800 4500    .PV.oG.PV.T-..E.
  16: 0034 139e 4000 4006 14c6 c0a8 4896 c0a8    .4..@.@.....H...
  32: 4879 a7e3 0da5 3e86 536f 5c9c 9ede 8011    Hy....>.So\.....
  48: 0073 44ed 0000 0101 080a 960d 4155 1dd7    .sD.........AU..
  64: e6c8                                       ..

[tmcneill30]

Attached is truss output for upsd. I ran a upsc power0@localhost and captured how upsd reacted.

Other than seeing STARTTLS in there, it doesn’t mean much to me.

[clepple]

Here is the debug output from Solaris upsd when a connection is attempted by (.150) upsmon

./upsd -DD

25.954192 write: [destfd=6] [len=12] [OK STARTTLS] 25.956692 Unknown return value from SSL_accept: Resource temporarily unavailable 25.956883 ssl_error() ret=-1 SSL_ERROR_WANT_READ

Ah, this does look like issue https://github.com/networkupstools/nut/issues/202

What confuses me is that the code should not get that error there - the file descriptor comes from select(), so it should be ready to read. (I think a short read is a different error code.)

I will try to look at this over the holidays.

Attached are the 6 packets generated by upsmon’s attempt to connect with upsd.

This might not be necessary, but note that none of your attachments are getting through to Github, only the text of your reply: https://github.com/networkupstools/nut/issues/246#issuecomment-167008728

Question: When my Linux upsmon is able to connect locally to upsd, why does it say Certificate Verification is Disabled?

https://github.com/networkupstools/nut/blob/master/clients/upsclient.c#L1041 and search for CERTVERIFY here: http://www.networkupstools.org/docs/man/upsmon.conf.html

[clepple]

@tmcneill30 please try this patch: https://github.com/networkupstools/nut/commit/f098486803921b8899d4172fff97846428d82c12

@aquette does the Ubuntu QA test cover SSL? Can you please run it with this patch to make sure I didn't break anything? The SSL_accept fix mostly targets the OpenSSL side, but there is one case for a zero-length read.

[tmcneill30]

Thanks for the patch. However it doesn’t compile.

The problem is a change you made in upsd.c, namely,

upsdebugx(2, "write: [destfd=%d] [len=%d] [%s]", client->sock_fd, len, str_rtrim(ans, '\n'));

This line generates a symbol not found error. Undefined first referenced symbol in file str_rtrim upsd.o ld: fatal: symbol referencing errors. No output written to upsd

Did you mean str_trim? I say this because I don’t get any google hits for str_rtrim, but I do for str_trim. The str_rtrim function call doesn’t exist in the original version of upsd.c.

Tom

(trimmed)

[tmcneill30]

Compilation attempts with str_trim and strtrim also fail. I’m not a C developer hence I’m just guessing with these function names.

(trimmed)

[clepple]

The problem is a change you made in upsd.c, namely,

upsdebugx(2, "write: [destfd=%d] [len=%d] [%s]", client->sock_fd, len, str_rtrim(ans, '\n'));

I don't see that particular line in the patch. Are you grabbing the whole source tree from that revision? (I was thinking that you might want to minimize the number of lines changed from the base 2.7.3 version - the patch should be standalone, although I haven't tried that yet.)

If you are using the whole Git source tree at f098486, you might need to re-run autogen.sh and configure, since a few files have been added since then (in particular, common/str.c has str_rtrim() and company).

[clepple]

the patch should be standalone

Confirmed that it builds on OS X.

If you download this, you can apply it to a 2.7.3 tree with "patch -p1 < f098486803921b8899d4172fff97846428d82c12.diff":

https://github.com/networkupstools/nut/commit/f098486803921b8899d4172fff97846428d82c12.diff

[aquette]

@clepple : sadly no, the Ubuntu QA test (also available in Debian) doesn't cover SSL yet. Part of the planned things for when NSS would be compiled in (already the case since 2.7.1-1)

[tmcneill30]

I had copied the entire files for netssl.c and upsd.c from github. I am not using git but rather the source tar for version 2.7.3. My brain lock for plugging in files from HEAD. Thanks for solving that for me.

Now that I have patched the 2.7.3 files instead, the compile succeeds. Unfortunately the ssl connection is still broken.

Here is what the debug output was:

-bash-3.2# ./upsmon -D Network UPS Tools upsmon 2.7.3 kill: No such process 0.000000 UPS: power0@localhost (master) (power value 1) 0.001277 UPS: ups0@localhost (master) (power value 1) 0.002841 Using power down flag file /var/state/ups/killpower 0.099623 debug level is '1' 0.111095 Trying to connect to UPS [power0@localhost] 0.120900 Unknown return value from SSL_connect -1: Error 0 0.121987 ssl_error() ret=-1 SSL_ERROR 1 0.123122 Can not connect to localhost in SSL, disconnect 0.124566 UPS [power0@localhost]: connect failed: SSL error: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed 0.125569 Communications with UPS power0@localhost lost 0.127137 Trying to connect to UPS [ups0@localhost] 0.135478 Unknown return value from SSL_connect -1: Error 0 0.136565 ssl_error() ret=-1 SSL_ERROR 1 0.137583 Can not connect to localhost in SSL, disconnect 0.139024 UPS [ups0@localhost]: connect failed: SSL error: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed 0.140222 Communications with UPS ups0@localhost lost

bash-3.2# ./upsd -D Network UPS Tools upsd 2.7.3 0.000000 fopen /var/state/ups/upsd.pid: No such file or directory 0.003991 listening on 0.0.0.0 port 3493 0.006187 /var/state/ups is world readable 0.008549 Can't connect to UPS power0: No such file or directory 24.935220 ssl_error() ret=-1 SSL_ERROR_WANT_READ 24.938237 ssl_error() ret=-1 SSL_ERROR_WANT_READ 24.940071 ssl_error() ret=-1 SSL_ERROR 1 24.940325 ssl_debug: error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca 24.940454 ssl_debug: error:140940E5:SSL routines:SSL3_READ_BYTES:ssl handshake failure 24.949531 ssl_error() ret=-1 SSL_ERROR_WANT_READ 24.951322 ssl_error() ret=-1 SSL_ERROR_WANT_READ 24.954868 ssl_error() ret=-1 SSL_ERROR 1 24.955083 ssl_debug: error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca 24.955271 ssl_debug: error:140940E5:SSL routines:SSL3_READ_BYTES:ssl handshake failure

(trimmed)

[clepple]

24.940325 ssl_debug: error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca 24.940454 ssl_debug: error:140940E5:SSL routines:SSL3_READ_BYTES:ssl handshake failure

Is the CA certificate (and any intermediates, if applicable) included in CERTFILE?

[tmcneill30]

Yes. I created the certificates following the instructions listed in section 9.5 of the NUT documentation. http://www.networkupstools.org/docs/user-manual.chunked/ar01s09.html#_configuring_ssl

Keep in mind that moving the exact same certificate files to my rhel server, I see no errors in debug mode and I confirmed thru packet sniffing that the connection between a local uspmon and upsd was indeed encrypted.

I rechecked my config files for my Solaris test and upsmon.conf and upsd.conf have the proper settings.

(trimmed)

[clepple]

I wonder if the "unknown ca" is really an expired certificate. At one point you mentioned that Solaris upsmon couldn't connect to the RHEL upsd. I don't know when the validity checks occur in OpenSSL. (The NUT instructions do mention that the default command lines will create certificates that expire in 30 days.)

(Also, when you reply by email, please trim off the previous text. GitHub apparently does not remove that automatically.)

[tmcneill30]

Good catch on the expired certificates but sadly after thorough re-testing I’m still getting the same message

-bash-3.2# ./upsmon –D Network UPS Tools upsmon 2.7.3 kill: No such process 0.000000 UPS: power0@localhost (master) (power value 1) 0.000134 UPS: ups0@localhost (master) (power value 1) 0.000360 Using power down flag file /var/state/ups/killpower 0.000731 debug level is '1' 0.008470 Trying to connect to UPS [power0@localhost] 0.015578 Unknown return value from SSL_connect -1: Error 0 0.015709 ssl_error() ret=-1 SSL_ERROR 1 0.015904 Can not connect to localhost in SSL, disconnect 0.016365 UPS [power0@localhost]: connect failed: SSL error: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed 0.016428 Communications with UPS power0@localhost lost 0.052170 Trying to connect to UPS [ups0@localhost] 0.057136 Unknown return value from SSL_connect -1: Error 0 0.058491 ssl_error() ret=-1 SSL_ERROR 1 0.059749 Can not connect to localhost in SSL, disconnect 0.061418 UPS [ups0@localhost]: connect failed: SSL error: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed 0.062690 Communications with UPS ups0@localhost lost

My retest consisted of: Creating new unexpired certificates. Testing them on my rhel system. They worked. (RHEL was throwing bad certificate messages on the old expired certificates). Re-downloaded the 2.7.3 source tar file. Re-applied your patch. Manually checked to make sure patch was truly applied to upsd.c and netssl.c. Re-made the package and installed it on my Solaris system. Thoroughly checked file and directory permissions on the certificates. Verified config files were set properly.

In summary, Solaris upsmon fails with above tracing, RHEL works fine with exact same certs. If you need any further info, let me know.

[clepple]

0.008470 Trying to connect to UPS [power0@localhost] 0.015578 Unknown return value from SSL_connect -1: Error 0 0.015709 ssl_error() ret=-1 SSL_ERROR 1

My mistake, it's the same blocking/non-blocking error on the client side.

This commit should be added on top of the previous one: https://github.com/networkupstools/nut/commit/213ee3d7e6eef697e3e113b074b87457023a4db0

However, I can't really test that here: OS X does not have the non-blocking issue on the client side. It is no worse with this patch, though.

[tmcneill30]

I added your upsclient.c patch to my build. Verified patch succeeded. Re-made package and re-installed.

I still get the below tracing when upsmon wants to connect locally with upsd.

-bash-3.2# ./upsmon -D Network UPS Tools upsmon 2.7.3 kill: No such process 0.000000 UPS: power0@localhost (master) (power value 1) 0.000147 UPS: ups0@localhost (master) (power value 1) 0.000408 Using power down flag file /var/state/ups/killpower 0.000747 debug level is '1' 0.010818 Trying to connect to UPS [power0@localhost] 0.018496 Unknown return value from SSL_connect -1: Error 0 0.018595 ssl_error() ret=-1 SSL_ERROR 1 0.018698 Can not connect to localhost in SSL, disconnect 0.019150 UPS [power0@localhost]: connect failed: SSL error: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed 0.019227 Communications with UPS power0@localhost lost 0.038963 Trying to connect to UPS [ups0@localhost] 0.043828 Unknown return value from SSL_connect -1: Error 0 0.045208 ssl_error() ret=-1 SSL_ERROR 1 0.046500 Can not connect to localhost in SSL, disconnect 0.048163 UPS [ups0@localhost]: connect failed: SSL error: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed 0.049529 Communications with UPS ups0@localhost lost

[clepple]

You might need to check with the OpenSSL developers, or a Solaris-specific forum.

[rgc2000]

Hi, Please can you try this very simple patch against nut-2.7.3. It will disable non-blocking sockets on Solaris for server (upsd). Then tell me if it works for you.

nut-2.7.3.solaris_ssl.patch.gz

[clepple]

It will disable non-blocking sockets on Solaris for server (upsd).

René, thanks for posting this, but isn't this patch is for the server listening socket? With the commits mentioned earlier in this issue, I think we have the server's client FD retrying. (Note that since the server is single-threaded, it shouldn't block - but the client API was written with the expectation that calls will block.)

Were you able to reproduce the error in upsmon or upsc?

[rgc2000]

I reproduced your problem on Solaris 10u11 and Solaris 11.3. I saw that problem comes from the server that closes the incoming connection with an unexpected error on the SSL_accept function. This is due to the lack of incoming data at this moment using non blocking sockets. Setting O_NDELAY on socket enables the non blocking IO behavior. This patch prevents setting this flag on server socket.

I have then tested upsc and upsmon successfully on Solaris using SSL

[clepple]

I reproduced your problem on Solaris 10u11 and Solaris 11.3. I saw that problem comes from the server that closes the incoming connection with an unexpected error on the SSL_accept function. This is due to the lack of incoming data at this moment using non blocking sockets.

Right, but this patch should allow the server to continue processing other events (rather than closing the connection):

https://github.com/networkupstools/nut/commit/f098486803921b8899d4172fff97846428d82c12

Setting O_NDELAY on socket enables the non blocking IO behavior. This patch prevents setting this flag on server socket.

I suspect that your patch will prevent the server from accepting multiple connections in quick succession. All of the other non-SSL server-side socket operations check to make sure it will not block first.

[rgc2000]

I've just tested patch f098486 and it looks to works fine on my Solaris with O_NDELAY socket flag set.

I haven't tested quick succession of connections. Just 2 client connections and running upsd with debug info I can see the mainloop trace with the number of filedescriptors increasing with clients.

[tmcneill30]

Hi rgc2000,

Thanks for reproducing and submitting a possible fix. Frustratingly, upsmon-upsd connection still produces a failed ssl handshake. Here is what the upsmon -D looks like

-bash-3.2$ sudo /usr/local/ups/sbin/upsmon -D Network UPS Tools upsmon 2.7.3 kill: No such process 0.000000 UPS: power0@localhost (master) (power value 1) 0.001242 UPS: ups0@localhost (master) (power value 1) 0.002939 Using power down flag file /var/state/ups/killpower 0.004561 debug level is '1' 0.015326 Trying to connect to UPS [power0@localhost] 0.024851 Unknown return value from SSL_connect -1: Error 0 0.026288 ssl_error() ret=-1 SSL_ERROR 1 0.027757 Can not connect to localhost in SSL, disconnect 0.029973 UPS [power0@localhost]: connect failed: SSL error: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed 0.031303 Communications with UPS power0@localhost lost 0.046528 Trying to connect to UPS [ups0@localhost] 0.051092 Unknown return value from SSL_connect -1: Error 0 0.052318 ssl_error() ret=-1 SSL_ERROR 1 0.053489 Can not connect to localhost in SSL, disconnect 0.055219 UPS [ups0@localhost]: connect failed: SSL error: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed 0.056437 Communications with UPS ups0@localhost lost

upsd -D looks like: -bash-3.2# ./upsd -D Network UPS Tools upsd 2.7.3 0.000000 fopen /var/state/ups/upsd.pid: No such file or directory 0.003053 listening on 0.0.0.0 port 3493 0.004899 /var/state/ups is world readable 0.006681 Can't connect to UPS power0: No such file or directory 18.613685 SSL_accept do not accept handshake.: Error 0 18.613913 ssl_error() ret=0 SSL_ERROR 1 18.614126 ssl_debug: error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca 18.639586 SSL_accept do not accept handshake.: Error 0 18.640664 ssl_error() ret=0 SSL_ERROR 1 18.640854 ssl_debug: error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca

I compiled with only your patch and also compiled with your patch + f098486. Output the same either way.

[rgc2000]

I don't know if this can make a difference but in my tests I have not enabled the tcpwrapper feature in configure. It is not available on my solaris machine. Can you try without it ?

[tmcneill30]

Not a bad thing to try. I removed --wrap from my configure command. Unfortunately upsmon -D output is still identical.

[rgc2000]

I really don’t understand. Both patches work for me. Could you, please, send me a tarball including the sources and binaries you compiled with —wrap removed (nut-sources directory). I would like to try it on my solaris.

René

Le 20 janv. 2016 à 02:29, tmcneill30 notifications@github.com a écrit :

Not a bad thing to try. I removed --wrap from my configure command. Unfortunately upsmon -D output is still identical.

— Reply to this email directly or view it on GitHub https://github.com/networkupstools/nut/issues/246#issuecomment-173052458.

[tmcneill30]

f098486.patch.txt nut-2.7.3.solaris_ssl.patch.txt patched-nut-2.7.3.tar.txt

Pardon the .txt appended to each filename. Its my first time using github and it says it won't accept .tar or anything linux. For some reason it refused the zip file I made even though that is supposed to be acceptable. (file size limitation?) the zip was only 8.5 MB.

Anyways, I"ve included the 2 patch files I made. One with your patch and the other from Clepple. I included my patched source (just to have you double check that my source was properly patched). I also included my package that was derived from that. (I have a build script that creates the package). My NUT compile relies on my openssl package which installs in /usr/local/ssl. That package is included.

Again here is the configure command I used. Note lack of --with-wrap. ./configure --with-ssl --with-openssl --with-logfacility=LOG_DAEMON --with-openssl-includes=-I/usr/local/ssl/include:/usr/include -with-openssl-libs='-L/usr/local/ ssl/lib:/usr/lib -lssl -lcrypto' --with-group=ups --with-user=root --with-snmp-libs=/usr/sfw/lib --with-snmp=no --with-usb=no

then the usual make && make install

The package includes the certificates and config files I am using. (If I get this working, I'll re-make my certificate) It also installs /etc/init.d/ups_nut.init. I haven't taken the time yet to move it from legacy to SMF.

Thank you for looking at these. Let me if you need anything further.

[rgc2000]

There is a problem with your compilation options, your binaries are not linked with your OpenSSL but with the system (and old) openssl located in /usr/sfw/lib

The SSL connexions work but the server certificate check fails. In upsmon.conf if you set CERTVERIFY 0 everything works fine.

I'm still investigating to understand why the certificate check fails. You are using a self-signed certificate for your server. I tried with a root CA and a server cert and it fails too using your binaries. It works with my binaries but I'm not using /usr/sfw openssl libs.

Next step : I will recompile your wineries with your sources and your options but I will ensure that your OpenSSL is used.

[clepple]

Note lack of --with-wrap.

I think this is tangential to the SSL issue, but note that in ./configure option parsing, the lack of an option allows the script to auto-detect the library or feature. You might want --without-wrap or --with-wrap=no.

[rgc2000]

SSL test results for nut-2.7.3 and patch f098486 on solaris 10 (32 or 64 bits)

• without libwrap : SSL connection OK with CERTVERIFY 1, upsc can't check server certificate
• with libwrap : SSL connection OK with CERTVERIFY 0, otherwise server certificate fails if set to 1 and SSL connection is closed (with error: tlsv1 alert unknown ca). Can't make it work with CERTVERIFY 1. upsc still can't check server certificate.

I guess that upsc can never check server certificates because it has no configuration file to make it search for trusted certificate authorities.

libwrap disturbs server certificate check but it still allows SSL connections.

Tests realized with OpenSSL 1.0.1q, 1.0.2e and the one in solaris directory /usr/sfw (0.9.7d) tcp-wrappers is the one in solaris directory /usr/sfw

[clepple]

Is libwrap altering the linker flags?

[rgc2000]

You are right. --with-wrap changes the library path order at compile time and thus it always links with the libssl located in /usr/sfw/lib

I managed to use configure options to make it use the libraries I want and now everything works (except server certificate verify with upsc as this is only available with nss, not openssl)

So. tmcneil30, to compile and openssl to match your needs :

export LD_RUN_PATH=/usr/local/ups/lib:/usr/local/ssl/lib:/usr/sfw/lib ./Configure -DPIC -fPIC --prefix=/usr/local/ssl --openssldir=/usr/local/ssl/etc zlib-dynamic shared solaris-x86-gcc make (then as root) make MANDIR=/usr/local/ssl/share/man MANSUFFIX=ssl install

The to compile NUT with f098486 patch included : export LD_RUN_PATH=/usr/local/ups/lib:/usr/local/ssl/lib:/usr/sfw/lib ./configure --with-ssl --with-openssl --with-logfacility=LOG_DAEMON --with-group=ups --with-user=root --with-snmp-libs=/usr/sfw/lib --with-wrap --with-snmp=no --with-usb=no --prefix=/usr/local/ups CFLAGS="-I/usr/local/ssl/include -I/usr/sfw/include" LDFLAGS="-L/usr/local/ssl/lib -L/usr/sfw/lib" make (the as root) make install

You can remove LD_LIBRARY_PATH stuff in your init script, as it will no longer be needed thanks to LD_RUN_PATH set at compile time.

ldd /usr/local/ups/sbin/upsmon libupsclient.so.4 => /usr/local/ups/lib/libupsclient.so.4 libssl.so.1.0.0 => /usr/local/ssl/lib/libssl.so.1.0.0 libcrypto.so.1.0.0 => /usr/local/ssl/lib/libcrypto.so.1.0.0 librt.so.1 => /lib/librt.so.1 libsocket.so.1 => /lib/libsocket.so.1 libnsl.so.1 => /lib/libnsl.so.1 libc.so.1 => /lib/libc.so.1 libgcc_s.so.1 => /usr/sfw/lib/libgcc_s.so.1 libdl.so.1 => /lib/libdl.so.1 libaio.so.1 => /lib/libaio.so.1 libmd.so.1 => /lib/libmd.so.1 libmp.so.2 => /lib/libmp.so.2 libscf.so.1 => /lib/libscf.so.1 libdoor.so.1 => /lib/libdoor.so.1 libuutil.so.1 => /lib/libuutil.so.1 libgen.so.1 => /lib/libgen.so.1 libm.so.2 => /lib/libm.so.2

Using solaris libssl in /usr/srw/lib makes upsmon fail in certificate verify when compiling with libwrap

[tmcneill30]

Rene - thank you for figuring this out. Especially for compiling --with-wrap. That is a requirement for me. I haven't had time to test your instructions, but will soon and will report back my results.

question - are the patches still necessary?

[rgc2000]

Yes upsd patch f098486 is needed to establish incoming ssl connections. I didn't mention that I've been using gcc to compile under Solaris.

[tmcneill30]

I've followed your instructions and .... SUCCESS!! However I needed to apply not only the f09486 patch but the patch you sent me was well. If you haven't done so, I would commit that patch and post the number here. I was still getting ssl errors in upsd until I recompiled with your patch.

The LD_RUN_PATH was critical to getting the ups binaries to depend upon my newer ssl. I did need to re-compile ssl as you stated above.

Last question - do I hit the close button? How do I know the 2 patches will make it into the next version of NUT?

[clepple]

Last question - do I hit the close button? How do I know the 2 patches will make it into the next version of NUT?

My usual procedure is to close the issue when all of the patches are merged into master. At this point, that branch is slated to be the basis for the next release.

However, unless I missed an update, the O_NDELAY removal patch has the potential for a denial-of-service if someone only partially completes the SSL handshake.

[rgc2000]

I've followed your instructions and .... SUCCESS!! However I needed to apply not only the f09486 patch but the patch you sent me was well. If you haven't done so, I would commit that patch and post the number here. I was still getting ssl errors in upsd until I recompiled with your patch.

I did not apply the O_NDELAY removal patch. The f09486 patch against nut-2.7.3 was enough to make SSL work fine under Solaris. Please check again because it should work with only one of those patches, both are not needed.

[tmcneill30]

I re-checked and still get the same results. To recap: I re-compiled 2.7.3 with only the f09486 patch following above instructions. My ldd commands against upsmon look exactly like yours.

I start upsd -D and initially get this: -bash-3.2$ sudo /usr/local/ups/sbin/upsd -D Network UPS Tools upsd 2.7.3 0.000000 fopen /var/state/ups/upsd.pid: No such file or directory 0.002299 listening on 0.0.0.0 port 3493 0.002837 /var/state/ups is world readable

I then start upsmon: -bash-3.2$ sudo /usr/local/ups/sbin/upsmon -D Network UPS Tools upsmon 2.7.3 kill: No such process 0.000000 UPS: power0@localhost (master) (power value 1) 0.000157 UPS: ups0@localhost (master) (power value 1) 0.000457 Using power down flag file /var/state/ups/killpower 0.000902 debug level is '1' 0.020375 Trying to connect to UPS [power0@localhost] 0.047428 Connected to localhost in SSL 0.048919 Logged into UPS power0@localhost 0.049834 Poll UPS [power0@localhost] failed - Driver not connected 0.049885 Communications with UPS power0@localhost lost 0.051993 Trying to connect to UPS [ups0@localhost] 0.072135 Connected to localhost in SSL 0.073696 Login on UPS [ups0@localhost] failed - got [ERR UNKNOWN-UPS] 5.075487 Poll UPS [power0@localhost] failed - Driver not connected 5.075698 UPS power0@localhost is unavailable 5.080378 Poll UPS [ups0@localhost] failed - [ups0] does not exist on server localhost 5.080460 Communications with UPS ups0@localhost lost

Once upsmon connects, I get the following from upsd 10.415016 ssl_error() ret=-1 SSL_ERROR_WANT_READ 10.416700 ssl_error() ret=-1 SSL_ERROR_WANT_READ 10.435500 ssl_error() ret=-1 SSL_ERROR_WANT_READ 10.439147 User jreupsmon@127.0.0.1 logged into UPS power0 10.445059 ssl_error() ret=-1 SSL_ERROR_WANT_READ 10.446088 ssl_error() ret=-1 SSL_ERROR_WANT_READ 10.459232 ssl_error() ret=-1 SSL_ERROR_WANT_READ 24.428169 User jreupsmon@127.0.0.1 logged out from UPS power0

When I add in the O_NDELAY patch, the SSL errors do not appear.

[rgc2000]

I have tested your attached packages and I am running into the same error messages as you (SSL_ERROR_WANT_READ). When I am using my own compiled nut suite I don't have these error messages even with O_NDELAY enabled.

What gcc compiler are you using ? I am using my self compiled gcc 4.8.3

gcc -v

Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/opt/gnu/libexec/gcc/i386-pc-solaris2.10/4.8.3/lto-wrapper Target: i386-pc-solaris2.10 Configured with: ../gcc-4.8.3/configure --prefix=/opt/gnu --enable-languages=c,c++ --with-gmp=/opt/gnu --with-mpfr=/opt/gnu --without-gnu-ld --with-ld=/usr/ccs/bin/ld --with-gnu-as CFLAGS='-g -O2 -mtune=opteron -march=opteron' CXXFLAGS='-g -O2 -mtune=opteron -march=opteron' Thread model: posix gcc version 4.8.3 (GCC)

[tmcneill30]

-bash-3.2$ gcc -v Reading specs from /usr/sfw/lib/gcc/i386-pc-solaris2.10/3.4.3/specs Configured with: /builds/sfw10-gate/usr/src/cmd/gcc/gcc-3.4.3/configure --prefix=/usr/sfw --with-as=/usr/sfw/bin/gas --with-gnu-as --with-ld=/usr/ccs/bin/ld --without-gnu-ld --enable-languages=c,c++ --enable-shared Thread model: posix gcc version 3.4.3 (csl-sol210-3_4-branch+sol_rpath)

[tmcneill30]

I switched my c compiler to a newer one I had installed. Same result. Still get ssl errors from upsd upon a upsmon connection.

-bash-3.2$ gcc -v Reading specs from /opt/csw/lib/gcc/i386-pc-solaris2.10/4.9.2/specs COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/opt/csw/libexec/gcc/i386-pc-solaris2.10/4.9.2/lto-wrapper Target: i386-pc-solaris2.10 Configured with: /home/dam/mgar/pkg/gcc4/trunk/work/solaris10-i386/build-isa-pentium_pro/gcc-4.9.2/configure --prefix=/opt/csw --exec_prefix=/opt/csw --bindir=/opt/csw/bin --sbindir=/opt/csw/sbin --libexecdir=/opt/csw/libexec --datadir=/opt/csw/share --sysconfdir=/etc/opt/csw --sharedstatedir=/opt/csw/share --localstatedir=/var/opt/csw --libdir=/opt/csw/lib --infodir=/opt/csw/share/info --includedir=/opt/csw/include --mandir=/opt/csw/share/man --enable-cloog-backend=isl --enable-java-awt=xlib --enable-languages=ada,c,c++,fortran,go,java,objc --enable-libada --enable-libssp --enable-nls --enable-objc-gc --enable-threads=posix --program-suffix=-4.9 --with-cloog=/opt/csw --with-gmp=/opt/csw --with-included-gettext --with-ld=/usr/ccs/bin/ld --without-gnu-ld --with-libiconv-prefix=/opt/csw --with-mpfr=/opt/csw --with-ppl=/opt/csw --with-system-zlib=/opt/csw --with-gnu-as --with-as=/opt/csw/bin/gas Thread model: posix gcc version 4.9.2 (GCC)

Attached is my config.log. I don't use --prefix because I don't want 'make install' to install in /usr/local/ups. I instruct make install directly to install in a build directory. And then of course I am creating a package from there. Other than that, I believer our configure commands are the same, but maybe you can spot something in there. config.log.txt