Missing 'FriendlyName' for bridged inerfaces [Windows]

[dotpcap]

Missing 'FriendlyName' for bridged inerfaces [Windows]

[theXappy]

I went digging in the code to see where the name is resolved (from the GUID-looking id) and found this:
In LibPcapLiveDevice.cs:
In the constructor - all NICs are retrieved using .NET's NetworkInterface.GetAllNetworkInterfaces()
So while the constructor is called for every adapter, including bridged ones, the list returned from LibPcapLiveDevice does not contain those.

I used dotPeek to see check the implementation of NetworkInterface.GetAllNetworkInterfaces() inside System.Net.NetworkInformation.dll
It calls some other functions in a chain ending in an internal class called 'SystemNetworkInterface'
There's a call there to GetAdaptersAddresses from iphlpapi.dll
My understanding is that this dll can get all adapters in the system but it can be called with filtering flags. The code in .NET always uses 2 flags:
"IncludeWinds" and "IncludeGateways"
there are several other flags including "IncludeAllInterfaces"
I tried calling this function by myself with that flag and received the missing NIC, along with several other 'unusual' network adapters.

Perhaps calling the IP Helper API (iphlpapi.dll) directly from sharppcap is the solution here but this is obviously a platform specific fix and resolving the names in Mac/Linux should still use .NET's GetAllNetworkInterfaces

[chmorgan]

Hi @Wootness. This does look like an issue. I'm not sure anyone is available to look at it at the moment. I can leave this open but it likely won't get fixed unless you or someone else submits a PR to address it.

[theXappy]

Hey Chris,
I wrote a changeset which deals with this issue. I commited it to the fork of your repo I have in my account.
While it seems to solve the problem, I have 2 reasons why I'm not sure it should be merged:

1. As mentioned the problem (and solution) is platform specific.
   The changes include P/Invoke calls to iphlpapi.dll (IP Helper API) and I have no clue if that code will break compilation/run-time for OSX/Linux
   As far as I understand there isn't a way to distinguish the compiling OS in SharpPcap ATM. So to tackle that I added some OS checking code into SharpPcap,csproj which basically sets a compiler constant named "Windows" iff the code is compiled on windows.
   You might want to implement this differently.
   Following that I just wrapped anything specific to the IP Helper API access with "#if Windows" scopes I believe it's enough but didn' try compiling on OSX/Linux.
2. To call the function in iphlpapi.dll and than wrap it in a nice .NET object (a 'fake' NetworkInterface class) I had to 'borrow' some very ugly code including structs for the P/Invoke call and decompiled code from System.Net

All the relevant changes can be seen in this commit:
theXappy@535c342

To conclude: I found a working solution but I am not sure I made the changes in the nicest way possible and don't want to 'pollute' SharpPcap's master branch with them.

[chmorgan]

@Wootness ahh. Yeah we wouldn't want to add another pinvoke dependency if we could avoid it, it would break usage on macOS and linux. Is there a way to retrieve this information from a .net api instead?

[theXappy]

@Wootness ahh. Yeah we wouldn't want to add another pinvoke dependency if we could avoid it, it would break usage on macOS and linux. Is there a way to retrieve this information from a .net api instead?

None that I'm aware of.

[lextm]

@Wootness Why do you need conditional compilation against Windows? Runtime check is already in place to support the current PInvoke usage,
https://github.com/chmorgan/sharppcap/blob/master/SharpPcap/LibPcap/LibPcapSafeNativeMethods.cs#L39

[theXappy]

@Wootness Why do you need conditional compilation against Windows? Runtime check is already in place to support the current PInvoke usage,
https://github.com/chmorgan/sharppcap/blob/master/SharpPcap/LibPcap/LibPcapSafeNativeMethods.cs#L39

Oh I was not aware of those.
This might change my patch but my it'll probably still be a mess considering the decompiled classes I had to use to make it work

[chmorgan]

@Wootness how is Wireshark getting the friendly name on windows? Note that the code is open so you could check there to confirm. Also, npcap is in active development, as is libpcap so there is always some possibility to modify the upstream code to improve the situation. Agreed the guid names are ugly to look at. I'm still not convinced we want to jump to adding some 800 lines of code to resolve until we've run down those other options that could help others and are seemingly better places to put the fix.

[kayoub5]

@chmorgan Wireshark is doing

• ConvertInterfaceGuidToLuid followed by ConvertInterfaceLuidToAlias on Windows Vista and later.
• NhGetInterfaceNameFromGuid undocumented function otherwise.

Both from hIPHlpApi.

A small helper class for this would be around 30-40 lines of code.

[chmorgan]

@kayoub5 should we ask the .net core guys to add support for this to .net? Then we wouldn't need more non-net code and we could potentially get cross platform support, if there is some equivalent for Mac/Linux.

[kayoub5]

You most certainly could open a ticket, since the problem is originally a .NET problem.
However I doubt you would get a fix before .NET 5 unless we implement the fix ourselves.

---

On a side note, this problem could be reproduced even on non bridged networks, simply disable IPv4 and IPv6 on any adapter and it would magically disappear from GetAllNetworkInterfaces().
(We do this on same logging adapters to have the adapter only log external network without having the logging PC add any traffic)

[zbalkan]

I'd like to add a workaround I've used for this: Getting a name from the description. The device interface description gives us something like this:
Network adapter 'Adapter for loopback traffic capture' on local host

Therefore, I use the string between the single quotes. However, since the names are still null, I use a new dictionary of generated device names as key with the interface as value.