Please follow the below template, it will help us to help you!
Expected Behaviour:
Active DHCP leases show MAC address in form of XX:XX:XX:XX:XX:XX where the XX the MAC address.
Actual Behaviour:
There is three entries in the active DHCP showing addresses in form of
YY:YY:YY:YY:XX:XX:XX:XX:XX:XX:00:00:00:00:00:00
The YY part is common amongst the three entries
The XX part is MAC address of other computers
The last part is usually string of 00 but also there is one with 01 in the middle.
Please post a screen capture of what you see (blur the identifying details as needed), but leave at least both ends of the string In this forum, you can directly paste a screen capture into a reply.
This looks like a rare occassion where a Client ID (normally only used wih DHCPv6) is used insetad of a MAC for registration of an IPv4 address via DHCP.
While this would not happen for an ordinary NIC, it may occur if you'd configure logical interfaces (like eth0:1).
You may have done this yourself to assign multiple IPs to the same interface on a machine, or certain types of devices may auto-configure this, e.g. network equipment like switches. A VM.might configure this as well, to share the host systems NIC.
What devices do match the corresponding IP addresses .119, .180, .193?
The middle corresponds to MAC addresses of some computers on my network
The one with IP address ending 119 is a intelnuc that is attached to my tv. it doesn't run any VMs
Ending 180 and 193 is a desktop which does run VMs but the those VMs (and the desktop/nuc above) all have other entries in the network table (with ipv4 / ipv6) all correctly labeled.
Perfectly legit, IAID calculations may include MAC addresses, and Client ID may itself be formed by combining DUID and IAID.
If by network table you are referring to Pi-hole's Network overview:
The information showing there is sourced from ARP or most recently NDP, while lease information is based on DHCPv6 and DHCP - different protocols, so they are expected to differ in places.
Since you are able to identify devices, I'd say you network looks unusual, but OK.
could you explain a bit more why this is happening?
The pihole box does't have the DHCP v6 set - so I am not sure why is is using these long identifiers and not the MAC address. Also with the IPs that the leases correspond to - they don't seem to be ping-able or otherwise connected to the boxes (they have other IP assignments and working fine off those)
Because your clients are providing that information via DHCP.
I probably should emphasise that this not related to Pi-hole, nor strictly to any one DHCP server, but to your clients behaviour.
As to why your clients are doing that: Only the programmer of that specific network code for your devices might know that.
Yes, those leases have been assigned via DHCP:
This is covered by RFC 2131, RFC 3315, RFC 8415 and especially RFC 4361 (I am sure I forgot to include at least half of the relevant other RFCs).
That may be a networking issue, or no issue at all (it's not unusual for devices to not answer ping), and has to be resolved from sources within your network and some additional research on networking.
Ok. Probably a little too difficult to really find out further given I don't really want to dig into Windows internal networking code and since those phantom IP addresses don't seem to be causing any problem or otherwise interfering with the normal IP setup I'll just ignore the extraenous entries.
This is accessible? In my understanding, Windows is a closed black-box containing (sometimes unpleasant) surprises around the corner. A lot of their security concept seems to be on security-by-obscurity*. Which is bad. Did this change?
*) My spellchecker suggested security-by-absurdity. I like this suggestion.
