Simpli-Fi: The Network Operator August 2, 2010

Posted by Devin Akin in : Uncategorized , 3comments

Do you know anyone who isn’t a Network Administrator, yet they are acting in some subset of that capacity almost every day?  Of course you do…and you could call them by lots of names: SubAdmin, Auxiliary, ParaAdmin, Attendant, Operator, Reluctant Administrators, and others (thanks Marcus).  We’ll call them Operators for now.

Teachers.  Nurses.  Homes (that’s you, “the computer guy”).

What’s their number one problem?  Clients.  A multitude of clients in fact.  Every brand and type imaginable.  iEverythings, CoWs, carts full-o-netbooks, laptops, phones, badges, RFID tags, etc.  The list is endless.  Driver capability and behavior is so varied that it’s a miracle that anything works at all (insert Kudos for the Wi-Fi Alliance here).  Just making sure a client is within normal operating parameters is half the battle toward a good and expedient client experience.  Ever watched (or perhaps been) a teacher burn valuable instruction time walking around a classroom making sure everyone’s computers are working properly?

What about nurses handling CoWs, infusion pumps, and VoWiFi badges/phones/RFID-tags?

What to do, what to do….

Aerohive’s Client Health to the rescue!

Network operators don’t want client statistics like CRCs, retransmissions, dropped frames, RF interference levels, and such as that.  They want a Go/No-Go answer.  They want to know a client’s health in familiar terms.  They want more bars, they want green lights, and they just want to know a client is operative so that they can get their primary mission done.  Client connectivity problems are a nuisance.  Am I wrong?

Of course, a network admin wants to drill down when they see red.  They may want to take a deep dive to look at the numbers.  That’s fine, they can…with just a click.

If you’re familiar with AirMagnet’s AirWISE, a remarkable spin on protocol analysis, Aerohive’s Client Health is conceptually similar.  When using AirMagnet’s Wi-Fi Analyzer Pro product, the AirWISE engine saves the analyst countless hours of manual troubleshooting by making sense of the captured packets and displaying problems and solutions to the analyst.  It also displays useful information in a “rolled up” format.  Instead of analyzing 1000’s of packets manually, the system does that for you and gives you the gist of it on a dashboard.  It’s the same with Aerohive’s Client Health engine.  It watches all of your client connections, analyzes a variety of connection parameters, compares client health to SLAs, gives the administrator the gist of it on a dashboard, and if necessary takes automatic action to improve client health.  If you want to drill down, you can, with just a click…just like with AirMagnet’s AirWISE.  Kudos to AirMagnet for pioneering the concept of simplified analysis.

Suppose that you want to take this concept even further.  We call it TeacherView, but certainly that’s just one spin on it.  A picture is worth a kiloword.

Yep, application integration with an intelligent infrastructure.  It’s Wi-Fi infrastructure that learns, and then helps you teach.

(Phrackin’) ARP Spoofing is now old enough to vote July 30, 2010

Posted by Matthew Gast in : security, wireless ARP spoofing , add a comment

(The title is a pun, related to the content of this post and an admission to the world that I was a huge fan of Battlestar Galactica, as reimagined by Ron Moore.)

The basis of the recently disclosed wireless ARP spoofing attack is, in fact, the well known technique of ARP spoofing, applied on a wireless network. ARP spoofing goes by various names, most notably ARP poisoning or ARP cache poisoning.

ARP was specified in RFC 826 in November 1982. ARP was not an immediate standard on Ethernet. While trying to find the first mention of ARP spoofing, I found some fascinating threads that indicate that ARP was an emerging protocol and, and descriptions of the difficulties in using early ARP implementations in the early- to mid-1980s. In 1983, ARP was fighting for market share. This message from the TCP-IP distribution list by Mike O’Dell (later Chief Technologist for UUnet, a major Internet backbone provider) states that the nascent TCP/IP community needed to pressure vendors into using ARP instead of proprietary equivalents.

But I digress. The first unambiguous reference I could find to ARP spoofing is in Phrack 34, section 12:

There are security considerations within the TCP/IP protocol suite.
To some people these considerations are serious problems, to others
they are not; it depends on the user requirements.

This tutorial does not discuss these issues, but if you want to learn
more you should start with the topic of ARP-spoofing, then use the
“Security Considerations” section of RFC 1122 to lead you to more
information.

Given that Phrack didn’t include a description of ARP spoofing, it must have been well known at the time of publication. Phrack 34 was published on October 2, 1991. That means that ARP spoofing at least 6,858 days old as I write this.

It turned 18 almost a year ago, which means that if it was discovered in the US it is now old enough to vote and marry without parental consent. Congratulations, ARP spoofing. Go out and celebrate!

Let’s take the analysis one step further.  Many people say that an “Internet year” is so action-packed that it is the equivalent of more than a calendar year. I’ve seen many calculations for the comparison of Internet time to regular time, and I like Eric Reiss’s approach best. He takes a macro-level approach and compares large-scale Internet adoption to the history auto industry, and calculates that one Internet year is 4.7 years.  Accepting Reiss’s figure, that makes ARP spoofing equivalent to a hair over 88 years old.

Glenn Fleishman on Wireless ARP Spoofing in Ars Technica July 29, 2010

Posted by Matthew Gast in : security, wireless ARP spoofing , add a comment

Glenn Fleishman (of WiFi Networking News fame) has written what is to date the best account of the Wireless ARP Spoofing attack for Ars Technica. There is a ton of detailed analysis in the massive story, and a lot to digest. The key insight is in the second paragraph:

In fact, the exploit continues to demonstrate a lack of any effective method of cracking the WiFi Alliance WPA/WPA2 certified versions of IEEE encryption standards found in WiFi gear of the past seven years. Brute force and dictionary attacks against short passphrases used typically on home and small-business networks are still the only means of key recovery.

There’s not much to say, other than “go read this. now.”

(Full disclosure: I have admired Glenn’s work for years, he graciously wrote the foreword for the second edition of my 802.11 book for O’Reilly, and I am quoted as a source in the article.)

Straight from the horse’s mouth: 802.11-2007 on ARP Spoofing July 29, 2010

Posted by Matthew Gast in : security, wireless ARP spoofing , 2comments

First of all, I’d like to thank Devin for letting me guest blog here.  For an introduction, I’m the Director of Product Management here at Aerohive, where I lead development of HiveOS, the operating system on our APs.

Obviously, a big part of what we do at Aerohive is design and build Wi-Fi APs.  One of the ways I contribute to that effort is by participating in industry organizations.  At the Wi-Fi Alliance, I serve as chair of the Security Technical Task Group and vice chair of the Security Marketing Task Group.  Before joining Aerohive, I was chair of 802.11 Task Group M, which was producing the 802.11 revision due in 2011.  (I had to give up leading TGm when I joined Aerohive because I just didn’t have the time because there are only 24 hours in my day.)  You may have also read one of my books…

This has been an “interesting” week for me because I’ve been having almost non-stop conversations with people about Wireless ARP Spoofing (originally published as “hole 196″).  I’m going to be writing a series of posts for the blog here about ARP spoofing, starting with the standards background, diving deeper into technical details, and highlighting other works worth reading as they come out.  This post is only the first in a series.

I’ll start with a warning on this post.  I wanted to start off by talking about what the 802.11 specification says about ARP spoofing.  As a result, this post is going to be one of the most wonkish and technical that I’ve ever written – I’ll be quoting liberally from the specification.  If you’d like to follow along at home, visit Get802 and grab your very own PDF copy of 802.11-2007.

The Wireless ARP Spoofing attack depends on the ability of any device to use the broadcast key to send an ARP packet as a vector to redirect traffic.  The reason it was initially dubbed “hole 196″ is that there is a sentence on page 196 about the ability of any device authorized to use a network to forge ARP frames.

The purpose of this post is to quote the specification directly regarding the protection offered by the broadcast key mechanism, and show that any time you have a symmetric key (not a public/private key pair), it is difficult to maintain security.  I’m not going to get into the effects of the attack in this post, but I’ll talk about that in the future.

First, there’s the famous part of the specification, on page 196:

8.5.1 Key hierarchy [ this is on page 196 – mg ]

RSNA defines two key hierarchies:

a) Pairwise key hierarchy, to protect unicast traffic

b) GTK, a hierarchy consisting of a single key to protect multicast and broadcast traffic

NOTE—Pairwise key support with TKIP or CCMP allows a receiving STA to detect MAC address spoofing and data forgery. The RSNA architecture binds the transmit and receive addresses to the pairwise key. If an attacker creates an MPDU with the spoofed TA, then the decapsulation procedure at the receiver will generate an error. GTKs do not have this property.

For the last week, the most quoted sentence of the specification is the last six words, but it’s hardly a secret that the GTK does not provide source address authentication.  For example, there’s the introductory material in clause 5, which provides an overview of the entire standard.  At the bottom of page 38, it reads (emphasis mine):

5.4.3.5 Data origin authenticity [ this is on page 38 – mg ]

The data origin authenticity mechanism defines a means by which a STA that receives a data frame can determine which STA transmitted the MAC protocol data unit (MPDU). This feature is required in an RSNA to prevent one STA from masquerading as a different STA. This mechanism is provided for STAs that use CCMP or TKIP.

Data origin authenticity is only applicable to unicast data frames. The protocols do not guarantee data origin authenticity for broadcast/multicast data frames, as this cannot be accomplished using symmetric keys and public key methods are too computationally expensive.

Finally, you can look at the assumptions that went into the construction of the Robust Security Network Architecture (RSNA), which was the security protocol defined in the 802.11i amendment in 2004.  Towards the bottom of page 157, the spec reads (once again, emphasis mine):

8.1.5 RSNA assumptions and constraints [ page 157 – mg ]

h)            The destination STA chosen by the transmitter is the correct destination. For example, Address Resolution Protocol (ARP) and Internet Control Message Protocol (ICMP) are methods of determining the destination STA MAC address that are not secure from attacks by other members of the ESS. One of the possible solutions to this problem might be for the STA to send or receive only frames whose final DA or SA are the AP and for the AP to provide a network layer routing function. However, such solutions are outside the scope of this standard.

To say that the specification had a “little-known vulnerability” regarding group keys is an overstatement.  Nearly 40 pages prior to the sentence that has been quoted so liberally, the authors of the standard admit that ARP is not secure.

Thanks to Henry Ptasinski (Broadcom) and Nancy Cam-Winget (Cisco) for identifying relevant pieces of the specification.

The Infrastructure is the Sniffer July 29, 2010

Posted by Devin Akin in : Uncategorized , add a comment

Know Thy Clients, Lower Thy OPEX July 27, 2010

Posted by Devin Akin in : Uncategorized , add a comment

I’m going to throw a statement out there early-on…

A Good Client Health Score means lower OPEX.

In Wi-Fi, it’s a universal truth.  Let me show you.

Suppose you’re an administrator for an organization who’s on the leading edge of IT in general.  You have gone with 802.11n-to-the-max and find yourself the happy new owner of the following devices:

1) An iPhone4 and iPad with Broadcom BCM4329 dual-band 1×1 802.11n
2) An HP 5101 netbook with Intel 5100 dual-band 1×2 802.11n
3) An old, crappy laptop with a Linksys WUSB600N USB2, dual-band 2×2 Ralink RT2870 802.l1n adapter
4) A Lenovo X201s laptop with Intel 6300 dual-band 3×3 802.11n

Note that while each of these clients is state-of-the-art 802.11n, they are all completely different.  They have different chipsets by different manufacturers with different drivers.  They have different behavior with different bugs, default settings, and configuration options.  If you’re unfamiliar with those 1×1, 1×2, 2×2, and 3×3 numbers, those are MIMO chipset specs that talk about how many transmitters and receivers each of those chipsets support, which is also an indicator of how many spatial streams they support.  Each is different, but they’re all 802.11n.  Note that we haven’t mentioned all of the 802.11a, 802.11b, 802.11g, 802.11a/b, and 802.11a/g chipsets in the market…we’re trying to keep it simple. We’ve just mentioned Broadcom, Ralink, and Intel here, but there are also Atheros, Marvell, and, well… a dizzying assortment of other client chipset manufacturers on the market.  The combinations and variances are simply overwhelming.

Some vendors try to simulate clients in order to provide some type of pseudo-guarantee that their infrastructure is going to be able to provide services to clients, but it’s simply not possible to simulate this kind of real-world variance…as I’m sure you can already see.  Some vendors observe client behavior but can do nothing to assist these clients in maintaining a healthy connection.

Question: How do you provide an Ethernet-like experience to clients in such a diverse scenario?

Answer: You learn client capabilities and behavior, and subsequently give them what they individually need to meet their application layer needs.  Ahhh yeah.

Rhetorical Question: If a client has a maximum-speed connection (e.g. 130 Mbps on 2.4 GHz or 300 Mbps on 5 GHz), does that mean the connection is “good” and can meet the demands of the applications of that client?

For example, suppose that a client has a 130 Mbps data rate (because it is 2×2 capable) but it has a large number of retransmissions and frame errors due to an environmental problem in its physical area.  Further, suppose that it has an SLA of 6 Mbps because it often streams HD video.  If its goodput (successful throughput) is less than 6 Mbps, does it make sense to give it more airtime?  Of course not, because that airtime would just be wasted on a bad connection.  Doesn’t it make more sense to encourage that client to move to another band (i.e. band steer from 2.4 GHz to 5 GHz) on the same AP or perhaps to a different channel on a different AP on the same band (load balancing)?  Then, after the client has moved, wouldn’t you assess what further steps need to be taken to improve its goodput (which might include additional airtime) in order to meet its SLA?  Obviously you’d need to know the client’s capabilities before you’d make the decision to band steer or load balance the client.

So in order to provide an Ethernet-like experience to Wi-Fi clients, you should, as a minimum:

1) Verify that clients are operative (which means infrastructure uptime and solid client connections with the infrastructure)
2) Assess client capabilities
3) Monitor a variety of parameters related to each client’s connection (behavior)
4) Make APPROPRIATE changes, based on the client’s capabilities/behavior and on the impact to other clients in the network

It’s infrastructure that learns.  We’ve always said that our APs are intelligent, but this is ridiculous, no?  It’s not only self-healing, but it’s also client healing.  Establishing and maintaining good client health is essential to lowering opex…and we make it simple, automatic, and customizable.

Aerohive set out to solve high Capex problems, bottleneck problems, reliability/resilience problems, and scalability problems…and we’ve been very successful in doing just that.  Now we’re on a new conquest: lower opex through good client health.  Consider that if your Wi-Fi infrastructure costs less initially, but has a very high opex (difficult and expensive to deploy/use/expand), you haven’t done yourself any favors by buying it.

Aerohive’s new Client Health feature set is a vaccine against Wi-Fi bitter beer face. 

Enter Hole196 July 22, 2010

Posted by Devin Akin in : Uncategorized , 7comments

Enter what?   Hey, it could be worse.  It could be BlackHole196.  Here’s the headline:

http://airtightnetworks.com/WPA2-Hole196

You knew the day would come didn’t you?  WPA2 has sprang a leak, but at least it’s not gushing.  When I first read this announcement, I thought to myself, “Self, is this a big deal?  Is this realistically exploitable or irresponsibly alarmist?”  Self believes that this has the potential to be a problem, especially if someone makes a Windows-based, push-button hacking tool based on it.  Creating such an exploit will take at least 8 hours to do, so we’re safe until…well…tomorrow.   I’m kidding of course…it’ll take at least a week.

The “aha!” moment came when I realized that I actually understood what the hell the attack was all about.  Sad, no?

When I first read the description of this security hole, of course I went straight to the statement in IEEE 802.11-2007, page 196.

NOTE—Pairwise key support with TKIP or CCMP allows a receiving STA to detect MAC address spoofing and data forgery. The RSNA architecture binds the transmit and receive addresses to the pairwise key. If an attacker creates an MPDU with the spoofed TA, then the decapsulation procedure at the receiver will generate an error.  GTKs do not have this property.

Normally it takes 30 minutes of silence, intense study, someone helping me think through it logically, and then divine intervention for me to understand some of the Wi-Fi industry’s security holes and exploits.  This one took me 30 seconds, and then…”oh crap.”   Traditionally 80% of attacks come from the inside, so this one looks realistic – especially if there’s a reasonably easy-to-use exploit tool forthcoming.

Here are some technical notes of interest regarding this security hole (BIG thanks to Matthew “Spock” Gast for lending me a huge helping hand)…

1) WPA2 encryption isn’t cracked with this attack – fortunately for us all.  “In-flight” data is still as secure as it ever was.

2) Hole196 attacks require that an insider use the GTK.   There will be no drive-by attackers executing this against WPA2-Enterprise networks.  An attacker working against a PSK (WPA2-Personal) will need to forcibly disconnect clients from the network to see the GTK exchange.  WIPS systems already alarm on forged deauths today, so an external attacker would need to become visible to run the attack.

3) It’s an insider attack.  Insiders are, by definition, already inside, and can already launch attacks at L3.  Nothing prevents an insider from doing ARP poisoning on the wired network right now.

4) Because this attack doesn’t compromise unicast keys, the attacker needs to use L3 to redirect packets, such as by substituting the attacker’s MAC for the router MAC or subverting DNS.  This can be defeated by a client isolation feature, but not everyone can use the client isolation feature (e.g. VoWiFi phones may need to talk to each other across the same AP).

Regarding a solution, here are some technical points to note as well:

1) An AP would know, when it heard the spoofed transmission from one client to another, that this attack might have happened.

2) This attack is packet-injection based, and given that these packets must be encrypted with the GTK, they must be broadcast or multicast packets.  This means that you can’t send a unicast packet to another client…an important distinction.  The attack has to be a one-packet-wonder attack at L3 or L2 broadcast/multicast – like ARP poisoning.

3) Since the AP can decrypt the attack packet, it can look at the IP addresses within it.  The AP can then look at the source and destination IP addresses to see whether this attack may have happened (based on the fact that we know which clients have which IP addresses due to DHCP).

4) Other attacks which are potentially useful to an insider are address sweeps and port scans, both of which are detected by the IP DoS module in HiveOS, and activated by default…so we’re not too worried about that happening.

Nice find Airtight.  Just tell me that you don’t have Hole274, Hole585, and Hole983 queued up for us too.   We’re looking forward to seeing the exploit.

Building a Controller July 19, 2010

Posted by Devin Akin in : Uncategorized , 2comments

I often hear, mostly from our competitors, that their platform is more flexible than Aerohive’s from an architecture perspective because they can do centralized or distributed forwarding, whereas we can only do distributed forwarding.  I’m not sure who the marketing goober who came up with that spin is, but he/she should start over from scratch.  Aerohive certainly doesn’t do everything perfectly, but picking on our architecture is just a bucket full of dumb.

Let’s say that, for some extremely odd reason, Aerohive wanted to build a controller…roll the day dreaming sound effects…

Controller-based solutions use AP-to-controller tunnels.  Each vendor uses a different tunnel type, but let’s say for the sake of argument, that we wanted to use GRE…since it’s generic.

Aerohive’s HiveAPs support GRE tunnels between APs for tasks such as guest tunneling, VPN tunneling, and L3 roaming and will load balance tunnels per subnet.

Let’s say you wanted to build a small controller.  You know, like those quirky little “branch” controllers that controller-based vendors sell.  Their best feature is that they don’t weigh much.   Well, HiveAPs have equivalent (and often more) horsepower than any of those controllers, which usually support 4-12 APs.  Our HiveAPs can support 200 such GRE tunnels each, so “small” is very relative for Aerohive.  In order to build a “small” controller, we just use a single HiveAP as the controller.

Other APs, using access-port connections to the Ethernet, will build GRE tunnels to our “controller AP” automatically when the first client connects to a regular AP.  The rest is automatic.  The controller AP would be trunked to an Ethernet switch, and all forwarding would be centralized.  This equates to what we do all the time, called Guest Tunneling, though normally we don’t trunk the AP that lives in the firewall’s DMZ when doing Guest Tunneling.

Let’s say you wanted to build a monstrosity of a controller.  You know, like those racks full of power-hungry behemoths that jack up your Wi-Fi spending by 40-75%.  Automatic tunnel load balancing allows a group of HiveAPs that live on the same subnet to act as a single unit (called a Hive), which means that you can build a controller of any size just by adding APs onto a subnet.

They self-discover, self-organize, and form a single coordinated unit that load balances clients, tunnels, and well, everything.  Which is more scalable and resilient?  20 APs, each with dual-core, high-end CPUs or a single controller with a single CPU?  So, while the APs are serving Wi-Fi clients, they can also act as a controller for purposes of centralized forwarding.  This equates to what we already do in the way of L3 roaming and VPN termination.  Why settle for a single piece of single-purpose hardware, when you can use the APs to do both serving clients and centralized data forwarding?

Back to reality…roll the day dreaming sound effects…

I can’t think of a scenario when you would NEED to do centralized forwarding other than Guest Tunneling, though I’m sure there are times when you might WANT to for some specific one-off reason.  Aerohive’s architecture can do both distributed and centralized forwarding, though we always recommend distributed for scalability and resilience.

The other day we won a big competition for a very large and prominent K-12 organization who has a VERY centralized wired network architecture.  They posed the question of how, with their wired architecture, would distributed forwarding for Wi-Fi have an advantage over centralized forwarding.  It was a good and valid question.  Our answer was something akin to:

Neither centralized nor distributed would give you any significant advantage with the wired architecture as-is, but if you begin distributing your functionality in any meaningful way (VoIP for example), a distributed architecture would suddenly give you many advantages.  In other words, a distributed architecture has no disadvantages, but in many cases will have huge advantages.

Sure, we can build you a controller, but why?  There’s scalability, resilience, and added security in not doing so.

My Dog Clarence July 16, 2010

Posted by Devin Akin in : Uncategorized , 2comments

GT Hill is in town – Woot!  Anytime GT comes to town, you KNOW he and David Callisch are going to do something funny.    This story is perhaps even funnier than our Infinitely Scalable Controller (ISC) prank from April Fool’s Day.

So I have to preface the rest with the fact that I’m purposefully picking at Adam Conway, the actor…uh, I mean VP of Product Mgmt… who starred in the ISC video here:  http://www.aerohive.com/isc because he has a good sense of humor.

So I’m headed to dinner with my most excellent friends Gene “GT” Hill and David “I have an 85% return rate on fist bumps with total strangers” Callisch from Ruckus Wireless when I dropped by Adam’s office to talk about some misc Wi-Fi related things.  I mentioned that I was headed to dinner with GT and DC, and suddenly we took a 20 minute deep dive into sundry conspiracy theories and paranoid delusions.  Yeeks.  So, I was then off to dinner.

Callisch offered up a pinky-swear-to-silence at the on-set, which I quickly declined due to being mid-recovery of one of Adam’s temporarily-projected delusions.  After being told I was a wenus (which has something to do with an elbow I think), I conveyed a high-level overview of the still-swirling-in-my-head-though-it-didn’t-originate-with-me thought that if I paid Ruckus a compliment at the dinner table, it might be used against me in the media (or something to that effect…it’s all kind of gray now).

Callisch now plotted on how to feed Adam’s paranoia…moahahahahaha.  Of course, it must look to Aerohive like Adam was consorting with the enemy (in an extremely quirky and odd sort of way).

At 5pm, GT, known only to Abby and me, entered our front door with a dog…a BIG STUFFED RUCKUS DOG…with a Ruckus T-Shirt on and a Ruckus AP2825 (gee, thanks…isn’t that 11b/g?) hooked to its collar.  There was, of course, a balloon that said, “Good Luck” and a very nice card with a very nice note attached wishing Aerohive the best of luck in “our markets.”   Classic!

We were just wrapping up a meeting in the conference room next to the front door, when GT arrived.  Our “big dogs” were in the room (except for Adam – figures, eh?), and got a HUGE laugh out of this whole thing.  I introduced GT to everyone and told everyone the story of the previous evening.  Dave Flynn (our CEO) was there to receive the gift from GT, so that just worked out GREAT.  Dave took the dog to Adam’s office, where it was promptly named Clarence by Adam.

I hear he’s not a very well-behaved dog…something about causing a ruckus in Adam’s office.

Our hats are off to Ruckus.  Those guys are great sports, and we certainly wish them the best in “their markets” as well.  Now I’m off to have BBQ with GT!

Fully Distributed means FULLY Distributed July 12, 2010

Posted by Devin Akin in : Uncategorized , add a comment

search

RSS Feed

• Recent Posts

  • Wi-Fi Spectrum Analysis? What’s That?
  • Branch Office Wi-Fi
  • The Relevance of 802.11n Transmit Beamforming (TxBF)
  • WLANs in K-12 – Part Deux
  • WLANs in K-12

• Archive of the Hive Mind

  Select Month September 2010 August 2010 July 2010 June 2010 May 2010 April 2010 March 2010 February 2010 January 2010 December 2009

• Aerohive Tweets

  • New Jersey School District Expands its Wireless Network - http://bit.ly/cBUi2D 2 weeks ago
  • A Tale of Two APs...Once upon a time in a land far, far away, there lived an Autonomous AP (A-AP)...http://blog.aerohive.com/blog/?p=415 4 weeks ago
  • TeacherView: Aerohive's innovative new application to make it easy to manage Wi-Fi in the classroom http://www2.aerohive.com/teacherview 1 month ago
  • Aerohive's free Wi-Fi planner - now more intuitive UI, AP auto placement & improved reporting. Register at http://www.aerohive.com/planner 2 months ago
  • Need convincing that controller-less is the future of Wi-Fi architecture? Read the latest blog post from Devin Akin - http://bit.ly/ajaLNu 3 months ago

© 2010 Aerohive Networks, Inc.