The best work this week happened in two dense sessions near the end — NDP Watcher picked up a live terminal UI and, more importantly, an actual fix for a false-positive problem I'd flagged as a known limitation weeks ago. The middle of the week belonged almost entirely to math ahead of Thursday's tuition, and one day disappeared to gaming after college and tuition already ate the hours. It closed with an unexpected but sensible move: starting a proper Python fundamentals track on W3Schools, even while the actual tool keeps getting more advanced.

Core Technical & Personal Insights

The week's first real technical push went into v0.4. I hit a PermissionError running the script without sudo and correctly reasoned it through as a raw-socket privilege issue rather than a bug in my own code — the kind of distinction that matters, since chasing a nonexistent code bug would've wasted real time. On top of the existing CSV logging, I added a rich-based live terminal table with color-coded alerts, using a deque to cap the on-screen view at the 15 most recent rows while the CSV file keeps the full, unbounded history underneath. Getting sniff()'s single-argument callback to work with my two-argument handle_packet(pkt, live) function meant properly internalizing lambda as a middleman — and understanding that the parameter name on either side of the colon is arbitrary, as long as both sides agree with each other. I also worked through why .append((timestamp, event_type, source_mac, details)) needs two sets of parentheses — the outer pair for the function call itself, the inner pair to bundle the tuple — and learned that init_log() isn't there to make the file exist (opening in "a" mode does that automatically), it's there to guarantee the header row gets written first. Wanting to keep the CSV log out of version control led into .gitignore properly, plus git rm --cached for a file that was already being tracked before I excluded it.

The most interesting catch of that session wasn't code at all — it was a real environment bug I found independently. Log timestamps were coming out roughly 9 to 10 hours off, and I traced it correctly to the Kali VM's system clock or timezone rather than anything in the Python logic, using date and timedatectl to dig into it, with the actual root cause (wrong timezone versus NTP drift) still pending confirmation. I also noticed a truncated last row in one log file, likely from an interrupted Ctrl+C run mid-write — not fixed yet, just flagged as something to watch.

The next big session pushed the tool to v0.5, and this one mattered more than a version bump suggests. Earlier work had flagged a real weakness: the spoofing detection treated every IP-to-MAC mismatch the same way, which meant legitimate IPv6 privacy-extension address rotation could trigger false alerts. v0.5 fixes that properly by comparing mismatches against a 30-second time window (SPOOF_WINDOW) — a fast, suspicious conflict gets flagged as ALERT_SPOOFING, while a slow one that's more likely just a legitimate address change gets logged as INFO_MAC_CHANGE instead. That's a genuine design upgrade, not cosmetic polish, and it's the kind of SOC-relevant triage thinking — distinguishing what's urgent from what's just informational — worth stating directly in an interview as "I found and fixed a false-positive source in my own detection logic." Getting there meant working through datetime versus timedelta properly — one's a point in time, the other's a duration, and subtracting two datetime objects gives you a timedelta you can compare directly with < and >. I also clarified how live.update(build_table()) actually works: build_table() rebuilds the entire table fresh from whatever recent_events currently holds, and live.update() just swaps the on-screen display to match, called once at the end of every packet-handling pass regardless of which NDP message type triggered it. Same session cleared up a smaller but genuinely useful point about .gitignore itself — the file is a normal tracked file, visible to anyone looking at the repo, but the content it excludes never gets uploaded at all. Existence being visible and content being private are two separate things, and conflating them would be an easy mistake to carry forward. I also scoped out an extended roadmap for the whole project, from v0.5 through v1.0 with a stretch goal of a web dashboard afterward — a deliberate choice to build this out properly rather than leave it minimal.

The week closed with a pivot I didn't see coming but makes sense: creating a W3Schools account and starting through Python Home, Python Intro, and Python Get Started, alongside some general coding practice. Going back to formal fundamentals while already deep into a working v0.5 tool isn't a contradiction — it's filling in the base underneath work that's already ahead of it.

What Didn't Go to Plan (Lessons Learned)

The middle of the week went almost entirely to math. One day was mostly spent pushing v0.3 to GitHub and fighting with VS Code inside the VM acting strangely — no run button showing up, still unresolved by day's end — before math took over as the priority with tuition looming on Thursday. The day after that was math homework and problems only, with honestly no cybersecurity or project work at all. And Thursday itself was a full write-off on that front: college and tuition ate most of the day, and the remaining time went to gaming rather than anything productive. Three days in a row with the project barely touched is a real gap, even with legitimate reasons behind most of it.

Focus for Next Week

Actually test v0.5's two alert types properly — ideally by simulating a controlled spoofing scenario rather than waiting around for organic traffic to trigger it, since that's the only way to confirm both the fast ALERT_SPOOFING and slow INFO_MAC_CHANGE paths actually behave the way they're designed to. Nail down the timezone bug's real root cause and fix it properly instead of leaving it as a known oddity. And keep the W3Schools fundamentals track running in parallel with the NDP Watcher build rather than letting one crowd out the other — they're reinforcing each other more than competing for time.

This is the week two separate things stopped being ideas and became real, versioned artifacts. NDP Watcher — my network anomaly detection tool — went from a broken environment and an unsaved file all the way to a working v0.3 with actual spoofing-detection logic, three GitHub commits deep. And on the content side, a YouTube channel finally got a name, a full recording pipeline, and a real production setup, after a genuine identity crisis over what to call it. Not every day was clean, but the two threads that mattered both landed somewhere real by Sunday.

Core Technical & Personal Insights

The NDP Watcher arc is the spine of this week, and it started rougher than it ended. Early on, a session that should have been about writing detection code turned into pure environment plumbing — I set up VS Code Remote-SSH from host to Kali VM successfully, but lost track of whether ndp_watcher.py had actually been saved before running Git commands on it. It hadn't. git add had nothing to stage, and both commit and push failed as a result. The real lesson wasn't the bug itself, it was the habit that came out of it: always verify a file physically exists with ls -la before trusting Git commands against it, instead of assuming a tab being open means it saved.

The environment kept fighting back the next day. Remote-SSH started crashing outright, and disabling remote.SSH.useExecServer didn't fix it, nor did uninstalling and reinstalling the extension — it would work briefly, then fail silently with no error output. Rather than keep sinking time into an unresolved SSH bridging issue, I diagnosed it as a host-side extension/core version mismatch and made the call to install VS Code directly on the Kali VM instead, skipping the bridge entirely. That's a legitimate pivot, not a failure — when a tool fights you for multiple rounds with nothing to show for it, changing the approach is the correct move, not giving up.

With the environment finally stable, v0.1 actually shipped. Getting there meant working through a genuine mystery: the script was producing no output at all. I confirmed the interface and permissions were fine by capturing raw traffic with scapy and seeing TCP and ARP packets come through, which told me the capture itself worked — the real issue was that the network's traffic was heavily IPv4 with IPv6 sitting idle. Forcing real IPv6 traffic with a ping6 to a public address finally produced a live NS/NA exchange the script correctly captured and classified. On top of that, I hit a "Repository not found" error pushing to GitHub, traced it independently to a scoped Personal Access Token that had been reused from an earlier repo, generated a fresh one, and confirmed the fix by testing pushes across both repos several times over. Getting through that last stretch without further guidance, mid-troubleshoot, is exactly the kind of "figured it out under pressure" story worth remembering for interviews later.

From there the tool grew fast. v0.2 upgraded it from bare message-type labels to full field extraction — router lifetime and the M/O flags and advertised prefix from Router Advertisements, target addresses from Neighbor Solicitation/Advertisement exchanges — and I verified it end-to-end against my own network's real traffic: a 7200-second (2-hour) router lifetime, both flags off confirming a SLAAC-only network with no DHCPv6, and the advertised prefix matching my VM's actual assigned IPv6 address. Along the way I picked up how to tell MAC and IPv6 formatting apart at a glance, and that a MAC address's first three byte-pairs (the OUI) identify the vendor — 08:00:27 being VirtualBox's own prefix. I also wrote a full README covering the project's purpose, security rationale, usage, example output, and a version roadmap out to v1.0, which matters more than it sounds — a roadmap like that signals a deliberate, iterative build process to anyone skimming the repo later.

v0.3 is where the tool actually became a detector rather than just a parser. I added two in-memory dictionaries — one tracking known routers by MAC against their lifetime and prefix, one tracking known neighbors by IP against their owning MAC — and built the actual detection logic on top: first-time sightings get learned silently, repeat sightings get compared against the stored baseline, and alerts fire on prefix changes, zero-lifetime RAs (a denial-of-service pattern), or a MAC claiming an IP that's already tied to a different one (NDP spoofing). It ran cleanly end to end on live traffic on the first real attempt. This learn-once, alert-on-mismatch pattern is the same fundamental structure real network anomaly detection runs on, which is worth saying plainly rather than downplaying. I'm also carrying forward a known limitation on purpose rather than pretending it's not there: the baseline is in-memory only and resets every run, and it doesn't yet account for legitimate IPv6 privacy-extension address rotation, which could trigger false positives — flagged clearly as v0.4+ work rather than something to quietly ignore.

Alongside all of that, a smaller thread ran in parallel: getting comfortable with actual Git internals. I reviewed the full SSH setup sequence for GitHub properly — ssh-keygen, starting the agent and adding the key, copying the public key to GitHub, testing the connection with ssh -T git@github.com, then cloning — and locked in why SSH auth is preferred over HTTPS-with-password for this workflow in the first place.

The second big thread this week had nothing to do with NDP Watcher: standing up a YouTube channel for project and cybersecurity content. The name took real work to land on — I went through on-brand extensions of ZeroVector, generic security-term names, movie-thriller-style options, and an earlier favorite, "Tripwire," before settling on Working Theory, chosen specifically because it ties to actual self-identity rather than being another genre trope, and because an existing company already uses the Tripwire name in the security space. The tagline landed on "Nothing here is finished — just tested," which frames every video around testing and refining ideas in public rather than presenting polished conclusions. I also decided against an AI-generated profile picture or watermark in favor of a real photo — notebook, whiteboard, or terminal shots — for authenticity.

The technical production setup got real depth too. OBS Studio is installed and configured with a working Window/Display Capture source, 1080p resolution, 30fps for tutorial-style content, NVENC/x264 encoding, a 12–16k Kbps bitrate, and mp4 output, plus hotkeys for start/stop/pause and mic mute chosen specifically to avoid clashing with other apps' shortcuts. Audio took several passes to land on the right tool — starting from a simple wired/USB mic straight into OBS, through a phone-as-synced-recorder fallback using clap-sync, into turning a phone into a live virtual mic via WO Mic (which meant understanding its server/client split and the hotspot/Wi-Fi Direct nuance when the phone acts as its own access point), and comparing that against AndroidMic, AudioRelay (ruled out partly over its one-hour free-tier mic limit), and finally landing on Micstream for low-latency Opus-codec streaming, with its ad-supported free tier accepted as a fair tradeoff.

What Didn't Go to Plan (Lessons Learned)

One day's morning and evening both got eaten by gaming instead of the planned work, which cut directly into what should have been productive blocks — worth naming plainly rather than folding into the day's technical wins. The channel name also went through several complete pivots before landing on Working Theory, which cost real time, even if it ended in a stronger, more honest choice than the first idea. Same with the audio setup — WO Mic got explored in real depth, hotspot handling and all, before ultimately getting replaced by Micstream. Not wasted effort exactly, but not the final answer either, and it's worth remembering that some research time won't survive contact with a better option found later.

Focus for Next Week

On NDP Watcher: handle the IPv6 privacy-extension rotation gap so it doesn't generate false positives, and — the more exciting one — actually simulate a spoofing attempt on the lab network to watch the v0.3 alert logic fire live. That's both a real validation step and a strong story for later interviews. On the channel side: get an actual test recording done instead of just the pipeline sitting configured and untested, and get the thumbnail, banner, and profile photo shot so the channel has a real face instead of just settings screens behind it.

This was the week where a lot of scattered pieces turned into actual infrastructure. I fixed my dev environment properly, went deep on DNS security, ran my first full Git workflow start to finish, built my own shell commands by debugging real errors instead of copy-pasting fixes, and closed the week with a hands-on network build in Packet Tracer. Only one day was a true write-off, and even the slower day still had real math work behind it. This is the most technically dense week I've logged yet.

Core Technical & Personal Insights

The week opened by fixing the boring-but-essential stuff: my actual dev environment. I confirmed VS Code on the host connecting via Remote-SSH into Kali is the standard professional setup, and my existing SSH config already supported it without changes. Getting Fastfetch and a Tokyo Night theme working seemed simple until the terminal color scheme turned into a real debugging chain — I assumed the wrong folder for QTerminal's color schemes, then a download silently landed in a qtermwidget5 path instead of qtermwidget6, then a second source URL 404'd outright. The actual fix only came from diffing find / -iname "*.colorscheme" output against qterminal.ini's real colorScheme= value, which showed the system-wide schemes live in /usr/share/qtermwidget6/color-schemes/, not the user-level path I'd assumed. The lesson that stuck: when the same error keeps showing up after several different fixes, it's often not the same bug at all — worth checking actual file paths and config state directly instead of retrying variations of a guess.

That same debugging instinct carried into a proper terminal deep-dive later in the week. I went through file navigation fundamentals (pwd, ls -a, cd, and the difference between find's live search versus locate's much faster indexed search), then built my first custom shell command — a rename function in .bashrc that prompts for a filename instead of typing out full mv syntax — and extended the same pattern into copy and move functions, checking for command-name collisions first with which. Getting there meant hitting three real bugs in one sitting: a syntax error from missing semicolons, arrow keys inserting garbage characters into filenames (fixed by adding read -e for proper line-editing), and ~ failing to expand inside a read prompt, since it only auto-expands as a typed command argument, not inside a variable read — fixed by manually substituting $HOME. None of this required knowing bash going in. The actual transferable skill was the debugging loop itself, and I compiled the whole thing into a running personal cheat sheet so it doesn't have to be re-learned from scratch.

Those same shell functions became the subject of my first full Git lifecycle a day later. I created a new dotfiles repository, cloned it into Kali, set up my Git identity for the first time, and added the bash functions in as a tracked file. Learned the three-stage workflow properly — add to stage, commit to checkpoint locally, push to upload — and hit a real wall almost immediately when GitHub rejected plain password authentication. Generating a Personal Access Token and using it in place of a password fixed it, which was less a coding problem and more a "how does GitHub's permission model actually work" gap. I also caught and fixed a missing closing bracket in the function code myself before committing, using pattern recognition from the earlier bash debugging session — and rewrote the README from a personal-narrative first draft into plain technical documentation, since that's what an actual reader of the code needs, not a story about my day. The repo itself is still thin — one file, three small functions, no license or .gitignore yet — but the workflow itself (create, clone, commit, authenticate, push, iterate) is now a known quantity instead of a mystery.

On the pure networking side, the standout session was DNS security — specifically TCP 53 versus UDP 53, zone transfers, DNS tunneling, and reverse DNS. DNS defaults to UDP for standard queries and falls back to TCP when responses exceed 512 bytes, during zone transfers, or for large record sets, which means TCP 53 showing up on a scan is worth a second look. Zone transfers are only meant to sync a primary DNS server to its secondaries, but misconfigured servers will hand the entire internal zone — subdomains, internal IPs, mail servers, staging environments — to anyone who asks with dig axfr @nameserver target.com. I tested this against a real target and got refused, which is the correct, secure outcome, not a failed command — and I used zonetransfer.me, an intentionally vulnerable practice domain, to see what a successful transfer actually looks like instead of testing against something I shouldn't. DNS tunneling was the other half worth remembering: attackers exploit the fact that firewalls almost always allow DNS traffic out, encoding data into subdomain queries sent to an attacker-controlled server — TCP 53 gets favored for this since it handles larger payloads and stable sessions, which is exactly how tools like dnscat2 work, and it's a genuine SOC blind spot since most monitoring focuses on HTTP/HTTPS instead of DNS logs. Reverse DNS rounded it out — reversing an IP's octets and appending .in-addr.arpa to query a PTR record, handled automatically with dig -x, useful for quickly identifying what an unfamiliar IP in a log actually is.

A separate self-test session covered Ethernet naming conventions and fiber optic fundamentals — strong sessions overall, six out of eight and six out of seven, with the misses being precision issues rather than misunderstandings. SX means short wavelength, not "small," and 10GBASE-T is 10 Gbps, with the number in the name directly stating the speed rather than implying something larger. Fiber cable layers run core → cladding → buffer coating → strengthening material → outer jacket from the center out, with the light source itself belonging to the transceiver equipment rather than being a cable layer at all.

The week closed with something more physical: a video-guided Packet Tracer exercise building a home network topology — PC, laptop, webcam, and a wireless router. I used the auto-select cable tool correctly for wired connections and performed a full NIC swap on two separate devices, powering off, removing the wired card, installing a WPC300N wireless card, and powering back on — then, notably, repeated the exact same swap on the second device without the video walking me through it again. That repetition without hand-holding was the actual signal, more than the video-following itself.

What Didn't Go to Plan (Lessons Learned)

One day was a genuine zero — I wasn't at home, so nothing happened, no real story there. The day after that I was back home but still logged no cybersecurity progress, though I did put real time into math, revising old material and working through Taylor's series. Not a wasted day overall, just not one that moved the security or networking track forward, and worth being honest that the streak of technical wins had exactly one full gap in the middle of it.

Focus for Next Week

Confirm the Tokyo Night terminal theme actually renders correctly after moving the color scheme file to its proper system path, then layer Powerlevel10k on top once that's settled. Start Phase 1 of the NDP Watcher project — reading pcap files with scapy — since the environment and Git workflow are both finally in a state where that's a realistic next step instead of another setup detour. And round out the dotfiles repo with an actual license and .gitignore so it reads as a complete, if small, project rather than a work-in-progress.

This week has an unusual shape: almost the entire technical output landed in a single day. Monday alone covered a real infrastructure debugging session, the actual kickoff of my Python learning roadmap, and a full CTI-style workflow for detecting AI-generated images. Then math obligations, a tuition day that ran long, and a couple of days out of station flattened the rest of the week down to close to nothing. Not the balance I'd want, but Monday was dense enough that it's worth walking through properly.

Core Technical & Personal Insights

The day started with a genuinely annoying infrastructure problem: getting file transfer working cleanly between my host machine and my Kali VM. I landed on SCP as the actual method, with VirtualBox Shared Folders and plain drag-and-drop noted as alternatives, but getting there meant working through a real chain of errors — literal <> brackets left in a placeholder IP, unquoted spaces breaking a "Tor Browser" path, doubled quotes, and finally the actual root cause: a NAT versus Bridged Adapter networking mismatch throwing "Network is unreachable." Switching Kali's VirtualBox adapter to Bridged, pulling a fresh IP with ip a, and confirming the SSH service was running fixed it, and the SCP transfer from Windows PowerShell finally went through. While I was in there, I also set up shared clipboard through Guest Additions in Bidirectional mode, then went a step further and installed CopyQ for Windows-style clipboard history, since Win+V doesn't carry across the host/guest boundary by default — bound it to a hotkey and added it to autostart so it's not a one-time fix.

From there I moved into actually starting the Python side of things. I locked in a three-phase, twelve-project roadmap — Python fundamentals, then a Python-plus-networking bridge phase, then real cybersecurity tooling, ending in a capstone SOC lab write-up mapped to MITRE ATT&CK. Decided to build all of it inside the Kali venv at ~/projects/python-labs rather than splitting work across Windows and Linux, which should keep the environment consistent as the projects get more networking-heavy. Project 1 — FizzBuzz — got started, covering loops, modulo logic, and conditional ordering, along with the basic setup commands for activating the venv and running scripts. Even the environment hygiene was a small lesson on its own: I had to fully tear down and reset the venv while troubleshooting a broken cd path, and it turned out projects had never actually been created under ~ — it existed under ~/Downloads instead, which is exactly the kind of assumption-checking mistake that's cheap to make and cheap to fix once you actually look.

The last piece of the day was building out a proper workflow for image forensics and AI-detection — something I'm treating as a CTI triage skill rather than a one-off curiosity. The pipeline runs EXIF/exiftool first, then checks C2PA credentials, then a reverse image search across Google, TinEye, and Yandex, then a manual visual artifact checklist (hands, shadows, reflections, texture), then Error Level Analysis through FotoForensics, and finally cross-checks against at least two independent AI detectors like Hive, Illuminarty, or AI or Not. Two things got reinforced hard while building this out: metadata alone is never a verdict, only a probability signal, and when detectors disagree with each other, that means "inconclusive," not "call it 50/50 and move on." The whole structure is deliberately built on intelligence-assessment logic — corroborate across independent sources before concluding anything, the same discipline CTI triage actually runs on.

What Didn't Go to Plan (Lessons Learned)

Everything after Monday went quiet on the cybersecurity side. Tuesday and Wednesday went entirely to math — homework and studying for an upcoming test, with zero cybersecurity work either day. Thursday's tuition session ran long, and by the time I got home I was tired enough that the evening went to gaming instead of anything productive, which I'm not going to dress up as anything other than what it was. Friday and Saturday I was out of station, so those two are genuinely no-fault — there wasn't really a study session to have. Sunday I was back home, but the day went to relaxing and playing rather than even a light session, which is the one day this week I'd actually push back on myself about, since there was no real obstacle in the way.

Focus for Next Week

Get back into the Python roadmap and move past Project 1 — FizzBuzz was the warm-up, not the destination. Keep the image forensics workflow alive as a real project, not just a one-time build; it's got genuine portfolio and blog potential as a documented CTI-style methodology. And going into a week that's likely to have fewer travel disruptions, the goal is simple: don't let one strong day carry six quiet ones again.

This week nearly didn't happen. The first half was close to a write-off — backlog piling up, networking postponed for days running, the honest kind of procrastination where you can name exactly why it's happening and still can't quite stop it. Then Thursday flipped a switch, and the back half of the week turned into the most technically dense stretch I've had yet: a brutal ports memorization session, my first taste of TryHackMe, a clean sweep on traffic types, and — the actual highlight — a full passive-and-active recon exercise on my own network that tied everything together into something that felt like real fieldwork instead of another self-test.

Core Technical & Personal Insights

The turnaround started with the least glamorous topic possible: memorizing common protocol ports. I went in and only got 6 out of 16 clean on the first pass, which sounds rough until you look at why — every miss was a number I'd guessed wrong or forgotten, not a concept I misunderstood. SSH and SFTP share port 22 because SFTP actually runs as a subsystem inside SSH rather than being a separate service. DHCP splits into server on port 67 and client on port 68. TFTP on port 69 is for firmware, config, and PXE boot transfers — not VoIP, which is where I'd misfiled it. I had HTTP and HTTPS numbers wrong outright (80 and 443), mixed up SNMP's versions (v1/v2 are plaintext with weak auth, v3 is properly encrypted with real authentication), and needed LDAP (389) versus LDAPS (636), SMB (445), MSSQL (1433), RDP (3389), and SIP (5060 plain / 5061 over TLS) filled in. The pattern was consistent enough that it pointed to a clear fix: this needs dedicated flashcard repetition, not more conceptual review — the reasoning is already there, the raw recall isn't.

That same evening I tried out TryHackMe's free rooms for the first time, mostly just to see what the platform actually feels like before committing money to it. First impression: genuinely well-structured, with explanations that hold up. The plan now is to finish the networking course first, then take a focused one-month membership and get as much out of it as possible in that window rather than dragging it out.

The weekend is where things really came together. A VPN and IPSec session landed at 8 out of 10, with the one correction that actually mattered being that IPSec's two core protocols are AH and ESP — not AH and ISAKMP, which belongs to the separate IKE key-management layer entirely. GRE came up too, and it's worth remembering it provides zero security on its own, no encryption or even integrity hashing, which is exactly why it's so often paired with IPSec. Right after that, a traffic-types session (unicast, multicast, anycast, broadcast) went a clean 8 for 8 — full sweep, including the detail that IPv6 replaces broadcast with multicast entirely.

Sunday closed the week with the actual highlight: a full passive-and-active reconnaissance exercise on my own hotspot network — laptop, Kali VM, two phones, and the hotspot device itself. I ran a passive capture with tcpdump -i eth0 -n -w recon_capture.pcap for about five minutes to grab natural traffic, then active host discovery with nmap -sn 10.234.20.0/24 to pull IP, MAC, and vendor info for everything live on the network. Cross-checked all of it against arp -a and the live ARP packets sitting in the pcap, then confirmed the gateway with ip route. The interesting find was a device nmap flagged as "Intel Corporate" that turned out to be my own laptop's Wi-Fi adapter, showing up separately from my Kali VM — the virtual NIC gets its own MAC and IP entirely, which I confirmed with lspci and dmidecode showing no real wireless hardware inside the VM, plus VirtualBox's known Intel-style MAC prefix for virtual adapters. Two phones showed up as "Unknown" vendor, which turned out to just be MAC randomization — a privacy feature on modern iOS and Android, not something to chase as suspicious. The real value wasn't any single finding, though — it was having three independent methods (nmap, ARP, routing table) all agree with each other, and getting to actually apply the passive-then-quiet-active-then-louder-active ordering to a real goal instead of reading about why attackers structure recon that way.

The same day rounded out with a Wi-Fi standards, cellular, and satellite session at 6 out of 10 first pass — again, mostly generational naming rather than misunderstood mechanics. The Wi-Fi 1/2/3 mapping was reversed in my head (it's actually b=1, a=2, g=3), and 802.11ax is Wi-Fi 6, not Wi-Fi 5. I also filled in that LTE unified two separate 3G lineages — GSM/UMTS and CDMA/EV-DO — and locked down the numbers: LTE tops out around 100 Mbps down, LTE-A theoretically around 1 Gbps, and 5G's theoretical ceiling sits near 10 Gbps (a rate, not a file size, which I'd apparently written down wrong at some point).

What Didn't Go to Plan (Lessons Learned)

The first three days of the week were close to dead on the cybersecurity side. Monday I published the previous week's overdue report but did nothing else — no math, no self-tests, which just moved the backlog forward into a day I already knew had an HOD-led class waiting, meaning I needed to revise old material on top of everything else. Tuesday and Wednesday kept the same shape: networking kept getting postponed, and I noticed it happening in real time without managing to stop it. I don't think there's a clean external reason for that stretch — it was just low energy and momentum that hadn't built up yet, and naming it honestly here felt more useful than inventing a cause that wasn't really there.

Focus for Next Week

Turn the ports weak spot into an actual flashcard routine — Anki-style, spaced repetition, treated as its own recurring task instead of something folded into general review. Keep pushing to finish the networking course inside the next two weeks, since that's the real gate before TryHackMe becomes the main focus instead of a side experiment. And carry forward whatever made Thursday through Sunday work, because whatever broke the early-week stall is worth understanding well enough to trigger on purpose next time, not just wait for it to happen again.

I wanted to answer a simple-sounding question: how many devices are actually connected to my mobile hotspot, and what are they?

My setup was small — my laptop (running Kali in a VM), my hotspot phone acting as the router, and two other phones connected to the same network. Simple enough to count on one hand, right? I thought so too. Turns out, actually proving it — with evidence, not assumptions — taught me more about ARP, DHCP, and virtualization than I expected from what I thought would be a quick 20-minute exercise.

This post walks through the full recon process I used, structured the way an attacker doing reconnaissance would approach it: passive first, active only when needed, and always cross-checking one source against another before trusting it.

Prerequisites

To follow along, it helps to already know:

• Basic IP addressing (what an IP address and subnet look like)

• What a MAC address is, at a surface level

• Comfort opening a terminal and running basic Linux commands

• Wireshark installed, and a Kali (or any Linux) environment with nmap and tcpdump available

The Core Concept

Every device on a local network needs two things to actually talk to other devices: an IP address (its logical "mailing address") and a MAC address (the physical hardware address baked into its network card). Devices don't naturally announce "here's my full identity" to anyone who asks — but they are constantly leaking information just by functioning normally.

Three protocols do most of this leaking, and they became the backbone of this whole exercise:

• ARP (Address Resolution Protocol) — resolves an IP to a MAC address. Think of it as shouting into a room: "Whoever is at this address, tell me your badge number."

• DHCP (Dynamic Host Configuration Protocol) — how a device gets assigned an IP in the first place, like checking into a hotel and being handed a room number by the front desk.

• mDNS (Multicast DNS) — how devices announce human-readable names on a local network without any central server, which is why your phone shows up as "Someone's iPhone" on shared Wi-Fi.

None of these require an attacker (or a curious student) to send anything unusual — you just have to listen.

How It Works

I followed a deliberate order, mimicking how a real attacker minimizes their footprint during reconnaissance — a concept that maps directly onto MITRE ATT&CK's Reconnaissance and Discovery tactics:

1. Passive listening first. Capture traffic without sending anything. Let devices reveal themselves through normal background chatter (ARP refreshes, mDNS announcements, DHCP renewals).

2. Quiet active scanning next, only if passive listening leaves gaps. ARP-based host discovery blends into normal network noise since ARP is required for basic connectivity anyway.

3. Escalate only if necessary. Louder techniques (full port scans, service enumeration) generate detectable footprints and were never needed for this exercise, since the goal was just device discovery.

4. Cross-verify everything. Never trust a single tool's output — confirm it against at least one independent source.

Syntax / Commands / Code

Step 1 — Passive capture:

sudo tcpdump -i eth0 -n -w recon_capture.pcap

• -i eth0 — capture on this specific interface

• -n — skip DNS/port name resolution (faster, and avoids generating extra DNS traffic that would pollute the very network I was trying to quietly observe)

• -w recon_capture.pcap — write raw output to a file for later analysis in Wireshark, rather than just scrolling text

Step 2 — Active ARP-based sweep:

sudo nmap -sn 10.234.20.0/24

• -sn — ping/ARP sweep only, no port scanning. This finds live hosts fast and quietly, and automatically resolves each MAC address's manufacturer using nmap's built-in vendor database.

Step 3 — Cross-checks:

arp -a          # Quick local ARP cache check
ip a            # Confirm my own machine's interface, IP, and MAC
ip route        # Confirm the actual default gateway

I also opened the .pcap in Wireshark and filtered specifically for the "free information" packet types:

arp or mdns or dhcp

Practical Example

Running the sweep gave me a full list of live hosts in one shot:

Nmap scan report for 10.234.20.28
MAC Address: 8C:E9:EE:86:01:32 (Intel Corporate)

Nmap scan report for 10.234.20.51
MAC Address: E8:5A:8B:8C:25:B5 (Xiaomi Communications)

Nmap scan report for 10.234.20.126
MAC Address: 3E:98:EB:7C:10:31 (Unknown)

Nmap scan report for 10.234.20.138
MAC Address: 8E:05:CF:B2:E6:45 (Unknown)

Nmap scan report for 10.234.20.192
Host is up.

Five hosts, no MAC shown for .192 since that was my own scanning machine. Straightforward — or so I thought.

Common Mistakes (and Where I Actually Got Stuck)

This is the part I want to spend real time on, because the "clean" writeup above hides how messy this actually was to work through live.

Mistake 1 — Trusting the vendor label at face value. .28 showed up as "Intel Corporate." I run an AMD laptop. My first instinct was: is this a rogue device? Another laptop I don't know about? That's a dangerous assumption to run with unverified — nearly wrote it off as "some Intel PC on the network" before stopping to actually question it.

Mistake 2 — Confusing CPU vendor with network chipset vendor. Even after doubting the "rogue device" theory, I initially forgot that a laptop's CPU (AMD) and its Wi-Fi card are completely separate pieces of hardware — plenty of AMD machines ship with Intel-made wireless chips. This cost me a detour running lspci | grep -i wireless, which returned nothing at all.

Mistake 3 — Not accounting for virtualization. The empty lspci output was actually the real clue, and I almost brushed past it. Once I checked dmidecode -s system-product-name and confirmed I was inside a VM, everything clicked: my Kali instance only sees a virtual network adapter, not my laptop's real physical Wi-Fi card. That explained three separate confusions at once — why I had eth0 instead of wlan0, why lspci showed nothing wireless, and why .28 carried an Intel-style MAC (VirtualBox's virtual NICs default to Intel-like vendor prefixes).

Mistake 4 — Assuming "Unknown" vendor meant something was wrong. Two phones (.126 and .138) showed "Unknown" instead of a real manufacturer name. My gut reaction was that nmap had failed to identify them. It hadn't — this is MAC address randomization, a deliberate privacy feature on modern iOS/Android where a device generates a fake, temporary MAC per network specifically to prevent tracking. "Unknown" here is actually a good sign — it means the phone's privacy protections are working as intended, not a gap in my tooling.

Mistake 5 — Misreading a DHCP packet direction. I found a DHCP Request going from my Kali VM directly to .138, and assumed I'd misidentified which device was the gateway — because I'd been treating .138 as "just another phone" up to that point. Running ip route settled it immediately: .138 was the actual DHCP server / default gateway (the hotspot phone) all along. The packet made perfect sense once I had the right mental model of who was who.

The "Aha" Moment

Genuinely, the moment ip route printed default via 10.234.20.138 was the most satisfying part of this whole exercise. Every earlier thread — the Intel mislabeling, the missing wlan0, the empty lspci, the DHCP packet aimed at a device I'd wrongly assumed was "just a phone" — collapsed into one consistent, fully explained picture within about thirty seconds of reading that one line.

It's a specific kind of relief that's hard to describe if you haven't felt it: the feeling of having four separate loose threads in your head, each one slightly annoying on its own, and then watching them all tie into a single, obvious knot at once. Nothing about the network had actually changed — I just finally had the right frame to interpret what I was already looking at. That's a genuinely different feeling than just "getting the right answer" from a tutorial; this was earned through actually being wrong first.

Best Practices / Tips

• Never trust a single tool's output in isolation. Cross-check nmap against ARP cache, live packet captures, and the routing table before treating anything as confirmed.

• Know your own hardware baseline before investigating unknown devices — I couldn't have caught the Intel discrepancy without already knowing I run AMD.

• "Unknown" vendor isn't automatically suspicious. Learn to recognize MAC randomization as expected, privacy-driven behavior on modern phones.

• Virtualization changes your network footprint. A single physical machine can appear as multiple distinct network entities (host + VM), each with independent IPs and MACs — factor this in before concluding a device is unidentified.

• Always confirm the gateway with ip route early — it resolves a lot of ambiguity about device roles before you go chasing false leads.

Real World Applications

This exact workflow — passive listening, quiet active discovery, cross-verification, and healthy skepticism toward tool output — is directly how SOC analysts and threat hunters build an asset inventory on unfamiliar or newly-monitored networks. Recognizing VM-originated traffic, randomized MACs, and gateway identification are all everyday tasks in real network investigations, not just classroom exercises. Understanding both sides — how an attacker performs low-friction recon, and how a defender interprets the same traffic — is core to CTI and SOC work alike.

Key Takeaways

• ARP, DHCP, and mDNS traffic passively reveal most of a network's device map without sending a single scan

• nmap -sn gives a fast, low-noise active sweep with automatic vendor identification

• Vendor/OUI labels are a clue, not proof — virtualization, chipset suppliers, and MAC randomization can all mislead a surface-level reading

• Cross-referencing multiple independent sources (nmap, ARP cache, routing table, live capture) is what actually builds confidence in a finding

• Getting confused and working back out of it taught me more than if everything had matched cleanly on the first try

Started strong — finally published the previous week's overdue report and scored 6/8 on a networking self-test the same day. Kept the momentum for two more sessions, catching a genuine misconception on VPC endpoints along the way. Then a surprise math test hijacked a full day, an AI rate-limit killed another, and a big note-taking push got cut short by a power cut. By the time this report was due, nothing was left in the tank, and it's going out late. Again. Same mistake as last time, and I noticed it happening.

The week that started strong

I opened the week by clearing a debt — the previous week's report finally went out, later than planned but out. Same day, I ran a self-test on IDS versus IPS, load balancers, NAS versus SAN, and proxy mechanics, and landed 6 out of 8 on the first pass. Two things needed tightening: an L3 switch isn't just "a switch with routing bolted on" — it routes between VLANs and subnets using IP, in hardware, at wire speed, which is a very different claim than the vague version in my head. And an access point bridges 802.11 into 802.3, not 802.2 — that's the LLC sublayer, a completely different layer of the stack I'd been quietly conflating. Two lecture videos got finished on top of that. A genuinely solid start, and I'm allowed to say that without immediately talking myself out of it.

The self-tests kept holding up

The next session went almost as well — another 6 out of 8, this time on DNS TTL, QoS naming, VPN concentrators, and routing loops. One correction actually mattered: I had the DNS TTL logic backwards. Before an IP change, you lower the TTL in advance, so the old, cached record expires fast, and everyone converges on the new IP sooner — I'd been picturing the whole mechanism running in the opposite direction. QoS terminology got cleaned up too; the real names are traffic shaping or traffic/bandwidth prioritization, not "packet shaping," which I'd apparently invented with total confidence.

A cloud networking self-test followed — 5 out of 8, three fixes needed, and one of them wasn't just sloppy wording. I genuinely had VPC endpoints wrong: they connect privately to the same cloud provider's own services, not a bridge between two different providers' VPCs like I'd assumed. Internet Gateways got a smaller correction too — they handle traffic both ways for public-IP resources, not just inbound. That one landed at 9:45 PM, cutting it close, but it still counts.

Then math ambushed me

One full day disappeared without a single minute going to networking. The head of the mathematics department sprang a surprise check on Class 11 and 12 basics, and I spent the entire day frantically re-learning material I hadn't touched in two years, purely so I wouldn't embarrass myself in front of an actual department head. My first math tuition class landed the same day — went fine, got practice questions, and discovered mid-session that I need an actual dedicated notebook before I can be consistent about any of it. Apparently, stationery is a prerequisite for discipline, which nobody warns you about but still no solution in sight sadly.

The AI token apocalypse

I tried to recover the next stretch by writing notes for three more lecture videos, and I did — but it took long enough, and burned through enough tokens, that I got rate-limited mid-session and had to stop entirely. No other study happened that day, college or cybersecurity. Losing a day because your own note-taking tool ran out of gas is a very specific, very 2026 way to fail at being productive.

The marathon, then the blackout

I came back hard after that — eleven straight videos of notes in one sitting, a real push. Then the power went out. Repeatedly. The session ended there, and math homework didn't get touched either. Still, eleven videos of notes in one day is not nothing, and I'm keeping that win without an asterisk attached to it.

Where it fell apart again

By the time this report was due, I had nothing left — tuition homework got done, nothing else did. No further networking notes, no further study. And the report itself went out late, same as last time, exactly one cycle apart. That's not bad luck twice. That's a pattern I need to actually name instead of quietly noting and moving on from.

The numbers

• 3 self-tests: 6/8, 6/8, 5/8

• Roughly 13 lecture videos noted across the week

• 1 genuine misconception caught and corrected (VPC endpoints)

• 1 surprise exam survived without public humiliation

• 2 days with zero networking progress

• 2 late weekly reports in a row

Going into Week 4

Same fix I keep writing down and not fully honoring: one fixed daily block, protected, no exceptions for surprise tests or dying AI tokens. And the report gets a hard deadline this time, not a "sometime around Sunday" one — if it's late again next week, that's the actual headline, not something buried at the bottom.

Let me just walk through it instead of dressing it up.

The part that stings a bit

Most of the week, I did basically nothing on the security side. No TryHackMe, no Bandit, no structured study. College started, and the first day I came home genuinely wiped out — that one I don't feel bad about, that's just real life. But instead of resetting the next day, I let that tiredness become an excuse, and one off day turned into several. Games and random videos ate the time that was supposed to go into learning.

And the part that actually bugs me more than the missed work itself — I had built a fallback for exactly this situation. "Even on a bad day, do the 15-minute version, keep the chain alive." I didn't even do that. I just... skipped it. Not because the fallback was too hard, but because once you miss one day it gets weirdly easy to justify missing the next.

So yeah. No sugarcoating — this week was mostly games and videos where study was supposed to be.

What actually did happen, though

It wasn't a total zero, even if it feels that way:

• Sorted out an annoying setup issue with the new Obsidian vault

• Actually wrote proper notes for the first couple of days

• Found a free platform + certificate route worth checking out before spending money on TryHackMe, plus did a little digging into how it's structured

• Sat down and read through the entire semester-wise curriculum PDF — genuinely useful, now I know what's coming in every semester, especially this one:

  • Major-1: Computer Fundamentals and Digital Logic

  • Major-2: Introduction to Programming using C

  • Minor-3: Introduction to Programming using Python

  • Minor-4: Data Structures & Algorithms

  • Minor-6: Operating Systems

That curriculum read-through matters more than it sounds like on paper — I'm not walking into class blind now, I know roughly what to pre-read before each subject actually starts.

What I'm taking from this

I already know my own pattern — big ambition, then a discipline dip, then feeling bad about it, then repeat. This week is basically that pattern on display in real time. Knowing that about myself doesn't make it not happen, apparently. But at least I'd rather write it down honestly than pretend week 1 went fine when it didn't.

Going into week 2

Not going to list five fixes, because that's usually how I set myself up to fail again. Just one thing: a fixed time block, same time every day, even if it's only 20–30 minutes. "Study more when I get the energy" isn't a plan, it's just hoping. A fixed slot is something I can actually check myself against.

I'm also cutting one goal off my original list for this next cycle — better to actually hit a smaller target than keep missing a bigger one.

Next Sunday's post will say straight up whether that time block actually held or not.