Bug: rfc1918 range handling.

[Stoatwblr]

Problem:

When fusioninventory does a netinventory or netdiscovery, it insists on renaming anything with a RFC1918 address (10., 191.168., 172.{16..32}.*) to "internal", even if there is functioning DNS for the address inside the network.

This is highly undesireable in an enterprise network with several thousand hosts that have RFC1918 assignments and valid DNS within the network.

What should happen:

Fusioninventory should respect existing names if they match dns lookups. Ideally fusioninventory should use DNS lookups to populate unknown entries, as long as fqDNS lookups verify the data.

arbitrarily renaming existing and named entries to "internal" is counterproductive.

[g-bougard]

Hi @Stoatwblr I agree with you but can you be more accurate giving us an example of what is renamed as we will need to create some related unittests ? Personally, I didn't notice such comportment with agent so I don't see where to start. Thanks

[Stoatwblr]

I have a large number (~800) of internal hosts - eg all campus switches, printers, WAPs, network cameras, ancilliary equipment, etc. These are all DNSed as something like switch-blah.mars, switch-foo.mars, switch-bixx.mars. Printers/cameras/waps etc are similarly named.

When they get scanned by netdiscovery, it appears to overwrite the hostname part of the ethernet device with "internal" but leaves the domain part intact. It's possible to mitigate the behaviour by manually creating a second or aggregation device with the same mac address. Fusioninventory usually(*) leaves that one alone, but it's a lot of extra effort

(*) But not always. There doesn't seem to be any pattern to the replacements other than "if it doesn't do it, it won't do it in future"

[g-bougard]

@Stoatwblr looking at that old issue, does this problem still exists ?