How it works
Five parts make up Totenvis. Three are built and running today; the
rest are on the roadmap. This page is kept in step with the product
repository's main branch — nothing below claims more than
what's actually shipped.
Discovery
Totenvis sweeps the subnets it's pointed at over ICMP and TCP probes, harvests ARP tables, and walks SNMP where a read-only credential is available — including LLDP and CDP neighbour tables, so device-to- device links show up automatically. Every asset is stored with its IP, MAC, hostname and first/last seen times. When discovery is blocked — a device that won't answer, a missing credential — Totenvis says exactly where and proposes what would unblock it.
Topology
An interactive, force-directed map is built from what discovery finds: assets, subnets and the links between them. Zoom, pan, filter by site, VLAN or device type, and open a detail panel for anything on the map.
Remediation
Discovery gaps turn into proposals with evidence attached, and closing the loop into an action against a device is live: nothing changes until an operator approves a proposal and applies it, with the result checked on the next scan and logged to the audit trail. Today's driver covers one class of fix — re-enabling SNMP access on Meraki-managed devices, the product's first real device write; more device types and fix kinds are still on the roadmap.
Compliance
Every install will assess itself against DORA, ISO 27001 and ITIL, produce supporting documentation, and propose fixes where it falls short — with room to add further frameworks over time. The control catalogue and assessment engine are on the roadmap; no compliance claim is made about the product today.
Agent
Where opening a port isn't an option, a small Totenvis agent will run on the device instead — PC, phone or server — and connect outbound. Remediation on agent-covered devices routes through it. The agent is still on the roadmap.