topic Re: HP SSL & SO_KEEPALIVE + TCPWare-TCP in Operating System - OpenVMS

HP SSL & SO_KEEPALIVE + TCPWare-TCP

Ruslan R. Laishev — Fri, 07 Nov 2008 09:11:11 GMT

Hi All!

I have a some application wich use HP SSL API, it
1) accept an incomming TCP connection witj $QIO
2) Use SSL_set_fd(,decc$socket_fd (chan))
SSL_accept(...)
3) set setsockopt(decc$socket_fd (chan),SOL_SOCKET,SO_KEEPALIVE,&chan,sizeof(chan));

So, a KEEP Alive checking is expecting for the TCP connection. But I do not see zero-length packets for the connection.

Is the SSL disable SO_KEEPALIVE actualy, or something else ?

Re: HP SSL & SO_KEEPALIVE + TCPWare-TCP

Richard Whalen — Fri, 07 Nov 2008 11:15:51 GMT

Ruslan,

If you are using TCPware 5.7 or 5.8 (as the title says), then the following will help you determine if the socket has keepalive turned on or not.
$ define tw$sda tcpware:tcpware$sda
$ ana/sys
sda> tw show connections
!find the appropriate connection in the list
sda> tw show socket
If keepalive is set you will see it listed in the options.

I've done some programming using the SSL library, but have not been concerned whether or not keepalive was set. It's possible that SSL is transferring information frequently enough that there is no need for keepalive packets.

Re: HP SSL & SO_KEEPALIVE + TCPWare-TCP

Ruslan R. Laishev — Fri, 07 Nov 2008 11:34:47 GMT

Him Richard!

Thanks, I'll try to get some more information...

Re: HP SSL & SO_KEEPALIVE + TCPWare-TCP

Ruslan R. Laishev — Fri, 07 Nov 2008 11:41:26 GMT

SDA> tw sho sock 906ACAC0
scb at 906ACAC0 BG8623 lia 172.16.0.45 fia 172.16.0.4 lpn 995 fpn 11490
options REUSEADDR KEEPALIVE
state SOCKET CONNECTED PRIV tcp flags IDLE WSCALE tcp state ESTABLISHED cdb 88E2A100
Receive Queue 90826700 90826700, byte count 0
Transmit Queue 906ACB4C 906ACB4C, byte count 0
Transmit data buffer 00000000, Byte count 0
Hash table entry 88E2AC88, Hash Link 00000000
Allocated RTE address 88E273C0 Send Unack 2190122137, Send Max 2190122137 Send next 2190122137 Send High water 32676
send window size 4096, maximum 4096 congestion window 4380
offered receive window size 61440
probe idle 15 Drop idle 60
maximum segment size 1460, original MSS 1460, MTU 8134

SDA>

$ netcu debug /tcp /lpn=995 /ria=dtv4
DTV5::LAISHEV 14:38:32 NETCU CPU=00:02:41.96 PF=15746 IO=138792 MEM=314
DTV5::LAISHEV 14:38:53 NETCU CPU=00:02:41.96 PF=15748 IO=138793 MEM=316

Hmmm... It looks like that KeepAlive is set socket but there is not any zero-length packets...

$ netcu debug /tcp /lpn=995 /ria=dtv4
DTV5::LAISHEV 14:38:32 NETCU CPU=00:02:41.96 PF=15746 IO=138792 MEM=314
DTV5::LAISHEV 14:38:53 NETCU CPU=00:02:41.96 PF=15748 IO=138793 MEM=316
DTV5::LAISHEV 14:39:53 NETCU CPU=00:02:41.96 PF=15748 IO=138794 MEM=316
DTV5::LAISHEV 14:39:53 NETCU CPU=00:02:41.96 PF=15748 IO=138795 MEM=316

Re: HP SSL & SO_KEEPALIVE + TCPWare-TCP

Richard Whalen — Fri, 07 Nov 2008 15:46:42 GMT

Ruslan,

Unfortunately the SDA callouts don't show the actual information used in figuring out when to send a keepalive packet. The default value for when to send a keepalive packet would be the drop idle time * 5 seconds, so you have to wait at least 5 minutes to see if a keepalive is sent.

Re: HP SSL & SO_KEEPALIVE + TCPWare-TCP

Ruslan R. Laishev — Sat, 08 Nov 2008 08:55:33 GMT

Hi, Richard!

I spend 10+ minutes in hope that will catch keepalive checking.

$ netcu sho conn /loc=*.995
TCPware(R) for OpenVMS Active Internet Connections (including servers ) :

ID RecvQ SendQ Local Address Foreign Address State
-- ----- ----- ------------- --------------- -----
BG50578 0 0 172.16.0.8.pop3s 83.149.3.47.5518 ESTABLISHED
BG0 171 0 172.16.0.8.pop3s 172.16.1.24.20735 CLOSE-WAIT
BG0 96 0 172.16.0.8.pop3s 89.223.96.210.12175 CLOSE-WAIT
BG0 102 0 172.16.0.8.pop3s 172.16.1.9.4001 CLOSE-WAIT
BG0 78 0 172.16.0.8.pop3s 172.16.1.9.4007 CLOSE-WAIT
BG0 96 0 172.16.0.8.pop3s 83.149.3.86.53202 CLOSE-WAIT
BG44749 0 0 *.pop3s *.* LISTEN

$ netcu debug /tcp /ria=83.149.3.47 /rpn=5518
DTV1::SSHD 0843A PTD 11:35:03 NETCU CPU=00:00:00.18 PF=608 IO=610 MEM=296
New mail on node DTV5 from MX%"jcagey@mail2doctor.com" "=?koi8-r?B?7NXexdrB0iDlxtLFzQ==?=" (11:35:49)
DTV1::SSHD 0843A PTD 11:36:34 NETCU CPU=00:00:00.18 PF=608 IO=611 MEM=296
DTV1::SSHD 0843A PTD 11:38:46 NETCU CPU=00:00:00.18 PF=608 IO=612 MEM=296
DTV1::SSHD 0843A PTD 11:40:15 NETCU CPU=00:00:00.18 PF=608 IO=613 MEM=296
DTV1::SSHD 0843A PTD 11:40:15 NETCU CPU=00:00:00.18 PF=608 IO=614 MEM=296
DTV1::SSHD 0843A PTD 11:41:25 NETCU CPU=00:00:00.18 PF=608 IO=615 MEM=296
DTV1::SSHD 0843A PTD 11:42:59 NETCU CPU=00:00:00.18 PF=608 IO=616 MEM=296
DTV1::SSHD 0843A PTD 11:42:59 NETCU CPU=00:00:00.18 PF=608 IO=617 MEM=296
DTV1::SSHD 0843A PTD 11:45:31 NETCU CPU=00:00:00.18 PF=608 IO=618 MEM=296
DTV1::SSHD 0843A PTD 11:47:13 NETCU CPU=00:00:00.18 PF=608 IO=619 MEM=296
DTV1::SSHD 0843A PTD 11:47:41 NETCU CPU=00:00:00.18 PF=608 IO=620 MEM=296
Cancel

$ netcu sho conn /loc=*.995
TCPware(R) for OpenVMS Active Internet Connections (including servers ) :

ID RecvQ SendQ Local Address Foreign Address State
-- ----- ----- ------------- --------------- -----
BG50578 0 0 172.16.0.8.pop3s 83.149.3.47.5518 ESTABLISHED
BG0 171 0 172.16.0.8.pop3s 172.16.1.24.20735 CLOSE-WAIT
BG0 96 0 172.16.0.8.pop3s 89.223.96.210.12175 CLOSE-WAIT
BG0 102 0 172.16.0.8.pop3s 172.16.1.9.4001 CLOSE-WAIT
BG0 78 0 172.16.0.8.pop3s 172.16.1.9.4007 CLOSE-WAIT
BG0 96 0 172.16.0.8.pop3s 83.149.3.86.53202 CLOSE-WAIT
BG44749 0 0 *.pop3s *.* LISTEN
$

SDA> tw sho sock 8A8BDDC0
scb at 8A8BDDC0 BG50578 lia 172.16.0.8 fia 83.149.3.47 lpn 995 fpn 5518
options REUSEADDR KEEPALIVE
state SOCKET CONNECTED PRIV tcp flags IDLE WSCALE tcp state ESTABLISHED cdb 89A9E000
Receive Queue 89C783C0 89C783C0, byte count 0
Transmit Queue 8A8BDE4C 8A8BDE4C, byte count 0
Transmit data buffer 00000000, Byte count 0
Hash table entry 89A9E47C, Hash Link 00000000
Allocated RTE address 89849C80 Send Unack 1063292057, Send Max 1063292057 Send next 1063292057 Send High water 32676
send window size 66240, maximum 66240 congestion window 4140
offered receive window size 61440
probe idle 15 Drop idle 60
maximum segment size 1380, original MSS 1380, MTU 1460

SDA>
DTV1::SSHD 0843A PTD 11:52:37 (DCL) CPU=00:00:00.30 PF=972 IO=960 MEM=165
$ netcu sho conn /loc=*.995
TCPware(R) for OpenVMS Active Internet Connections (including servers):

ID RecvQ SendQ Local Address Foreign Address State
-- ----- ----- ------------- --------------- -----
BG50578 0 0 172.16.0.8.pop3s 83.149.3.47.5518 ESTABLISHED
BG0 171 0 172.16.0.8.pop3s 172.16.1.24.20735 CLOSE-WAIT
BG0 96 0 172.16.0.8.pop3s 89.223.96.210.12175 CLOSE-WAIT
BG0 102 0 172.16.0.8.pop3s 172.16.1.9.4001 CLOSE-WAIT
BG0 78 0 172.16.0.8.pop3s 172.16.1.9.4007 CLOSE-WAIT
BG0 96 0 172.16.0.8.pop3s 83.149.3.86.53202 CLOSE-WAIT
BG44749 0 0 *.pop3s *.* LISTEN
$

Re: HP SSL & SO_KEEPALIVE + TCPWare-TCP

Richard Whalen — Mon, 10 Nov 2008 16:32:58 GMT

Works fine for me using a modified version of the SSL sample programs with the following line added after the connect() call
err = setsockopt(sock, SOL_SOCKET, SO_KEEPALIVE, &on, sizeof(on));

Re: HP SSL & SO_KEEPALIVE + TCPWare-TCP

Ruslan R. Laishev — Mon, 10 Nov 2008 17:35:06 GMT

Richard,
see my first post. A TCP-connection is accepted by using $QIO. SSL stuff want "unix socket handle", to get it decc$socket_fd() is used.

Re: HP SSL & SO_KEEPALIVE + TCPWare-TCP

Richard Whalen — Mon, 10 Nov 2008 19:27:40 GMT

For the server it works if the setsocketopt is done on the listening socket before the accept, but not on the socket created as a result of the accept.

Re: HP SSL & SO_KEEPALIVE + TCPWare-TCP

Ruslan R. Laishev — Tue, 11 Nov 2008 07:51:43 GMT

Richard,
pay attention that $QUI has been used. A test prog to reproduce the problem:
http://starlet.deltatel.ru/~laishev/work/pop3/zzs.c

Re: HP SSL & SO_KEEPALIVE + TCPWare-TCP

Richard Whalen — Tue, 11 Nov 2008 14:12:06 GMT

If you change the qio to set keepalive to do it on the listen channel and do it after the listen and before the accept, then it will work.

I will accept the argument that it should work your way too.

Setting the keepalive on the listen channel is more efficient as you do one call for many accepts, instead of one call for each accept.

Re: HP SSL & SO_KEEPALIVE + TCPWare-TCP

Ruslan R. Laishev — Tue, 11 Nov 2008 14:29:15 GMT

Thanks, Richard! This "tip & trik" is work fine.

Re: HP SSL & SO_KEEPALIVE + TCPWare-TCP

Richard J Maher — Tue, 11 Nov 2008 21:56:41 GMT

Hi Richard,

[Setting the keepalive on the listen channel is more efficient as you do one call for many accepts, instead of one call for each accept.]

Are we talking about the BG driver here?

If so, is this "anomally" going to be fixed?

Cheers Richard Maher

Re: HP SSL & SO_KEEPALIVE + TCPWare-TCP

Ruslan R. Laishev — Wed, 12 Nov 2008 10:06:40 GMT

Nice question!

Re: HP SSL & SO_KEEPALIVE + TCPWare-TCP

Richard Whalen — Wed, 12 Nov 2008 14:02:39 GMT

Yes, I will be investigating why it the keepalive timer isn't started when keepalive is enabled for an existing connection and if it can be changed so that it works as expected.

Re: HP SSL & SO_KEEPALIVE + TCPWare-TCP

Richard J Maher — Wed, 12 Nov 2008 22:11:04 GMT

Sounds good!

In the meantime if anyone can report back on whether it is just the KEEPALIVE option that is exhibiting this recalcitrance (or whether it extends to Full_duplex_close, Linger, InLine, TCP Options, and so on. . .) it would be much appreciated.

Cheers Richard Maher

Re: HP SSL & SO_KEEPALIVE + TCPWare-TCP

Richard Whalen — Tue, 18 Nov 2008 16:23:31 GMT

released today:

DRIVERS_V582P050 - ECO Rank: 3 - Corrects a specific problem

UDPDRIVER, TCPDRIVER, IPDRIVER - Reduce alignment faults on Integrity and Alpha
systems.

BGDRIVER - The BGDRIVER will now start the keepalive timer when keepalives are enabled on a connected socket.

Re: HP SSL & SO_KEEPALIVE + TCPWare-TCP

Ruslan R. Laishev — Tue, 04 May 2010 19:17:45 GMT

Thanks to all!