I've had great success using ethernet sniffers (such as Etherdetect, or Ethereal) to troubleshoot communication problems. Installing a sniffer, even after installing the required WinPcap packet capture library, doesn't require a reboot. I frequently use sniffers to troubleshoot servers and desktops alike. Ethernet sniffers should be a standard tool in your development troubleshooting toolkit, too.
I suppose you could always try mapping localhost to an external interface in hosts, or just using an external proxy (and using the external interface IP), but if the app explicitly binds to only the localhost, you’ll find that most anything you try is going to be a problem.
Pop over the sysinternals, and try TCPView and TDIMon (in the networking section). They MIGHT (heavy grain of salt here) do what you need, but you’ll definitely have to write an app to translate their logs into something more useful for parsing.
A sniffer can capture traffic, but it’s a little harder to actually change it (inbound or outbound). It’s also not as useful when the content is compressed or encrypted But if you’re looking at packet-level stuff it can’t beat.
A proxy isn’t the only option…there’s several for localhost. The easiest is tcptrace (http://www.pocketsoap.com) that’s a port forwarder…like localhost:81-localhost:80
Another is a tool like TamperIE that lets you modify the POSTs and GETs just before they hit WinInet.
Personally, I prefer to do sniffing at the ethernet level because it’s the most flexible, and it’s not tied to any particular protocol (HTTP), or application (web browser).
Localhost packets don’t pass through the
regular network stack, so they’re invisible
to an ethernet sniffer.
– Jeff Atwood
This isn’t exactly true.
Localhost packets do “pass through [much of] the regular network stack”. Localhost packets just don’t pass through any physical NIC or NIC driver layer ( possibly the network interface layer).
And since many Ethernet sniffers only record packets that pass through the NIC or NIC driver layer, localhost packets are not recorded.
Actually, there are several solutions to sniff a local (as in the same machine) connection:
1.You could run either server/service or client/consumer in a VM with virtual NATed or switched network (not bridged). I use VMware so my experience is with this one. Then you sniff packets.
2.You install two more NICs in you machine (PCI or USB), give them valid IPs and connect them with a crossover cable (one to the other). Then bind the server/service to one of those IPs and the client/cosumer to the other. Then you sniff packets.
3.You do number 2 but additionaly, if you just have to involve localhost (127.0.0.1), you route packets that have localhost as destination through one of these NICs. You’ll have to fiddle with the routing table and I’m not sure about the exact command sequence (I have done this, but only with Linux). Then you sniff packets addressed or coming from localhost because they will pas through the complete IP stack (redirected to a physical NIC as they are).
I haven’t found a reliable way to sniff PPP traffic on WinXP systems.
For example, my connection is PPPoA, and as such, appears to Windows as a PPP connection. Ethereal (mostly Winpcap’s fault) refuses to see the traffic passing through it
I found tcptrace very useful in my case. Thanks to Scott Hanselman for mentioning it.
I have a proprietary web application that I administer my web applications with. I can stop and start them using this admin application. The admin application talks (HTTP post to localhost:1085) to a deamon running on the same box and tells it to stop/start a particular application.
So I launched the admin application, stopped the daemon (to free up port 1085), launched tcptrace and told it to listen on 1085, clicked in the admin to stop my app and tcptrace grabbed me the HTTP post request that stops my app
Now I run a job that updates a db and then restarts my app to pickup the changes.
I had a local proxy running ( WebCleaner ) to do some testing, and had no luck capturing anything with Wireshark, since it was all localhost traffic. Tried IEinspector and it worked great – its a phenomenal tool! Thanks Stefan!
Have you tried sniffing localhost by adding a route to localhost to your gateway? I think the Windows command would be:
route add 127.0.0.1 mask 255.255.255.255 gateway IP metric 1
All of your packets would appear twice though, once on the way out and again coming back in. I think you would also have to turn off the Automatic metric check box in your advanced TCP/IP settings tab.
On 2nd thought, your gateway doesn’t know what to do with an IP packet destined for 127.0.0.1, so this probably won’t work. It will if you replace the localhost IP with your NIC’s IP address though. Then you would need some internal configuration though that maps localhost to your NIC’s IP address - not too sure how to do that.
But if you’re looking at packet-level stuff it can’t beat.