Monitor Socket Connection Attempts?

[Jim Turner]

Greetings!

Here's the situation: I'm working with an outside vendor that connects to us via MQ Series through a firewall to a server in our environment. The vendor says he's making a connection attempt. The LAN guys say they see the connection attempt at the firewall and that it must be a problem on "our end" not accepting the connection. However, I never see a socket connection from the vendor with netstat. Further, it is our contention that the connection request is never making it to our box.

Is there a good way to reliably monitor/log all TCP connection attempts (successful and unsuccessful) that my HP-UX box gets?

Thanks!
Jim

[Cross-posted to dutchworks]

[Jim Turner]

I should add that we can connect to the queue in question from a local server with no problem at all.

[James R. Ferguson · Accepted solution]

Hi Jim!

Restart 'inetd' with logging enabled:

# /usr/sbin/inetd -l

From the man pages for 'inetd(1M)', "If no inetd is running, the -l option causes the inetd to start with connection logging enabled. Otherwise the -l option causes inetd to send the signal SIGQUIT to the inetd that is already running, which causes it to toggle the state of connection logging."

Regards!

...JRF...

[Bill Douglass]

You can monitor connections using a packet-capture tool like tcpdump

http://hpux.cs.utah.edu/hppd/hpux/Networking/Admin/tcpdump-3.7.2/

Also requires that you install libpcap:

http://hpux.cs.utah.edu/hppd/hpux/Networking/Admin/libpcap-0.7.2/


You can also use nettl, which is likely on your system now. Check the nettl manpage.

Filter on the IP address or port of interest, and you should be able to tell if the SYN packets are ever reaching your host. YOu should also see if a response if being sent from your host.

[Michael Steele_2]

Absolutely, tcpdump:

http://hpux.cs.utah.edu/hppd/hpux/Networking/Admin/tcpdump-3.7.2/

The best.

Also try lsof:

lsof -i tcp:23
lsof -i udp:23

[Jim Keeble]

As root:

cat >filter
filter tcp_sport
filter tcp_dport
^D

nettl -tn pduin pduout -e ns_ls_ip -s 1024 | netfmt -N1nT -c filter -F

The -F will cause the netfmt to "follow" the input pipe until you interupt it with ^C. The filter will sort out only the traffic for the one application.

Try a connection from a client that works so you can see what it should look like. (If there's a lot of traffic, you might get 1000's of lines of output). Then try a connection from the client outside the firewall. If you don't see the packets from that host in the trace, it never got to you.

The inetd logging is only valid if your app uses inetd to accept connections. If it has it's own listener (like oracle, for example), inetd logging won't do any good, but nettl will capture ANY traffic.

[Jim Turner]

Thanks all for the excellent advice. It turned out to be simplest to use inetd's logging to prove what we already knew. Someone mucked-up a firewall ACL which jammed the traffic before it got to us.

Regards,
Jim