Tag Archives: Ubiquiti

The Idiot’s Guide to Ubiquiti UniFi

BTW- I’m the idiot, in this case. Something about Ubiquiti’s “UniFi” approach to networking can make me feel confused and inexperienced at times. But I’m determined to make peace with it, and to also maybe help save someone else the confusion. Ubiquiti’s product lines are interesting, feature rich, innovative, flexible, and cost-effective. And… also occasionally bewildering if you have yet to Ubiquitize your mind. To this point, let me (hopefully) make the indoctrination to UniFi a little easier.

UniFi is a Management Methodology AND Networked Components

Part of what confused me early on was the name- “UniFi” must surely just be a bunch of bridges and access points… As in, things that do Wi-FIIf you’re thinking that, you’re wrong. UniFi is more like UniFied in that a wide range of switches, access points, security gateways, video components, and more are branded with the UniFi moniker and managed as an ecosystem.  First major point: UniFi isn’t just wireless.

As for how the UniFi ecosystem is managed, that’s one of the main areas of getting to know Ubiquiti’s latest stuff that made me feel like a child (and not a very smart child, at that). I have set up and managed my share of other non-UniFi Ubiquiti bridges, where you get to the individual component’s UI and configure to you heart’s delight. But if it’s a UniFi AP, switch or gateway, life gets a little more involved. Forget the individual per-component UI, for UniFi you need to adopt each component into a “controller” and then manage a “site” worth of stuff (or multiple sites) via the controller.  Second major point: you don’t generally manage individual UniFi parts/pieces, you adopt each into a “controller” and then manage them all from the controller interface. I’m not a fan of the term “controller” here, but it is what it is. Think OpenMesh or Meraki dashboards and you’re on the right track.

Maybe Too Flexible?

This is where experienced UniFi users might tell me to go eat rocks, and I’m OK with that. But I have been utterly confounded trying to wrap my head around the various incarnations of the UniFi Controller. One way or another, you need to get to this point:
UniFi Controller

This inventory view of the Controller shows what devices I have, then from there it’s pretty robust in both configuration and monitoring capabilities.
UniFi Controller1

UniFi Controller2

Once you get your devices into the controller instance, life gets pretty pleasant. I give Ubiquiti a lot of credit for the completeness of the management interface and for putting together a framework that makes perfect sense- once you get there. Getting there, however, can be tricky. To me, Ubiquiti isn’t doing so hot on their messaging that the UniFi controller can take multiple forms and that you have to really know which form you want to use before your bring an environment to life.  I’ve spent a lot of time pouring through Ubiquiti’s web pages, and there seems to be more of an emphasis on dazzling potential customers with grand claims of cloud this and that and SDN blah blah blah than a realization that newcomers to Ubiquiti may need some basic buzzword-free guidance on this controller thing. The UniFi controller can exist in different forms, and you can only use one at a time with a given set of end devices:

  • On a laptop. You need to use the controller to manage devices, but the devices don’t NEED the controller to operate, so you might only invoke the controller when you have changes to make. But… here you don’t get the monitoring and statistics that you would with a more persistent controller method.
  • On a CloudKey.  Now this is cool. I wrote about my first use of CloudKey here, and you need to know that it’s just another way of managing the UniFi devices.
  • On your own virtual host. Load up a controller in AWS, manage a bunch of sites in your own private cloud- but know that you have to provision the devices to get them to your cloud-hosted controller with effort not required in pure cloud-managed systems like Meraki and OpenMesh.
  • Let Ubiquiti host it. Recently added to the UniFi offerings is the Elite Controller option. Here, you end up with something that’s kind of like Meraki but not nearly expensive. You pay a modest fee per device, and in exchange Ubiquiti provides cloud hosting of the controller for your devices, and phone and chat support. Unlike Meraki or Open Mesh, this is not plug and play. Your devices do not magically tunnel out to the cloud controller just because you’d like them to! You need to provision the devices, as Justin Paul writes about in his blog. If you don’t do the provision thing right, you’ll beat your head against the wall in frustration.

Third major point: there are several versions of “UniFi Controller”. You have to grasp the differences to decide how you’ll manage a given network, 

I’m currently kicking tires on UniFi hardware and the Elite Cloud option. I will have much to say on both as my evaluation continues, but I do hope that this quick primer can help anyone who is new to Ubiquiti’s UniFi environment.

Newsflash: All 5 GHz Clients Don’t Work on All 5 GHz Channels

OK- this really shouldn’t be a newsflash. But, if you’ve never had to deal with what I’m about to summarize, then it may well be a headline story. But first, a word from today’s musical guest- Genesis, fronted by the great Phil Collins:

Talk to me, you never talk to me.
Ooh, it seems that I can speak.
I can hear my voice shouting out.
But there’s no reply at all.

Look at me, you never look at me,
Ooh, I’ve been sitting, staring, seems so long.
But you’re looking through me
Like I wasn’t here at all.
No reply, there’s no reply at all.

Phil and the boys know well what happens when you assume that any 5 GHz client will work on any 5 GHz access point. Rumor has it that Genesis was troubleshooting a wireless installation at a mall in Duluth when they were inspired to write the super-hit “No Reply at All”, but that’s a story for another time.

I’m here to tell you of- and show you- an example of a 5 GHz client that just can’t (and therefore WON’T) talk to anything but a few 5 GHz channels. If it’s not obvious, there is high potential for the “the network sucks!”  factor here. If you don’t know what you’re doing, you can foolishly add more APs, tweak every setting there is to tweak, RMA one client device after another, and end up with an over-radiating nonfunctional heap of squadoosh, baby.

Trouble in Po Po Land

Once upon a time, there was an awesome dual-band Wi-Fi network that few could match. The APs were pretty, the signals were clean, and the installation crew was a bunch of snappy gents. Thousands upon thousands of client devices used this high-performing WLAN daily- every kind of laptop under the sun, all sorts of common mobile devices, and smartphones aplenty.

Then the police cars came.

The Long Arm of the Law wanted in on that Wi-Fi goodness. The idea was simple: police cars would pull into their very wireless well-covered parking area at the end of shift, and dashcam video would automatically download to network servers via that sweet, sweet Fi. A vendor was hired to equip the cars, the police technical staff got the lowdown from the network folks on how to configure the client devices, and everything seemed good.

Except it didn’t work.

About That Police Car Wireless Client Device

The cruisers in question are equipped with the Ubiquiti Bullet M5 radio. These have a handy form factor, and can be had for less than $100 (then obscenely marked up and resold as something special).  And look- they are 802.11a and 11n-capable!


Should be no issues on that robust dual-band network, as long as signal is coming out of the 5 GHz radios in theAPs and the 5 GHz radio in the M5- yes? I can stand next to the police car with my iPhone and connect on 5 GHz, so the car should work too! But… the cars weren’t working at first, despite their 5 GHz output being verified with a number of tools.

Curse you, fickle Fi! What dark magic is afoot?

5 GHz is a Big Range of Channels. You Gotta Understand Those Channels.

So, this big world-class WLAN uses a lot of 5 GHz channels (36, 40, 44, 48, 52, 56, 60, 64, 149, 153, 157,  and 161). But take a look at that graphic again. The M5 operates in the range of 5170 to 5825 MHz, whatever that means. And did you catch the footnote?

DID YOU CATCH THE FOOTNOTE? (* Only 5725 – 5850 MHz is supported in the USA)

If you didn’t know any better, you might expect that the entire range of 802.11a and .11n is 5725-5850 MHz, and that all of the channels on the WLAN would fit in that range. This is American Wi-Fi, and that’s an American client device!

It just isn’t that simple. Looky here (5 GHz channels, Wikipedia):
5 chans

It turns out that the M5 only works in one small slice of the entire 5 GHz range that 802.11a/n/ac Wi-Fi can function in. So… those police cars were hitting lower frequency channels from the WLAN that they don’t support. A quick channel change for the parking lot APs to the few that the M5 does support, and the video was soon flowing from the cars as desired.

This Happens Often on Utility Devices- Be Aware!

I’ve seen this same scenario play out on ticket scanners in stadiums, retail scanners in warehouses, and wireless cameras that all operate in only a slice of 5 GHz. You absolutely MUST understand what radio capabilities are in play when it comes to non-mainstream devices.

These are the cases that often separate WLAN pros from those who don’t understand the important nuances that unfortunately pervade modern Wi-Fi. And that lack of understanding can lead to a lot of wasted time and money trying to fix a problem that is nothing more than poor configuration born of ignorance.

Just how complicated is the question of which individual devices can operate on what specific 5 GHz channels? Let’s ask a good guy named Mike Albano.


Getting to Know Ubiquiti’s UniFi Cloud Key

Ubiquiti is a fairly fascinating WLAN gear company. I use different Point-to-Point bridge models from Ubiquiti, including some in 900 MHz, 5 GHz, and their big ol’ 24 GHz AirFiber 24. I don’t have a real deep history with the company’s Wi-Fi access gear, but have enough hands-on time with it to understand the mass appeal of this competitively-priced WLAN product line. I’ve written about things I’ve learned about regarding Ubiquiti bridges along the way, and covered the company’s introduction of 11ac access points back in 2013 for Network Computing. I consider myself familiar with Ubiquiti enough to have my own opinions about various products and the way the company does certain things, but I am by no stretch a Ubiquiti “power user”.

I mention that because many of the Ubiquiti faithful in the company’s support forums can be a bit- shall we say – fervent in their loyalty to the company, it’s products, and it’s methodologies even when those of us outsiders with WLAN expertise call Ubiquiti into question for something or other. I’m not bashing those rabid Ubiquiti fans, but I also know that they have long since lost their objectivity on the product and tithe frequently at the Church of Ubiquiti. For me, I try to see the good and bad for what it is with each product or feature and not generically bash or praise any product line or vendor. That’s my self-characterization on objectivity, and it brings me to a handy little gadget I’m evaluating now: the Ubiquiti Cloud Key.

CLoud Key

The product glossy is here, and my own dashboard looks like this for device management:Cloud Key Manage

And system monitoring (don’t read anything into the sucky throughput values, this test environment is set up extremely crudely right now):

cloud key mon

Now, back to the Cloud Key itself. It’s an interesting device, roughly the size of an elongated Raspberry Pi. It can be accessed locally, or from the Internet if you opt to allow that. It’s an NMS that requires no server, and it does a pretty decent job of managing and monitoring the Ubiquiti UniFi environment. (This blog isn’t about individual APs or overall system performance that you should expect if you use Ubiquiti networking equipment- it’s just a quick intro to the Cloud Key as it really is a slick and curious system manager.) I’m currently managing an edge security gateway, a switch, and two APs, but the Cloud Key can certainly scale much, much larger for bigger Ubiquiti environments.

Drilling into my switch shows the types of config work done via the Cloud Key, as an example:

cloud key switch

You’d see similar for the access points and security gateway in my environment if your were to click around.

Administration of the Cloud Key itself is fairly intuitive and pretty well designed, from bringing it to life to assigning administrative roles to adding managed devices and doing upgrades.

That’s enough for now… if you’ve never seen the UniFi Cloud Key, hopefully this blog gives you some idea of what it can do. I reserve my opinions on the other Ubiquiti network pieces for future blogs as I spend more time with this eval environment. But I can say that the Cloud Key has impressed me as innovative, interesting, and effective (so far) in doing what it was built to do. With a low price and no licensing costs, it is one example of why Ubiquiti sells A LOT of wireless gear.



Ubiquiti Bridges- Discoveries and Tips

It seems like almost everywhere I go to consult with small networks that have wireless bridge links in use, I run into some model of Ubiquiti gear. My own knowledge with this tier of hardware isn’t all that deep, as I’m used to dealing higher-priced enterprise-grade stuff. That’s not to sound snobby, but more to add context- and I can say that I’m developing a real appreciation for the likes of Ubiquiti Nanostations and such. Now that I’ve inherited a number of these to verify, optimize, or fix, I’ve found a handful of discussion points worthy of sharing.

I’ve had new-to-me customers declare that their links are failing or that the last guy to touch them did something odd to them. In some cases, the bridges are so high up on a building, you have no way to read the model on them, and the customer has no idea whether he’s using 900 Mhz, 2.4 GHz, or 5 GHz. Many of these cases have come to be in their current state from either a shoestring budget, a poor choice of “network guy”, or both. Whether you’re putting in new Ubiquiti bridges or trying to tame existing deployments, here’s some guidance to help you to be successful, based on my own recent experience:

  • Use the Device Discovery Tool. Found at the bottom of the Ubiquiti downloads page, the tool can save a lot of time and frustration for figuring out what model numbers of hardware is in use, firmware version, and IP addresses. One recent use of the tool showed me this:hourigan bridges

Of course, I wasted time and energy trying to get pictures of the labels on the bridges and finding them via arp, etc before I got smart – the discovery tool is a must-have.

  • Use the Latest Firmware. The operating system on Ubiquiti brides is called airOS. Different model numbers use different “latest” releases, and if you look at the picture above, you’ll see these NanoStation M5s are all on v5.5.9. This happens to be the latest available for this model (as I write this). firmware

  • Keep a Spare Handy. For links that don’t cost much, especially when they are deployed off the beaten path, having a spare or two on hand is just good strategy. Again, using the M5 as an example, you can see a spare bridge (and proprietary 24v power injector block) doesn’t take a lot of coin to get into.amazon M5Remember to backup the configs of all of the bridges you support (found in Device pages of airOS software config pages) so bringing a spare to life can be done quickly.

  • Watch That Mast/Mounting As A Frequent Source of Headache. Ubiquiti bridges like the M5 tend to be lightweight, and are often constructed to be mounted with nothing more than tie-wraps. Though simplicity is nice, mounting these things can get you in trouble. I have found them under metal roofs, on flimsy conduit “masts” that wiggle in the breeze, and put up with no regard for Fresnel zone dimensions. This is one place where the cheap gear and the expensive stuff share commonality: they still have to mount solidly, with proper alignment, and in a way that provides appropriate radio line of sight for the frequency in use. Given that 900 MHz is popular in this space, anyone working with them needs to know the difference when it comes to Fresnel calculations for the different bands. that 8 foot pole that you can get away with for 5 GHz isn’t going to cut it for 900 MHz.

The Ubuiti bridges (excluding the AirFiber products and optional parabolic antennas) are remarkable lightweight and easy to work with. At the same time, best practices and wireless networking craftsmanship are still required for link success and minimal downtime. Don’t let “cheap” overtake your approach because of the product set you’re dealing with.

What Ubiquiti bridge tips do you have to share?

Related Post: In Defense of Little Wireless


Faster Wireless Isn’t Always Better Wireless

There- I said it! Let the trouncing commence, as I fully realize the title of this blog borders on sacrilege for those of us that do wireless for a living. But, after you curse me and Google my image to throw tomatoes at, give me a chance to explain what I mean.

Different Frequencies, Speeds For Different Applications

We of the Wi-Fi mindset have the numbers 2.4 and 5 etched upon our psyche. We know that these numbers are followed by GHz in our version of reality, and that depending on what we do with spatial streams, output power values, and antenna designs, we’ll achieve fairly standard (to us) rate-over-range permutations that more or less make up the various possibilities for connectivity that we provide to our clients. Not exactly news, right? Let’s take a quick look at some other frequencies, applications, and data rates that you might not be aware of, before I get to the point of this blog: 

  • Frequency: 76 Hz. Application: ELF Military Comms. Data Rate: a fraction of a bit per second
  • Frequency: 60 kHz. Application: Atomic Clock. Data Rate: 1 bit per second
  • Frequency: 4235kHz. Application: WeatherFax. Data Rate: 45 bits per second
  • Frequency: 144 MHz. Application: “Short-range” Amateur Radio. Data Rate: 1200 bits per second
  • Frequency: 900 MHz. Application: WLAN P-P Bridging. Data Rate: 50 Mbps+

You know the rest of the story- as we go up in frequency to the familiar 2.4 and 5 GHz ranges, we can achieve higher data rates with generally shorter distances in play. We also know that power output and antenna configs contribute to cell range capabilities, and that modulation types ultimately decide what we can do with a given channel width at a specific frequency. This is wireless 101, yes?

And us wireless types get jazzed over HIGHER speeds, not lower- this I know. But I’m here to tell you that it’s worth stepping outside of our normal for a bit and spending some time on the last bullet in the list above- 900 MHz- and what it can do for us.

What’s So Exciting About 900 MHz?

To most of us doing normal, day to day Wi-Fi, the answer is “nothing”. The lowly 900 MHz space is meaningless to the modern WLAN. But… some of us also have to do point-to-point bridging on occasion. Even here, 900 MHz is generally considered a dated technology as we put in our fast licensed and unlicensed bridges that deliver hundreds of Mbps or even Gig speeds on really neat hardware that needs line of sight to work.

Wha? What was that last part?

“… on really neat hardware that needs line of sight to work.”

So what happens if you can’t get line of site? If you didn’t know better, you might just say “I cannot do this link, for I don’t have line of sight! Everyone knows ya gotta have line of site! I can’t do this!” But not all bridge links NEED blistering throughput and “carrier-grade” expensive hardware. There is some handy gear out there available for 900 MHz bridge links that can overcome many LOS challenges you’re likely to hit, and still provide a few dozen Mbps of throughput. Depending on your creativity and skills, you can also use of couple links in parallel to double your fun. 900 MHz will go through trees, small buildings, and can feel like magic compared to the more strict LOS-dependent characteristics of the higher frequencies.

Ubiquiti gear is among the more popular in this space, and this is the sort of use case that gets people excited. They don’t need gobs of throughput, but do need to get through obstacles.

Read a few of these testimonials (there is almost a cult following of sorts to some Ubiquiti hardware) and you can get the sense why 900 MHz is popular in agricultural settings, where there is distance to cover, trees and terrain changes are a fact of life, and where moderate throughput is better than no throughput when you want to link things up. I recently learned of a farm-specific hardware line from Ayrstone that includes infrastructure and in-vehicle components in what amounts to a really fascinating product set (yes, it based on Ubiquiti, but with proprietary firmware.) Ubiquiti isn’t the only player in 900 MHz kit, but they seem to be the most visible.

Your 900 MHz Mileage May Vary (and so might your noise floor)

Out in the boonies, 900 MHz has a fighting chance as a bridge solution given the lack of people who might have competing devices. Get near a population center, and things get more worrisome for 900 MHz hardware. There are lots of cordless telephones that use 900 MHz, and in the Amateur Radio world, 900 MHz is also known as the licensed 33cm band. Here you’ll find a mix of activities from voice to data and FM to sideband, and hams usually get to use a lot more power than unlicensed network equipment. There may be pagers and other unlicensed 900 MHz gadgets afoot as well.

If you need non-LOS bridging and don’t have contention for the spectrum from nearby devices, 900 MHz might be the slower-speed solution that works when the stuff that you’d rather use wont.

Nothing Magic About Gartner’s Quadrant When It Comes To Wi-Fi

I just digested the latest “Magic Quadrant for the Wired and Wireless LAN Access Infrastructure”, and I have a feeling I’m not the only WLAN professional or analyst that finds significant fault with what this once-decent “evaluation” has become.

Where to start with this train wreck? Maybe a little background is in order. Through 2011, Gartner dedicated a Magic Quadrant report to WLAN only, and one to Enterprise LAN. That changed in 2012, when they moved to  “Magic Quadrant for the Wired and Wireless LAN Access Infrastructure” format. And here’s where the problem starts. This thing doesn’t know what it wants to be… is it enterprise-oriented? Is it supposed to somehow capture the spirit of unified access? Is there supposed to be a decent analysis of the WLAN industry in here? I really can’t tell as it’s named and delivered. Despite Gartner’s overview of criteria up front in the report, it just feels bizarre when you dig into it.

You’ll notice this is not named the “Magic Quadrant for Unified Access”, which might more justify the “if you don’t have your own LAN switches, you can piss off as a WLAN vendor” reasoning that is in play here. But with a title like Wired and Wireless LAN Access, I’d expect to see companies that do LAN, WLAN, and both.  But since 2012, if a vendor doesn’t have switches AND a WLAN solution, then there’s No Soup For You. Forget that vendors OEM each others stuff, and that a company might be best of breed at either WLAN or LAN and mediocre at the other- you gotta have both to come to this weird party. Which leaves out some important players in the WLAN industry, like:

  • Ruckus Wireless – who happens to be rolling out one new municipal Wi-Fi deployment after another, doing many stadium deployments, and is visible all over my immediate area as viewed through the rogue detection on my own WLAN NMS
  • Meru Networks – who not so long was #3 in a market that was fairly defined as consisting of Cisco, Aruba, and Meru when it came to enterprise WLAN. Lately Meru is making noise in the SDN space, but more on that in a minute
  • AirTight Networks – An interesting newcomer to the WLAN access market (made the jump from WIPS-only), with growing market share and has been connected to some of the brightest technical minds in the industry (Akin, von Nagy)
  • Ubiquiti – like ’em or hate ’em, they are selling in volume, and are as viable of a Wi-Fi option as other players that made it into the Quadrant
  • Meraki – yes, Meraki is listed under Cisco, but even that is wonky in this context, as Meraki and Cisco have fundamentally different paradigms

Flash forward (clever plot device): D-Link made the quadrant, while Ruckus did not. 

Now let’s pick apart what is in the report a bit. Where vendors have “end to end” offerings that Gartner seems to harp on for this exercise, some of them are almost irrelevant because they aren’t “seen” the same way by those shopping for a solution. Adtran has a “complete” solution cobbled together from Adtran switches and Bluesocket Wi-Fi (purchased a few years back). Yet they are a niche player in the Wi-Fi world. Adtran made the quadrant, but Ruckus did not.

Aruba is a top-shelf, WLAN-centric market Force To Be Reckoned With.  They absolutely belong where they landed in the Leaders rankings. But Aruba is rebadged by Dell and Alcatel-Lucent. So Dell is “allowed” to combine their own switches with rebadged Aruba hardware to get into the quadrant… meanwhile, Dell made the quadrant but Ruckus did not.

The treatment of Cisco is pretty weird here, but that may be more Cisco’s problem (to a point) than Gartner’s. Though Meraki WLAN and Cisco WLAN are both technically Cisco WLAN, Meraki WLAN is worlds apart in functionality and approach from Cisco WLAN (I know, because I use them both). Gartner attempts to explain this, but when a product set like Meraki is reduced to being a bullet item under the Cisco heading, there’s something lacking in the analysis and delivery.

Uh… Huawei? Really? Guess what- Huawei made the quadrant but Ruckus did not.

For D-Link, I know pitting them against market leaders is unfair. I have no ill-will against D-Link, and frequently recommend D-Link products for the SMB/residential spaces. But Gartner’s own “cautions” outweigh the listed “strengths”, and the report stresses that D-Link lacks an enterprise reputation, and is a brand that “seldom comes up in conversations with Gartner clients”. But I bet of few of those clients ask about Ruckus on occasion.

Now that the SDN tide is rising (albeit not as fast as the media hype that goes along with it), the notion of “everything from one vendor” starts to be less important. Meru Networks, who I’ll remind you also did not make the quadrant, gets that. Fast forward down the SDN timeline, and the fact that a single vendor has switches and access points both becomes more irrelevant when it comes to what happens on SDN-enabled networks. Sure, you still need to manage the underneath networking, but many “single pane of glass” NMS are so poor at either WLAN or LAN that you’re frequently better off with one for each.

Finally, it’s my conjecture that Gartner is out of touch with who the WLAN industry itself sees as worth comparing. Each of these views shows head-to-head comparisons of various sorts by different vendors or IT experts (click picture for source doc):




I can’t remember the last time I saw a bake-off between Cisco, D-Link, and Huawei. Can you?

So how do you fix the Flawed Quadrant?

I’d urge Gartner to consider any and all of these:

  • Bring back a WLAN-specific quadrant
  • The market is so striated, show some effective creativity. Quadrants for MSP-suitable wireless, cloud-enabled wireless, true enterprise WLAN and other tiers
  • Stick to single lines (break out Cisco from Meraki)
  • Do a “Rebadgers Quadrant”

Just shooting from the hip with these, but the point is that the current Quadrant is a defective vehicle, and I think anyone who drives it is getting ripped off.

Today, On The Ubiquiti Show…

Today I learned that a freakishly rich dude runs Ubiquiti, and hats’ off to Mr. Robert Pera for the success of his company. I also caught the interesting mention of Ubiquiti as part of Motorola’s bombshell today- the one about Moto wanting to exit the WLAN business stage left:

“It’s a tough market. It’s being squeezed from the top by Cisco and from the bottom by Ubiquiti,”
-Anonymous Quotee

That Ubiquiti is declared a book-end that is squeezing the market from one end while giant Cisco works the other is fairly flattering to a WLAN company that many industry folks consider “not quite Enterprise grade”. Personally, I kind of like Ubiquiti’s approach and recognize the attractiveness of their price point as an occasional Ubiquiti customer and admin. ( I also recently chuckled out loud at the slick Golden AP campaign.) My own main beef is Ubiquiti’s all-over-the-place PoE strategy– it’s just maddening at times to guess which goofy little brick goes with which radio unit.

Now, Ubiquiti is in the router business, too, and is embarking on an interesting campaign to help network the rural parts of the US (and the world) that are minus broadband, with it’s Ubiquiti World Network. It’s a noble goal, and we’ll see how it plays out. Here’s the FAQ’s, ma’am.

I do know that price very much counts in depressed markets, having personally done networking in the poorest country in the western hemisphere, and price is one area where Ubiquiti shines.

I also know that I’m not the the only one who can’t quite figure Ubiquiti out, as they don’t tend to be part of mainstream WLAN market discussions. Yet Mr. Pera’s baby seems to be gaining traction in a competitive space that is about to shed a big name like Motorola… Ubiquiti will certainly stay interesting to watch, at least for a while.