A customer running Windows is having issues with two server components that communicate with each other using TCP. Normally the two components live on two separate server, so Wireshark lets me easily see all of the communications at the byte level, however in this case the components must live on the same server.

Wireshark offers a few suggestions for capturing over the loopback interface, but I am hesitant to ask the customer to install the Loopback adapter (which may not even work according to that page) or mess with the routing tables of a production machine.

I was thinking that my best bet might be some sort of logging TCP Proxy (I saw a similar thread here) but I would need one that can log the individual bytes (so that I can happily analyze them later with a hex editor). I can probably write one in less than an hour, but I'm sure someone out there (I just can't find it) has already done a much better job than I can do for this one-off project, and I can't be the only person with this type of issue.


I had a service that communicated locally that I needed to debug in exactly the same manner as you describe a couple of weeks ago.

I opted to used the rinetd (http://www.boutell.com/rinetd/) program referenced in that same thread that you referenced. I reconfigured the server to send the traffic to my logging computer where I was running rinetd and proxying the traffic right back to the real destination port on the source server computer.

It was pretty easy to wire up for me, and should be for you if the server process will let you configure the traffic flow such that you can get it out to your monitoring machine.

  • Yeah that seems reasonably non-invasive, if slightly indirect – Adam Batkin Jul 24 '09 at 17:27
  • I liked it, in favor of trying to use a proxy that just dumped traffic to files, because I got the Wireshark UI "for free", rather than a raw dump of packets that I'd then have to get into a format that could be parsed. – Evan Anderson Jul 24 '09 at 17:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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