Welcome to the second in our series on network troubleshooting. In part one we covered how to use ICMP PING to perform basic network troubleshooting. In this part, we’re going to see how to troubleshoot at layer four with a tool called tcping. This program, written by Eli Fulkerson, does at layer four with TCP what ping does at layer three with ICMP.
If you would like to use it, download tcping from here. You can save the exe to your system32 directory, or your homedir if you have one, which will make it available to you no matter what system you are logged onto. It is a self-contained binary so you don’t need anything else, and it will work on 2000/2003/2008/XP/7 equally well. Read on to see how to use this little gem.
Level 100-A review of TCP
To really understand how tcping can help you troubleshoot, you need to know something of how TCP works. The Transmission Control Protocol is a session layer protocol that provides reliable service. It establishes and maintains sessions, ensures delivery of data using acknowledgements, and can retransmit data if necessary. Almost all of the data transported on IP networks uses TCP. Before data can start moving, TCP needs to establish a session, using something called a three way handshake between client and server. The handshake creates the session between client port and server port, establishes the parameters for sequence numbers, and sets the amount of data that can be transferred before an acknowledgment is required. It looks likes the diagram to the left, but this video might help make the concept a little more clear.
Direct link for RSS and email subscribers…http://www.youtube.com/watch?v=z40w3G8szK0
At the end of a session, the client and server both close out with a FIN-ACK/ACK exchange. This is not shown above, but the FIN-ACK lets both client and server release any resources allocated to the session (like buffer space in memory) and allows them to reuse ports for other conversations. Eventually, timers would expire out these resources, but the FIN-ACK is the polite way to gracefully end the session.
Level 200-TCPING basics
Many of you have probably used telnet to connect the the ip.addr and port for a service to see if you can make the connection. While this does do much the same thing as tcping does, it takes longer, leaves you needing to either wait for a timeout or CTRL-BREAK the connection, and does not gracefully end the session on the server side. It also cannot test ports continuously like tcping can. If you have already downloaded the binary and placed it in your path, open a cmd-prompt and enter
So this tells us that the syntax for tcping is full of optional switches, and that by default, we target port 80. So the command
tcping 192.168.100.2 [enter]
will probe 192.168.100.2 on tcp port 80. That looks like this
The replies tell us that the server at 192.168.100.2 is up, a service is listening on port 80, and it responds to us on average in 17.472ms. Look at this snip of a Wireshark trace.
See what happens? We complete our three-way handshake, and then we politely tell the server that we’re done by sending a FIN-ACK. Since we didn’t request any actual data over the session, the server responds with a RST-ACK instead of its own FIN-ACK, but that actually saves us both another ACK. This is much better than telnetting to the port because it checks repeatedly, gives us response time, and gracefully ends the connection each time.
So what does it look like if we try to connect to a port that is not listening? Here we will specify port 81, which is not normally used by any Windows service.
We get a connection refused response. On the wire, the server is receiving our SYN packet, and replying that, while it is up and running and received our request, it is not running any service on TCP port 81 and would kindly appreciate it if we would sod off. In networking, that is called a RST-ACK. Here’s what it looks like in a Wireshark snip.
To see if RDP is running on a server, do this… 
You can try any other server/port combination you want, and you can use the name or the ip.addr.
If you try to connect to a service on a system that is down, or firewalled and configured to drop(not block,) it looks like this. 
Tcping waits 20 seconds before giving up on each SYN sent.
Level 300-Advanced TCPINGing
But wait, there’s more. Let’s look at a couple of the other switches supported with tcping. Much like the ping command, tcping tries four connections by default, but we can specify another number of attempts or run a continuous tcping with the same switches. Currently though, we can’t get total statistics from either a ctrl-c or a ctrl-break.
tcping –n 30 will connect 30 times. This will give you summary stats.
tcping –t will connect continuously until interrupted by ctrl-c. No summary stats.
By default, tcping starts its next connection the greater of one second later, or as soon as it receives a response, with a maximum of 20 seconds between attempts. We can specify another timing with the –i switch.
tcping –i 60 will try one connection every sixty seconds.
We can also write the current date/time to each line using –d. This is useful if we are outputting to a file and want to see when each connection attempt was made. Try this.
tcping –i 60 –d –n 5 192.168.100.2 > results.txt [enter]
and then open the results.txt file to see what it contains.
Instant logfile…niiice!
Did you know that splunk> can tail a log file like this? <♫>The more you know </♫>
Level 400-Audible TCPINGing
Have you ever had to bounce a box, and run a continuous ping against it to see when it came back up? Tcping has an audible feature that you can use to annoy the hell out of your neighbors, but also to let you know what is going on without you having to keep a cmd window visible. The –b switch enables audible beeps, with four options.
- 1 will beep twice when a service does not respond
- 2 will beep once when a service does respond
- 3 will beep when the service changes from one state to the other. One beep if it goes from down to up, two beeps if it goes from up to down.
- 4 will beep every time it sends a SYN…one beep for up, two for down.
Say you are bouncing a server, or even just a service (iisreset, net stop && net start, /etc/init.d/servicename restart, etc.) and you just want to know when the service finally starts to respond again.
tcping –b 2 –t a.b.c.d port#[enter]
will try to connect, and as soon as it starts to get a response you will hear it start to beep. You might as well use those speakers for something besides mp3s and YouTube vids.
And speaking of YouTube vids, here is one I love to show to my non-technical friends and family when they ask me about the tubes. While completely over the top in parts, and taking poetic license in others, it still helps a luddite visualise what is going on, and the voiceover is pretty funny in parts too. Enjoy.
Direct link for RSS and email subscribers…http://www.youtube.com/watch?v=Ve7_4ot-Dzs
If you found this post useful, please consider following us on twitter. You’ll be the first to learn about new posts, and, rarely, we’ll share a comedic or witty tweet. Of course, you can also leave a comment below (anonymous allowed) to let us know we hooked you up.
You might also enjoy:
