ECSE Troubleshooting
After a manic two weeks, I’m finally home and enjoying my own bed. First came the ECSE Design course, then the ECSE Troubleshooting course capped off with WiFi Design Day on Friday. All three were awesome but quite a few people were asking me about the troubleshooting course, especially after hearing Keith’s talk at WDD. So as best I can, here is my rundown of the course and what I learnt.
Firstly, and I know this might sound obvious but… Keith knows his s%#t! I was also lucky enough to be in a room with a bunch of other people that know what they’re doing. Peter MacKenzie, Nick Turner, Raymond Hendrix and Ferney Munoz all willing to help a noob try to understand some of this stuff.
This is how the course plays out:
From the start, it’s a great refresher on the basics of RF and ran through the same things as the beginning of the Design course. It was helpful to me even though I’d literally done it the week before (hopefully, it’ll help me remember it). We also went through the now-famous Troubleshooting Process that Keith came up with.
@KeithRParsons
@KeithRParsons
@KeithRParsons
The course is basically running through this process to find out where issues could be and what tools would be best to ask the right questions.
On day two we looked at Wired v Wireless problems - how do you know if it’s an issue with the wireless? For this, we did a Netool.io lab. After lunch, we started looking at the ‘Investigate’ section of the process. We used the Ekahau RTFM Scanner, WLAN Pi (HORST, BetterCap, Kismet and Client Profiler). We finished the second day looking at ‘Measure’ by doing some Performance and throughput testing using iPerf and the HTML end-point test on the WLAN Pi.
Day Three we started on ‘Validate’. Looking at how to perform accurate validation surveys using Ekahau. This was a great lab looking at the strengths of Ekahau Pro and what to be careful off under each of the sections. It was really good to go through things that can look bad on a survey and explaining why they happen and why you may or may not want to include these on your reports. Things like roams on an active survey or throughput when the client you’re using hasn’t roamed. Showing that if your client wants to know these metrics how you’ll have to set up your tests to makes sure that these reports are accurate and helpful. Just before lunch, we started looking at ‘Analyze’. Time for the Spectrum Analysis… we used the sidekick to track both 802.11 traffic and non-WiFi interference. As someone looking at this for the first few times I’m still surprised how resilient WiFi is. It’s only really WiFi that causes WiFi an issue (unless you stick a jammer next to a client or AP). After lunch, we started on ‘Interrogate’ - this was the section I was most keen to get into. We used Wireshark for the packet analysis and looked at things like setting up profiles, adding columns, using filters, adding colour rules, adding friendly names to the ethers file, using frame comments and Graphing.
Day Four we continued looking at ‘Interrogate’ and used the WLAN Pi for remote packet capture then moved on to doing some ‘soft skills’ exercises and testing what we’d learnt by giving each other scenarios to troubleshoot. The point was to use the processes above to pinpoint the issue… my group did not do this… we just carried on troubleshooting the way we always have… oh well, at least we learnt something… This was a brilliant exercise to do just before the final ‘exam’ as it helped to show that these things won’t come naturally to us, our default is to work off of experience, not process. After lunch, we took the exam (a round-robin of the troubleshooting process).
All in all, I would suggest people take this course. Whether you’re new to the game (like me) or you’ve been doing this for ages it’s a great refresher course that helps to get you back on track.
Here’s Keith doing a cut-down version of the course during WLPC Prague 2019
