Let me know if you use it and if it's useful to you =)
Re: My latest project - "TipOff"
By: MeaTLoTioN to All on Thu Jul 02 2026 11:52 pm
Howdy,
Let me know if you use it and if it's useful to you =)
Just had a play today - nice tool, well done.
Be keen to see where you take this - I think there could be a few great things added.
* I see from the mac address you can identify the vendor - be good to identify all VMs (from their mac)
* Might be good to be able to group stuff, ie: seperate the appliance
from the homelab, etc...
* Could be helpful to have some lan topology if you can get it. ie: I
dont use a /24 on the same wire - some devices I route to, so it could
be useful to find out which devices are acting as a router
* Wondering how you could do IP6?
* I see from the mac address you can identify the vendor - be good to identify all VMs (from their mac)
* Might be good to be able to group stuff, ie: seperate the appliance
from the homelab, etc...
* Could be helpful to have some lan topology if you can get it. ie: I
dont use a /24 on the same wire - some devices I route to, so it could
be useful to find out which devices are acting as a router
* Wondering how you could do IP6?
Do a `docker compose pull && docker compose up -d` and you'll have all of these =)
* Could be helpful to have some lan topology if you can get it. ie: I dont use a /24 on the same wire - some devices I route to, so it could be useful to find out which devices are acting as a routerDo a `docker compose pull && docker compose up -d` and you'll have all of these =)
MAC Address identify is a little better, can identify which hosts are VM's if the MAC address matches a known template.
The network topology is not 100% fot me. To give you an example, at
home, I use 10.1.3.0/25 for my homelab. Tipoff is running on 10.1.3.54.
Thus everything on 10.1.3.0/25 you'll get a MAC address and know its "local", if you havent figured that out from quizzing 10.1.3.54 network routing table.
10.1.3.192/28 is running inside an emulator off of 10.1.3.111 and you
may be able to work that out via the same way traceroute does. Those addresses wont have a MAC address (from 10.1.3.54) - but they are
grouped under 10.1.3.0/24 (even though I choose "network" from the
network map).
Simularly 10.1.3.240/29 is another network via my core router 10.1.3.1.
Interestingly, my wifi is 172.31.20.0/24 and on it I have my home assistant VM, it shows as "infrastructure" at the top of the network diagram, next to 172.31.20.1 - what makes it "infrastructure" and not a "device"?
It would be ideal if 10.1.3.1,172.31.20.1,10.1.3.246 were discovered as the same router.
MAC Address identify is a little better, can identify which hosts are V if the MAC address matches a known template.
How do I define a mac mask, so that all my proxmox and esx machines are discovered as a VM?
I've had a look at the issues you raised:
On 04 Jul 2026, MeaTLoTioN said the following...
I've had a look at the issues you raised:
Do a `docker compose pull && docker compose up -d` now and hopefully you'll get some changes and they'll work a bit better for you.
In the settings, you can now add a custom VM MAC filter(s) (comma separated). All gateways from routing table should now show correctly/better ASUS removed from infra
Multiple gateway nodes in the topology gateway tier side-by-side
By network grouping - hosts that fall outside your entered discovery CIDRs (like 10.1.3.192/28 when you've only entered 10.1.3.0/25) have no CIDR context so they fall back to /24 grouping. The fix there is actually on your end - adding 10.1.3.192/28 and 10.1.3.240/29 as discovery CIDRs will get them grouped correctly. They can be comma separated in the settings page.
By network grouping - hosts that fall outside your entered discovery CI (like 10.1.3.192/28 when you've only entered 10.1.3.0/25) have no CIDR context so they fall back to /24 grouping. The fix there is actually on end - adding 10.1.3.192/28 and 10.1.3.240/29 as discovery CIDRs will ge them grouped correctly. They can be comma separated in the settings pag
Bummer, I was hoping tipoff could work it out :) For example I'd
forgotten about the 10.1.3.240/29 subnet, especially when I saw 10.1.3.246. I was further confused because 10.1.3.246 responded in 1 hop and as I mentioned, my subnet is a /25. I realised, its a gateway to a VPN, so off my router...
As part of your ping probe, can you pluck the TTL out of the reply and
it might be able to determine (relatively) how far away the address is from others. Using that you might be able to guess some of the network topology up front.
eg:
64 bytes from 10.1.3.111: seq=0 ttl=64 time=0.289 ms
64 bytes from 10.1.3.194: seq=0 ttl=62 time=2.768 ms
(its not fool proof, and I'll need to check why, because 193 which is the router here returns 59.. hmm...)
64 bytes from 10.1.3.193: seq=0 ttl=59 time=1.254 ms
Can you add ICMP to the monitor? I have one devices that doesnt expose
any ports (I need to figure out what it is).
Also my domains on the status page appear down. What makes a domain "up"?
with a dashed line. - Better still: within a remote subnet, if exactly
one host is a full hop closer than all the others, tipoff promotes it to
a "VPN Peer" card and hangs the rest underneath it. So your
10.1.3.240/29 with 10.1.3.246 should render as: router -> dashed line -> VPN peer -> the hosts behind it. It would have told you about the subnet you'd forgotten :)
Might I suggest, since it's doing an https check already, to show when
the SSL certificate expires or whether it's self signed.
On your TTL 59 mystery - remember the replying device never decrements its own reply; only routers forwarding it do. So 59 means either the reply genuinely crossed 5 routers on the way back to you, or the box originates packets with a non-standard initial TTL, or the reply is actually coming from inside a tunnel (which for a router that's also a VPN endpoint wouldn't surprise me).
A traceroute to it should settle which. Tipoff's inference
uses relative hop differences within a subnet rather than trusting absolute numbers, and falls back to a flat group when the evidence is messy, so
Re: Re: My latest project - "TipOff"
By: MeaTLoTioN to deon on Sun Jul 05 2026 10:31 am
On your TTL 59 mystery - remember the replying device never decrements own reply; only routers forwarding it do. So 59 means either the reply genuinely crossed 5 routers on the way back to you, or the box originat packets with a non-standard initial TTL, or the reply is actually comin from inside a tunnel (which for a router that's also a VPN endpoint wou surprise me).
A traceroute to it should settle which. Tipoff's inference
uses relative hop differences within a subnet rather than trusting abso numbers, and falls back to a flat group when the evidence is messy, so
So using a relative inference I think is right, I know some OS's start
TTL at different numbers (I think linux is 64)...
The TTL 59 actually does cross 5 devices, to get to 193 from 54, it
would go
54 -> 1 -> 111 -> 250 -> 193 -> 194
tipoff wouldnt see 250, its a point to point link and a traceroute shows "*". Its not a linux device, so it could well be starting its TTL differently. (But it would be getting a reply from it.)
The 194 is the next hop, is linux and technically is 6 hops away I guess.
Ping -R finds it though:
PING 10.1.3.194 (10.1.3.194) 56(124) bytes of data.
64 bytes from 10.1.3.194: icmp_seq=1 ttl=62 time=3.20 ms
RR: 10.1.3.54
10.1.3.1
10.1.3.250
10.1.3.194
10.1.3.194
10.1.3.111
10.1.3.54
The "Routed Subnet" shows those two addresses from 192/28 but above it is 10.1.3.0/24. So while it would be difficult to figure out its a /28, in this case you could because you should be getting an ICMP redirect from
1 pinging anything from 192-207. (The redirect points to 111).
It also used to be if you pinged the broadcast address (207 in this
case), every device should respond but I'm not sure if that is reliable anymore...
Also, so I thought I'd try scan my IPv6 subnet, and that was a bad idea.
I scanned the /64 (I saw from the change log some references to IPv6), which pegged the CPU at 100% and while I left it go to see what happens
I came back an hour or two and the VM was unresponsive. It ultimately consumed all memory and swap space and took me a good hour to kill it
from the console :( Actually, I think the kernel finally killed it...
I see in 0.2.7 you at least have link local addresses, which is sometimes useful though, and some hosts have the fd00:368:: address that I use.
I think there is a rendering issue also. When you open a host card and click on the rescan, after the scan, the card is rendered inside the
card (so you have two header lines and hamburger selection icons).
Loving what you doing with this, its going to be a useful tool to everybody with a homelab...
The ping sweep builds one task per address in the range, and a /64 is 2^64 addresses, so it ate all your RAM and swap until the kernel put it out of its misery. Discovery CIDRs are now validated before any scan starts: IPv6 ranges are rejected with a proper message (IPv6 hosts are found via NDP neighbor discovery after each IPv4 scan, which is the only sane way - you can't sweep a /64), and IPv4 is capped at /16. Failures also now tell you WHY in the UI instead of "check the container logs".
Your cm5-3-0-2 mystery: that's not tipoff mangling it - it's mDNS name-conflict renaming (RFC 6762).
The ICMP redirect idea for sniffing out the /28 - genuinely clever, and I went down the rabbit hole on it. Trouble is catching redirects needs a raw ICMP listener, half the world disables them outright (accept_redirects=0,
Howdy,
There's a container log? Assume you mean the containers stdout as seen by docker log tipoff? I've just seen that as HTTP traffic between the
browser and tipoff, but if there is other stuff there, I'll look there more often.
Yeah, and it really only helps if the subnet is local (this side of the router), which most wouldnt be. Bummer this one. I've even done some research myself, it used to be easy but now not so...
All of that will be v0.2.11, the "stop assuming everything is a web and mail server" release. Keep the feedback coming, it's exactly this stuff that makes it better.
On DMARC/SPF for non-mail domains, one counterpoint before I concede the rest: current best practice (NCSC and friends) is that even a domain that never sends mail should publish "v=spf1 -all" plus a DMARC p=reject, otherwise spammers can spoof it freely. So the check stays for every domain. What's wrong is the framing - today you get the same red CRITICAL whether you're a mail domain missing SPF (urgent) or a web-only domain (housekeeping).
Howdy,
A "host" (website.example.com) should result on the lookup of
example.com for SPF record to confirm with it applies. If the host has
On that, .AU domains dont publically list the expiry date, so instead of "Acknowledging the issue" it might also good to ask "When does it
expire" and you can report when that expiry is close :)
Given that you also know when certificates expire, perhaps its warrants
a new view of "upcoming events" that show the expiry dates of things so that you can be proactive?
I see on the IP addresses it mentions "Agent not installed", what agent
is that? If I run snmp on my routers, perhaps that could help with topology?
Close, but one correction: SPF authentication happens against the exact From-domain, so a spoofed mail claiming to be from website.example.com would NOT be caught by example.com's SPF record - only one published at that exact name (or a wildcard) covers it. So I didn't want to silently borrow the parent's record, that would be a false sense of coverage.
We're good :)
| Sysop: | Eastside75 |
|---|---|
| Location: | Tupelo, MS |
| Users: | 9 |
| Nodes: | 4 (0 / 4) |
| Uptime: | 145:29:42 |
| Calls: | 309 |
| Files: | 1,346 |
| Messages: | 39,811 |