Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I'm running on Windows and trying to get Wireshark to pick up my network traffic. It picks up all outbound and inbound traffic fine, except for a client/server I'm running on my local system. As it is, even when I'm sending packets through my LAN IP, it's still not picking up the traffic. Is something clever/stupid about Windows likely to be routing it so it doesn't travel through the network? Is there anything I can do to force the packets to meander down the intended path (ie. going out to my router and back in so Wireshark can see it)?

What I want is to ensure my packets, which are being sent out to 192.168.x.x don't get 'redirected' to 127.0.01 - which Wireshark cannot sniff. I suspect Windows is detecting I'm connecting to the same machine and is being 'clever' by skipping the network - and I need to stop it doing so.

share|improve this question
    
Just did a traceroute.. something is definitely messing with it. No hops. –  Rushyo Nov 18 '10 at 19:42
    
isn't there an official way of doing this documented on Wireshark's website? –  djangofan Nov 18 '10 at 21:39
    
They pretty much state everything they suggest is a hack, liable not to work. None worked. See accepted answer. –  Rushyo Nov 20 '10 at 12:23
add comment

marked as duplicate by Tim Brigham, dawud, Rex, mdpc, Mark Wagner yesterday

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

3 Answers

up vote 5 down vote accepted

That's the way Windows networking works - there is no loopback adapter and traffic that has the same source and destination addresses never descends the driver stack so it never reaches the Winpcap driver.

The Wireshark wiki has some more information on this here including some workarounds with the Microsoft Loopback adapter which might help.

share|improve this answer
    
Drat, bollocks, crud. The workabouts on that article don't work unfortunately. I'm going to have to route this out to the internet aren't I? -.- –  Rushyo Nov 18 '10 at 20:12
1  
You could set up a VM and move the client or server component into the VM and trap the traffic between the VM and the host - VMWare Player\VirtualBox will do the trick. It's somewhat heavy handed but provided you can separate the functionality it should work. –  Helvick Nov 18 '10 at 20:16
    
Neat idea (got VMWare Workstation + spare pcs anyway) but would make other debugging elements a nightmare. Maybe I could sit a proxy on another server on the network that redirects traffic back to the original machine. Still, all seems a bit much. –  Rushyo Nov 18 '10 at 20:23
    
Routing it through the net does the trick. Not much harm in it in this instance. –  Rushyo Nov 18 '10 at 20:50
add comment

You could try a technique called "hairpin NAT" to route your packets out-and-back through an external router/PC. This will force Windows to actually send and receive data through the NIC.

Here's how: You set up a router with two network interfaces: One interface on your network (say: 192.168.66.0/24), and one interface on a "fake" network (say: 10.10.66.0/24) that exists only for your test. (I assume your PC's address is 192.168.66.100, and that the router's NICs have addresses 192.168.66.254 and 10.10.66.254, respectively.) On the router, you set up two NAT rules (written in iptables-save format):

-t nat -A PREROUTING -p tcp -d 10.10.66.254 --dport 80 -j DNAT --to-destination 192.168.66.100
-t nat -A POSTROUTING -p tcp -s 192.168.66.0/24 -d 192.168.66.100 --dport 80 -j SNAT --to-source 192.168.66.254

The first rule is a standard "port forwarding" rule that sends all traffic bound for 10.10.66.254:80 to 192.168.66.100. The second rule is the key to "hairpin NAT". It makes all traffic from the 192.168.66.0/24 network and bound for 192.168.66.100:80 to appear to come from the router's local interface (192.168.66.254). The second rule is necessary to force the client and server (who are on the same network, 192.168.66.0/24) to route their packets through the external router instead of attempting direct delivery to each other.

With this setup, you can now use Wireshark to capture the client/server traffic on the Windows NIC. The client initiates by connecting to the "fake" address 10.10.66.254:80, and the server should see the corresponding traffic coming from 192.168.66.254.

share|improve this answer
add comment

If you have a second NIC in the box you could setup weighted metrics with your application listening on the higher weighted metric. The machine should go out looking for the application on the lower weighted interface which might allow you to catch that traffic.

I havent verified that this will work but it's an idea to try (if you have two NICS on the machine)

share|improve this answer
add comment

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