Diversion Resolve IPv6 Hostnames

[zaxcom]

Is there a way for Diversion to resolve client names in IPv6 instead of just showing the client address?

 

[ColinTaylor]

Set "Diversion" as the prefix of your thread title, otherwise it's confusing.

 

[zaxcom]

yep, meant to do that. Senior moment.

 

[thelonelycoder]

Is there a way for Diversion to resolve client names in IPv6 instead of just showing the client address?

That depends, if the router UI resolves it and writes it to one of the files that Diversion checks then yes it will do it, otherwise there is no way for my software to get that info.

 

[zaxcom]

That depends, if the router UI resolves it and writes it to one of the files that Diversion checks then yes it will do it, otherwise there is no way for my software to get that info.

I am on an RT-AX86U, with the latest version of Merlin. How would one go about looking to see if the router can write to the files?

 

[zaxcom]

Looks like the router resolves the names.

 

[thelonelycoder]

Looks like the router resolves the names.

That‘s the MAC address, not IPv6 address. Diversion does not have that info.

 

[zaxcom]

Thats too bad, would be nice if it could do it like PiHole does.

 

[ColinTaylor]

Looks like the router resolves the names.

Which page of the GUI is that? I don't recognise it.

 

[zaxcom]

Its in the system Log tab

 

[zaxcom]

That‘s the MAC address, not IPv6 address. Diversion does not have that info.

Says its the IP address in the column header

 

[krwy0330]

How can I get this info with CLI?

 

[5stringdeath]

That‘s the MAC address, not IPv6 address. Diversion does not have that info.

The system log on my router has the same information. There are three columns:

Hostname / MAC Address / IP Address (which are IPv6's)

My router shows information in each column for devices.

Referring to System Log / IPV6 tab

 

[dave14305]

After you’ve viewed the tab in the GUI, you could find the info in /tmp/ipv6_client_info. The GUI collects it by running the equivalent of ip -f inet6 neigh show dev br0 | grep lladdr and parsing the MACs with the host details.

I’m not sure how useful it would be in any historic reports if using IPv6 SLAAC addresses. Too many to keep track of in my opinion.

 

[SomeWhereOverTheRainBow]

After you’ve viewed the tab in the GUI, you could find the info in /tmp/ipv6_client_info. The GUI collects it by running the equivalent of ip -f inet6 neigh show dev br0 | grep lladdr and parsing the MACs with the host details.

I’m not sure how useful it would be in any historic reports if using IPv6 SLAAC addresses. Too many to keep track of in my opinion.

I agree with dave here. IPv6 addressing can range from rather challenging to near impossible regarding adequate ipv6 hostname implementation. Pihole utilizes a very sophisticated method which relies on the storing historic connection information about the clients. Still, even with such a sophisticated method, the multiple(and temporary) addressing challenges of SLAAC proved to be too much of a bother. Piholes "default" method only holds on to the most recent information regarding ipv6 clients. Otherwise users have to turn on a resolving ipv6 address feature that performs information renew lookups similar to how the ipv4 does. Then users quickly see how those ipv6 addresses quickly fill up with multiple SLAAC addressing per client.

At that point, it really boils down to if it is worth it.

 

[sfx2000]

FWIW - in my internal openwrt builds, I use mDNS/Avahi to resolve internal IPv6/IPv4 hostnames...

And I just worry about the link-local records, not the global scope ones, as those can/do change - link-local (fe80::/10) are typically consistent with the MAC addr associated with it.

MAC addr, since this is lower layer, you can correlate the IPv4 and IPv6 entries accordingly...

Note - I use avahi, but a combo of ARP (ipv4) and NDP (ipv6) can do the same thing, and now thinking about it, I might rejigger my implementation to see if that is more effective or not...

 

[SomeWhereOverTheRainBow]

FWIW - in my internal openwrt builds, I use mDNS/Avahi to resolve internal IPv6/IPv4 hostnames...

And I just worry about the link-local records, not the global scope ones, as those can/do change - link-local (fe80::/10) are typically consistent with the MAC addr associated with it.

MAC addr, since this is lower layer, you can correlate the IPv4 and IPv6 entries accordingly...

Note - I use avahi, but a combo of ARP (ipv4) and NDP (ipv6) can do the same thing, and now thinking about it, I might rejigger my implementation to see if that is more effective or not..

For my network, I have a secondary custom prefix that I advertise with DNSMASQ because my gua prefix changes often. And no I am not talking about NATTING ULA Prefixes, each device still gets their own address from the main prefix, but internal name resolution between devices is done with the secondary custom prefix. My br0 interface still gets the main prefix, but I have a script that creates another generic prefix that doesn't change for communication and name resolution within my network. Basically, so I can have a static internal addressing setup, while at the same time i don't really care about the external route-able addresses changing.