Hey, I just installed Wireshark after downloading 2.0.3 on Windows 10 x64 and I can't figure out how to get it to capture packets on the local host of 192.168.xxx.xxx:myport If I build a filter after selecting my WiFi interface (the only interface with any traffic when WireShark monitors) for tcp.port == myport it captures no packets. This port is running a http server on myport. The httpd is working and running and returning the requested URLs with code 200. I can get it to capture packets though by typing in an incorrect local IP address on port 'myport' but oddly not by using the correct IP address on 'myport'. I should add I know the localhost traffic on Port 7888 is not showing on the the WiFi interface I'm monitoring but Wireshark is not offering another network interface to monitor that has traffic on it. Without the filter I can see the local IP address' TCP traffic to the internet. What am I doing wrong? Thanks. asked 16 May '16, 23:12  WireBananaSlug edited 16 May '16, 23:36 |
2 Answers:
Are you sending requests to the server from a client application on the same machine? If so, then this is an issue with capturing local loopback traffic on Windows, see the Wiki page on Loopback Capturing. Your options (as discussed on the Wiki page) are:
answered 17 May '16, 02:57  grahamb ♦ 1 @grahamb, I'm afraid there is an issue I haven't reported to @Yang Luo yet, but Microsoft seems not to route packets whose destination is an IP address of some local NIC via npcap - installed loopback adapter which is the only place where npcap can capture them. So, @WireBananaSlug, on top of what @grahamb wrote, you may have to send the http request to 127.0.0.1 rather than 192.168.x.y to be able to capture it using npcap. This may have changed recently or may change in near future, but two weeks ago I had this issue. (17 May '16, 04:04) sindy Thanks very much. (17 May '16, 10:44) WireBananaSlug @sindy I've confirmed, with npcap 0.07-r3 on Win 10, that packets sent to 127.0.0.1 are captured as such, packets to the "host.name" are captured with the APIPA address assigned to the npcap looback adaptor, and packets to a real local NIC IP are captured as such. In all cases, the source and destination MAC addresses are all zeros, and the source and dest IP addresses are the identical. Note that the packets to "host.name" used the APIPA address regardless of whether the NetBIOS or DNS name was used. (18 May '16, 02:50) grahamb ♦ @sindy, I'm curious what that issue is about "Microsoft seems not to route packets whose destination is an IP address of some local NIC via npcap"? I thought Npcap loopback adapter should have captured all the local packets. (02 Jun '16, 08:44) Yang Luo @Yang Luo, my exact setup back then was two SIP softphones running on the same machine and connected to a remote PBX via Cisco Anyconnect VPN client also running on the same machine. The PBX did not insert itself into the media path so the softphones were sending media directly to each other, both indicating in their SDPs the local IP address assigned to the virtual Anyconnect interface. If I remember right, I was capturing on the loopback interface in parallel with the virtual one created by the Anyconnect, as I was interested in the SRTP between the two softphones, and I've seen no UDP there at all - while if the call was running between one of the softphones and a remote phone also accessible via the VPN, the SRTP could be captured on the virtual interface. Unfortunately, I am unable to arrange that setup again in a short time. As soon as I can do that, I'll repeat the exercise and let you know directly by e-mail, as I think we've got quite far from the scope of this Question. What I've done right before writing this was to capture in parallel at the loopback interface and on a wireless interface switched over to monitoring mode so that the frame encapsulation would be different on each of the two interfaces and set up a call between the two softphones locally, i.e. sending not only SRTP but even SIP directly between them. And I have seen both SIP and SRTP from 192.168.x.y to 192.168.x.y (which is the address of the wireless interface assigned before I've switched it over to monitoring mode). (02 Jun '16, 15:15) sindy |
You could also try using RawCap instead; I've had good luck with it in the past. answered 17 May '16, 11:18  cmaynard ♦♦ |
I've already install nCap & it worked but maybe if it doesn't reveal the cause of the problem I'll try RawCap.
If I can have RawCap installed at the same time as nCap I will go ahead and insteall it.
I don't really now how to mark answer of the answers as valid but both nCap & RawCap work for my problem and can be used.
Thanks.
They are both comments rather than answers, but we can make them answers so you can mark them as accepted. Which one is the "best" answer for you?
You can use both npcap and rawcap at the same time, but npcap can be used directly by Wireshark (if npcap is installed in "WinPcap" mode), whereas rawcap requires you to use another application to make the capture that you can then open in Wireshark. rawcap also has a number of other limitations on use as listed on it's website.
The 1st comment, grahamb's, as it allows we to use Wireshark still and has the link the the extra information that sinday was nice enough to tell me about.
By the way, although my localhost httpd server was configured for an address on the 192 network Wireshark with nCap was able to capture the traffic on the 127 network.
@WireBananaSlug, I feel the above needs some clarification.
With npcap, you do not "capture on an IP address", you always capture on an interface. The operating system (or, more precisely, its networking stack) chooses the interface through which to send the packet depending on the packet's address (IP address in this case) when sending a packet to an external system. In case of local traffic, a special virtual interface exists in unix-like operating system, but not necessarily on Windows.
If the networking stack of Windows finds out that the packet's destination IP address matches one of its network interfaces, it delivers the packet "internally", bypassing any interface. In newer versions of Windows, this can be changed by creating the virtual interface and sending such traffic to it, which is what npcap does; the RawCap does another thing, it hooks to another place in the networking stack than the interfaces' NDIS slots for filters.
And in addition to IP addresses assigned to interfaces, there are also IP addresses with a special meaning, such as "0.0.0.0" which means "any of my interfaces' IP addresses, and "127.0.0.x" which means "myself".
Some servers can be configured to listen for new connections only on (a) particular IP address(es) if the machine they run at has several interfaces, but most of them listens on all of them (i.e. at 0.0.0.0); what exactly did you mean when you wrote
?
And a second question, the capture you have posted in your other question has been taken at the npcap - created local loop interface or using rawcap?