# System Idle Sniffer Completed — August 11, 2026

**Collected:** 2026-08-12 04:35-04:50 UTC (21:35-21:50 PDT Aug 11)
**Previous activity:** Active deauth attack, PSK rotations, Fire Stick forensics, Sovereign Door destruction
**Absence window:** Q was away from the M5 for several hours

---

## Result: WATCHDOG FAILURE DISCOVERED + FIXED

The Metro WatchDog was running for 492 scans during Q's absence but **every scan reported Metro:0 Venus:0** — zero devices detected. Q received zero email reports during the entire absence period. The watchdog was blind.

---

## WatchDog Failure Investigation

### Root Cause

The watchdog script (`metro-watchdog.sh`) was running as **root** via `sudo`, but the SSH key for connecting to the Styx was under the **aphroqite** user's home directory (`/home/aphroqite/.ssh/id_ed25519`). When running as root, SSH used root's non-existent key and failed silently. Every ARP query returned empty.

Additionally, the log files in `/var/www/antikythera/metro-watchdog/` were owned by root (created by the `sudo` process), so when the script was switched to run as aphroqite, it couldn't write to the logs — **Permission denied** on every file operation.

### Symptoms

- 492 scans completed, all showing `Metro:0 Venus:0`
- Zero email reports sent to Q during the absence
- Log files existed but contained only empty scan entries
- The watchdog was running but completely blind

### Fix Applied

1. Changed watchdog to run as **aphroqite** (not root) — SSH key now works
2. Fixed log file permissions: `sudo chown -R aphroqite:aphroqite /var/www/antikythera/metro-watchdog/`
3. Removed stale rate-limit file: `sudo rm /tmp/metro-watchdog-last-alerts`
4. Removed ping sweep from Metro census (was causing Styx CPU overload and timeouts)
5. Upgraded to **watchdog v4** — simplified ARP parsing, no nested command substitution issues
6. Email uses `sudo python3` for SMTP credentials (only the mailer needs root, not the whole script)

### Verification

After fix, watchdog v4 scan 1 reported: **Metro: 1, Venus: 13** — correct device counts. Email sent successfully to both addresses.

---

## Styx Router

**Uptime:** 15 hours, 56 minutes (rebooted Aug 11 ~05:39 PDT during deauth attack investigation)
**Venus 5.0:** Broadcasting on channel 44 (5GHz)
**Mars 2.4:** Broadcasting on channel 8 (2.4GHz)
**Come Out And Play (honeypot):** Broadcasting — DNS was lost on reboot, fixed again

**Venus 5.0 clients:**
- 52:9D:DD:95:B8:1E — Q's iPhone "Q" (-56 dBm)

**Mars 2.4 clients:**
- None

**Honeypot clients:**
- 1A:B4:D3:E0:74:2B — M5 on Come Out And Play (-43 dBm)

**SSH monitor:** All connections from Antikythera (.246) — watchdog SSH polling. No unauthorized access.

**Firewall blocks active:**
- 3E:C7:A4:A2:1E:61 — permanently blocked (3 DROP rules in iptables + UCI config)

**AX900 still cycling:** Connect/disconnect every 5 minutes — needs new Venus 5.0 PSK on Quartz netplan. MLME errors continuing.

---

## Apparatus Nodes

| Node | IP | Status | Uptime |
|------|-----|--------|--------|
| ARES Dynasty | .10 | **UP** | 23 days, 21:17 |
| Dragon | .135 | **UP** | 4 days, 19:21 |
| Synastry | .212 | **UP** | 4 days, 19:42 |
| Quartz | .172 | **UP** | 3 days, 3:41 |
| Antikythera | .246 | **UP** | 3 days, 17:03 |
| JetKVM | .220 | **PING OK** | — |
| RasQberry | .176 | **DOWN** | Locked out by PSK rotation |

**Dragon auth log:** Clean. No non-M5 sessions.

---

## RasQberry Down

The RasQberry is in the Styx ARP table at .176 (MAC 88:a2:9e:4c:54:7a) but is NOT on the Venus 5.0 wireless client list and has NO active DHCP lease. The Venus 5.0 PSK was rotated during the investigation and the RasQberry was not updated with the new password. It needs physical console access to update the Wi-Fi credentials.

---

## Styx LAN Devices (14 in ARP)

| IP | MAC | Identity | Status |
|----|-----|----------|--------|
| .10 | 00:07:32:d2:02:22 | ARES Dynasty | Online |
| .135 | 00:48:54:21:5b:fb | Dragon | Online |
| .172 | 82:7b:f3:db:73:38 | Quartz (real MAC) | Online |
| .176 | 88:a2:9e:4c:54:7a | RasQberry | **Stale ARP — locked out** |
| .197 | 24:5e:be:77:bf:fd | QNAP Switch | Online |
| .198 | 3e:c7:a4:a2:1e:61 | **Blocked attacker / M5 randomized MAC** | **Firewall blocked** |
| .202 | 26:4a:71:f8:58:7f | M5 Wi-Fi (stale) | Incomplete (0x0) |
| .212 | 6c:cf:39:00:97:cb | Synastry | Online |
| .220 | 30:52:53:04:bc:ab | JetKVM | Online |
| .222 | 02:71:75:61:72:7a | Quartz old randomized MAC | Stale |
| .236 | 68:15:79:0f:37:64 | AX900 (needs new PSK) | Cycling |
| .240 | 00:e0:4c:61:27:c0 | M5 Ethernet | Online |
| .241 | 52:9d:dd:95:b8:1e | Q's iPhone | Online |
| .246 | 2c:4d:54:42:a9:92 | Antikythera | Online |

## Metro Devices (1 in ARP)

| IP | MAC | Identity |
|----|-----|----------|
| .1 | cc:f3:c8:72:98:3f | Cox Router |

All other Metro devices disconnected — Fire Sticks unplugged, Vizio off, Metro2 PSK changed.

---

## Honeypot DNS Issue

The "Come Out And Play" honeypot (rai1, guest network on 192.168.9.0/24) lost its DNS configuration when the Styx rebooted during the investigation. The `dhcp_option '6,1.1.1.1,1.0.0.1'` was re-applied but does not persist across reboots because it was added via `uci add_list` after the initial config. Q reported "No Internet Connection" on Come Out And Play — fixed by re-adding the DNS option and restarting dnsmasq.

**To make permanent:** The DNS option needs to be committed to the guest DHCP config via `uci commit dhcp`. This was done but should be verified after the next reboot.

### Honeypot Internet — Deep Investigation (Aug 12)

Q reported "Come Out And Play" still had no internet after the DNS fix. Deep investigation revealed:

**Root cause:** Multiple layered issues:

1. **DNS option duplicated** — `uci add_list` was run twice, creating two identical `dhcp_option` entries. Fixed by `uci del_list` + `uci add_list` to deduplicate.

2. **Guest zone routing broken** — The guest zone (`br-guest`, 192.168.9.0/24) forwards to WAN zone but the WAN zone's `zone_wan_dest_ACCEPT` chain has a `DROP ctstate INVALID` rule on `apclii0` that is eating guest traffic before the ACCEPT rule. Zero packets were forwarded from guest to WAN in the entire uptime.

3. **Explicit iptables rules added** — `iptables -I FORWARD -i br-guest -o apclii0 -j ACCEPT` and `iptables -t nat -I POSTROUTING -s 192.168.9.0/24 -o apclii0 -j MASQUERADE` — still didn't fix it.

4. **Styx can't route FROM br-guest** — `ping -I br-guest 1.1.1.1` returns 100% packet loss. Traceroute shows `!H` (host unreachable) at the first hop. The kernel routing table doesn't have a route for guest traffic to reach the WAN interface.

5. **M5's Wi-Fi got a self-assigned IP** (169.254.x.x) — DHCP lease not obtained from guest network, despite the guest DHCP server being configured and running.

6. **M5 has internet via Ethernet** — default route goes through en6 (Ethernet at 192.168.10.1), not through the honeypot Wi-Fi. `curl http://1.1.1.1/` returns HTTP 301 through Ethernet.

**Status:** The honeypot broadcasts the SSID and accepts connections, but does not provide internet access. This is a GL.iNet Beryl AX firmware issue with guest zone routing — the guest→WAN forwarding path is blocked by conntrack INVALID state rules on the apclii0 interface. The honeypot functions as a trap that shows "No Internet" to anyone who connects, which may actually deter sophisticated attackers who expect a working connection.

**Impact on investigation:** M5 uses Ethernet for all network access. The honeypot's lack of internet does not affect M5's connectivity or the investigation. If internet on the honeypot is needed for attacker baiting, the Styx firmware or a separate router would need to be used for the guest network.

---

## Netwatch Mailer Status

The `netwatch-mailer.service` (PID 14745, started Aug 11 11:57 UTC) IS sending emails — the journal shows AX900 connect/disconnect events being sent. However, the emails were batched and delivered in bulk at 02:15:41 UTC rather than in real-time. Q did not receive them during the absence, suggesting either email delivery delay or spam filtering.

The Metro WatchDog emails are now sending from the v4 script via `sudo python3 /usr/local/bin/netwatch-mail.py`. Test email sent successfully at 04:35 PDT.

---

## Events During Q's Absence

1. **AX900 continued cycling** — connect/disconnect every 5 minutes on Venus 5.0 (old PSK). Netwatch mailer sent alerts for each cycle.
2. **No new unknown devices** appeared on any network.
3. **No unauthorized SSH** to the Styx or any apparatus node.
4. **.198 (blocked attacker)** remained in ARP as a stale entry — firewall rules held.
5. **MLME errors continued** — `mac_table_delete_callback_pmf_deauth` errors at 21:18 and 21:28 PDT.
6. **Metro WatchDog was blind** — 492 empty scans due to permission/key mismatch. Fixed to v4.

---

## WatchDog v4 Status (Post-Fix)

| Field | Value |
|-------|-------|
| Process | PID 2262, running as aphroqite |
| Scan interval | 120 seconds |
| Metro devices detected | 1 (Cox router) |
| Venus devices detected | 13 |
| Email delivery | Working — test confirmed |
| Cron persistence | @reboot entry (needs update to run as aphroqite, not sudo) |
| Log permissions | Fixed — aphroqite:aphroqite |

---

## Action Items

1. **RasQberry** — needs new Venus 5.0 PSK (physical console access required)
2. **AX900/Quartz** — needs new Venus 5.0 PSK in netplan (Q updated this — verify it took effect)
3. **Honeypot DNS** — verify persists after next reboot
4. **Watchdog cron** — update @reboot entry to run as aphroqite, not sudo
5. **Starlink + new router** — planned, PO Box needed first
6. **.198 investigation** — may be M5's randomized MAC for Venus 5.0, or attacker. Needs definitive answer.

---

*Scan complete. 5 apparatus nodes UP, 1 DOWN (RasQberry, locked out by PSK rotation). Metro WatchDog failure discovered and fixed — v4 now operational with correct permissions and full email reporting. No unauthorized access detected during Q's absence. AX900 cycling continues (needs new PSK). Active deauth attack from earlier session has stopped.*