Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

On a centos box, I like to dump tcp connections - I would like to see if a server tries to send requests to a certain IP. Usually tcpdump would do the trick - but tcpdump is not installed, and installing software is not an option (because of company policy). I am afraid netstat will not show me a single request.

So I was wondering what other options I have. I do have root access on the server.

share|improve this question
Do you have root access on the server ? – Iain Jun 19 '14 at 12:02
Yes, I do have root access. – Isaac Jun 19 '14 at 12:04
You should also work on getting the company policy fixed. When it stops you from doing your job, the policy is broken. – Michael Hampton Jun 19 '14 at 14:42
Well, change control its basically an FDA requirement - so nothing I will be changing in this life :) – Isaac Jun 20 '14 at 5:18
up vote 14 down vote accepted

Surely you have python?

from socket import * 
from struct import unpack 
import sys 

INTERFACE = "eth0"
TARGET = "" 

if __name__ == "__main__": 
  sock = socket(AF_PACKET, SOCK_DGRAM, 0x0800) 
  sock.bind((INTERFACE, 0x0800)) 
  while True: 
    data = sock.recvfrom(1500, 0)[0] 
    ip = inet_ntop(AF_INET, data[12:16]) 
    if ip == TARGET: 
      print "GOT TARGET" 

This will exit with "GOT TARGET" providing the IP address coming back matches. Since TCP has to send something back during a handshake, this should catch anything from a specific target address. It doesn't care if the protocol is TCP or UDP though (nor do I check).

Dont forget to change TARGET and INTERFACE.

share|improve this answer
Hey, this is the coolest solution so far - great! – Isaac Jun 20 '14 at 5:16
Works like a charm! – Isaac Jun 20 '14 at 5:31
How would you modify this to also catch a tcp syn packet? Because if the target is not reachble, an attempted but failed connection won't show. – Isaac Jun 20 '14 at 12:32
Isn't this script a new software (so is not to be installed in the system)? – Vi. Jun 20 '14 at 15:48
@Vi with that logic, you can argue that any shell script is 'new software'. It depends how you define 'software'. – Matthew Ife Jun 23 '14 at 20:05

Iptables has a debug capability and that can be used for traffic analysis too.

The solution is described on the URL below.

Debugging rules in Iptables

It's also worth reading the following URL to set up the logging of trace output to a file of your choice.

I would not consider this solution equal to tcpdump, but it can be done using a minimal install of Centos. You need to be careful not to fill up the disk with the logs, because tcpdump is much more efficient in disk use. Turn off the logging when it is not required.

You can use the following as a basic template in your script.

# Logging
SOURCE=a.b.c.d (IP address)
$IPT -A INPUT   -s $SOURCE -m limit --limit 50/minute -j LOG --log-level 7 --log-prefix "In: "
$IPT -A OUTPUT  -s $SOURCE -m limit --limit 50/minute -j LOG --log-level 7 --log-prefix "Out: "
$IPT -A FORWARD -s $SOURCE -m limit --limit 50/minute -j LOG --log-level 7 --log-prefix "Fw: "
$IPT -t nat -A POSTROUTING -m limit --limit 50/minute -j LOG --log-level 7 --log-prefix "Nat: "
#log  (remove comment to enable)

iptables -t raw -A PREROUTING -p tcp  -j TRACE
iptables -t raw -A OUTPUT     -p tcp  -j TRACE
#trace (remove comment to enable)
share|improve this answer
+1 Beat me to it. – James Sneeringer Jun 19 '14 at 14:00

I'd really try to get tcpdump. That being said, some alternatives to see if a certain connection exists for an IP are:


[kbrandt@ny-kbrandt01: ~] strace -e trace=network nc 1234
connect(3, {sa_family=AF_INET, sin_port=htons(1234), sin_addr=inet_addr("")}, 16) = -1 EINPROGRESS (Operation now in progress)


[kbrandt@ny-kbrandt01: ~] nc 1234 &
[1] 11434
[kbrandt@ny-kbrandt01: ~] lsof -p 11434
nc      11434 kbrandt    3u  IPv4 4543149      0t0     TCP> (SYN_SENT)


[kbrandt@ny-kbrandt01: ~] nc 1234 &
[1] 11486
[kbrandt@ny-kbrandt01: ~] sudo netstat -a -p | grep 11486
tcp        0      1           SYN_SENT    11486/nc
share|improve this answer
That was the kind of answer I was hoping for. Unfortunatly strace is not installed either :/ – Isaac Jun 19 '14 at 12:24
I will try lsof – Isaac Jun 19 '14 at 12:28
@Isaac: Also netstat, if they won't let you have netstat you might want to start searching the job market before you go nuts ;-) – Kyle Brandt Jun 19 '14 at 12:30
We have netsat :) – Isaac Jun 19 '14 at 12:40

If you need specific software to do your job, and aren't allowed to, you're either not making a good business case or selling your ideas to the right people... or you're not in control of this system...

If I were tasked to do something and needed the type of debugging/troubleshooting information that you require in this case, I'd use the right tool. That's likely tcpdump or tshark. Yes, those are pieces of software, but I'd deem them more essential utilities. In fact, they are utilities that could be installed or loaded onto the system temporarily and removed without incident (is removable media an option?...hint)

But the point is that a janky workaround to company policy probably takes more effort than getting approval for this use case.

share|improve this answer
I completly agree on using the right tool for the right job. In fact, I can install software, but we have to use change control, so the process takes a few days - I needed the dump right now, so installing was not an option. I was just wondering if I overlooked some options have not thought about yet. – Isaac Jun 19 '14 at 12:22
:( about change-management. Is there any way to play a political game and get the people/parties who'd benefit from the dump to fast-track the change-management process? – ewwhite Jun 19 '14 at 12:23
I am afraid not - but since its the customer who requires change-management and also tcpdump, he will have to accept the facts. I was hoping I could make him happy anyhow. – Isaac Jun 19 '14 at 12:26
@ewwhite: Any good change management policy should have the ability to exempt specific, or classes of, changes from going through the full process. If this one doesn't.... – Scott Pack Jun 19 '14 at 12:27
Can't you compile a statically linked tcpdump elsewhere, and just copy it to /tmp and run from there? – che Jun 19 '14 at 13:06

Kyle offered some great options. One more would be to use iptables:

[james@server ~]$ sudo iptables -I OUTPUT -d
[james@server ~]$ sudo iptables -L OUTPUT -n -v
Chain OUTPUT (policy ACCEPT 105 packets, 35602 bytes)
 pkts bytes target  prot opt in  out  source      destination
   87 33484 LOG     all  --  *   *     LOG flags 0 level 4

This is essentially an accounting rule. It doesn't explicitly permit or deny traffic, so the default policy for the OUTPUT chain is used (which defaults to ACCEPT). However, any matching packet will increment the counters for the rule.

You can optionally log details about the packet as well with the -j LOG option:

[james@server ~]$ sudo iptables -I OUTPUT -d -j LOG
[james@server ~]@ dmesg | grep | tail -1
IN= OUT=eth0 SRC= DST= LEN=100 TOS=0x10 PREC=0x00 TTL=64 ...

Logs will go to the kernel logging facility, so it should show up in /var/log/messages on Red Hat derivatives and /var/log/kern.log on Debian derivatives. It would also be visible in the output of dmesg, as shown. Unlike tcpdump, however, it will not log the complete contents of the packet, only the contents of the packet header.

share|improve this answer
I was thinking of iptables myself, but also not installed :/. Anyway, nice solution. – Isaac Jun 19 '14 at 17:39

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.