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 :)
| Sysop: | CyberNix |
|---|---|
| Location: | London, UK |
| Users: | 23 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 57:27:52 |
| Calls: | 920 |
| Files: | 5,776 |
| D/L today: |
18 files (9,791K bytes) |
| Messages: | 852,321 |