The house next door is about to be renovated, including removing a chimney stack from the room next door to my office. It'll be a loud, and likely very distracting process. I've got noise cancelling headphones, but, the dogs don't. So, I decided that it would be wise to make sure that we've got an alternative workspace available. At the bottom of our garden is a summer house which currently functions as a (somewhat neglected) gym. There's currently a TP-Link Deco unit in there, meshed onto the rest of our wifi network. The connection is unstable but is, usually, enough for us to be able to play workout videos (albeit with occasional frustration). This post talks about measuring and improving the wireless connectivity of our summer house. The Plan No Trench First, to address the obvious: outdoor wifi is always going to be a little problematic. A far more reliable connection could be achieved by establishing a physical connection (by running copper or fiber down the garden). However, that's not currently an option because there's an air gap at the back of the house that I'd need to span. Although the ground is concrete, there's a nice convenient fence to run conduit along. The problem is, that fence is going to be ripped out and replaced as part of the renovation. Although I'll probably run a physical connection at some point, it doesn't make sense to do so yet. Adding An Outdoor Access Point The Deco in the summerhouse does establish a connection, just not a very reliable one. It connects to the Deco2 in my office, meaning that it has to contend with: A cavity wall (and the insulation in the cavity) Background noise generated by kit (and now AC) in my office The branches of a tree between the house and the summer house Once overcoming those obstacles, it then has to compete with every other client of the office Deco. During the renovations, it'll also have to cope with whatever RF noise the builder's power tools leak. There isn't much that I can do about the tree1, but the other issues could all be addressed by putting a Deco outside. The advantage that an outside Deco has over a point-to-point link is that, even if I later run cable down the garden, the Deco will still provide improved wifi connectivity to the garden and other outbuildings. So, I ordered a TP-Link Deco BE25. Initial State To be able to assess what kind of impact the outside Deco had, I needed to collect some metrics before installing it. I started with a simple check - speedtest.net on my phone: Run Speed Notes 1 47 Mbps 2 - Failed to connect 3 1.67 Mbps 4 67 Mbps Although not particularly scientific, this neatly displayed the reliability issues that I knew the summerhouse had: if you use the connection it performs for a bit, then wobbles before recovering. It's annoying when that happens mid rowing session, but would really help make a working day unbearable. What this phone based speedtest doesn't show, though, is: How prolonged the failures actually are How much connectivity is actually fluctuating mid-test (and how much of that is contention of our WAN) For some reason, speedtest.net also didn't run an upload test. Using iperf3 Most of the above can be eliminated by testing with iperf3 instead: sudo apt install iperf3 I stood the server up on one of the boxes in my rack: iperf3 -s Normally, when running iperf at the client end, you'd have it write output to stdout. However, I stumbled upon this utility to create graphs from the output, so told iperf3 to write results out to JSON: iperf3 \ -c 192.168.13.22 \ -J \ -P 4 \ -t 300 \ --logfile before-up.json Just to break those arguments down: -c [ip]: the server to connect to -J: Write out JSON -P 4: Run 4 parallel client streams to ensure we're measuring link capacity rather than just latency -t 300: Run a 5 minute test --logfile: write out to the specified file I then ran almost the same command again, but with -R (and a different output filename): iperf3 \ -R \ -c 192.168.13.22 \ -J \ -P 4 \ -t 300 \ --logfile before-down.json The inclusion of -R tells iperf3 to run in reverse: testing download rather than upload. To check that the server end was happy, I ran a quick control test while my laptop was still in the office: This confirmed that the server end was happy to do gigabit level speeds. Speeds and Reliability I used an ethernet cable to plug my laptop into the summerhouse Deco's gigabit port and triggered the tests. Upload speeds fluctuated quite a bit and achieved an average of 92.26 Mbps: 92 Mbps isn't exactly a stellar speed, but it's more than enough for video calls and git pushes. However, under the hood, things weren't so happy: $ cat before-up.json | jq '.end.sum_sent.retransmits' 1762 There being 1767 retransmits indicates that there was some packet loss: although the average speeds look OK, latency sensitive activities (like video calls) would likely still have suffered. Download were even less reliable, with a complete speed drop-off mid-test: The average speed across this test was 87.03 Mbps. There were also nearly 4 times as many retransmissions: $ cat before-down.json | jq '.end.sum_sent.retransmits' 6607 Curious to see if there was any repeater penalty to connecting via wifi, I disconnected the ethernet cable, re-enabled the laptop's wifi and re-ran the download test: Although peak speeds were similar, reliability was far worse: $ cat before-down-wifi.json | jq '.end.sum_sent.retransmits' 27939 Note: The wifi test also wasn't necessarily definitive - the peak throughput was still a fraction of the Deco's capability, so there wasn't yet any contention to introduce a real penalty. The Install The plan was simple: Drill a hole through my office wall3 Push some armoured cable through Install the Deco on the pergola (roughly) opposite the summer house Fit an ethernet faceplate inside the office Terminate the Deco end with an RJ45 Power via POE One important thing to note about the Deco is that it requires 802.3at POE - passive and 802.3af won't work with it (.at can deliver 30W compared to .af's 15W). My ageing switch only does 802.3af, so I bought a POE+ injector4. Drilling After figuring out roughly where I wanted the cable to come through, I marked the wall up with the holes of a standard backbox. I used a long 12mm SDS drill bit to put a hole through wall, before putting two smaller holes in for wall-plugs and poking a wire through the main hole to help me find the other end: To avoid blowing the external brick (like last time), I switched the SDS's hammer mode off as soon as I felt the drill bit enter the cavity. Then, I went outside to check where I'd come out: Cutting it a little close, but almost exactly where I wanted it. I pushed my drill bit back through and then duct taped some ethernet cable on the end: After pulling the cable through, I passed it through the back of the backbox, stripped the end and then wired into the ethernet faceplate (I did tidy the messy tails after this photo): As I only had dual port faceplates on the shelf, I had another socket spare, so drilled a second hole to run a cable round to the living room6. Then, I went outside and started the process of running the cable along to where I wanted the Deco to be. The Deco comes with a small plastic bracket, held in place by two screws. I put this in place, terminated the cable with an RJ45 and then popped it into my ethernet tester. Each pin lit up one by one, so I was ready to roll. I clicked the RJ45 into the Deco and slid the access point into it's mount: Note: I guess stripping and repainting the pergola is next on the to-do list. Back in the house, I screwed the ethernet ports into the backbox and then clipped the faceplate on: I plugged an ethernet cable into the port, connected the other end to the POE injector and then ran a cable back to my switch. The Deco powered up and I was able to add it to the network via the Deco app. Actually Using It At this point, I ran into a fairly major headache. Logically a mesh network node should associate with whatever node it's best able to communicate with. However, Decos seem to have a bias towards the main unit (in this case, my office). The Summerhouse stubbornly stayed connected to the office Deco: I tried Rebooting the Summerhouse Deco (it reconnected to Office when it came back) Rebooting the Office Deco (Summerhouse reconnected to it when it came back) Powering off the office node, then power cycling Summerhouse (Summerhouse flashed red and refused to connect to anything) You could be forgiven for thinking that this doesn't sound like a mesh at all. A post on TP-Link's forum suggests that Decos will mesh to others if they have a better connection back to the main unit. I don't know, but I'm guessing that the logic behind that fails to consider ethernet backhaul. Newer TP-Link firmwares have a feature called "Specified Connection": which allows you to set which Deco a device or access point uses to. The option wasn't appearing in my app, so I checked firmware versions The Summerhouse deco was rocking firmware from June 20235 - 6 months before TP-Link released Specified Connection. Happily, there was a firmware update available, so I hit the button to install it. That, alone, was enough - the newer firmware instantly globbed onto the outdoor deco being a better choice: New Speeds and Reliability I ran the same tests again: ben@optimus:~/Downloads$ cat after-up.json | jq '.end.sum_sent.retransmits' 5 Uploads were no faster, but definitely less prone to loss. I triggered the download test: ben@optimus:~/Downloads$ cat after-down.json | jq '.end.sum_sent.retransmits' 13772 All that effort... the performance was basically the same. Hoping that I hadn't just pissed away a Saturday afternoon, I double checked a few things: The NIC on my test laptop was definitely negotiating 1Gbps (apparently the M4's sometimes drop to fast ethernet) The Summerhouse Deco was still connected to the outdoor Deco The Outdoor Deco had negotiated 1Gbps with the switch With those ruled out, the most likely explanation was that the summerhouse Deco was falling back to 2.4 GHz backhaul, perhaps because of the whopping great tree in the way. Peering out of the summerhouse window, I realised that I couldn't actually see the outside Deco past the tree. Objections from indoors be damned, I grabbed my chainsaw and gave the tree a trim: removing lower branches until the Deco had comfortable line of sight to the outdoor Deco (and then, a little more, just to balance things out). Post-Tree Trim This seemed to have worked, the app showed that the summerhouse was now exclusively using 5 GHz for backhaul: I gave the tests another run but, to help assess stability, gave these 0 minutes each: Average speed: 215.83 Mbps $ cat after-up-stablemode.json | jq '.end.sum_sent.retransmits' 2312 Average speed: 237.96 Mbps $ cat after-down-stablemode.json | jq '.end.sum_sent.retransmits' 6674 Speeds had greatly improved. There was still some level of loss, but no dramatic drops in connectivity. They key component here was that the Deco was now reliably using 5 GHz for it's backhaul. If/when it drops back to 2.4 GHz, I'll see ~90Mbps again (although, hopefully still much more stable than it was before). Work Laptop Isolation There was one more thing that I needed to address: client isolation. In my office, my work laptop is connected to a dedicated (and isolated) network segment - it has no access to the LAN, and the LAN no access to it. That level of isolation is probably overkill, but work run various EDR solutions on our laptops and I don't really want a rogue EDR sending details of the rest of my network to god-knows-where. So, I wanted my laptop to remain isolated even when working in the summer house. If I had a wired (or a point-to-point) connection, I could achieve this with VLANs. Unfortunately, though, the Decos strip tagging information, so VLANs don't work across the wireless hop. Given that working in the summerhouse (at least via the wireless link) should be a temporary thing, I decided to implement isolation using firewall rules on my travel router - a little GL.inet thing: The GL.inet admin panel doesn't let you manually create firewall rules. However, under System is Advanced Settings which exposes the ability to enable OpenWrt's LuCI. From there: Network -> Firewall -> Traffic Rules I created a rule to block any traffic from the LAN side of the router to my LAN's subnet: Everything on the LAN side of the travel router is now, effectively, isolated from my network, while things like my phone (which will associate with the Deco) remain unimpeded. There was one final change required though: my travel router advertises a 5 GHz network of it's own. That being active was enough to knock the Deco back to 2.4 GHz and ~90Mbps speeds. Conclusion I've not achieved the speed that I'm used to when working in my office, but, I was never going to: a wired connection will always outperform down-the-garden wifi. The setup is also a temporary solution: once next door have replaced the fence, I'll run a physical link down to the garage and, from there, out to the summer house. However, the Outside Deco will stay, providing better coverage for our phones when we're out in the garden, While I'm out in the summerhouse, though, my travel router will also help to ensure that my work laptop remains isolated from the rest of the LAN. Actually that's not true. There isn't much that I'm allowed to do about the tree ↩ If you're wondering, I was saying to someone just this morning that I have some regret over choosing Decos - I hate the app-centric oversimplified mangement - but they do work well enough that I can't really justify spending out on replacing the system ↩ For some reason, I've put more holes through the house this last few weeks than in all the years we've been living here... ↩ I'd love to buy a new switch, but it's hard to justify ↩ In my defence, TP-Link have a torrid history of updates breaking things, so I tend to disable auto-updates on the basis I'd rather manage landing them. It's just that I forgot. ↩ The living room currently relies on a powerline bridge, which I know isn't a great idea. Also, means I get to put another hole through the wall! ↩