Author Archives: Keith Miller

About Keith Miller

Keith Miller is currently a network engineer for a consulting company on a military base in South Carolina, USA. He was promoted from help-desk technician to network engineer in June of 2010 and has been doing it ever since. Networking is definitely his passion, however he enjoys most things that are IT or technology related. Keith is always looking for ways to improve myself and network with his peers in this industry so feel free to contact him if you’d like to exchange ideas! Twitter: @packetologist

First impressions of the WLAN Pi Go

Table of Contents

As I sit here eating a delicious Cinnamon Crunch bagel in Panera on a beautiful Saturday morning, I thought this would be the perfect time to write about the WLAN Pi Go and my initial impressions of it so far after only a few days of having it. Thanks Om for the push!

The WLAN Pi Go (Go) was officially launched on July 30th, 2025 via a live YouTube stream by the WLAN Pi team. Since I learned about the Go, I knew it was likely an immediate purchase for me. In fact, I ordered one from Josh’s BigQAM store before the live stream was even over.

Image courtesy of the BigQAM website
Continue reading →

Automating backups of your floor plans and AP locations using Python

Table of Contents

Background

At my new $dayjob, we’re undergoing a migration/refresh to Juniper Mist which will encompass over 13K APs when the dust settles. If you’re reading this, you already know that just performing a 1:1 swap for that many APs requires a lot of planning and resources. And depending on the size of your team, things may move faster or slower, or you may opt to contract out some of the work that’s required. Now, some organizations with large deployments choose to refresh portions of their network on a yearly cycle, let’s say 20% per year over 5 years. For us, that would have been a pretty manageable 2600 APs per year. However, given the variables listed below, we’re having to move fast (I mean like Jimmy Johns fast), but our team is small so we’re also having to pull in more resources, including external ones which can result in inconsistencies if left unchecked.

Continue reading →

Decoding Mist AP to Mist Edge tunnels with Wireshark

I don’t have any hard statistics to back this up, but I’m willing to fake bet that at least 90% of Mist’s customer deployments use local breakout (LBO) or local bridging as the method of offloading Wi-Fi client traffic onto the wired network. If this is your first time seeing the term LBO, it’s essentially bridging traffic directly onto the switch port that the AP is connected to. It requires a L2 network where your client VLANs are available on the switch(es) that your AP(s) are connected to.

Fig. 1 Local bridging or LBO deployment model courtesy of Mist’s website
Continue reading →

Finding non-working and statically configured radios in Mist with code

Table of Contents

    Background

    When working with networking vendors in this day and age, AI and ML are terms that are thrown around as features that add value to your team by proactively monitoring and alerting you of interesting or problematic things that may unknowingly exist in your environment. At face value, that sounds great! You don’t have to constantly check your network for issues because the system will bubble them up for you. And in an environment with close to 310,000 APs across multiple orgs and sites, it’s pretty much table stakes. The good news is that I’ve seen this work, as long as you’re checking those alerts because today, these systems will most likely alert, but not automatically remediate any of its findings. The remediation process still requires human intervention in most cases. However, what happens if the vendor’s AI/ML solution isn’t trained to find something in your environment that it should or something that you might be interested in looking at? That’s where knowing how to code and also work with APIs really comes in handy these days. I’m going to walk you through two different scenarios where writing my own code to leverage one of our WLAN vendor’s APIs led to insightful discoveries in our environment to help find a few needles in a massive haystack. One of the scenarios even led to the vendor implementing their own proactive checks into the platform which has sparked an auto RMA process for us.

    Continue reading →

    Why speed tests aren’t always the answer when troubleshooting Wi-Fi networks

    Table of Contents

      Background

      In my current role, we sometimes receive complaints about the Wi-Fi being slow or not working properly. When we ask what the issue is, we’re often sent responses referring to speed test results only that are supposed to serve as the definitive proof that something’s wrong with the Wi-Fi. What our user base often doesn’t understand is that there are many variables when it comes to speed tests in general, but when running these speed tests while connected to Wi-Fi, even more variables exist. Let me try to explain.

      Whether it be wired or Wi-Fi, there are theoretical and real-world throughput maximums in networking that are affected by a number of things. For example, even when you have a 1 Gbps wired connection, chances are you’ll never get full 1 Gbps line-rate speeds in a raw throughput test due to at minimum, the overhead needed to put bits onto the wire, not to mention whether the latency and TCP Window Size (if using TCP) can support the line-rate speed. Latency and the TCP Window Size are two things I’ll come back to in more detail later.

      Continue reading →