TCP Socket Options

[Alan Shearer_1]

Hi,

Is there a way to determine the TCP values configured for a particular process on HP-UX (11.23 and 11.31)?

I've been searching around, but have failed to find an answer.

The closest I can get is with lsof and the "-Tsf" option. Though this does not report all values for all UNIX versions. HP-UX seems to be one of the versions with less information.

For example, if I wanted to check if the TCP_DELAY value was set on a socket used by a process I can't find this with lsof.

Anyone else any ideas?

Thanks.

[Steven Schweda]

Hmmm. Socket options... How would I get
socket options?

I know nothing, but you might do better
looking for TCP_NODELAY. For example:

http://docs.hp.com/en/B2355-60127/TCP.7P.html

which suggests, "(see getsockopt(2))".

[Alan Shearer_1]

Well spotted Steven - missing the NO was a typo on my part.

I had already looked at this information - is there not an option to a command that can make this getsockopt(2) system call and retrieve this information for you, such as lsof -Tsf does on other UNIX flavours?

If not I'm hoping someone more proficient than me out there can give an example of how it could be done.

[rick jones]

If there is any "supported" way (or probably even an unsupported way) to get the socket options for an arbitrary process's sockets, it would be some variation on a pstat() call.

To what end to you intend to use the information? You won't be able to change a process's socket options behind its back (well, short of having LD_PRELOADed a library implementing your nefarious intent), and if an application has a way to be told to set certain socket options, presumably that would appear in a config file.

Now, if you can get to the process before it opens the socket(s) of interest, you could use tusc to trace its setsockopt() calls.

If you cannot get to the process before it opens the socket(s) of interest, you might be able to take a packet trace and look at the behaviour and deduce some things, perhaps in conjunction with a tusc trace after the app is started. For example, if you see the application making several "sub-MSS" send() calls on the same socket without recv() calls interspersed, and then you look at the packet trace and you see one small TCP segment go out, but nothing more until either a MSS-sized segment or a sub-MSS segment after an ACKnowledgement received, you can reasonably infer that the application has not called setsockopt() to set TCP_NODELAY on that socket/connection.

Similarly, if you see it having more data outstanding on the connection than the ndd setting for tcp_xmit_hiwater_def (well, that times 2 probably) then you can reasonably infer that the application has called setsockopt() to set SO_SNDBUF.

None of those means will be terribly convenient if the goal is to fill-out a TPS report :) but if the goal is to try to debug application behaviour without source they might get you at least partway to where you want to be.

[Alan Shearer_1]

Hi Rick,

Thanks for the pointer in the right direction. pstat is the way to go. I've been looking at the pstat man page and the wp below:

http://docs.hp.com/hpux/onlinedocs/os/11i/pstat_whitepaper.pdf

Though with my virtually non-existent C programming knowledge I struggled to get the examples working.

I've had more success with this link:

http://docs.hp.com/en/B2355-60130/pstat.2.html#d0e604810

I've been compiling and running the examples fine. The one of interest to me is obviously Example 11 - which is a bit more complicated than some of the others I've tried. Whilst it works, it only provides the statement "Success" followed by "The type of socket is 1, should be 1"

Not really the detailed socket info I was after.

I would very much appreciate some help/guidance on taking this example further and using it to gain the socket information I would like to collect of a PID.

Rick, anyone, any ideas?

Thanks.

[Dennis Handly]

>I've had more success with this link:

If you want example 11, you should provide a link to it, not 2:
http://docs.hp.com/en/B2355-60130/pstat.2.html#d0e604907

>Not really the detailed socket info I was after. I would very much appreciate some help/guidance on taking this example further

You need to get into the debugger and do a "ptype psfsocket" and "p psfsocket" to see all of the fields in struct pst_socket.

The white paper has details too:
pst_socket
Header file:

[Laurent Menase]

there is an HP support internal support named
xportshow developped by 3rd level of support.

xportshow -ca all will give that information.


xportshow is available through HP soft support.

The other way is to take a network trace,
- the TCP_NODELAY- is obvious if you send submss messages.

[VK2COT]

Hello,

OK, C programming is not something many admins
deal with these days. In old time, that was
my bread-and-butter but I also moved on
and Perl is an easier choice:

Are you OK with Perl:

http://search.cpan.org/~schwenke/HPUX-Pstat-1.01/Pstat.pm

Cheers,

VK2COT

[Dennis Handly]

>ME: You need to get into the debugger and do a "ptype psfsocket"
(gdb) p psfsocket
$1 = {pst_hi_fileid = 3758096385, pst_lo_fileid = 1858914688,
pst_hi_nodeid = 3758096385, pst_lo_nodeid = 1872417728,
pst_peer_hi_nodeid = 0, pst_peer_lo_nodeid = 0, pst_flags = 1, pst_type = 1,
pst_options = 0, pst_linger = 0, pst_state = 0, pst_family = 2,
pst_protocol = 6, pst_qlimit = 0, pst_qlen = 0, pst_idata = 0,
pst_ibufsz = 32768, pst_rwnd = 0, pst_odata = 0, pst_obufsz = 32768,
pst_swnd = 0, pst_pstate = 4294967291, pst_boundaddr_len = 16,
pst_remaddr_len = 16, pst_boundaddr = "", pst_remaddr = ""}
(gdb) ptype *&psfsocket
type = struct pst_socket {
uint32_t pst_hi_fileid;
uint32_t pst_lo_fileid;
uint32_t pst_hi_nodeid;
uint32_t pst_lo_nodeid;
uint32_t pst_peer_hi_nodeid;
uint32_t pst_peer_lo_nodeid;
int32_t pst_flags;
uint32_t pst_type;
uint32_t pst_options;
uint32_t pst_linger;
uint32_t pst_state;
uint32_t pst_family;
uint32_t pst_protocol;
uint32_t pst_qlimit;
uint32_t pst_qlen;
uint32_t pst_idata;
uint32_t pst_ibufsz;
uint32_t pst_rwnd;
uint32_t pst_odata;
uint32_t pst_obufsz;
uint32_t pst_swnd;
uint32_t pst_pstate;
uint32_t pst_boundaddr_len;
uint32_t pst_remaddr_len;
char pst_boundaddr[256];
char pst_remaddr[256];

[Alan Shearer_1]

Thanks for the comments on the alternative approach of looking for the behaviour of a certain option to determine if its set, but this is not really the solution we're looking for.

Dennis - I'm not experienced in using the debugger and it seems a complicated (and possibly risky approach on a Production system?) to get this info compared to lsof -Tsf.

Laurent - how does xportshow collect this information? Using pstat interface?

VK2COT - I had already spotted that module on CPAN, but wasn't sure about using someone else's code that I don't really understand. So I thought the best option would be to try and cobble something together myself in C that used the pstat API.

I've also been looking at the getsockopt2() - though I assume this can only be used on a socket created by your program, rather than on existing sockets? I can't see how I would find and use the socket descriptor of an existing socket in my program. So for instance if I wanted to check the keep alive setting I can use:

getsockopt(s, SOL_SOCKET, SO_KEEPALIVE, &optval, &optlen)

But I can't work out how (if) I can populate "s" with the details of an existing socket.

Back to the pstat approach, on looking through the specific header file:
socket_pstat_body.h

I can see the options flags listed as:

/*
* Option flags per-socket (for pst_options)
*/
#define PS_SO_DEBUG 0x0001 /* turn on debugging info recording */
#define PS_SO_ACCEPTCONN 0x0002 /* socket has had listen() */
#define PS_SO_REUSEADDR 0x0004 /* allow local address reuse */
#define PS_SO_KEEPALIVE 0x0008 /* keep connections alive */
#define PS_SO_DONTROUTE 0x0010 /* just use interface addresses */
#define PS_SO_BROADCAST 0x0020 /* permit sending of broadcast msgs */
#define PS_SO_USELOOPBACK 0x0040 /* bypass hardware when possible */
#define PS_SO_LINGER 0x0080 /* linger on close if data present */
#define PS_SO_OOBINLINE 0x0100 /* leave received OOB data in line */
#define PS_SO_REUSEPORT 0x0200 /* allow local address & port reuse */
#define PS_SO_GETIFADDR 0x0400 /*
* HP: save the loc IP addr for
* inb UDP packets
*/
#define PS_SO_PMTU 0x0800 /* HP: advise to use PMTU discovery */
#define PS_SO_INPCB_COPY 0x1000 /* HP: local copy of inpcb */

As it only seems to mainly list SOL_SOCKET level options does this mean I can't determine the four TCP socket options, such as TCP_NODELAY, using pstat?

Perhaps this is why this function is not included in the HP-UX version of lsof?

Any thoughts/comments?

[Laurent Menase]

How xportshow is getting all the information from sockets:
A magic glue - it looks in /dev/kmem, all the kernel structures using some internal framework named libp4.
It works on live and crash dump, and it is what we use to analyze crashdumps to extract xport data

[Alan Shearer_1]

Hi Laurent - Thanks for the extra info. Its interesting to get a bit of insight into how it works.

Based on your reply, I think our preferred method would be to use the pstat API, which should need little modification for future HP-UX releases. Whereas according to the whitepaper, linked in a previous response above:

"..many system management and measurement tools read kernel data structures
through unsupported interfaces, such as /dev/kmem pseudo driver.."

So I guess pstat is the better option for casual collection of this information by the user (assuming pstat can!), as opposed to debugging activities and the like for which you use xportshow.

[Laurent Menase]

indeed; if this is only a one time research, xporshow is the quickest,
if you want to write a tool, pstat is more portable.
xportshow is a living application which is adapted and modified when major changes are made in the kernel structures.

[Dennis Handly]

>I'm not experienced in using the debugger and it seems a complicated (and possibly risky approach on a Production system?)

The purpose of using gdb was to see what fields and values were in struct pst_socket and to suggest what code to add to the source. And it wouldn't be risky at all.

>I can see the options flags listed as:

Ok, you actually have some documentation to decode the bits.

[Dennis Handly]

Here is how to decode the bits:
printf("The type of socket is %u, should be %d\n",
psfsocket.pst_type, PS_SOCK_STREAM);
#define dump_option(name, mask) \
printf("pst_options: " name "=%d\n", psfsocket.pst_options & mask)
dump_option("DEBUG", PS_SO_DEBUG);
dump_option("ACCEPTCONN", PS_SO_ACCEPTCONN);
dump_option("REUSEADDR", PS_SO_REUSEADDR);
dump_option("KEEPALIVE", PS_SO_KEEPALIVE);
dump_option("DONTROUTE", PS_SO_DONTROUTE);
dump_option("BROADCAST", PS_SO_BROADCAST);
dump_option("USELOOPBACK", PS_SO_USELOOPBACK);
dump_option("LINGER", PS_SO_LINGER);
dump_option("OOBINLINE", PS_SO_OOBINLINE);
dump_option("REUSEPORT", PS_SO_REUSEPORT);
dump_option("GETIFADDR", PS_SO_GETIFADDR);