Davor Network Watch: making network monitoring understandable
A local Windows pilot that grew from intermittent connection drops into a clearer view of traffic, Wi-Fi devices and router observations.
- Status
- Local Windows pilot · v0.30
- My role
- Problem definition, product decisions, practical testing & review
- Stack
- Python standard library · HTML / CSS / JS · SQLite · Windows & router sources
The connection was back.
The evidence was gone.
When short drops on my own network resolved before I could inspect them, I wanted more than a green “connected” indicator. Was the problem on my PC, the Wi-Fi link, the router or farther upstream? Davor Network Watch grew from that question.
I drove the idea and priorities and tested on my Windows PC and router. AI helped write and review code and tests, and interpret evidence; I reviewed the practical behavior. My responsibility was to decide what the product should explain—and to check whether it actually did.
Different sources.
One understandable next step.
I keep Windows observations, optional connection checks and router data distinct. Their freshness and limitations matter as much as the values themselves.
Observe
- Windows adapters, endpoints & processes
- Optional DNS / HTTPS / ICMP targets
- Read-only router Wi-Fi & WAN data
Keep context
- Local Python collection
- SQLite: existing local history
- RAM: WAN graph & live session
Explain
- What was observed?
- What could it mean?
- What should I check next?
- What remains unknown?
Visibility without pretending to know everything.
The Windows view
Real TCP connections, local listeners, UDP endpoints, processes and traffic from the selected Wi-Fi or Ethernet adapter. Port hints are not verified protocol or content inspection.
Connection evidence
Optional DNS, HTTPS and ICMP checks sit alongside Windows Wi-Fi events and existing local incident logs, with TXT and JSON exports. A missed ping is not a proven Internet outage.
Wi-Fi, by association
Tested local Sagemcom authentication and router-reported active Wi-Fi state feed a graphical AP/device view. Browser-local labels override host-name/IP enrichment when supplied, joined by exact MAC; unknown data stays unknown.
A separate WAN perspective
An implemented WAN page uses a session-local graph, cumulative error/discard counters and baseline/gap explanations. English and Danish UI, plus support contact, make the evidence easier to follow.
Seven stages. Each changed the question.
- Explore the question
First, a deliberately fictional prototype
Short connection drops on my own network could resolve before I could inspect them. I wanted evidence about whether the issue was on the PC, the Wi-Fi link, the router or farther upstream. My first visual prototype used fictional devices to test the layout and device-review workflow. It was a demo—not real monitoring.
The aim became understandable monitoring for households and small businesses: what was observed, what it could mean, what to check next and what remains unknown. That is a product goal, not a claim of customer adoption.
- Choose the right source
Replace the demo with Windows observations
I built a local Python + HTML/JavaScript app to collect real Windows TCP connections, listeners, UDP endpoints, processes and interface traffic. Selecting the actual Wi-Fi or Ethernet adapter mattered: a virtual or filter interface could show zero traffic while a video was playing.
This changed how I treated a reassuring number. A zero is only useful when I know which source produced it. An unknown device or a listening port is not, by itself, proof of compromise.
- Separate observation from diagnosis
Checks need context, not alarmist labels
Optional DNS, HTTPS and ICMP checks and Windows Wi-Fi events added connection evidence. I needed to distinguish a missed ICMP response from a proven Internet outage: a public target or intermediate network may not answer a ping even when other traffic works.
A sleeping PC creates another boundary. No observations while the PC is asleep must not become a story of continuous network downtime. The interface should tell me what was measured and where the evidence stops.
- Test the interaction
A dashboard that respects the person using it
I split the dashboard into overview, devices, activity, connection history and settings, then added WAN. Danish and English explanations describe the observation, the concern, the next action and the limits.
A real user recording exposed live refresh closing details and moving the scroll position. I implemented state, focus and scroll preservation. Screenshots, recordings and logs changed the product—not just cosmetic preferences.
- Firmware-specific investigation
Ask the router, read-only
The Windows neighbor cache was not a complete list of Wi-Fi clients. I investigated the read-only internal API of a Sagemcom F@ST3890V3 / WIFIHUBC2, starting with bounded local sample extracts that excluded authentication fields.
A local hidden-password probe confirmed SHA512 login and both Wi-Fi AssociatedDevices reads on this firmware. I integrated periodic read-only collection, controlled session renewal, latching rejected credentials rather than retrying indefinitely, and source-freshness information. Collection changes no router settings; this is not universal router support.
- A practical phone test
Count devices, not duplicate associations
The graphical Wi-Fi window shows router-reported AP associations, with active-only as the default and optional history. The same MAC under two APs is one unique device with separate association records. Disconnecting a phone from Wi-Fi reduced the active device count by one in a practical test.
I implemented host-list reading and name/IP joining by exact MAC, with my own browser labels as overrides. Missing data is not guessed. In the documented development history, host-list path support and actual names still needed firmware confirmation. The implementation is not evidence that every device is identified automatically.
- Counter quality before spectacle
Find the real WAN route—and leave honest gaps
A WAN probe confirmed an enabled IPv4 default route referencing IP_DATA, which was UP and exposed byte/error counters. I did not select inactive IP_BR_WAN merely because its name said WAN.
I built the WAN dashboard from delta counters over monotonic elapsed time, guarded for uptime, identity changes, resets and gaps. Missing samples become null gaps, not fabricated zeros or spikes. I do not sum IP, Ethernet and DOCSIS layers because their counters may overlap.
Sustained WAN accuracy, counter width, offload/completeness and firmware-specific behavior remain pilot validation work. Discovering a usable source and proving its long-duration accuracy are different milestones.
What the record supports.
What still needs testing.
Historical development-environment counts for v0.30—not a certification, a current performance score or a substitute for native Windows/browser, long-duration, reboot/session and multi-network testing.
Validated in the local pilot record
- Local login and router read paths were validated by the pilot user.
- A phone Wi-Fi disconnection reduced the active count by one.
- WAN discovery found the enabled IPv4 route and UP IP_DATA counters.
- The genuine 4 November v0.30 overview shown above records actual Windows traffic and check timestamps.
Implemented, but not fully confirmed
- Sustained WAN graph accuracy, counter width and firmware-specific completeness.
- Automatic host names and host-list path behavior on the documented firmware.
- Reliability over long runs, reboots, session renewal and other networks.
- A screenshot of the overview is not proof of every feature.
Local does not mean limitless—or encrypted.
The Python standard-library backend serves an HTML/CSS/JavaScript UI, with SQLite for existing local history. Device lists and logs are not automatically uploaded to a cloud service. Optional external checks do contact public targets, so I do not claim zero external traffic.
The router admin password is entered locally and not saved to disk. Credentials and session material reside in process memory. This pilot uses HTTP on the LAN, like the router administration page; local transport is not encrypted. Read-only collection changes no settings.
WAN history is RAM-only: up to 240 points in the current app process. It is not included in older PC diagnostic exports. A restart and a persistent incident record are therefore different things.
This is a local pilot, not a generally available SaaS product or a security suite. It does not inspect mail or encrypted contents, guarantee attack detection, support every router, or provide production managed security.
Reliability before a bigger promise.
The next validation work
- Sustained reliability and data-quality checks across long runs, reboot and session renewal.
- More readable incident timelines and persistent WAN history.
- Simpler installation and updates, plus more secure credential handling.
- Validate adapters on other routers, households and small-business networks.
The longer-term ambition
Subscription/support and central administration with multi-site access controls are an ambition—not delivered features, paid users, revenue, enterprise readiness or a promised launch date. First I need stronger evidence that the local pilot stays dependable.
“The most useful dashboard is not the one with the most numbers. It is the one that makes the next reasonable action clearer—and tells you when the evidence is incomplete.”