Published 9 minutes ago

Maker, meme-r, and unabashed geek, Joe has been writing about technology since starting his career in 2018 at KnowTechie. He’s covered everything from Apple to apps and crowdfunding and loves getting to the bottom of complicated topics. In that time, he’s also written for SlashGear and numerous corporate clients before finding his home at XDA in the spring of 2023.

He was the kid who took apart every toy to see how it worked, even if it didn’t exactly go back together afterward. That’s given him a solid background for explaining how complex systems work together, and he promises he’s gotten better at the putting things back together stage since then.

I’ve upgraded my home network in a fairly slapdash manner over the years, and as such, I wasn’t entirely sure whether any networking hiccups while watching Netflix were the ISP’s fault, the streaming service’s, or something inside my walls. I hadn’t been documenting my home lab shenanigans with NetBox or similar tools, and had started suspecting one or two of those VMs were causing trouble.

In short, it was time to do something about it, and map out my network so I could troubleshoot from a place of information. Automation tools will only get you so far, because many are IPv4-only, modern devices use MAC address randomization for privacy, and dual-stack networks (like mine) might show you multiple IPs for the same devices because IPv4 and IPv6 both assign addresses.

But between tools, my router dashboard, and some physical delving, I managed to figure out what’s what, and do some Wi-Fi scanning in the process. What I learned is that assumptions had been killing my network, and not necessarily the devices on it.

My home network was a mess

It was time to map it out properly

I know, with how much I talk about monitoring your home network, I haven’t been as fastidious with my own network. Things are constantly in flux: the home lab network changes weekly to test new features, apps, or devices, and my home network is only touched when something goes wrong.

I did have a few intermittent issues on my home network that I could never quite iron out, so it was well overdue for mapping. I wanted to know which devices are connected (including devices that connect to them, like a smart home hub), which rooms have Wi-Fi devices, which devices are roaming, and whether there’s anything I could do to optimize things.

Some tools were needed

My Eero mesh network is good at showing what’s on my home network, but it doesn’t tell me what’s happening on my managed switch, or which VLANs are in use there. I had to go into the switch’s management pages to get that info, and pull any device information so I could check it against the Eero list. Those matched, mostly, except for a few virtual machines that I’d removed from my home lab but were still showing in the recent devices list on Eero. Not sure how many days that stays in view, but I’d rather see them than lose visibility over what has been on the network.

The other thing is that I wanted to check physical connections while I was at it, so I picked up an inexpensive cable tester. Maybe one day I’ll afford a Fluke, but I still caught that one of the in-wall runs the builders added was loose in a keystone, which would have been an issue once I’d used it for adding another access point. I can also check PoE power connectivity, and I recommend that any tester you get should be able to do this as well.

Eero Pro 6E

$330 $550 Save $220

Coverage 6,000 square feet

Bands 2.4GHz, 5GHz, 6GHz

And don’t forget to match it to a physical cabling diagram

The virtual IP map generated by the software never quite tells the entire story. It’s also worth mapping a physical cabling diagram, either by floor or by room, to show where each network appliance and client lives, and where the cables between them run. That will come in handy if you need to replace any backhaul after testing, any patch cables, or any other hardware that might go faulty.

Wireless needs a different approach

Use heatmapping tools instead of anecdotal device data

Once the hardwired connections, appliances, and client devices were handled, I moved on to mapping my Wi-Fi. Unlike the others, it’s not about figuring out what’s on the network, but about identifying any signal-strength deficiencies in occupied parts of my house.

To do this, I used NetSpot: first installed on my phone for a quick overview to see which areas needed a more detailed scan, then another walkaround with the app running on a laptop. Now, a couple of provisos here: the Android app is more feature-comparable to the computer app, while the iOS app is lacking, as Apple won’t allow scanning of APs that you’re not connected to.

Once the heatmap was generated for every floor of my home, I checked it against the physical locations of any Wi-Fi connected devices and the usual places our phones and laptops are used, to make sure none of our normal operating areas had issues.

I also checked channel overlap by wandering around, checking congestion on the 2.4GHz, 5GHz, and 6GHz bands, and comparing it to the busyness report generated by my mesh nodes. We don’t own that many 2.4GHz devices anymore, but the few existing ones have been moved away from the most congested areas caused by the neighbors’ overlapping router signals.

Credit: Source: NetSpot

NetSpot

What I thought were dead zones were caused by something else

The heatmaps told me I didn’t have Wi-Fi broadcasting issues. Instead, it was issues with the individual client devices, sometimes from where they were used, but also because of driver or firmware problems.

For example, a Pixel 9 Pro kept disconnecting from Wi-Fi and using the 5G signal, and that was traced back to it not handing off properly from the first-floor mesh node to the upper-floor one. There’s not much you can do if that’s the issue; it takes the phone manufacturer to issue an update with better handoff performance. If my node let me adjust the broadcast power, I could have reduced it slightly, and that might fix the issue.

My home lab was (most of) the problem

Virtual adapters and bridging for VMs are a pain

I really love spinning up VMs and containers on Proxmox, but I’m not always careful to shut them down when not in use, and that makes my DHCP controller unhappy. But it’s not only DHCP conflicts that are the issue. Sometimes I change the MTU on individual VMs, like when I want to simulate packet issues or play with jumbo frames. Leaving that on causes problems on the network, as does OPNsense when using a VirtIO interface, which looks like interface hang-ups but is actually from using the wrong virtual driver.

And as more networking resources become software-defined or virtualized in other ways, you can’t assume that because you’ve checked every physical device, your network will be fine. Many issues come from those virtual devices, which aren’t always found by network mapping tools or are switched off during testing, leading to the assumption that they aren’t an issue.

Mapping my network showed me what to fix

Testing and mapping out my home network and home lab networks was time well spent. It gave me valuable insights, showing that the issues I thought I had were, in fact, caused by something else, and helped me fix a couple of things I didn’t know were issues at all. I highly recommend doing at least some of these mapping exercises at home, regardless of the size of your network, because you never know what you might find.