# GOTCHA
### A forensic record of the night of 2026-08-02 → 03

> **If you're reading this and I'm not around to explain it:** on the night of August 2nd, 2026,
> an unidentified device made repeated, *failed* connection attempts against **Venus 5.0 — my
> company's private business network, specifically configured to reach NFT Las Vegas's AI apparatus
> and server nodes** while I was asleep and alone on-site. It never got in — my encryption held. I
> have not been able to explain what it was or why it was there, and no one in my household created
> it or the mystery network my own laptop kept getting pulled onto. This document separates what
> the logs **prove** from what I only **suspect**, in the order I found it out. Everything factual
> here is drawn from router logs with a clock verified accurate to the second. — Q

---

## 0. TL;DR

- An unknown device (`e8:fb:1c:65:20:73`, whose MAC belongs to **AzureWave** — a maker of Wi-Fi
  modules embedded inside other gadgets) generated **8 disassociation events on my 5 GHz network
  "Venus 5.0" between 1:33 PM and 7:16 PM PDT on Aug 2**, while no people were home, and **never
  once completed a successful join** — no association handshake, no IP, no ARP entry, no LAN
  access. **No breach occurred.** *(What it was doing — probing, a misconfigured gadget, or
  something else — is NOT established by these logs; see §3.4.)*
- I have **never changed** my Wi-Fi password, so nothing of mine should be "stranded" with a stale
  key. I do not recognize owning an AzureWave device, my TV was off for 3 days, and my only
  doorbell is a Ring (not AzureWave). These make the ordinary benign explanations **seem less
  likely — but I have not definitively ruled them out.**
- Separately, a network named **"Metro3"** — following my household's `Metro1 / Metro2` naming
  scheme — appeared in range and my laptop (M5) fell back onto it. **VERY LIKELY OURS — EXPLAINED
  (Aug 4):** my brother says *we* created a Metro3 (a future higher-speed Cox line), **and** the
  auto-connection is now accounted for — ~a month ago I manually joined M5 to Metro3 using the
  **Metro2 password, and it worked**, so M5 has it saved and re-joins on its own. A shared Metro2 key
  is strong evidence it's the same household infrastructure. The one remaining formal check is
  **matching the BSSID M5 recorded to our AP** (his "not transmitting yet" is imprecise — M5 plainly
  associated with it). Treat as benign, pending that BSSID confirmation.
- A scare that turned out **fine:** at 11:46 PM I thought I'd been "kicked off Venus 5.0." The logs
  proved my laptop was on the **genuine** company network (Venus 5.0) the whole time (its MAC is in the router's
  own client table) — it was just **flapping** on a weak 5 GHz signal and bouncing to Metro3. Not
  an attack.
- In response I built a **three-layer network guardian** across two of my nodes that now records
  every return of that device — with its signal strength — and alerts me. It has been tested
  end-to-end and is live.
- **UPDATE (Aug 4): it came back.** The device returned at **~2:30 AM PDT on Aug 4** and made
  **3 more attempts** (`02:29:40`, `02:32:21`, `02:34:06`) — all rejected again, still no successful
  join, still no LAN access, still no signal exposed. The guardian logged it silently while I was
  away. **This is not over. It is contained, and now it is watched.**

---

## 1. The trigger

Late on **Aug 2**, my laptop **M5** dropped off my company's 5 GHz access point **"Venus 5.0"** and was
placed onto a network called **"Metro3."** I noticed at **~11:46 PM PDT** and called Mike Wilson
immediately (there is a phone-call record establishing the time). Two things bothered me:

1. I don't know who made **Metro3**.
2. I couldn't explain the drop.

That was the loose thread. Pulling it took most of the night.

---

## 2. Ground truth — the instruments are trustworthy

Before trusting any timestamp, I verified the router's clock, because an earlier mistake in my
work has taught me never to trust an instrument without checking it (this is my **Prediagnosis
Protocol**: a cause is only a *prediagnosis* until a hard fact clears it).

- **The River Styx** (my boundary router, GL.iNet Beryl 7, OpenWrt) reported its clock as
  **identical to my Mac's, to the second**, timezone `America/Los_Angeles`, NTP-synced to
  `time.cloudflare.com`. So every log timestamp below is **real PDT**, confirmed.
- Its logs covered the whole window in question (they span back through the afternoon of Aug 2).

---

## 3. The investigation, in the order it actually unfolded

### 3.1 First hypothesis — "evil twin" — RAISED, then FALSIFIED
Because at 11:46 PM the *real* Venus 5.0 log showed a device **joining**, not being kicked, and
(at first) it looked like I might have been on a **different** access point impersonating my SSID,
I seriously entertained an **evil-twin / rogue-AP** attack. I even took protective steps.

**Then the facts killed it:**
- I read M5's own Wi-Fi address for Venus 5.0: **`26:4a:71:f8:58:7f`**.
- That exact MAC is present in **the Styx's own Venus 5.0 client list** (`iwinfo rai0 assoclist`) —
  a router only lists devices connected to *its own* radio.
- I confirmed I **was home** at 11:46 PM.

→ M5 was on the **genuine** home Venus 5.0 the entire time. The real Venus 5.0's BSSID is
**`BE:D6:CF:14:8A:25`**. Evil-twin hypothesis: **dead.**

### 3.2 What actually happened to M5 — benign flapping
M5 (`26:4a`) was **ping-ponging**: dropping off Venus 5.0 and falling back to Metro3, then
rejoining. Its 5 GHz signal is borderline (**−66 to −67 dBm**; the AP's link quality read 45/70),
and because **both** Venus 5.0 and Metro3 are saved on M5, it defects to whichever is stronger.
Contributing factor: the Styx's single 5 GHz radio serves Venus 5.0 **and** backhauls to the
upstream "metro2" gateway on the **same channel (44)** — a shared-radio setup that makes Venus 5.0
inherently less stable. **Not an attack. A weak-signal roam.**

### 3.3 Metro3 — LIKELY OURS, NOT YET CONFIRMED (Aug 4)
At first this looked unexplained: Metro3 followed my household's `Metro#` naming, but when my dad
asked my brother, my brother said "no." **On Aug 4 my brother said in our group chat that we *did*
create a Metro3** — a Wi-Fi line reserved for **future higher-speed data once Cox supports it**,
which per him **does not transmit anything yet.**

This is a **plausible benign explanation, not a confirmed one** — it stays a *prediagnosis* because
of two unresolved gaps:
- **"Not transmitting yet" contradicts the observation.** M5 didn't merely *see* Metro3 — it
  **associated with and was placed on it** on Aug 2 (§0). A network that isn't transmitting cannot be
  joined. So either the description is imprecise, or the Metro3 M5 joined is not the one my brother
  means.
- **Ownership is unproven without a BSSID match.** Anyone can broadcast an SSID named "Metro3." The
  only way to *formally* confirm the network M5 joined is ours is to compare the **BSSID M5 recorded**
  against our household AP's BSSID. That comparison has not been made.

**Update (operator):** the auto-connection is now explained. **~A month ago I manually joined M5 to
Metro3** (I'd heard it might be faster than Metro2) using the **Metro2 password — and it worked.**
That Metro3 accepts the Metro2 WPA key is strong evidence it's the **same household infrastructure**,
and it's why M5 re-joins on its own — it's a saved network I added myself. This also settles the
"not transmitting" wrinkle: it was plainly transmitting both a month ago and on Aug 2.

→ Metro3 is now **very likely our own — benignly explained.** The BSSID match remains the one formal
confirmation, but nothing here points to a stranger.

### 3.4 THE GOTCHA — the unidentified device `e8:fb:1c:65:20:73`
While reconstructing the evening I found a device that **behaves nothing like any of mine.**

- **Vendor:** `e8:fb:1c` = **AzureWave Technology Inc.** (Taiwan) — a maker of **embedded Wi-Fi/
  Bluetooth modules** that live *inside* other products (IP cameras, doorbells, IoT hubs, smart TVs,
  drones, some laptops/SBCs). It is **not** a phone or Mac (mine use Apple radios with randomized
  MACs). I **do not recognize** owning an AzureWave device.
- **Behavior:** it appeared **only** on Venus 5.0 (5 GHz), **8 times**, **1:33 PM → 7:16 PM PDT on
  Aug 2**, then vanished. Every event is a **disassociation/drop** — there is **never** an
  `associated` line, **never** a WPA key handshake, **never** a DHCP lease, and it is **not** in the
  ARP table. Confirmed across both the RAM log and the persistent log: **it never once succeeded.**
- **What this could mean (PREDIAGNOSIS — NOT established):** the pattern is *consistent with* a
  device repeatedly attempting my network and being rejected for lack of the key. But the available
  logs do **not** prove it was targeting "Venus 5.0" specifically, that it was "configured" for my
  SSID, or that a wrong password was the cause. I don't have the underlying authentication frames,
  and this MediaTek driver's disassociation logging is ambiguous (a device that never fully
  associates can still produce "disassociated" lines). The "why" is an open question.
- **What IS certain (evidence-backed): it never got in.** No successful association, no key
  handshake, no IP, no ARP entry, no LAN access. WPA (with 802.11w PMF) rejected/dropped it each time.
- **This happened while I was asleep and no one else was home.**

**Benign explanations I consider less likely — but have NOT definitively ruled out:**
1. *Stale password on an old device of mine?* → I've **never changed** the Wi-Fi password, which
   makes a stranded-key device of mine less likely.
2. *One of my devices failing?* → My devices have the password and connect fine.
3. *A gadget I own?* → I don't recognize owning an **AzureWave** device; my **TV was off 3 days**;
   my doorbell is a **Ring** (not AzureWave).

None of these is *proof* of anything — they narrow the field, they don't close it. The honest,
careful statement: **an unidentified device made repeated failed connection attempts on my Wi-Fi
while I slept, never got on, and I cannot yet account for it.** It never breached anything — but it
is unexplained, which is why I built the monitoring in §6 to catch it if it returns.

---

## 4. What I KNOW vs. what is OPEN

**Known (evidence-backed):**
- The clock is accurate; timestamps are real PDT.
- `e8:fb:1c` never completed a successful join (no association handshake, no lease, no ARP), so it
  never reached the LAN. **No breach.** *(Why it was attempting at all is unproven — see §3.4.)*
- M5 was on the genuine company network; its "kick" was benign flapping on a weak signal.
- Venus 5.0 is WPA/RSN-encrypted with PMF (the logs show real key handshakes; an `iwinfo`
  "Encryption: none" readout is a known MediaTek misreport).
- My known devices: **M2** (`de:6f…`, .194), **M5** (`26:4a…`, .202), **iPhone** (`52:9d…`, .241),
  plus apparatus nodes ares-dynasty (.10) and synastry (.212).

**Open (unresolved):**
- **What device is `e8:fb:1c`, and where is it physically?** It **returned Aug 4** (~2:30 AM PDT, 3
  more failed attempts) and is therefore ongoing. Because it never associates, the radio still
  exposes **no signal**, so proximity is still unknown — a dedicated monitor sniffer (§7) is the
  only way to get it.
- A LAN device `192.168.10.197` currently reports **no hostname** — identity unconfirmed.
- The logs don't retain more than ~a day, so I still **cannot see whether `e8:fb:1c` was probing
  before Aug 2.** (Retention is fixed going forward — see §6.)

**Updated since first draft:**
- **Metro3** — my brother says it's **ours** (a future higher-speed Cox line). **Probably benign,
  not yet confirmed:** "not transmitting yet" contradicts M5 having joined it, and origin is unproven
  until the **BSSID M5 recorded** is matched to our household AP. See §3.3.

---

## 5. Evidence appendix

**MAC / device map**
| MAC | Who | Notes |
|---|---|---|
| `26:4a:71:f8:58:7f` | **M5** (my laptop) on Venus 5.0 | −66/−67 dBm, flapping |
| `de:6f:c6:1a:27:9a` | **M2** (my MacBook), .194 | on Venus 5.0 |
| `52:9d:dd:95:b8:1e` | **iPhone**, .241 | normal cycling |
| `e8:fb:1c:65:20:73` | **UNKNOWN — AzureWave** | 8 disassociation events, never on LAN |
| `192.168.10.197` | **UNKNOWN — no hostname** | on LAN, unidentified |

**Key BSSIDs**
- Real home **Venus 5.0** AP: `BE:D6:CF:14:8A:25` (5 GHz ch 44, WPA/RSN+PMF)
- Upstream **metro2** gateway: `72:7F:F8:C4:18:D2` (strong in-home signal)

**`e8:fb:1c` timeline on Venus 5.0 (all disassociations, no successful join):**
`13:33`, `14:07`, `18:23` (×5), `19:16` — Aug 2 PDT. Absent since.

**Commands that produced this record** (run from my Mac to the Styx over the LAN/tailnet):
`iwinfo rai0 info` / `iwinfo rai0 assoclist` (AP + client list) · `logread` and
`/overlay/log/messages` (event logs) · `cat /tmp/dhcp.leases` (device inventory) · MAC-vendor
lookup via `macvendors.com`. The Styx clock was cross-checked against my Mac (`date`) and found
identical.

---

## 6. Defenses now standing watch (built the same night)

I did not just document this — I built a **three-layer guardian** and verified it end-to-end:

1. **Styx local watcher** (`/root/netwatch.sh`, a boot-persistent auto-respawning service): follows
   the live Wi-Fi log; on any sighting of `e8:fb:1c` it records the time **and signal strength** to
   `/overlay/netwatch/sightings.log`.
2. **Off-router durability:** the Styx now ships **all** its logs to **Antikythera** (my
   observability node) over syslog → `/var/log/styx/remote.log`, so records survive even if the
   router is wiped. (This also fixed a retention gap: the router only kept ~9 hours locally.)
3. **Alert agent** on Antikythera (`netwatch-agent`): watches the shipped logs for `e8:fb:1c` and
   raises an **ALERT** (`/var/log/netwatch/alerts.log` + a live `status.txt`) the instant it returns.
4. **Signal census:** every minute, the Styx logs the RSSI of **every** associated device on both
   bands — known or unknown — so I have a continuous proximity record.

**Verified:** I injected a simulated `e8:fb:1c` event on the Styx and watched it travel Styx →
Antikythera → fire a real alert. All pieces are persistent across reboots.

**If `e8:fb:1c` (or another unknown) comes back:** it will be caught in three places at once, with
its signal strength — which finally answers *in my home vs. a neighbor.* Check
`/var/log/netwatch/alerts.log` and `status.txt` on Antikythera, and
`/overlay/netwatch/sightings.log` on the Styx.

---

## 7. If it escalates — next moves already scoped

- **`e8:fb:1c` returned Aug 4 and is ongoing.** Because it never associates, the Styx can't read
  its signal — a **dedicated monitor-capable USB Wi-Fi sniffer** parked on ch 44 (separate hardware)
  is the way to finally get its proximity.
- **Email alerts** (LIVE): every connect and every disconnect on Venus 5.0 emails me, and an
  EMERGENCY button files a fact-based PDF report — *with the supporting logs attached* — to LVMPD on
  confirmation.
- Identify the unnamed LAN device `192.168.10.197`.
- **Match the Metro3 BSSID** that M5 recorded against our household AP — that is the only thing that
  confirms the network M5 joined is actually ours (§3.3). Until then it's probably-ours-**unverified**.
- Consider **rotating the Venus 5.0 password** (never changed) to invalidate anything that might
  hold it.
- Physical sweep for anything with an **AzureWave** module I didn't set up (camera, sensor, hub,
  plug, drone, old laptop, a device left behind).

---

*Filed under duress and dark humor, but every fact here is real and sourced from my own logs.
The encryption held. The watch is set. — Q, 2026-08-03*