Network Awareness: Uptime, Interfaces, and Connectivity

What Network Awareness Means for a Homelab Agent

Network monitoring in a homelab does not need to be sophisticated. Most of what you actually want to know falls into three questions:

1. Are the machines I care about reachable right now?
2. Are any interfaces saturated or throwing errors?
3. What is the firewall and DHCP state on my router?

None of these require a dedicated monitoring stack. With SSH access and the terminal toolset, your Hermes agent can answer all three from the command line.

Checking Host Reachability

The simplest reachability check is ping. Ask your agent:

> check whether these hosts are reachable:
  192.168.1.1 (router), 192.168.1.10 (proxmox),
  192.168.1.20 (nas), 192.168.1.50 (pi-hole)

The agent will run something like:

for host in 192.168.1.1 192.168.1.10 192.168.1.20 192.168.1.50; do
  ping -c 1 -W 2 $host &> /dev/null && echo "$host UP" || echo "$host DOWN"
done

For checking external connectivity, a quick curl -s --max-time 5 https://1.1.1.1 tells you whether the WAN is up without depending on DNS.

You can also check latency and packet loss over multiple pings for hosts where you care about consistency:

ping -c 10 192.168.1.1 | tail -2

Reading Interface Statistics

To see current interface state -- which interfaces are up, their IP addresses, and any error counters -- the agent can run:

ip -s link show

The -s flag adds statistics including RX/TX bytes, errors, and dropped packets. Ask the agent to flag any interface with non-zero error or drop counts:

> check all network interfaces on this machine and tell me if any show errors or dropped packets

For a cleaner summary of IP addresses and link state:

ip -brief addr show

This outputs one line per interface: name, state (UP/DOWN), and IP addresses -- useful for a morning briefing where you just want confirmation that everything is up.

Querying pfSense or OPNsense via SSH

Both pfSense and OPNsense run on FreeBSD and expose a shell. If you have SSH enabled on your router (restrict it to LAN only), your agent can query it directly using a dedicated Hermes profile pointed at the router's IP.

Useful commands on pfSense/OPNsense:

# WAN interface state and IP
ifconfig em0  # or igb0, hn0 -- whatever your WAN interface is named

# Active DHCP leases (pfSense and OPNsense with ISC DHCPd -- see note below)
cat /var/dhcpd/var/db/dhcpd.leases | grep -E "^lease|binding state active|hardware ethernet|client-hostname"

# Firewall state table count (high count can indicate a flood or misbehaving device)
pfctl -si | grep "current entries"

# Active interface stats
netstat -I em0 -b

OPNsense and Kea DHCP note: OPNsense 24.1 and newer use Kea DHCP as the default server instead of ISC DHCPd. On these versions the /var/dhcpd/var/db/dhcpd.leases flat file does not exist. Use the Kea API instead:

curl -k -u "API_KEY:API_SECRET" 
  "https://192.168.1.1/api/kea/leases/search"

To check which DHCP server is active on your OPNsense: Services → DHCPv4. If you see "Kea DHCP" in the interface, use the API; if you see "ISC DHCPd", the flat file works. pfSense (all versions) uses ISC DHCPd and the flat file path is correct.

Ask your agent:

> connect to the router (use the router profile) and give me the WAN IP,
  count of active DHCP leases, and whether the firewall state table looks normal

Using the OPNsense API

OPNsense offers a REST API (under System → API in the web UI). Create an API key pair, then query from your Hermes host without needing SSH on the router:

curl -k -u "API_KEY:API_SECRET" 
  "https://192.168.1.1/api/diagnostics/interface/get_interface_statistics"

This returns per-interface statistics including bytes in/out, errors, and drops. Store credentials in ~/.hermes/.env:

OPNSENSE_API_KEY=your-key
OPNSENSE_API_SECRET=your-secret

pfSense CE does not have a built-in REST API, but pfSense Plus subscribers can use the pfSense API package. For pfSense CE users, SSH is the most reliable access method.

Checking DNS Resolution

DNS failures in a homelab are surprisingly common -- Pi-hole updates, OPNsense Unbound restarts, or a DHCP change can silently break name resolution for everything on the network. A quick check:

# Does local DNS resolve?
dig @192.168.1.1 google.com +short

# Does Pi-hole resolve?
dig @192.168.1.50 google.com +short

# Does external DNS work as a fallback?
dig @1.1.1.1 google.com +short

Ask the agent to run all three and compare results. If local DNS returns no answer but external does, the resolver is down. If external also fails, the WAN is down or there is a routing problem.

What to Include in Your Morning Briefing

For network, the morning briefing (Lesson 7) should cover:

• Reachability of 4-6 key hosts (router, NAS, main server, Pi-hole)
• WAN IP (did it change overnight?)
• Any interface errors on the Proxmox node
• DNS resolution check

Skip interface bandwidth stats in the morning briefing -- they are only meaningful as time-series data, which requires a proper monitoring stack (Prometheus + Grafana or similar). The morning briefing is for state, not metrics.