I am trying to do the following:
- Display a list of human-readable network interface names and their IP addresses to the user.
- Start a jpcap packet capture on the interface the user selects.
However, the following points are giving me trouble:
- jpcap only provides
PacketCapture.lookupDevices(), which returns a list of Windows' NPF driver device paths to the interfaces (e.g.\Device\NPF_{39966C4C-3728-4368-AE92-1D36ACAF6634}) and a rather bland display string (e.g.Microsoft), and no other info. So I cannot use it to construct the UI interface list. NetworkInterface.getNetworkInterfaces()provides a list of interfaces on the system with all the info I need for the UI, butNetworkInterfacedoes not provide the NDF driver device path, only display names, and device names such as "net5", "lo", etc.- jpcap's
PacketCapture#open()only accepts device paths.
The list of NetworkInterfaces that are both up and not loopback do correspond to the list of devices returned by jpcap, although they are not in the same order.
So, I can't find anything in NetworkInterface that can be passed to PacketCapture#open(), and I don't know how to get UI-appropriate info from the device paths returned by PacketCapture#lookupDevices(). PacketCapture does not accept NetworkInterface#getName(). Therefore, I'm stuck.
I have not tried this on Linux. I suspect the problem is unique to Windows, where NetworkInterface#getName() does not correspond to the device paths recognized by PacketCapture#open().
How can I get the information that jpcap needs to open the device from a NetworkInterface (or the other way around - get a NetworkInterface given a device path), or is there another approach that will allow me to just get a nice display name and IP address for each device directly from jpcap?
Windows' Registry: I've been doing some digging and have at least found information about NPF devices in the registry. Given a jpcap device path, and using either one of the techniques here or a native library, a nice adapter name (equivalent to the ones NetworkInterface returns) and the current IP address can be obtained from the registry as follows:
- Extract GUID from path (e.g.
{39966C4C-3728-4368-AE92-1D36ACAF6634}from above example). Leave the curly braces and call this . HKLM\SYSTEM\CurrentControlSet\services\Tcpip\Parameters\Interfaces\<guid>contains current IP address for device as well as some other configuration info.HKLM\SYSTEM\CurrentControlSet\services\<guid>\Parameters\Tcpipcontains similar information.- Search all subkeys of subkeys in
HKLM\SYSTEM\CurrentControlSet\Control\Class\. If a subkey is found that contains a keyNetCfgInstanceIdwhose value is <guid>, then the rest of the keys there will contain driver info - the nice display name, vendor info, etc.
I do not know how IPv6 factors into the above (there are a few registry areas with a separate Tcpip6 block of info). I also do not know if these keys are the same outside of Windows 7, but I suspect they are. I will convert the above to an answer, with example code, if no better answers are presented. I am still looking for a more direct (ideally platform-independent and registry-free) way.
Platform-Independent, NetworkInterface
Here is an alternate solution that should be platform independent although only provides info for interfaces that are up. The registry solution was my first attempt, it works well, but I believe this is a better solution as long as information about down interfaces is not required.
Method
PacketCapturecan provide a network address and subnet mask given a device string (it's an instance method, not a static method, though). For each device string inPacketCapture.lookupDevices():PacketCaptureinstance (capture does not need to be open).NetworkInterface.getNetworkInterfaces()and find one that has an address that is on the same network given by the network address and mask that jpcap returned for the device.NetworkInterface(probably) corresponds to the device string.Implementation
Prerequisites:
Issues:
Code
Code is below. Usage is free under SO's CC attribution-sharealike license. It's self-contained so I did not put it on github.
Example
Here is an example:
On my machine (same setup as registry solution), this outputs:
\Device\NPF_{691D289D-7EE5-4BD8-B5C1-3C4729A852D5} : null \Device\NPF_{39966C4C-3728-4368-AE92-1D36ACAF6634} : name:net5 (1x1 11b/g/n Wireless LAN PCI Express Half Mini Card Adapter)I did not make the output as pretty as the other solution. Note that the "virtual wifi miniport adapter" (the first one) has a null
NetworkInterfacebecause, since it is not up, a match could not be found (an IP address and network address was not present).