|Home » Learning Curve
Cool Clever Stuff with CLIX II
A look at netstat.
Netstat is a powerful app. It does literally everything. It's written by a guy who worked for FreeBSD once upon a time.
The source is actually licensed under a 'beer licence': if you meet him some day and you liked what he did - you buy him a beer.
Rixstep's GD is patterned after Radsoft's GD which in turn is patterned after netstat.
What It Means
What does netstat do? Clearly its application domain is extensive. The manpage for netstat says the following.
netstat - show network status
netstat [-AaLlnW] [-f address_family | -p protocol] [-M core] [-N system]
netstat [-gilns] [-f address_family] [-M core] [-N system]
netstat -i | -I interface [-w wait] [-abdgt] [-M core] [-N system]
netstat -s [-s] [-f address_family | -p protocol] [-M core] [-N system]
netstat -i | -I interface -s [-f address_family | -p protocol] [-M core] [-N system]
netstat -m [-M core] [-N system]
netstat -r [-Aaln] [-f address_family] [-M core] [-N system]
netstat -rs [-s] [-M core] [-N system]
Which is obviously too much and may well have readers running for the hills. So it's better to try a few things you know it can do and work from there.
It's fairly easy to set up a network poll so you both see what is happening with your connection and log it all to disk.
# Simple netstat polling loop.
netstat -f inet
Put the above into a file called (for example) netstat.sh, change its mode to 0700, and run it.
% chmod 0700 netstat.sh
Active Internet connections
Proto Recv-Q Send-Q Local Address Foreign Address (state)
tcp4 0 0 localhost.1033 localhost.1010 ESTABLISHED
tcp4 0 0 localhost.1010 localhost.1033 ESTABLISHED
tcp4 0 0 localhost.1033 localhost.1020 ESTABLISHED
tcp4 0 0 localhost.1020 localhost.1033 ESTABLISHED
tcp4 0 0 localhost.1033 *.* LISTEN
udp4 0 0 localhost.1033 *.*
The script will poll your Internet connections every ten seconds; use ⌘. to break it.
The first column gives you the protocol polled: TCP is listed first, followed by UDP. The next two columns are the receive and send queues. Then you have your local and remote addresses, resolved from their IPs if at all possible, followed by either the ports being used or if possible the service found on the ports. Finally you have - in the case of TCP - the status of the connections.
UDP and TCP work differently: UDP is a 'datagram' protocol, sending out packets and hoping for the best (in terms of a reply).
With TCP it's different: TCP is a 'connection based protocol'. Consider the difference between a postcard and a telephone call. The postcard just goes out; someone may reply later (perhaps with a postcard of their own). But with a phone call, you don't actually hear anything until the other party picks up too - you get a connection.
Whoever initiates a TCP connection attempt contacts the other end and asks for a 'connect': this is a 'three way handshake' - entailing both a request, an 'ack' (acknowledgement) back, and another 'ack' back the other way.
[Which incidentally forms the basis of a classic 'DoS' (denial of service) attack: send out the first request, get your 'ack' back, and just leave the other guy sitting there waiting forever (or for the longest time) for a reply that will never come. Then keep on contacting the server and leaving it hanging on each request until the poor sucker goes down.]
Thus your final output column shows you the transitions in your TCP connections - most of which will hopefully be better behaved.
- CLOSED: The socket is not in use.
- LISTEN: The socket is listening for incoming connections.
- SYN_SENT: The socket is actively trying to establish a connection to a remote peer.
- SYN_RCVD: The socket has passively received a connection request from a remote peer.
- ESTABLISHED: The socket has an established connection between a local application and a remote peer.
- CLOSE_WAIT: The socket connection has been closed by the remote peer and the system is waiting for the local application to close its half of the connection.
- LAST_ACK: The socket connection has been closed by the remote peer, the local application has closed its half of the connection, and the system is waiting for the remote peer to acknowledge the close.
- FIN_WAIT_1: The socket connection has been closed by the local application, the remote peer has not yet acknowledged the close, and the system is waiting for it to close its half of the connection.
- FIN_WAIT_2: The socket connection has been closed by the local application, the remote peer has acknowledged the close, and the system is waiting for it to close its half of the connection.
- CLOSING: The socket connection has been closed by the local application and the remote peer simultaneously and the remote peer has not yet acknowledged the close attempt of the local application.
- TIME_WAIT: The socket connection has been closed by the local application, the remote peer has closed its half of the connection, and the system is waiting to be sure that the remote peer received the last acknowledgement.
It's thus possible to closely monitor what is happening with your computer: what connections it has initiated and - heaven forbid - if someone else is trying to contact you. You'll normally see your 'web' connections as they'll be to port 80 ('http') and you'll see that you're connected to the remote web servers on a higher port of your own.
You should also notice attempts by 'embedded URLs' (or demographic trackers) to contact you - DoubleClick and the like - as well as the real identities of the servers you think you're surfing to. For example, an incredible number of connections to the most trafficked sites go through Akamai - watch for that name. Webbugs and the latest tricks will show up here.
Make a Log
That netstat output is going to scroll by fast, so it might make sense to try to create a log of it all. Change your command line to the following.
% ./netstat.sh | tee -a netstat.log
tee makes a 'tee' of the output, letting your current output remain where it is - in your terminal window - but also creating an additional copy in the file netstat.log. Use any text editor to open the file.
But be careful: every ten seconds the command is going to add on perhaps one thousand bytes to that file - that's six thousand a minute and a third of a megabyte per hour...
Another good one with netstat is the per-protocol statistics switch ('-s'). Use it twice to get only your non-zero counters.
% netstat -ss
4637 packets sent
4290 data packets (369352 bytes)
285 ack-only packets (221 delayed)
62 control packets
4653 packets received
4345 acks (for 369339 bytes)
12 duplicate acks
4314 packets (369148 bytes) received in-sequence
[The full output is much longer and includes the UDP, IP, ICMP, IGMP, IPSec, and a few more protocols.]
It's a good way to see what kind of traffic has been going in and out of your computer, and of course if your friends have a look, they'll be very impressed.
And if they ask you to explain what it all means, even better. Act like you're studying intently and say something like: 'only nineteen ICMP error calls - can't beat that, eh?'
Back to CLIX
It's time to integrate the script into CLIX. Choose a title and a category (such as 'Network') and write a brief description along with the command line itself (and tcsh works nicely - YMMV).
tcsh ~/<path to your>/netstat.sh
Stop the command and copy the output when you're ready to take a closer look.