WifiNigel

Here are the top 10 things (IMO) you don't want to hear from a customer when you arrive on site to install a new WiFi network (I compiled this rather quickly in a flippant moment - please don't take it too seriously...): Our networking guy, who was going to be helping you today, isn't available, I'm afraid he's... (choose from the following): On a late shift Off sick On leave Over-slept Double-booked Left the company Had a baby Buying a radiation suit Oh, you wanted POE ports for those APs? Our goods-in department has definitely received the kit, they're just not sure which part of the hospital it went to... Oh, we thought you were bringing the kit with you. No, we haven't received anything. You know that 500-person call-center where you said we might have issue with personal hot-spots? The good news is, we've introduced a policy of 'no personal hot-spots' in that area! As a sweetener, we gave all of the operatives a bluetooth

Last year, I put up a  posting  which highlighted the fact that here in the UK (and I suspect all of Europe) we often have 3 channels missing from our allocation of unlicensed channels in the 5GHz band.  Looking at many manufacturer data sheets, channels 120, 124 and 128 are often shown as not being supported. This is despite the fact that they are allocated for use by local regulatory bodies (OFCOM here in the UK). I recently posted a question about this on a partner forum of a major WiFi vendor that I deal with and finally got a definitive answer on this. In this post, I'll share my findings. The reason that these particular channels (120 - 128) receive special treatment is that they occupy frequencies that are used by weather radar systems. WiFi systems have to be very careful not to interfere with those systems during their normal operation. Therefore, WiFi equipment has some additional checks and tests imposed on it to make sure that it does not inadvertently cause any int

With all of the excitement around 802.11ac that is currently unfolding, I was very interested to hear about the support for 11ac by the recently released  Saumsung Galaxy S4. Having a quick scan of the reviews across the web about the new handset, I was intrigued to see claims that it supports 802.11ac, allowing speeds up to 1.3Gbps! Feeling a little sceptical that it would support anything close to those speeds, I did a bit of digging to see what I could find. My first port of call was a product tear-down over at  TechInsights.com . They revealed that the WiFi chip in the S4 is the  Broadcom  BCM4335 A quick look around the Broadcom site soon revealed the product page for the BCM4335, with an overview of the chipset specification. In summary, it supports: Single stream IEEE 802.11ac solution with  data rates up to 433.3 Mbps Full IEEE 802.11a/b/g/n legacy compatibility with enhanced performance Supports 20, 40, and 80 MHz channels with optional SGI (256 QAM modulation

 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