Note for those who are unaware: those who are unaware, I am self employed within IT services in and around London.
Last week I was contacted by a former client of mine who had lost the majority of his wifi coverage in his home, and wanted me to come around and fix it.
Freelancers and small businesses often can not afford the expensive tooling bigger companies can use, such as fluke testers and certifiers to more quickly test a network, and certify that the ethernet runs are up to spec.
This blogpost serves as a guide on how I get around such limitations on freelance jobs and small contracts I get.
When freelancing, your most common client will be either an individual or a small business, commonly referred to as SOHO (Small Office; Home Office). These companies tend to not have a dedicated IT team, or in the case of individuals, not the knowledge of how to fix problems themself, and therefore it is your job to come in on demand to provide the service as and when needed.
The downside of this, is almost all individuals I have worked for have no clue what a network diagram is, or how to properly map out their network, and a lot of small businesses will not either. This makes your life harder, instead of looking at a network diagram and being able to picture the network easily, you are going to have to do this manually, the hard way.
What I like to do is firstly walk around the property with the client and have them explain the network to their knowledge, and also get an idea for how the network is hooked up.
Then we can follow each step top to bottom.
The router usually resides where the cabling enters the property, in most cases for small networks it will simply be the ISP router.
Once you identified the router, you will want to connect to it either via WiFI or Ethernet (recommended) to ensure DHCP is working, and that you can indeed reach the internet.
In my case with the client, we had no issues with the router, and the client had been working off the WiFi provided by the router in the meantime.
Once you are satisfied that the internet connectivity, and the router are working as expected, we can move to switches. Switches allow us to connect more devices to the network, and also form sub-networks using VLAN tagging (802.1q) to isolate broadcasts to specific sections of the network, and if the router is VLAN-aware, it can treat packets differently despite them coming in on the same port.
Most home networks tend not to have a distribution switch, which is simply a fancy word for the main switch which all other devices and switches connect off from. However especially for small businesses, distribution switches are common to increase the performance of the network.
Do note, home routers do tend to have a "switch" built into them, usually having around 4 ports to connect devices.
In my case, my client didn't have a distribution switch, all devices were directly connected to the router, or connected to a switch downstairs. A bit of a weird setup, but that wasn't the problem.
After identifying whether there is a distribution switch or not, walk around the network and find all the switches, draw a rough tree diagram, with the router at the top and all the switches connected it it branching off from it. Then check if these switches have switches connected to them, until all the switches are mapped out in a nice tree.
WiFi APs have to be treated a little special, because they do not always work as simple access points, some of them can have their own networks, especially within larger businesses.
What we want to do is identify where these are connected, and ensure that if they do have their own networks (802.1q usually) that the switch they are connected to is indeed connected to the router. In most cases WiFi APs will handle the network themselves without needing to worry.
In my case, the WiFi APs simply were bridged, so I didn't need to worry about any issues with subnetworks.
Finally we identify the end devices. Devices connected over ethernet branch off from network switches, while devices connected over WiFi branch off from the WiFi APs we mapped in the previous step.
My client reported to me issues only with the WiFi, however this doesn't mean there is not an issue with a switch or another device on the network.
I knew the network already, so I had a mental picture of the network, but if I had drawn it I would have looked at the diagram and seen the switch downstairs was the point at which all the problematic WiFi APs were connected to.
So I went downstairs, and I looked at the switch. Even dumb switches can give us some important information about the quality of the runs. From looking at the switch I can see that link negotiation had negotiated 1000baseT with the router, this run was working as expected.
The client didn't really care about network speeds.
However, for those who do, a quick way to get a rough idea if the cabling is
up to spec is to plug two devices into either side of the ethernet run and
then used iperf3 (source) between the
two devices. You can typically do this with a laptop and a SBC running
iperf3 as a server. This does not certify the speeds, but it does give a
rough idea if the cabling is reaching 1000baseT or not. Just because link
negotiation negotiates 1000baseT does not mean the carrier in reality can do
it.
This does not replace a fluke tester, or certification tool, and if you are growing a business this would be one of the first investments your company should invest in, as not only is it more accurate, and provides your clients with certification which they can trust, but it also makes it quicker to diagnose network problems and fix them.
When checking the other devices attached to the switch, I saw that one of the WiFi APs had no link activity, the cabling failed link negotiation, so I did a continuity test (which is all a cheap tester can do) which it passed. So the cabling was properly terminated but not up to spec, looking at the plugs the cable was mangled at each end, which I blame for this. I did not have cat 6 plugs on me unfortunately, and the client expressed that they would like to reterminate it themself, so I write it down to give to the client as a reminder after I had finished.
After checking all the other runs, I notice that the wiring was all working between the switch and the other APs, but two APs in particular were playing up, one connected to the other, and then that one connected to the switch.
Firstly, let me point out you should never do this, you want to limit the number of devices in a chain to limit the points of failure on the network, WiFi APs and end user devices should always be connected to a switch, which should as best as possible be connected to the distribution switch, nott more intermediary switches. This provides better network reliability.
Although a poor network design, this was not the issue, the issue is a more sinnister one which is all too common on home networks, and is a pain in the ar*e to fix.
Upon connecting to the WiFi APs I instinctively check the DHCP assignments being returned, and what do I notice, a different subnet. Uh oh, this is a DHCP conflict. Finding such conflicts is a pain, any DHCP daemon can respond to DHCP broadcasts with their own assignments, and tracking these down is a pain.
The way I like to deal with it is disconnect the affected region of the network, and check any DHCP-capable device network configuration. Sure enough I found both APs for some reason were broadcasting their own DHCP despite not routing traffic. These being old WiFi routers, I decided it was not worth the effort trying to diagnose where in the config it is broken, and reset them, and set them up properly as WiFi APs.
In my case, as I explained above, there was 2 faults on the network. One faulty cable connecting one of the WiFi APs, and then two APs broadcasting their own DHCP, causing a dreaded DHCP conflict.
A note for faulty cables, is these can be annoying as well, sometimes a simple retermination will do, but in other cases, the cable has sustained damage along it, and without a proper fluke tester it can be difficult to find where this fault is within the cable, thus requiring a complete new ethernet run.
In total it took me 1.5 hours, I could have likely done it in an hour but I was a bit obsessive with walking around and testing all the WiFi APs were working correctly, and also the setup of old WiFi routers as APs, especially netgear ones, are a pain.
For those installing wifi into your home or office, I urge you to buy proper WiFi APs, not some old WiFi router, and putting it into AP mode. Proper WiFi APs from the like of ubiquity are higher quality, provide more reliable connectivity (especially when you live in a city with lots of congestion) and provide far more features to securing and growing your network if/when its required.
Computer networking does have a steepish learning curve, and also upfront costs, however with a strong understanding of the fundamentals, and some thinking outside the box, you should be able to wiggle your way in, at least within the freelance space.
Having the proper tools, although very expensive, is valuable, especially if you are working full time on networking alone. In my case I do IT services as a whole, and do not get enough clients to justify investing into fluke testers.
I hope this breakdown of how I diagnose a faulty network may come in use to someone else.
Thank you for reading!