WifiNigel

 In a  recent post , I was voicing my concerns around the existing default security method employed by cloud-wireless solutions to 'protect' administrative access to their service. In summary, I proposed that some type of multi-factor authentication should be the default method of access for administrators (both customer and vendor) of cloud wireless services. The current default of a "username and password" is too weak when considering the damage that can be inflicted on an organization by unauthorized access to any cloud-managed network. I heard from one of the  guys at Meraki , letting me know that they already have multi-factor authentication.  I already knew that they have an SMS OTP method, but I didn't really think that it was a particularly good solution. For instance, what about if you're out of cell-phone range or suffer one of those annoying delays in receipt of an SMS message? However, after taking another look, they also now show support f

I've been thinking about writing this article for a while and today I came across some articles and Tweets which finally spurred me in to action (see references at the end of this article). In this article I discuss the CWNP program, with particular emphasis on the CWTS certification, for those wishing to learn about WiFi networking. I meet a lot of people in my line of work (IT professionals in the main) who would like to improve  their   knowledge  of WiFi networking, or would perhaps even like to shift their area of expertise to become focused in this area. However, the question often arises: "how do I get  into  WiFi networking".  If you're an IT professional who already has one or two areas of expertise (maybe you're already a security, routing or perhaps voice specialist?) perhaps you would like to understand WiFi networking, as it will doubtless touch your core area of focus during your day-to-day networking life. Or, perhaps you'd just like to

In this article, I present some of my thoughts around security of cloud-managed wireless solutions (which I am a massive fan of!). Hopefully the views here will be construed as constructive ideas that may prompt vendors to perhaps look more closely at their current implementations to perhaps feed in to product improvements. I've been taking a close look at a some cloud-managed wireless solutions recently and they appear to be a very exciting area, providing a very compelling proposition for many organisations. Remote access to manage your network from anywhere that you have an Internet connection is an incredibly powerful (and empowering) feature. As a consultant working for a vendor-neutral re-seller  the possibilities around remote support and managed services for my customers provide a whole new avenue of exciting opportunities. However, after the initial buzz and excitement of playing with these solutions, I started to think long and hard about their security. Ma

Just a quick note to myself (as well as sharing for anyone interested)... Aerohive APs can be told where to find Hive Manager using DHCP option 225 (for the HM name) or option 226 (for the HM IP address). - (see here for a much better explanation) I tried to set up the DHCP option 226 for an Aerohive AP today to tell it where to find Hive Manager in my lab. The DHCP server I am using is a Cisco IOS switch. I couldn't get the AP to accept the option for some reason. After lots of playing about, I finally figured out what my issue was: I was using the ' ascii ' keyword for the option type, when it should have been the ' ip ' type (...yes, it's always obvious in retrospect). Here is the correct configuration for a DHCP scope in case you find yourself in the same position: ! *** only assign addresses above .150 *** ! ip dhcp excluded-address 192.168.50.1 192.168.50.150 ip dhcp excluded-address 192.168.50.254 ! ip dhcp pool AP-VLAN    network 192.16

I like pictures of stuff. Some people understand and learn more easily through hearing the spoken word, some through reading text and others prefer pictorial representations of ideas, concepts and information. For me, it's definitely pictures, which is why I love Metageek's Eye PA product. In this article, I take a look at the Eye PA wireless network analysis tool and talk about why I'm so enamored with this product. If you're like me, one of the first things you do when visiting a new building, venue or customer site is to fire up your copy of Metageek's free (and incredibly useful) WiFi tool: inSSIDer . It's always interesting to see just how many SSIDs organisations are still trying to cram on to the 2.4GHz band or are perhaps creating themselves and their neighbors a whole heap of trouble by not using non-overlapping channels. Here's how things look for me, sat at home, as I write this article: inSSIDer However, I now have an additional habit

I recently had an interesting customer WiFi performance issue to investigate which turned out to be a whole host of issues on the 2.4GHz band that he was using for his WiFi network. His issues were solved by moving his clients (iPads in this case) across to the 5GHz band, which instantly gave much higher throughput and reliability. However, when he was testing his much-improved network by doing some throughput testing with an iperf server, I noted a sound of disappointment in his voice when he said that he couldn't get a throughput greater than 35Mbps on his iPad.I told him that this was, in  fact, as good as it was ever going to get when using an iPad, even with high performance 802.11n access points. I thought it might be useful to have a look at what realistic throughput figures might be for an iPad on a WiFi network when using 802.11n access points, and why we hit much lower throughput figures than we might expect from the AP manufacturer data sheets. I set up my home lab