Troubleshooting wired and wireless clients on Windows, macOS and Linux

Why this matters

Most network tickets start at a user's device, not at a router. "I can't get on the Wi-Fi", "the intranet won't load", "it works for everyone except me". A help-desk analyst moving into networking, or a network technician on a site visit, has to work out from the client itself whether the fault is the laptop, the wireless security settings, the address, the path or the service. That means knowing the commands on all three desktop operating systems, because a single office usually has Windows, macOS and Linux machines side by side.

Without a method, people jump to the end. They reboot the access point, or blame DNS, or escalate to the server team, when the laptop simply has a mask typed wrong or a driver that cannot speak WPA3. A few minutes with ipconfig /all, ip addr show or networksetup -getinfo usually answers the question, and it gives the next person in the chain evidence instead of a guess.

The lesson

Checking client addressing, reachability and wireless security on Windows, macOS and Linux

Troubleshoot a client from the bottom up, and stop at the first step that fails:

1. Link. Is the client connected: a cable with link lights, or an association to the right SSID with usable signal?
2. IP configuration. Does it have a sensible address, mask, default gateway and DNS servers?
3. Local reachability. Can it reach its default gateway?
4. Remote reachability. Can it reach a remote host by IP address? Where does the path stop?
5. Name resolution. Can it reach the same host by name?
6. The service. Does the application port answer?

Each step rules out a layer. If a ping to a server's IP address works but a ping by name fails, addressing, the gateway and the path are all fine, so look at DNS. If the gateway does not answer, there is no point testing DNS yet.

The commands on each operating system

A few distinctions are worth fixing in memory:

• ipconfig prints only addresses, masks and gateways. ipconfig /all adds the physical (MAC) address, the DHCP server, lease times and DNS servers. ipconfig /renew requests a new lease but then prints only the basics.
• ip addr show (short for ip address show) lists each interface's IPv4 and IPv6 addresses with prefix lengths. ip -s link show lists the same interfaces with MAC addresses and traffic counters but no IP addresses. ip neigh show is the neighbour (ARP) table. ip route show is the routing table.
• tracert is the Windows name. traceroute is the macOS and Linux name. Both send probes with increasing TTL values and list each router that answers, so the last hop that responds shows where the path stops. ip route get only shows which local route the Linux host would choose.
• networksetup -getinfo Wi-Fi prints the configuration method, IP address, subnet mask, router and MAC address of the macOS Wi-Fi service. networksetup -getdnsservers Wi-Fi shows only the DNS servers.

Reading the IP configuration

Here is the relevant part of ipconfig /all from a Windows laptop that can print to local printers but reaches nothing beyond its own subnet:

C:\>ipconfig /all

Wireless LAN adapter Wi-Fi:

   Connection-specific DNS Suffix  . : corp.example
   Physical Address. . . . . . . . . : 3C-A9-F4-12-5E-7B
   DHCP Enabled. . . . . . . . . . . : No
   IPv4 Address. . . . . . . . . . . : 10.1.40.77(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.224
   Default Gateway . . . . . . . . . : 10.1.40.97
   DNS Servers . . . . . . . . . . . : 10.1.1.53

Work it through, using the block-size method from lesson 3:

1. 255.255.255.224 is a /27. Block size 256 - 224 = 32.
2. Blocks in the last octet: 0, 32, 64, 96. The address 77 sits in the block 64 to 95.
3. The client's subnet is 10.1.40.64/27, broadcast 10.1.40.95.
4. The gateway 10.1.40.97 is in the next block, 96 to 127. The client cannot reach it directly, so local traffic works and everything off-subnet fails.

The gateway is not the broadcast address (that is .95); it is simply in the wrong subnet. Fix whichever value is wrong, usually by moving the client back to DHCP.

On Linux, the same check looks like this:

$ ip addr show wlan0
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 9c:b6:d0:4e:21:7a brd ff:ff:ff:ff:ff:ff
    inet 192.168.8.130/26 brd 192.168.8.191 scope global dynamic wlan0
       valid_lft 85912sec preferred_lft 85912sec
    inet6 fe80::9eb6:d0ff:fe4e:217a/64 scope link
       valid_lft forever preferred_lft forever
$ ip route show
default via 192.168.8.129 dev wlan0 proto dhcp metric 600
192.168.8.128/26 dev wlan0 proto kernel scope link src 192.168.8.130 metric 600

A /26 has blocks of 64, so 192.168.8.130 is in 192.168.8.128/26, broadcast 192.168.8.191, which matches the brd field. If the site gives each gateway the first usable address, the gateway is 192.168.8.129, and the default route agrees. 192.168.8.128 is the network address, so it can never be a gateway. The word dynamic means the address came from DHCP.

When you set an address by hand, convert the prefix to a mask correctly. A Mac on 172.20.4.0/22 that needs the manual address 172.20.5.20 must be given 255.255.252.0, which covers 172.20.4.0 to 172.20.7.255. Typing 255.255.255.0 would make it treat hosts in 172.20.4.x, 172.20.6.x and 172.20.7.x as remote.

$ networksetup -getinfo Wi-Fi
Manual Configuration
IP address: 172.20.5.20
Subnet mask: 255.255.252.0
Router: 172.20.4.1
Wi-Fi ID: a4:83:e7:19:0c:52

A 169.254 address means DHCP failed. If Windows shows 169.254.23.9 with mask 255.255.0.0, it asked for a lease and no server answered, so it gave itself a link-local (APIPA) address. macOS and Linux behave the same way, or leave the interface with no IPv4 address at all. Check the path to the DHCP server next: the VLAN, the switch port, and any DHCP relay (lesson 7).

To confirm the gateway on Windows, ipconfig /all lists it per adapter, and route print -4 shows it as the gateway of the 0.0.0.0 default route. netstat -an lists connections and listening ports, not routes.

Reachability and name resolution

Once the configuration is right, test in order: the gateway, a remote IP address, then a name.

$ ping -c 3 10.50.1.20
PING 10.50.1.20 (10.50.1.20) 56(84) bytes of data.
64 bytes from 10.50.1.20: icmp_seq=1 ttl=62 time=2.41 ms
64 bytes from 10.50.1.20: icmp_seq=2 ttl=62 time=2.18 ms
64 bytes from 10.50.1.20: icmp_seq=3 ttl=62 time=2.25 ms
$ ping -c 3 fileserver.corp.example
ping: fileserver.corp.example: Name or service not known

The path to 10.50.1.20 works, so the gateway, routing and the server are fine. The name does not resolve, so the problem is name resolution. Check which DNS servers the client uses (resolvectl status on Linux, ipconfig /all on Windows) and query them directly with dig or nslookup. Lesson 20 covers DNS records themselves.

A classic Windows case: after an intranet server's A record changes, one client still connects to the old address. Windows caches DNS answers until their TTL expires. ipconfig /flushdns empties the cache so the next lookup fetches the new record. ipconfig /displaydns only lists what is cached, and ipconfig /registerdns re-registers the client's own name.

If a ping by IP fails, trace the path to see where it stops. On an Ubuntu laptop:

$ traceroute 10.9.9.9
traceroute to 10.9.9.9 (10.9.9.9), 30 hops max, 60 byte packets
 1  192.168.8.129 (192.168.8.129)  1.204 ms  1.188 ms  1.170 ms
 2  10.255.0.1 (10.255.0.1)  3.911 ms  3.874 ms  3.860 ms
 3  * * *
 4  * * *

The second router answers and nothing beyond it does, so start at the router after 10.255.0.1. Some firewalls drop the probes even when traffic flows, so treat stars as a clue, not proof.

If both name and address work but the application still fails, test the service port. In PowerShell:

PS C:\> Test-NetConnection portal.corp.example -Port 443

ComputerName     : portal.corp.example
RemoteAddress    : 10.20.30.40
RemotePort       : 443
InterfaceAlias   : Wi-Fi
SourceAddress    : 10.1.40.77
TcpTestSucceeded : False

The name resolved and the client chose a source address, so DNS and local addressing are fine. The TCP connection to 443 failed, which points to the web service, a firewall, or the path to the server. Get-NetIPConfiguration -Detailed would only show local settings; it sends nothing to the server.

Wireless signal and security parameters

On a wireless client, check the link and its security settings before the IP layer. Windows shows the live connection with netsh wlan show interfaces:

C:\>netsh wlan show interfaces

    Name                   : Wi-Fi
    State                  : connected
    SSID                   : Corp-Staff
    BSSID                  : 70:1f:53:a2:44:10
    Network type           : Infrastructure
    Radio type             : 802.11ax
    Authentication         : WPA3-Personal
    Cipher                 : CCMP
    Connection mode        : Profile
    Band                   : 5 GHz
    Channel                : 44
    Receive rate (Mbps)    : 1201
    Transmit rate (Mbps)   : 1201
    Signal                 : 88%
    Profile                : Corp-Staff

That gives the SSID, the BSSID of the AP it joined, the authentication and cipher, the channel and the signal. netsh wlan show drivers is different: it lists what the adapter and driver can do, including the authentication and cipher pairs they support. netsh wlan show profiles lists saved networks.

On Linux, iw dev wlan0 link describes the current connection, and nmcli device wifi list scans and lists every network in range with its channel, signal and security:

$ iw dev wlan0 link
Connected to 00:11:22:33:44:55 (on wlan0)
        SSID: Lab-Net
        freq: 2437
        signal: -84 dBm
        tx bitrate: 6.5 MBit/s

$ nmcli device wifi list
IN-USE  BSSID              SSID        MODE   CHAN  RATE        SIGNAL  SECURITY
*       00:11:22:33:44:55  Lab-Net     Infra  6     65 Mbit/s   22      WPA2
        00:11:22:33:44:66  Lab-Net     Infra  44    540 Mbit/s  58      WPA2
        70:1f:53:a2:44:10  Corp-Staff  Infra  44    1201 Mbit/s 61      WPA3

Read the iw output carefully. The client is associated, so the passphrase was accepted. 2437 MHz is 2.4 GHz channel 6, not a DFS channel. But -84 dBm is very weak (lesson 5), and the radio has fallen back to a slow, robust 6.5 Mbit/s. The client is at the edge of the cell. The nmcli list shows a stronger 5 GHz radio for the same SSID nearby, so the fixes are better AP placement, band steering, or moving closer.

On a Mac, the quickest view needs no Terminal: hold Option and click the Wi-Fi icon in the menu bar. The extended menu shows the BSSID, channel, security, RSSI, noise and transmit rate. The Wi-Fi details in System Settings show addressing and DNS, but not RSSI or noise.

Security mismatches stop a client joining at all. Common cases:

• WPA3 only, but the client cannot do SAE. Staff laptops stop joining after an SSID moves to WPA3-Personal only. Their netsh wlan show drivers output lists only WPA2-Personal CCMP, WPA2-Enterprise CCMP and Open None. They cannot perform SAE. Enable WPA3-Personal transition mode, which lets WPA2-Personal and WPA3-Personal clients share one SSID and passphrase while newer clients keep WPA3. Adding TKIP would not help, since the laptops already support CCMP.
• A wrong or changed passphrase. The client fails at the handshake and never gets as far as DHCP. A saved profile with an old passphrase does the same; forget the network and rejoin.
• 802.1X certificate trust. With PEAP or EAP-TLS, the client validates the RADIUS server's certificate before sending credentials. If the server's certificate is replaced with one from a new private certificate authority (CA) that the laptops do not trust, they abort the exchange and cannot join the WPA2-Enterprise SSID. The fix is to deploy the new CA certificate to the clients. Clients do not need static addresses for 802.1X, because authentication completes at Layer 2 before DHCP runs.
• 6 GHz requirements. A client that sees a 6 GHz SSID but cannot join may lack WPA3 support, which that band requires.

What the exam is really asking

• Order of tests. Link, IP configuration, gateway, remote IP, name, service. Success by IP and failure by name means DNS; a gateway fault would break the ping by IP too.
• 169.254.x.x means no DHCP reply, not a DNS or duplex fault.
• Gateway in the wrong subnet. Work out the block. Local hosts work; nothing off-subnet does.
• Which command shows what. ipconfig /all versus ipconfig. ip addr show versus ip -s link show. netsh wlan show interfaces (the live link) versus netsh wlan show drivers (what the adapter supports). iw dev wlan0 link (current link) versus nmcli device wifi list (all networks in range). networksetup -getinfo versus -getdnsservers.
• tracert is Windows; traceroute is macOS and Linux.
• ipconfig /flushdns clears a stale cached record; /displaydns only shows it.
• Test-NetConnection -Port tests a TCP service.
• Weak signal shows as a large negative dBm and a low bit rate while still associated. A wrong passphrase fails the four-way handshake, so the client never completes the connection.
• WPA3-only SSIDs and WPA2-only drivers need transition mode. New RADIUS certificates need the issuing CA trusted on the clients.