Learn how data moves between computers: layers, IP addresses and subnets, ports, DNS, DHCP, HTTPS, and the tools to troubleshoot it.

Networking Fundamentals

Show your configuration: `ipconfig /all` (Windows), `ip addr` and `ip route` (Linux) or `ifconfig` and `netstat -rn` (macOS). Write down your IP address, subnet mask or prefix, default gateway and DNS servers.

Ping yourself: `ping 127.0.0.1` (add `-c 4` on macOS/Linux). This tests your own network stack.

Ping your default gateway (from step 1). Note the round-trip times.

Ping a public IP address: `ping 1.1.1.1`. Then ping a name: `ping example.com`. If the IP works but the name fails, which layer is the problem?

Trace the route: `tracert example.com` (Windows) or `traceroute example.com` (macOS/Linux). Count the hops, note where the times jump, and note any `* * *` lines.

List listening ports: `netstat -an` (Windows: also try `netstat -ano` to see process IDs; Linux: `ss -tulpn`; macOS: `netstat -an | grep LISTEN`). Find two listening ports and look up which service usually uses them.

List established connections (`netstat -an` and look for ESTABLISHED). Open a website and run it again: find the new connections to port 443.

Write a short troubleshooting note: for each layer you tested (local stack, LAN, internet, DNS, application), what you ran and what the result showed.

## Why it matters

"I can't connect" is one of the most common tickets in IT, cloud and database work. Three built-in tools answer most of it in a few minutes: **ping** (can I reach it?), **traceroute** (where does the path break?), and **netstat** or **ss** (what is my computer connected to and listening on?). The skill is not the commands themselves but running them in a sensible order and reading the results.

## Start with your own configuration

Before testing anything remote, check what your machine thinks its settings are:

```bash
ipconfig /all          # Windows
ip addr; ip route      # Linux
ifconfig; netstat -rn  # macOS
```

Look for: an IP address in the expected range (not `169.254.x.x`), a subnet mask, a **default gateway**, and DNS servers.

## ping: is it reachable?

`ping` sends ICMP echo requests and reports replies and round-trip time:

```text
$ ping -c 4 1.1.1.1
64 bytes from 1.1.1.1: icmp_seq=1 ttl=57 time=12.4 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=57 time=11.9 ms
...
4 packets transmitted, 4 received, 0% packet loss
```

(On Windows `ping` sends 4 by default; on macOS/Linux it runs until Ctrl+C unless you add `-c 4`.)

Read the result:

- **Replies with low, steady times:** reachable.
- **Request timed out:** no reply. The host may be down, the path broken, or a firewall may block ICMP. Many servers block ping on purpose, so a timeout alone does not prove a server is down.
- **Destination host unreachable:** a router (or your own machine) has no route.
- **Packet loss or very uneven times:** a congested or flaky link, often Wi-Fi.

## traceroute: where does it break?

Every IP packet has a **TTL** (hop limit) that each router decrements; at zero, the router discards it and sends back an ICMP "time exceeded". `traceroute` (Windows: `tracert`) sends packets with TTL 1, 2, 3 and so on, so each router along the path reveals itself:

```text
$ traceroute example.com
 1  192.168.1.1     1.8 ms
 2  10.40.0.1       9.7 ms
 3  * * *
 4  72.14.215.85   14.2 ms
 ...
11  93.184.215.14  21.3 ms
```

- Hop 1 is your router. If that fails, the problem is in your home or office.
- `* * *` on a middle hop is usually just a router that does not answer traceroute; if later hops answer, ignore it.
- If every hop after a certain point is `* * *`, the path breaks there (or a firewall drops the probes).
- A big, sustained jump in time from one hop onward points to a slow link at that hop.

## netstat and ss: what is my machine doing?

```bash
netstat -an            # all connections and listening ports, numeric
netstat -ano           # Windows: add the process ID
ss -tulpn              # Linux: TCP/UDP listening sockets with process
```

Look for states: **LISTEN** (a service waiting for connections), **ESTABLISHED** (an active connection), **TIME_WAIT** (recently closed). This answers "is my web server actually listening on 8080?" and "what is this program connected to?".

## Worked example: a layered diagnosis

A user cannot open an internal web app at `http://intranet.local:8080`.

1. `ipconfig` shows `192.168.1.57/24`, gateway `192.168.1.1`. Settings look fine.
2. `ping 192.168.1.1` replies. The local network works.
3. `ping 1.1.1.1` replies. Internet routing works.
4. `nslookup intranet.local` returns NXDOMAIN. **DNS is the problem.** The user's DNS server is a public resolver that does not know internal names.
5. The fix is to use the company DNS server. If DNS had worked, the next step would be `netstat`/`ss` on the server to confirm something LISTENs on 8080, and then the firewall.

The order matters: you proved each lower layer before moving up, and stopped at the first failure.

## Other handy tools

- `nslookup` / `dig` for DNS (previous module).
- `curl -v https://example.com` shows the TCP connection, TLS handshake and HTTP response in one go.
- `Test-NetConnection example.com -Port 443` in PowerShell, or `nc -vz example.com 443` on macOS/Linux, checks one TCP port.

## Common mistakes

- **Concluding a server is down because ping fails.** Try the actual service port.
- **Panicking over `* * *` in the middle of a traceroute** when the destination still answers.
- **Skipping the local checks** and debugging the internet when the laptop has a 169.254 address.
- **Scanning or tracing networks you do not own** beyond normal use. Probing other people's systems can break policies or laws.

## Quick recap

- Check your own config first, then ping loopback, gateway, public IP, then a name.
- traceroute shows each hop; look at where replies stop or times jump.
- netstat/ss shows listening ports and connections.
- Work up the layers and stop at the first failure.

## Try it

Open the **Do** tab and run a full troubleshooting pass on your own machine.


Use ping, traceroute and netstat to diagnose a connectivity problem one layer at a time.

ping, traceroute, and netstat

PING and TRACERT (traceroute) networking commands

NETSTAT Command Explained

Find your router's address (your default gateway, from `ipconfig` or `ip route`) and your public address (search "what is my IP" in a browser). Are they the same? If not, why?

Identify the physical boxes: modem (or ONT for fibre), router, any separate access points, mesh nodes or switches. Note which cables connect what.

If it is your router, log in to its admin page (often printed on its label) and open the list of connected devices (DHCP clients). Otherwise, use your phone's or laptop's list of devices it can see.

List each device with its name, IP address and whether it is wired or wireless. Note any device you cannot identify.

Check the Wi-Fi settings on your laptop or phone: network name (SSID), band (2.4 GHz or 5 GHz, sometimes 6 GHz) and security type (WPA2 or WPA3).

Walk to the far side of your home and compare signal strength or speed (a speed test site, or the signal bars) with standing next to the router.

Draw the map on paper or in a drawing tool: internet, modem, router, switches/access points, devices, with IP addresses and bands.

Write down two improvements, for example: change a default admin password, turn off WPS, put smart-home devices on a guest network, or move the router to a central spot.

## Why it matters

Your home network is a full working network in miniature: addressing, DHCP, NAT, DNS, wireless and security, all in one box. Understanding it makes you better at supporting remote colleagues ("my VPN keeps dropping"), helps you secure your own devices, and gives you a lab you already own. Cloud virtual networks reuse the same ideas, just without the antennas.

## The boxes and what they do

- **Modem** (cable or DSL) or **ONT** (fibre): converts the ISP's signal to Ethernet. It is the edge of your ISP's network.
- **Router:** routes between your private network and the internet. It also runs NAT, the DHCP server, a firewall, and usually a DNS forwarder.
- **Switch:** connects wired devices on the same network (layer 2). Most home routers have a small switch built in (the LAN ports).
- **Wireless access point (AP):** bridges Wi-Fi devices onto the wired network. Also usually built into the router.
- **Mesh nodes:** several APs that cooperate to cover a larger home under one network name.

Many ISPs supply a single "gateway" that combines all of these.

## A typical home layout

```text
Internet
   |
[Modem/ONT] --- public address 203.0.113.7
   |
[Router: NAT, DHCP, firewall, Wi-Fi AP]  192.168.1.1
   |--- wired: desktop 192.168.1.20, TV 192.168.1.31
   |--- 5 GHz Wi-Fi: laptop 192.168.1.57, phone 192.168.1.58
   |--- 2.4 GHz Wi-Fi: smart plug 192.168.1.80, printer 192.168.1.90
```

Every inside device has a private address from DHCP and shares the public address through NAT.

## How Wi-Fi works, briefly

Wi-Fi (the IEEE 802.11 family) is layer 1 and 2 over radio. Devices and the AP take turns on a shared **channel**. Because only one device can transmit on a channel at a time, Wi-Fi speed is shared, and neighbours on the same channel slow each other down.

| Band | Range | Speed | Notes |
|---|---|---|---|
| 2.4 GHz | longest, passes walls best | lowest | crowded; only 3 non-overlapping channels (1, 6, 11) in most regions |
| 5 GHz | medium | high | many more channels |
| 6 GHz (Wi-Fi 6E/7) | shortest | highest | needs newer devices |

Generations you will see on boxes: Wi-Fi 5 (802.11ac), Wi-Fi 6/6E (802.11ax), Wi-Fi 7 (802.11be).

Signal strength drops with distance, walls (especially concrete and metal), floors, and interference from microwaves and other networks.

## Wi-Fi security

- **WPA3-Personal** is the current standard; **WPA2-Personal (AES)** is acceptable if devices do not support WPA3.
- **WEP and WPA (TKIP)** are broken; do not use them.
- **WPS** (push-button or PIN pairing) has a history of weaknesses; turning it off is a common hardening step.
- A long, unique Wi-Fi passphrase matters because anyone nearby can try to guess it offline after capturing a handshake.

Router admin hygiene matters just as much: change the default admin password, keep firmware updated (or choose a router that updates itself), and disable remote administration unless you need it.

## Guest networks and segmentation

A **guest network** puts visitors, and ideally smart-home ("IoT") devices, on a separate segment that cannot reach your laptops and file shares. This is a small-scale version of **network segmentation**, a core idea in security engineering: if one device is compromised, it should not reach everything.

## Worked example: "Wi-Fi is slow upstairs"

1. Check whether it is Wi-Fi or the internet: run a speed test next to the router. Fast there? The ISP is fine.
2. Upstairs, the laptop shows 2.4 GHz with one bar. Far from the router, it fell back to the longer-range band.
3. Options, cheapest first: move the router to a central, raised position away from metal; set a less crowded channel; add a wired access point or mesh node upstairs.
4. Re-test in both places and record the numbers.

## Common mistakes

- **Leaving the default router password**, or exposing the admin page to the internet.
- **Assuming more bars means faster.** Interference and crowded channels matter too.
- **Putting a second router in router mode** behind the first (double NAT, two DHCP servers). Use access-point mode instead.
- **Ignoring unknown devices** in the client list.

## Quick recap

- Modem/ONT, router (NAT, DHCP, firewall), switch and access point are separate roles, often in one box.
- 2.4 GHz reaches further; 5 and 6 GHz are faster but shorter range.
- Use WPA3 or WPA2-AES, change default passwords, update firmware, and segment guests and IoT.

## Try it

Open the **Do** tab and map your own home network.


Explain how a home router, Wi-Fi bands and security settings fit together, and map your own home network.

Wi-Fi and home networks

Routers vs. Switches vs. Access Points - And More

2.4 GHz vs 5 GHz WiFi: What is the difference?

Install Wireshark from https://www.wireshark.org/ (on Windows, accept the Npcap install; on macOS, accept the ChmodBPF helper). Open it and pick your active interface (the one with a moving traffic graph).

Start a capture, then in a terminal run `nslookup example.com`, and open https://example.com in your browser. Stop the capture after about 10 seconds.

Apply the display filter `dns` and find the query and its response. In the details pane, expand Ethernet, IP, UDP and DNS, and note the source and destination port and the answer address.

Apply the filter `tcp.flags.syn == 1` and find the SYN and SYN-ACK to the address from the DNS answer. Right-click a packet, choose Follow > TCP Stream, and confirm the content is unreadable (TLS-encrypted).

Apply the filter `tls.handshake.type == 1` to find the Client Hello, and look for the server_name (SNI) field. What does it reveal even though the traffic is encrypted?

Open Statistics > Protocol Hierarchy and note the three most common protocols in your capture.

Delete or securely store the capture file when you are done: captures can contain sensitive data from your own machine.

## Why it matters

Every tool so far gives you a summary. A **packet capture** shows the actual frames on the wire, so you can see exactly what a device sent and what came back. Security engineers use captures to investigate suspicious traffic, network and cloud engineers use them to prove where a connection fails, and database administrators use them to debug slow or dropped client connections. **Wireshark** is the free, standard tool.

## Before you capture: rules

Capture only traffic you are authorised to see: your own computer on your own network, or a lab you are allowed to use. On a work or school network, ask first; capturing other people's traffic can break the law and policy even if the tool makes it easy. Captures can also contain your own secrets (cookies, internal names), so store them carefully and delete them when done.

## How a capture works

Your network adapter normally hands the operating system only the frames meant for it. A capture library (**Npcap** on Windows, **libpcap** on macOS/Linux) copies frames as they pass through the adapter. On switched wired networks you see your own traffic plus broadcasts; on Wi-Fi you normally see only your own traffic. Captures are saved as `.pcapng` files.

The command-line equivalent is `tcpdump`:

```bash
sudo tcpdump -i en0 -n port 53        # DNS on interface en0
sudo tcpdump -i eth0 -n -w out.pcap   # save to a file for Wireshark
```

## The Wireshark window

1. **Packet list:** one row per frame: number, time, source, destination, protocol, length, info.
2. **Packet details:** the layers of the selected frame, one expandable line each: Frame, Ethernet II, Internet Protocol, TCP or UDP, then the application protocol. This is the OSI model made visible.
3. **Packet bytes:** the raw hex.

## Filters

There are two kinds:

- **Capture filters** (BPF syntax, set before you start) decide what is recorded: `port 53`, `host 192.168.1.1`.
- **Display filters** (set after) decide what is shown, and are far more flexible:

```text
dns                          DNS only
ip.addr == 93.184.215.14     to or from one address
tcp.port == 443              HTTPS traffic
tcp.flags.syn == 1           connection attempts
tcp.analysis.retransmission  resent segments (a sign of loss)
http || dns                  combine with or
!(arp || mdns)               hide noise
```

The filter bar turns green when the syntax is valid.

## Worked example: reading a DNS lookup

You capture while running `nslookup example.com` and filter on `dns`:

```text
No.  Source         Destination    Protocol  Info
12   192.168.1.57   192.168.1.1    DNS       Standard query 0x3a1f A example.com
13   192.168.1.1    192.168.1.57   DNS       Standard query response 0x3a1f A example.com A 93.184.215.14
```

Expanding packet 12: **Ethernet II** shows your MAC and the router's MAC; **IPv4** shows the two IP addresses and a TTL; **UDP** shows source port 58123 and destination port 53; **DNS** shows the transaction ID 0x3a1f and the question. Packet 13 has the same ID, which is how your computer matches the answer to the question.

## Worked example: a TCP handshake

Filter `tcp.port == 443` after opening a site:

```text
21  192.168.1.57 -> 93.184.215.14  TCP  52814 -> 443 [SYN]
22  93.184.215.14 -> 192.168.1.57  TCP  443 -> 52814 [SYN, ACK]
23  192.168.1.57 -> 93.184.215.14  TCP  52814 -> 443 [ACK]
24  192.168.1.57 -> 93.184.215.14  TLSv1.3  Client Hello
```

The time between 21 and 22 is the network round trip. If you saw SYNs repeated with no SYN-ACK, a firewall or a dead server would be the suspect; a reply with `[RST, ACK]` means the host answered but nothing listens on that port.

Follow TCP Stream on an HTTPS connection shows unreadable bytes: TLS works. The Client Hello still shows the **SNI** (server name), which is why an observer can usually tell which site you visited.

## Common mistakes

- **Capturing everything for an hour** and drowning. Reproduce the problem, capture for seconds, then filter.
- **Confusing capture and display filter syntax** (`port 53` vs `udp.port == 53`).
- **Expecting to see other devices' Wi-Fi traffic.** You normally see only your own.
- **Sharing a capture file** without checking what personal data it holds.

## Quick recap

- Wireshark shows every frame with its layers decoded: Ethernet, IP, TCP/UDP, application.
- Use display filters (`dns`, `tcp.port == 443`, `tcp.flags.syn == 1`) to find what matters.
- A handshake, a reset or repeated SYNs tell you exactly where a connection fails.
- Capture only what you are authorised to capture, and handle files as sensitive.

Next step if you enjoyed this course: CompTIA Network+ is a common vendor-neutral certification; see https://www.comptia.org/certifications/network for the current exam details (Checked on 2026-10-23).

## Try it

Open the **Do** tab and capture and read your own DNS and HTTPS traffic.


Capture your own traffic in Wireshark, filter it, and read the layers of a DNS query and a TCP handshake.

Packet capture basics

Learn Wireshark! Tutorial for BEGINNERS

Learn Wireshark in 10 minutes - Wireshark Tutorial for Beginners

Diagnose problems with ping, traceroute and netstat, map your home network, and read packets in Wireshark.