Network addresses shown in this article are documentation addresses (RFC 5737) and do not represent the actual LAN configuration.
I recently ran into a networking problem at home that turned into a useful exercise in troubleshooting across several layers of a network.
My Internet plan is advertised as 1 Gbps, but my Windows desktop was suddenly getting approximately 0.48 Mbps download and roughly the same upload speed. My initial thought was that it was a temporary ISP problem. A connection that should have been capable of hundreds of megabits per second was operating at less than one.
It later turned out that the ISP was fine. The actual problem was a wireless extender sitting between my upstairs network and the rest of the LAN.
The Network
My home network contains several Raspberry Pis, laptops, and other devices, including a Pi-based NAS and a Raspberry Pi hosting this website.
The relevant portion of the network originally looked something like this:
UPSTAIRS
Windows PC ──┐
├── Switch ── Wireless Extender
Website Pi ──┘ │
│
Connection downstairs
│
Powerline adapter
│
DOWNSTAIRS │
|
Rogers Router ── Switch ────────┘
│
├── Pi NAS
└── LaptopThe important detail was that traffic between the Windows computer and the Website Pi stayed entirely on the upstairs switch. Traffic destined for the router, NAS, or Internet had to cross the extender. That distinction eventually became the key to diagnosing the problem.
Step 1: Determine Whether the ISP Was Actually Slow
My immediate thought upon recognizing the slow connection was that it was a temporary ISP problem. To truly find out if that was the case, I tested the connection from other devices.
A cellphone placed near the router reached approximately 300 Mbps, and a laptop downstairs achieved a similarly high result. Meanwhile, the Windows desktop remained at approximately 0.48 Mbps.
So the ISP theory was unlikely, meaning the fault was probably somewhere within the local network.
Step 2: Test the Local Network
I started with ping tests to determine where packet loss appeared. From the Windows computer, I first pinged the "Website Pi":
ping 192.0.2.82This showed 0% packet loss.
I then pinged the gateway:
ping 192.0.2.1This test showed approximately 16% packet loss.
So, the Windows machine could communicate perfectly with the "Website Pi" beside it on the same switch, but communication with the router was unreliable.
I reversed the tests from the Pi as well. The Pi could reach both the Windows computer and the gateway without packet loss.
At this point I suspected something peculiar about the Windows networking stack.
Step 3: Check the Windows Network Configuration
I checked the Windows machine's IP configuration:
ipconfig /allThe relevant IPv4 configuration looked normal:
IPv4 Address: 192.0.2.94
Subnet Mask: 255.255.255.0
Default Gateway: 192.0.2.1
DHCP: EnabledThe machine had a valid address of the expected LAN subnet, the expected /24 subnet mask, and a single default gateway pointing to the router. DHCP was enabled.
I then inspected the routing table:
route print -4
There was one expected default route through the router, 192.0.2.1, with
no competing default gateways. I also checked the ARP table:
arp -aThe gateway MAC address seen by Windows matched the MAC address seen by the Raspberry Pi. There was no obvious rogue gateway, duplicate router, or routing-table problem.
Step 4: Rule Out TCP and MTU Problems
Since the Windows computer appeared, at this point, to be the only affected machine, I continued by checking its TCP configuration:
netsh interface tcp show globalImportant settings such as Receive-Side Scaling and TCP receive-window auto-tuning were enabled and appeared normal.
I then checked the MTU:
netsh interface ipv4 show subinterfacesThe active Ethernet adapter had the expected MTU of 1500. To verify that a full-size packet could traverse the LAN without fragmentation, I ran:
ping 192.0.2.1 -f -l 1472The packets succeeded, which made an MTU problem unlikely.
Step 5: Wi-Fi Produced the Same Problem
I disconnected Ethernet and ran another speed test over Wi-Fi.
The result was still only about 0.37 Mbps.
Ethernet: ~0.48 Mbps
Wi-Fi: ~0.37 MbpsAt first, this seemed like strong evidence that Windows PC was the common denominator. Two different network interfaces were exhibiting essentially the same problem. In retrospect, however, there was another common denominator: both connections were still relying on the same upstream network equipment.
Step 6: Look at Latency and Network Topology
A large ping to the Website Pi consistently returned in less than one millisecond:
Reply from 192.0.2.82: time<1ms
Reply from 192.0.2.82: time<1ms
Reply from 192.0.2.82: time<1ms
Reply from 192.0.2.82: time<1msThe same kind of test against the gateway returned values such as:
125 ms
25 ms
8 ms
59 msQuite high latencies for a router located inside the same house.
File transfers from the NAS were also extremely slow. This was another important clue because the NAS was located on the downstairs portion of the network.
Drawing the topology made the pattern clearer.
Windows PC ── Switch ── Website Pi
│
│
upstream link
│
▼
Router
│
┌───────┴───────┐
NAS InternetCommunication between the Windows PC and Website Pi never had to leave the upstairs switch. Communication with the gateway, NAS, and Internet all had to cross the upstream connection.
The Culprit: A Wireless Extender
I eventually discovered that the device connecting the upstairs network was not a powerline adapter/wireless extender as I had been assuming. It was just a wireless extender. Therefore, the upstairs segment was relying on a wireless backhaul connection to reach the rest of the LAN.
That connection had degraded badly enough that communication among local devices on the upstairs switch still appeared perfectly healthy, while anything that needed to cross the extender became almost unusable.
Windows PC
│
Switch
│
Wireless Extender
│
X <-- bottleneck
│
Rest of LAN
│
Router
│
InternetThis also explained the seemingly contradictory Wi-Fi result. Switching the Windows computer from Ethernet to Wi-Fi did not bypass the bad upstream connection, so Internet performance remained terrible.
The Fix: Replacing the Extender With Powerline
I happened to have another compatible powerline adapter available in another upstairs room. I removed the wireless extender and replaced it with the additional powerline adapter, and the improvement was immediate.
Before:
~0.48 Mbps download
~0.48 Mbps upload
After:
~250 Mbps download
~200 Mbps uploadThat is still below the theoretical maximum of a 1 Gbps Internet service, but it is a much more reasonable real-world result for a connection traversing residential powerline networking.
Powerline networking is generally a bit of a bottleneck itself because it depends heavily on the electrical wiring in the building, circuit layout, interference, and distance, so the advertised powerline link rate should not be confused with actual application throughput.
Ideally, I would utilize ethernet networking, but as I'm renting and not too keen on walking over cables all the time, powerline networking certainly suffices.
Repairing and Reusing a Cat6 Cable
Since I replaced the wireless extender with a powerline adapter from another upstairs room, I needed to figure out how I could now have that adapter provide reliable access to the entire floor.
Since the adapter was in the hallway at roughly the midpoint between the two rooms, the obvious answer was a ~25ft Cat cable. Problem was, I already used that cable to connect the other room.
Fortunately, I remembered a 50ft Cat6 cable I had used in a previous setup. Something I only stopped using because my cat had treated part of it like cat food. Since then, I had equipped myself with a variety of cable-saving tools. So, I cut the 50ft cable before the damaged section, stripped the remaining good cable, arranged the conductors, terminated it with a new RJ45 connector, crimped it in place, tested it, then used it to provide the wired connection to the other room.
It was a small part of the overall repair, but it turned a broken cable into useful network infrastructure rather than waste.
What I Learned
Perhaps the most prudent reminder was the value of testing before changing configuration. During the troubleshooting process, several explanations were considered:
- An ISP problem
- A Windows TCP configuration problem
- An MTU problem
- A routing-table problem
- An ARP or gateway problem
- A faulty Ethernet adapter or cable
- A Windows-wide networking problem
- A problem somewhere in the network topology
Changing several settings at once might have temporarily altered the symptoms without identifying the actual fault. Comparing different paths and narrowing the focus through the network was much more useful.
A Useful Troubleshooting Method
The experience reinforced a general troubleshooting process that can be applied to many network problems:
- Test another device.
- Test communication within the local LAN.
- Test the default gateway.
- Test the Internet connection.
- Compare which paths work and which paths fail.
- Draw the network topology if necessary.
- Identify what the failing paths have in common.
- Bypass or replace the suspected component.
- Retest and compare the results.
Instead of asking simply "What could be broken?", a more useful question became "Where does the network stop behaving normally?"
In this case, the observations could eventually be summarized as:
Windows -> Website Pi GOOD
Windows -> Gateway BAD
Windows -> NAS BAD
Windows -> Internet BAD
Other PC -> Internet GOOD
Once viewed this way, the fault domain became much smaller.
Final Result
Replacing the failing wireless extender with a powerline connection raised the Windows computer's Internet throughput from approximately 0.48 Mbps to approximately 250 Mbps download and 200 Mbps upload.
There is still room for improvement. A direct Ethernet run would almost certainly outperform powerline, but the original network fault has been isolated and resolved.
And fittingly, one of the Raspberry Pis that helped me diagnose the problem is also the machine hosting the website you are reading this on.
