[Rack] ubiquiti wifi routers

Ben Kochie ben at nerp.net
Wed Aug 6 19:08:13 UTC 2014


We have our setup such that internal users ssid is on 5ghz, and our guest is 2.4ghz.  Since our users are 95% Mac, and 5% thinkpad, this works well.  We also do not allow mobile devices on the internal ssid.

On August 6, 2014 8:09:33 PM CEST, Rubin Abdi <rubin at starset.net> wrote:
>The UAP/UAP-PRO aren't routers for what it's worth. They're only a wifi
>radio hooked up to an ethernet port, nothing more. You'll still need
>something on the network to providing routing to the internet.
>
>Their proprietary zero handoff works really great if you've running
>less
>than 5 clients. I'm guessing the use case is something like inventory
>laptops walking through a very large warehouse. With anything more than
>5 clients the thing is total garbage and shouldn't be used.
>
>As far as non proprietary client side roaming goes, in practice I've
>found most Apple devices, many Androids, and my Linux laptop running
>wpasupplicant 1.1 with an Intel wifi NIC, roaming fine. All devices are
>happy to hop from AP to AP without much fuss or user intervention after
>a minute or two of realizing it has less noise from another AP.
>
>2.4/5gHz is a different story. In my humble opinion 2.4gHz coming off
>of
>these devices is fucking good. I am now only recommending the
>costs-4-times-more UAP-PROs only if what you need is massive bandwidth
>beyond everyday internet access which you can get with 5gHz (and by
>bandwidth I mean 100mbit and beyond). 2.4gHz alone is sufficient (with
>the appropriate amount of radios in the space) for most use cases such
>as fast internet browsing, and also way more affordable. I honestly
>believe Noisebridge could get away with 3 2.4gHz UAPs installed for
>about $160 than two UAP-PROs at $400.
>
>The RSSI stuff is a nice option but it's still too finicky of a setting
>for any sort of production use (requires a lot of testing and hand
>holding), and the whole system right now works pretty well as is just
>as
>long as your client isn't being super stupid.
>
>There is also the annoyance of choosing a channel. Placing the choice
>on
>users to pick what's best kinda sucks in reality, so I've started doing
>this...
>
>sitename - Attached to both 2.4 and 5gHz radios
>sitename 5g - Attached to 5gHz radio only
>
>Most users will connect to the first network as they will either not
>see
>5g or honestly wont know what that means and not bother. If their
>hardware only support 2.4gHz they'll connect to that. If both are
>supported, the device will (hopefully) make the best decision on which
>to initially connect to (almost always 2.4gHz first) then roam when it
>feels like a different radio is a better choice. Apple hardware is
>really good at this, my test Androids are so/so, wpasupplicant fucking
>sucks and would much rather connect to a horse's ass before ever even
>thinking of connecting to a better link.
>
>With all that being said, when using a $60 UAP, 5gHz is really over
>rated and not worth the money and hassle if all you're just going to
>provide is speedy net access. In all honesty you should be able to
>connect 50-60 clients to each radio without much noticeable degradation
>in wifi performance. I believe 100-120 clients per radio is where they
>start to actually crap out.
>
>And for what it's worth, running the controller 24/7 doesn't actually
>effect performance or load balancing or anything like that. All the
>controller is good for is configuring and monitoring. The access points
>are more than happy to talk to each other and help each other when
>needed, but that too is fairly minimal. I also recommend running the
>controller not in the space but somewhere else on the internet. It has
>proven helpful in aiding friends with network woes remotely.
>
>-- 
>Rubin
>rubin at starset.net

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.noisebridge.net/pipermail/rack/attachments/20140806/1aca885f/attachment-0003.html>


More information about the Rack mailing list