Machine scan seeing incorrect interface ID & IP/Mac during scan

[klepp0906]

Any idea why this would be behaving in such a way?

I have 3 machines, they're all picked up properly. IP/Mac/Interface ID.

My main machine it seems to want to peg my VMware Virtual Ethernet Adapter for VMNet 8 as being what its looking for.

anyone that can help id appreciate it

[klepp0906]

anyone able to tell me what this is scanning for when it does its network search?

I need to try and figure this out. I limit the IP to a range that includes the trouble pc, and it gets picked up, yet it displays the wrong IP/IP associated with my virtuallan adapter.

[basildane]

I think the scan looks for IP's that answer pings. Then it attempts to use WMI to see what's there. Of course if its not a Windows device then it only register it as an active IP address. But if it can see into WMI it will inspect it see if network is setup to enable WOL.

This is all hit-miss. It won't work in all situations. It's can be a convenience for some to help you get a lot of machines added.

[klepp0906]

yea theyre all windows devices. it detects them all correctly except for the main machine that has vlan adapters.

it picks it up properly, but sees and thus wants to assign the vlan IP and mac address.

this is odd as i dont even have it scanning for the range that the vlan adapters IP falls within.

Above all else I want to make sure this weird behavior isnt going to affect me elsewhere down the road, hence why I wanted to understand why it was doing so.

Similar to a network interface index value conflicting with a vlan adapter that prevented wake on lan from working in the past.

the pc works/wakes/can wake others fine so long as I add the mac/ip manually. So ultimately im just trying to understand why it isnt picking up my actual physical NIC as being top dog.

thanks for the reply :)

[klepp0906]

Here is a quote from a helpful gentleman over on the vmware forums. Hopefully someone with the time, and ability to address the shortcoming can shore things up so to speak. Sounds like a likely candidate for the issue.

So... Looking through the code, I think function GetWmIdata (GetWMIdata) in Search.vb has a logic defect (if I am understanding the code correctly – I last used Visual Basic about 20 years ago, and last used CIM/WMI many years ago, so take my analysis with a large pinch of salt). Upon connecting to a remote host, it fetches the computer name and OS name, then loops through every IP-enabled NIC on the host. For each NIC in the host, it:

Picks the last IP address assigned to the NIC and uses that as "ipaddress";

Extracts` the description from the NIC and uses that as "netinterface";

Extracts the MAC address from the NIC and uses that as "macaddress";

Checks the NIC for power-management capabilities, wake capabilities and WoL capabilities. When multiple NICs are present, it appears to continue looping away until it has enumerated them all, but in each case it overwrites any previously-discovered properties with those of the latest-discovered NIC (except for the power-management and wake capabilities... those end up set to true if any NIC has those capabilities). I do not see any code there which actually verifies that it is choosing the properties from the NIC which is connected to the interface over which it is performing the probe... or even that the interface is reachable from the network from which the probe is being performed. It simply walks the list of NICs in the system and ends up using the properties from the last NIC it finds, whichever that happens to be.

I think function GetWMIdata needs to evaluate the reachability of that interface from the scan host, and take that into consideration when choosing which NIC's properties to return.

Hope this is of some use (and is not completely misleading or wrong...).

[dariusd0]

I'm the one who wrote the above-quoted comment in the VMware Communities. I probably should have posted it here myself. 😄

@basildane Let me know if my feedback is useful or is off the mark. I'm not sure what an appropriate fix is for the issue... That is far beyond my Visual Basic and WMI skillz.

[basildane]

Your explanation sounds reasonable, I haven't looked at the code in years but I will try and investigate that. Thanks for analyzing it.