Is your feature request related to a problem? Please describe.
An IPv6-only Device never reaches the map, and until the diagnostics work there was no indication why.
gpsmap_load_devices() keeps a Device only if it passes both tests:
if (!is_ipaddress($hostip) || substr_count($hostip, '.') != 3) {is_ipaddress() accepts IPv6, but the dotted-quad count rejects it immediately afterwards. In 2026 that is a real exclusion rather than an edge case.
Describe the solution you'd like
Treat the address family as a property of the Device rather than assuming four octets.
This is not a one-line change. The subnet drill-down is built entirely on octet slicing:
$octets = array_pad(explode('.', $host->iprange), 4, '0');
$parent = implode('.', array_slice($octets, 0, $preempt)) . '.';
$child = implode('.', array_slice($octets, 0, $preempt + 1)) . '.';gpsmap_subnet_prefixes() derives /8, /16 and /24 the same way. Supporting IPv6 means a prefix concept that covers both families, with nibble or hextet boundaries for v6, and artefact filenames that survive a colon.
Describe alternatives you've considered
Mapping IPv6 Devices while leaving them out of the drill-down. Simpler, and it would at least put them on the map, but it produces a navigation tree that silently omits part of the estate, which is its own trap.
Additional context
Worth sequencing with the navigation discussion. If Sites or groups replace subnet drill-down as the organising principle, the octet dependency largely disappears and this becomes much smaller.
Is your feature request related to a problem? Please describe.
An IPv6-only Device never reaches the map, and until the diagnostics work there was no indication why.
gpsmap_load_devices()keeps a Device only if it passes both tests:is_ipaddress()accepts IPv6, but the dotted-quad count rejects it immediately afterwards. In 2026 that is a real exclusion rather than an edge case.Describe the solution you'd like
Treat the address family as a property of the Device rather than assuming four octets.
This is not a one-line change. The subnet drill-down is built entirely on octet slicing:
gpsmap_subnet_prefixes()derives /8, /16 and /24 the same way. Supporting IPv6 means a prefix concept that covers both families, with nibble or hextet boundaries for v6, and artefact filenames that survive a colon.Describe alternatives you've considered
Mapping IPv6 Devices while leaving them out of the drill-down. Simpler, and it would at least put them on the map, but it produces a navigation tree that silently omits part of the estate, which is its own trap.
Additional context
Worth sequencing with the navigation discussion. If Sites or groups replace subnet drill-down as the organising principle, the octet dependency largely disappears and this becomes much smaller.