Posts

Devin was right...?

In the WiFi industry, there are fewer characters who are more polarizing than Devin Akin ( @DevinAkin ). I guess he is the 'Marmite' of the WiFi industry: you will generally be a huge fan, or maybe not so much :) I personally have always been a huge fan of the work he did when he was part of the CWNP organization - I would not be in the position I am now without the fantastic work that Devin and the guys over at CWNP have done in providing vendor-neutral WiFi certifications. However, back at the beginning of 2012, Devin had moved to Aerohive and was presenting at the WiFi Symposium, which was part of the Wireless Field Day 2 event. I watched all of the videos from that event and learned some very valuable information. However, Devin's presentation about Aerohive's architecture (which you can see at the bottom of this article), and his belief that in the future other vendors must move in a similar direction, was a 'light-bulb' moment for me. I had only been

Configuring DHCP Option 226 on a Cisco Router/Switch for an Aerohive AP

There are a number of methods of directing an Aerohive AP to find its instance of HiveManager, including using a DHCP option. In this quick tip, I share how to set up a Cisco switch or router DHCP server range to provide the correct  DHCP option to direct an Aerohive AP to a local instance of HiveManager. This is useful if you have a copy of HM running on your own appliance or virtual server. APs may be passed the IP address of HM via DHCP option 226. In the example below, APs are assigned addresses in the range 192.168.20.0/24. The Hive Manager server may be found at 192.168.50.7 in this example. The default router and DNS server options will need to be set to match your own environment. ! ! DHCP range for Aerohoive APs ! (HM address passed to AP using option 226) ! ip dhcp pool APs    network 192.168.20.0 255.255.255.0    default-router 192.168.20.254    dns-server 8.8.4.4     option 226 ip 192.168.50.7 Hopefully, this is all fairly self-explanatory if you are famil

The Missing Feature in WiFi Solutions: Performance Testing

In this article I suggest a nice feature that would provide a useful WiFi vendor differentiation and a valuable tool for administrators of WiFi networks. As a WiFi network value added re-seller (VAR) I visit a lot of customers, interacting mainly with the poor, down-trodden folks who comprise the IT department of an organisation. They are generally responsible for fending off the daily barrage of complaints about " the network" . In general, they are mainly concerned about two factors when it comes to their wireless network: coverage and performance. There are many other factors that they should probably be concerned about, but these are the two factors that tend to keep users off their back if they are both taken care of. Verifying WiFi coverage for an average IT administrator is generally very simple. They simply do a Google search download a tool such as Metageek's inSSIDe r and visit the area where users are complaining. Even if they don't manage to use