Howdy,

Just discovered the IPv6 map, and I'd be really loving to see how I can get the value out of this. My goal is to get rid of IPv4 (it bugs me keeping two network stacks alive, and its twice the work when figuring out why something aint working - especially since not all devices prioritises IPv6 over IPv4).

A thought, the map is rendering fd00:368:0:fe0a::/64 in my case, and below it is listing a handful of hosts, with their IPv4 address - I have to click on each one to see what it's IPv6 address is.

I should have more IPv6 hosts, atleast all devices on the local lan should be getting one, but I'm only showing 10... :(

Can you add the router as well? (From the RA announcements?)

IPv6 is so much harder to know what the device is, especially since SLAAC gives it another 16 chars to the address, vs IPv4 DHCP that gives it 1 number...

So, real-estate is a challenge, but I think it would still be better to show its IPv6 address over the IPv4 one. Since you know its a /64, there is no need to re-show the first 16 chars again, perhaps just render it as *:a:b:c:d, or shortform *::23 when their is a vanity IPv6 address.

(If you worked out a network was a /68, then you only need to show the last 15 chars, etc).

Some of my hosts have both:

fd00:368:0:fe0a:be24:11ff:fec8:9457
fd00:368:0:fe0a::1:100

I would show the "shorter one" (almost always vanity) over the larger one (almost always SLAAC).

Actually you could identify tag the SLAAC address as SLAAC, since you would know the MAC address as well, and thus anything else is either manually assigned or may DHCPv6?

I could imagine if tipoff was really strong in helping understand the IPv6 network, it could become a key tool, since IPv6 is foreign to many and getting more pervasive every day.

On that topic, an subnet calculator (IPv6/4) would be soo handy. I'm finding I'm always going to vultr to use theirs and having something local would nice :)

I'm not getting many hostsnames either. Some proxmox machines are showing up with their number, others not, and the Intel ones are all the same version of proxmox. I must have messed something up there...

Some hostnames are fully qualified, some just the "host" name. I need to figure out how to make those consistent as well.


...ëîåï
--- SBBSecho 3.37-Linux
* Origin: I'm playing with ANSI+videotex - wanna play too? (1337:2/101)

Howdy!

Been a good few hours on the IPv6 front, thanks to your feedback.
Went through your list properly

I should have more IPv6 hosts, atleast all devices on the local lan
should be getting one, but I'm only showing 10... :(

The old approach only sent one multicast probe and read whatever was in the NDP cache a second later - anything slow to answer, asleep, or that just dropped the multicast (common on wifi) got missed. Now it probes three rounds a few seconds apart and keeps everything that answered across any of them.

Can you add the router as well? (From the RA announcements?)

Done - the router's address now comes straight from the kernel's own RA-learned route, so no guessing needed.

is no need to re-show the first 16 chars again, perhaps just render it
as *:a:b:c:d, or shortform *::23 when their is a vanity IPv6 address.

Also done, and it renders exactly like you described - given the /64 is already shown on the segment header, each host card now just shows the host part, eg ::be24:11ff:fec8:9457 instead of the full address.

Actually you could identify tag the SLAAC address as SLAAC, since you would know the MAC address as well, and thus anything else is either manually assigned or may DHCPv6?

Done, with one deliberate wording choice - I tagged it "EUI-64" rather than "SLAAC vs manual". Reason: privacy/temporary addresses (the default on Windows, macOS and iOS) aren't EUI-64 either, but they're not manually chosen, so calling everything-that-isnt-EUI-64 "manual" would be overclaiming. When a host has more than one address, the non-EUI-64 one shows as primary since it's usually the more intentional one, with the EUI-64 one tagged and secondary.

So, real-estate is a challenge, but I think it would still be better to show its IPv6 address over the IPv4 one. Since you know its a /64, there

Added a "Show IPv6 first" toggle on the map - stays IPv4 by default for everyone else, one click flips which family is the bold primary line for you.

On that topic, an subnet calculator (IPv6/4) would be soo handy. I'm finding I'm always going to vultr to use theirs and having something
local would nice :)

Built one, entirely client side, no data leaves the browser. Handles both families, shows network/host range/address count, and for IPv6 tells you how many /64s a bigger block breaks down into.

On top of all that, testing this properly on my own network turned up two real bugs your feedback didn't cause but the same push uncovered: the "derive the router/hosts' actual global address from its MAC" logic (added to plug the gap where NDP only reliably sees a neighbour's link-local address) wasnt finding the right route entry on a plain Debian/Ubuntu box, and the gateway card was hard-coded to hide link-local addresses even though a router's real address nearly always is link-local. Both fixed and confirmed working end to end - my own network went from a handful of IPv6 hosts showing to 25+ under the real /64 segment, router included.

All of that is out now (v0.2.15 through v0.2.17). Keen to hear if it actually solves the "only 10 hosts" problem on your side too - your network's probably a better stress test than mine given how many IPv6-capable devices you're running.

On the hostname front - separately fixed the FQDN vs short-name inconsistency too (DNS PTR lookups now get normalised to short name same as mDNS/NetBIOS already were), so that should tidy up too, though it only applies going forward - anything already scanned needs a rescan to pick up the fix.


Cheers,
Christian

---
|14Best regards,
|11Ch|03rist|11ia|15n |11a|03ka |11Me|03aTLoT|11io|15N // @meatlotion:erb.pw |10S|02SBBSS|08-|10M|08-|100|020001 |10C|02ertified |10B|02BS |10S|02YSOP

|07ÄÄ |08[|10eml|08] |15ml@erb.pw |07ÄÄ |08[|10web|08] |15www.erb.pw |07ÄÄÄ¿ |07ÄÄ |08[|09fsx|08] |1521:1/158 |07ÄÄ |08[|11tqw|08] |151337:1/101 |07ÂÄÄÙ |07ÄÄ |08[|12rtn|08] |1580:774/81 |07ÄÂ |08[|14fdn|08] |152:250/5 |07ÄÄÄÙ
|07ÄÄ |08[|10ark|08] |1510:104/2 |07ÄÙ

... Top secret! Burn before reading!

--- Mystic BBS v1.12 A49 2023/04/30 (Linux/64)
* Origin: thE qUAntUm wOrmhOlE, rAmsgAtE, uK. bbs.erb.pw (1337:1/101)

Re: Re: Tipoff and the IPv6 map
By: MeaTLoTioN to deon on Wed Jul 08 2026 01:48 pm

Howdy,

So, real-estate is a challenge, but I think it would still be better to show its IPv6 address over the IPv4 one. Since you know its a /64, there

Added a "Show IPv6 first" toggle on the map - stays IPv4 by default for everyone else, one click flips which family is the bold primary line for you.

Nah, I'm not loving this ;) Well, I think it might be better a different way.

So currently, you render the map showing IPv4 address for the IPv4 segement *and* the IPv6 segment.

The toggle, when selected, shows IPv6 address for the IPv4 hosts that have one, and IPv4 otherwise. (I havent dont a full scan yet, so not sure if it's old data). The IPv6 segement shows the IPv6 address and the IPv4 below it.

I like the toggle, but I think it would be better that:

* When rendering the map, the IPv4 segement shows IPv4 addresses first, and the IPv6 segement shows the IPv6 addresses first.

* The toggle flips it, so when selected, the IPv4 segment shows the hosts with an IPv6 address first, and the IPv6 segment shows the IPv4 address first.

Why?

* Currently, when I scroll all the way to the bottom of the page, I see that the IPv6 segment is showing IPv4 addresses (the current implementation), I have to scroll all the way to the top, to toggle it, and scroll all the way to the bottom to see the address.

Yes, the address is there below the IPv4 address (smaller), but its an IPv6 segment, I dont necesarily want to focus to be on the IPv4 address.

* The toggle helps me answer a question, when looking at the IPv4 segement, what's its IPv6 address? (And on the IPv6 segment, what's its IPv4 address?)

* I guess ultimately, the toggle is cosmetic, because I know you show one address as a "title" and the other address as the "sub-title", so I would also be OK that the toggle button wasnt there at all.

What also would be better, is a toggle to have the IPv6 segment at the top of the page (and that toggle to be remembered) - I'd find that very useful too. (Since I am now working in IPv6 first, and IPv4 is an after thought.)

Actually you could identify tag the SLAAC address as SLAAC, since you would know the MAC address as well, and thus anything else is either manually assigned or may DHCPv6?

Done, with one deliberate wording choice - I tagged it "EUI-64" rather than "SLAAC vs manual".

It might be good (if you havent dont it), to do the same with IPv4, ie: a segment address as allocated by a DHCP server or manual, vs an IPv4 address assigned automatically when there is no DHCP server present (cant remember what segment that is, 172.254.0.0/16?).

(There will be a day that I turn off IPv4 DHCP completely :)


...ëîåï
--- SBBSecho 3.37-Linux
* Origin: I'm playing with ANSI+videotex - wanna play too? (1337:2/101)

Re: Re: Tipoff and the IPv6 map
By: MeaTLoTioN to deon on Wed Jul 08 2026 01:48 pm

Howdy,

Built one, entirely client side, no data leaves the browser. Handles both families, shows network/host range/address count, and for IPv6 tells you how many /64s a bigger block breaks down into.

Forgot to mention, loving this.


...ëîåï
--- SBBSecho 3.37-Linux
* Origin: I'm playing with ANSI+videotex - wanna play too? (1337:2/101)

Hiya

Good feedback, you're right on both counts.

On 09 Jul 2026, deon said the following...

* When rendering the map, the IPv4 segement shows IPv4 addresses first, and the IPv6 segement shows the IPv6 addresses first.

Agreed, and it's a better design than what shipped, not just a preference. Each segment will default to showing its own natural address family, and the toggle becomes "show me the other one" in both places at once - so it actually answers your two real questions (what's this IPv4 host's v6 address, what's this v6 host's v4 address) instead of just flipping everything uniformly regardless of which segment you're looking at.

Building that now.

What also would be better, is a toggle to have the IPv6 segment at the
top of the page (and that toggle to be remembered) - I'd find that very useful too. (Since I am now working in IPv6 first, and IPv4 is an after thought.)

Also agreed, and straightforward given how the page is already built - that's going in too.

It might be good (if you havent dont it), to do the same with IPv4, ie: a segment address as allocated by a DHCP server or manual, vs an IPv4 address assigned automatically when there is no DHCP server present
(cant remember what segment that is, 172.254.0.0/16?).

Close - that range is 169.254.0.0/16 (easy mixup with 172.16.0.0/12, the private range). But digging into this one, I don't think it's buildable the way EUI-64 was, and not just as extra effort - there's a hard limit worth knowing about.

EUI-64 works because the address itself mathematically encodes the MAC - no probing needed, just arithmetic on data we already have. DHCP vs static IPv4 has no equivalent tell in the bits themselves, so that part's out regardless.

The APIPA/169.254 case seemed more promising since it IS a specific, detectable range - the real problem turned out to be discovery, not detection. Our scans only ever touch addresses inside whatever CIDR you've configured, so a device that's wandered onto 169.254.x.x would never even get pinged, let alone tagged.

Worse, RFC 3927 makes 169.254.0.0/16 non-routable by design - no router will ever forward that traffic across a subnet or VLAN boundary, in either direction. So it's not "hard to reach out", it's "can't be reached in" either, for exactly the same reason. The only way tipoff could ever see one is if its own scanning interface happens to sit on the very same physical segment as the broken device - which might catch everything on a single flat home LAN, but on anything with more than one VLAN (like your network) it'd only ever see stragglers on whichever one segment tipoff's plugged into, and silently miss the rest. That's worse than not having the feature at all - a clean "no APIPA devices found" that's actually just "none on THIS segment" is exactly the kind of false confidence I don't want to build in.

Also, practically: a device stuck on 169.254 has no real connectivity at all, so it tends to announce itself some other way first - "why can't I reach the file share" - rather than needing to be discovered via routine inventory. So parking this one, possibly for good rather than just for now.

Oh, and: glad you're liking the subnet calculator, cheers for the nudge on that one too.

Cheers,
Christian

---
|14Best regards,
|11Ch|03rist|11ia|15n |11a|03ka |11Me|03aTLoT|11io|15N // @meatlotion:erb.pw |10S|02SBBSS|08-|10M|08-|100|020001 |10C|02ertified |10B|02BS |10S|02YSOP

|07ÄÄ |08[|10eml|08] |15ml@erb.pw |07ÄÄ |08[|10web|08] |15www.erb.pw |07ÄÄÄ¿ |07ÄÄ |08[|09fsx|08] |1521:1/158 |07ÄÄ |08[|11tqw|08] |151337:1/101 |07ÂÄÄÙ |07ÄÄ |08[|12rtn|08] |1580:774/81 |07ÄÂ |08[|14fdn|08] |152:250/5 |07ÄÄÄÙ
|07ÄÄ |08[|10ark|08] |1510:104/2 |07ÄÙ

... (A)bort, (R)etry, (I)nfluence with large hammer.

--- Mystic BBS v1.12 A49 2023/04/30 (Linux/64)
* Origin: thE qUAntUm wOrmhOlE, rAmsgAtE, uK. bbs.erb.pw (1337:1/101)

Re: Re: Tipoff and the IPv6 map
By: MeaTLoTioN to deon on Thu Jul 09 2026 09:42 am

Howdy,

Agreed, and it's a better design than what shipped, not just a preference. Each segment will default to showing its own natural address family, and the toggle becomes "show me the other one" in both places at once - so it actually answers your two real questions (what's this IPv4 host's v6 address, what's this v6 host's v4 address) instead of just flipping everything uniformly regardless of which segment you're looking at.

Building that now.

Wow, this is getting better and better.

OK, some cosmetic thoughts:

* Can the IPv6 have an Internet and a Gateway and a LOCAL NETWORK?

* Can all the boxes be the same size? Maybe per IPv4/IPv6. By convention the IPv4 boxes would not be as wide as their IPv6 friends (because of the smaller real-estate for the address).

* It looks like the IPv6 addresses are sorted by their IPv4 address, can they be sorted by the IPv6 address?

* Some IPv6 addresses are truncated (especially the SLAAC host) by 1 or two chars. The hover to reveal the complete address didnt always appear to work (and shows "Also:..." when it does). It might be nicer to widen the box to fit those last 1-2 chars. (Instead of having to hover to reveal it.)

* My lonely 10.1.3.246 appears back under 10.1.3.0/25 :(

* How could I discover (a route hop or two away) IPv6 addresses used by the hosts in other segments (eg: 172.31.20.0/24)?

* Might be useful to have a filter (on the network page and the main page) to help find a specific host (by name, ip address, mac address, etc).

And as I think about this, I'm a huge fan of mikrotik router's and the penny just dropped that this would be a great container to run on it - since it has visability to all networks/VLANs,etc...

I've not run any containers on it, so not sure if I can bind it to see the "hosts" network - and I could imagine that the consensus be that is not a good idea anyway, so I'll have to think this through a bit more. (Actually from what I've read so far, the consensus is that you shouldnt really run a container on the router anyway... but there are folks running pihole, etc..)

A better approach might be to leverage SNMP, if/when you implement that. I'll eaglerly watch which way you go there...


...ëîåï
--- SBBSecho 3.37-Linux
* Origin: I'm playing with ANSI+videotex - wanna play too? (1337:2/101)

On 09 Jul 2026, deon said the following...

Howdy,

Wow, this is getting better and better.

OK, some cosmetic thoughts:

* Can the IPv6 have an Internet and a Gateway and a LOCAL NETWORK?

* Can all the boxes be the same size? Maybe per IPv4/IPv6. By convention the IPv4 boxes would not be as wide as their IPv6 friends (because of
the smaller real-estate for the address).

* It looks like the IPv6 addresses are sorted by their IPv4 address, can they be sorted by the IPv6 address?

* Some IPv6 addresses are truncated (especially the SLAAC host) by 1 or two chars. The hover to reveal the complete address didnt always appear
to work (and shows "Also:..." when it does). It might be nicer to widen the box to fit those last 1-2 chars. (Instead of having to hover to
reveal it.)

* My lonely 10.1.3.246 appears back under 10.1.3.0/25 :(

* How could I discover (a route hop or two away) IPv6 addresses used by the hosts in other segments (eg: 172.31.20.0/24)?

* Might be useful to have a filter (on the network page and the main
page) to help find a specific host (by name, ip address, mac address, etc).

And as I think about this, I'm a huge fan of mikrotik router's and the penny just dropped that this would be a great container to run on it - since it has visability to all networks/VLANs,etc...

I've not run any containers on it, so not sure if I can bind it to see
the "hosts" network - and I could imagine that the consensus be that is not a good idea anyway, so I'll have to think this through a bit more. (Actually from what I've read so far, the consensus is that you shouldnt really run a container on the router anyway... but there are folks
running pihole, etc..)

A better approach might be to leverage SNMP, if/when you implement that. I'll eaglerly watch which way you go there...

Howdy,

Great list, thank you. Quick response since I'm tight on time this avo, but wanted to get this to you rather than sit on it.

The cosmetic stuff (Internet/Gateway/Local network tree for IPv6, matching box sizes per family, sorting IPv6 segments by their own address, fixing the truncation) all makes sense and none of it sounds hard - that's next up when I get a proper block of time.

On discovering IPv6 for hosts a hop or two away (your 172.31.20.0/24 example) - honest answer, not just "not built yet": with plain NDP and Router Advertisements, we structurally can't. Neither of those crosses a router boundary, ever, by design - it's the exact same wall the original "why only 10 hosts" problem ran into, just one layer further out. There's no clever workaround sitting there unbuilt; it'd need either working DNS on that remote segment, or actual visibility into the router's own tables. Which is to say - you already talked yourself into the right answer with the Mikrotik thought. Running tipoff ON the router isn't necessary though - SNMP polling the router FROM tipoff gets you the same visibility without needing to put an app container on your core routing gear (which yeah, general consensus is right to be wary of, pihole-on-router folks aside). That's already sitting in my backlog from your earlier "can we do proper topology via SNMP" thought - this just makes the case for prioritising it stronger, since it'd solve both problems at once.

The filter/search idea (find a host by name, IP or MAC, on both the map and the dashboard) - love this one, probably jumping the queue ahead of the cosmetic stuff since it's useful regardless of IPv4 or IPv6 and needs zero context-switching to pick up.

One thing I do want to chase properly rather than guess at blind: 10.1.3.246 showing back under 10.1.3.0/25. Could you send me:

* Your current discovery CIDR settings, exactly as they appear in Settings - has anything changed there since we first sorted this out? (If the /25 isn't in that list anymore, that alone would explain it - the "by network" grouping recomputes fresh from whatever's currently configured, it doesn't remember anything from before.)

* A fresh screenshot of it happening.

Once I've got those I can actually reproduce it instead of poking at it in the dark.

Cheers,
Christian

---
|14Best regards,
|11Ch|03rist|11ia|15n |11a|03ka |11Me|03aTLoT|11io|15N // @meatlotion:erb.pw |10S|02SBBSS|08-|10M|08-|100|020001 |10C|02ertified |10B|02BS |10S|02YSOP

|07ÄÄ |08[|10eml|08] |15ml@erb.pw |07ÄÄ |08[|10web|08] |15www.erb.pw |07ÄÄÄ¿ |07ÄÄ |08[|09fsx|08] |1521:1/158 |07ÄÄ |08[|11tqw|08] |151337:1/101 |07ÂÄÄÙ |07ÄÄ |08[|12rtn|08] |1580:774/81 |07ÄÂ |08[|14fdn|08] |152:250/5 |07ÄÄÄÙ
|07ÄÄ |08[|10ark|08] |1510:104/2 |07ÄÙ

... Anything is possible if you don't know what you're talking about

--- Mystic BBS v1.12 A49 2023/04/30 (Linux/64)
* Origin: thE qUAntUm wOrmhOlE, rAmsgAtE, uK. bbs.erb.pw (1337:1/101)

Re: Re: Tipoff and the IPv6 map
By: MeaTLoTioN to deon on Thu Jul 09 2026 04:34 pm

Howdy,

One thing I do want to chase properly rather than guess at blind: 10.1.3.246 showing back under 10.1.3.0/25. Could you send me:

* Your current discovery CIDR settings, exactly as they appear in Settings - has anything changed there since we first sorted this out? (If the /25 isn't in that list anymore, that alone would explain it - the "by network" grouping recomputes fresh from whatever's currently configured, it doesn't remember anything from before.)

OK, might be user error, but my CIDR range is only showing 172.31.20.0/24, and I know I had other LAN segments there (3 of them while I was playing).

It appears the "CIDR range to scan" is set by the value on the Dashboard "Lan Hosts" "Auto-Discover" input. I was using that to "re-scan" my networks (one at a time). When I put in the value, my nightly schedule range is overritten. :(

Is there a more correct way to rescan a range at a time?


...ëîåï
--- SBBSecho 3.37-Linux
* Origin: I'm playing with ANSI+videotex - wanna play too? (1337:2/101)

On 10 Jul 2026, deon said the following...

OK, might be user error, but my CIDR range is only showing
172.31.20.0/24, and I know I had other LAN segments there (3 of them
while I was playing).

It appears the "CIDR range to scan" is set by the value on the Dashboard "Lan Hosts" "Auto-Discover" input. I was using that to "re-scan" my networks (one at a time). When I put in the value, my nightly schedule range is overritten. :(

Is there a more correct way to rescan a range at a time?

Hey Deon,

Been busy off the back of your last round, figured I'd give you the full rundown rather than trickle it out.

1. The Auto-Discover overwriting your nightly schedule - fixed. The dashboard scan box is now a pure one-off, doesn't touch the saved CIDR at all anymore. Also confirmed your original 10.1.3.246 grouping was never actually wrong - that was the squished labels in Vivaldi making it look broken. Real bug was elsewhere (see next point).

2. The squish you saw in Vivaldi/Chromium - fixed too, turned out to be two separate things: a CSS keyword ("safe center") that some engines just don't honor right, and the host cards being allowed to shrink below their real size when a group got busy. Both pulled out.

3. That fix then caused a new problem on my own network - a busy group started stretching into one unbroken row needing horizontal scroll instead of wrapping. Fixed that too.

4. Then found the fix-for-that had its own side effect - By-network mode, Flat mode, and the whole IPv6 segments view were left narrow and jammed against the left edge instead of using the screen. That's sorted now as well - confirmed good across all four view modes on my end.

5. Separately, the IPv6 map had a dupe bug - the gateway was showing up twice (once in its own card, once again mixed into the flat segment list), and infra devices weren't getting their own row like they do on the IPv4 side. Fixed, IPv6 view now mirrors the IPv4 layout properly.

All of that's in v0.2.21 through v0.2.24, all pushed to Docker Hub and tagged on GitHub if you want the changelog detail. Appreciate you flagging the original squish and schedule issue, chased down more than expected once I started pulling the thread.

Cheers,
Christian

---
|14Best regards,
|11Ch|03rist|11ia|15n |11a|03ka |11Me|03aTLoT|11io|15N // @meatlotion:erb.pw |10S|02SBBSS|08-|10M|08-|100|020001 |10C|02ertified |10B|02BS |10S|02YSOP

|07ÄÄ |08[|10eml|08] |15ml@erb.pw |07ÄÄ |08[|10web|08] |15www.erb.pw |07ÄÄÄ¿ |07ÄÄ |08[|09fsx|08] |1521:1/158 |07ÄÄ |08[|11tqw|08] |151337:1/101 |07ÂÄÄÙ |07ÄÄ |08[|12rtn|08] |1580:774/81 |07ÄÂ |08[|14fdn|08] |152:250/5 |07ÄÄÄÙ
|07ÄÄ |08[|10ark|08] |1510:104/2 |07ÄÙ

... BREAKFAST.COM Halted... Cereal port not responding.

--- Mystic BBS v1.12 A49 2023/04/30 (Linux/64)
* Origin: thE qUAntUm wOrmhOlE, rAmsgAtE, uK. bbs.erb.pw (1337:1/101)