Home – Blog – Cool Tools: Cool Tools Part III: TcpTrace
October 19, 2007 —
As we’ve discussed again and again (and again), there are a lot of network connections flying around your network, and without additional tools, you likely don’t have a lot of visibility into what that traffic looks like.
You could download a network sniffer like Ethereal, but the results of a sniffer can be confusing at best, and downright impossible to interpret at worst, because without proper filters, you end up seeing EVERYTHING, including a lot of “noise” on the network.
A better tool that allows more “surgical” analysis is tcpTrace. Basically, all it does is listen on a port, and any connections that come into that port are redirected to a another server and port, displaying requests in one window and responses in another.
Take the following example: suppose I want to see exactly what kind of HTTP traffic is passing between my portal server and collaboration server (in this example, both are installed on the same machine). I simply run tcpTrace on that server, and tell it to listen on port 9999 (or any other open port). I also tell it that any requests to that port should be redirected to the local machine on port 11930 (the port that Collab is listening on). Finally, in the portal’s Administration section, I change Collab’s remote server to use port 9999 instead of 11930.
From the portal’s perspective, tcpTrace is completely transparent, and it’s talking to Collab on port 9999, but in reality, we’re adding another hop in the middle so we can trace the requests to this machine from the portal (and, unlike Ethereal, ONLY those requests).
Viola! Now when I navigate to a Community that has Collaboration portlets on it, I can see all the traffic that the portal is sending to Collab:
This can be even more useful when diagnosing strange errors; occasionally PTSpy doesn’t generate useful errors, and the errors that are actually displayed in the portal aren’t much help either. By monitoring the traffic between different components, you can often find a more specific error message in these requests. Also note that you don’t have to just use the tool between portal components; I recently solved an issue with LDAP authentication by putting a tunnel between the LDAP AWS and the LDAP server itself. The portal was throwing some generic error, but in the trace, the LDAP server was very clear about the authentication credentials not being valid.