Real home network lab
The virtual lab stayed inside a network with no connection to anything else — safe to break, safe to misconfigure, safe to tear down without consequence. Your actual home network doesn't have that luxury: other devices depend on it right now, and a router's own DHCP pool, default gateway, and DNS settings are shared infrastructure the moment more than one device uses them. This lab applies the exact same inspection — routing table, ARP resolution, packet capture — to that real, shared network instead, with the added care that comes from it actually mattering if something goes wrong.
Goal and end result
By the end of this lab, you'll have mapped your own home network from your laptop alone — its address range, its default gateway, every other device currently on it — using nothing but read-only commands, and you'll understand exactly what each one is asking the network to tell it.
Topology
Internet
|
+--------+--------+
| Home router |
| 192.168.1.1 |
| (DHCP + NAT) |
+--------+--------+
|
home Wi-Fi / Ethernet segment
|
+-----------------+-----------------+
| | |
your laptop phone, TV, etc. other devices
192.168.1.somenumber (addresses assigned by the
same router)
Every device here got its address from the same router's DHCP server — the exact process the DHCP lease articles already covered message by message. This lab confirms that from the outside, by reading what your own machine actually received, rather than taking the protocol's description on faith.
Requirements
- A laptop or desktop already connected to your home network, wired or Wi-Fi.
ip(fromiproute2, installed by default on virtually every current Linux distribution) and, optionally,nmapfor the device-discovery step — install it if it isn't already present.
Safety note
Every command in this lab is read-only: it asks your own machine or your router what's already true, and changes nothing. Nothing here modifies your router's configuration, your DHCP pool, or any other device's network settings. The one command that scans other addresses on the network (nmap, in the device-discovery step) only sends the same kind of probe traffic a normal device already generates constantly — it doesn't attempt to connect to, exploit, or disrupt anything it finds.
Scan only networks you have the right to scan
Running nmap against your own home network, which you own and administer, is unambiguously fine. Running the same scan against a network you don't own or administer — a coffee shop's Wi-Fi, a corporate network you're a guest on — is a different situation entirely, and in many places a legal one, regardless of intent. Keep this specific step confined to your own network.
Step 1: find your own address and your router's
2: wlo1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether a4:5e:60:11:9c:02 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.42/24 brd 192.168.1.255 scope global dynamic wlo1
valid_lft 42891sec preferred_lft 42891sec
192.168.1.42/24 is this machine's address, assigned dynamically (dynamic, rather than a manually configured static address) by DHCP — the same private-address range this course covered from the start. Now find the router itself, which is the default gateway every packet leaving this subnet passes through first:
192.168.1.1 is almost always the router itself on a home network — proto dhcp confirms this route came from the DHCP lease, not a manual configuration, tying directly back to the router option in the DHCP ACK message the DHCP lease articles already described.
Step 2: confirm the router actually answers
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=2.13 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=1.87 ms
64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=1.95 ms
64 bytes from 192.168.1.1: icmp_seq=4 ttl=64 time=2.02 ms
--- 192.168.1.1 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3005ms
rtt min/avg/max/mdev = 1.870/1.992/2.130/0.098 ms
A ttl=64 at a distance of one hop and a round trip in the low single-digit milliseconds is exactly what a healthy local Wi-Fi or Ethernet segment should look like — compare this to the latency figures this course already discussed for longer paths, where even a single-digit millisecond round trip only happens at very short physical distances.
Step 3: see the ARP resolution behind that ping
Before the ping in step 2 could reach 192.168.1.1, this machine needed the router's MAC address, resolved through the same ARP exchange the ARP article covered in depth:
That lladdr is the router's actual MAC address, on this specific network, right now. Keep it visible for the next step — a changed MAC address for the same IP, with no explanation, is exactly the ARP-spoofing signature that article's scenario walked through.
Step 4: discover what else is on the network
Starting Nmap 7.94 ( https://nmap.org ) at 2026-07-27 14:02 UTC
Nmap scan report for 192.168.1.1
Host is up (0.0019s latency).
MAC Address: 58:60:5F:08:E8:AA (TP-Link Corporation)
Nmap scan report for 192.168.1.42
Host is up.
Nmap scan report for 192.168.1.67
Host is up (0.0041s latency).
MAC Address: 3C:22:FB:1A:9E:04 (Apple, Inc.)
Nmap done: 256 IP addresses (3 hosts up) scanned in 2.31 seconds
-sn is nmap's own ping scan flag — its own --help output describes it exactly as "Ping Scan - disable port scan." The nmap article already introduced nmap's core scanning modes; this flag specifically skips port scanning entirely and only checks which addresses on the range respond at all, which is exactly the read-only, non-intrusive discovery this lab needs. sudo here is for the same reason the nmap article already explained root is needed for certain scan types: some of nmap's host-discovery techniques use raw sockets, which require elevated privileges to open. The vendor name in parentheses after each MAC address comes from the same OUI system the MAC address article already covered — nmap looks up the first half of the address against a database of manufacturer registrations, which is how it can label an unfamiliar device "Apple, Inc." without ever contacting it beyond the ping itself. The router shows up at .1, this machine at .42, and one more device at .67 — three hosts on a /24 that could technically hold 254.
Step 5: watch a real DHCP renewal, without forcing one
Rather than releasing and renewing your own lease — a genuinely disruptive action on a network you're currently using — capture passively and wait for a lease renewal to happen on its own, or trigger one from a device you're not actively depending on:
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on wlo1, link-type EN10MB (Ethernet), snapshot length 262144 bytes
14:15:02.881233 IP 192.168.1.42.68 > 192.168.1.1.67: BOOTP/DHCP, Request from a4:5e:60:11:9c:02, length 300
14:15:02.883701 IP 192.168.1.1.67 > 192.168.1.42.68: BOOTP/DHCP, Reply, length 300
Ports 67 and 68 are DHCP's well-known server and client ports — the exact ports the DHCP article already named. A Request followed by a Reply from the router is a lease renewal, not a fresh lease negotiation — the full four-message DISCOVER/OFFER/REQUEST/ACK exchange only happens when a device first joins the network or its previous lease has fully expired, which the DHCP lease process covered as the less common, full-negotiation path.
Don't force a lease release on a connection you're currently using
sudo dhclient -r or an equivalent "release and renew" action drops your current address immediately and can leave the interface without one for several seconds while it renegotiates — disruptive on a machine doing anything else at the time, and a bad idea over an SSH session to a remote host that depends on this same connection staying up. If you want to see a fresh full lease negotiation rather than a renewal, do it on a secondary device you're not actively using, or be prepared for a brief, real disconnection on the device you do run it on.
Troubleshooting
ip route show defaultreturns nothing. The machine has no default gateway configured at all — checkip addr showfor whether it received an address via DHCP in the first place, since a missing gateway route often means the DHCP lease itself never completed.nmap -snfinds only the router and this machine, despite other devices clearly being connected. Many phones and some IoT devices ignore ICMP echo requests by default as a privacy measure, which is exactly what a ping-scan-based discovery depends on —-snwill undercount a network with several privacy-conscious devices on it, not because they're absent, but because they don't answer the specific probe this scan mode uses.- The DHCP capture in step 5 shows nothing for a long time. Lease renewal timing depends on the lease length your router hands out, which can be hours — this step may require patience, or triggering a renewal on a device you're not using instead of waiting.
Cleanup
Nothing to tear down — every command in this lab was read-only, and no configuration was changed on your machine or your router.
Evaluation criterion
You've completed this lab correctly if you can state, from your own captured output rather than from memory: your own address and how it was assigned, your router's address and MAC address, at least one other device's presence on the network, and what a DHCP renewal's Request/Reply pair looks like in a live capture.
Both home-network labs stayed at the level of what's already on the network and how it behaves. The next lab looks inside a single capture in real depth — following one TCP stream from the handshake through to teardown, rather than a handful of isolated packets checked one at a time.
Sources
- Nmap.org, Chapter 15. Nmap Reference Guide