What makes for good dedicated access points?

Discussion in 'Tomato Firmware' started by Madumi, Feb 12, 2018.

  1. Madumi

    Madumi Serious Server Member

    OK, this is indeed a general question (not a "please tell me which router to buy" question).

    Moving from network to network, I tend to notice different degrees/levels of service at the "handshake" point of joining the network. In the past, I have put most of this behavior down to the DHCP server IP provisioning/CPU speed etc in the gateway router, but I'm curious... where do "excellent" access points excel?

    Eg. if I were to run Tomato on a sufficiently fast router for DHCP/routing, what gains (beside signal strength) would enterprise access points provide (eg. ubiquti/mikrotik/engenius/cisco)?

    much appreciated!
    Last edited: Feb 12, 2018
  2. eibgrad

    eibgrad Network Guru Member

  3. Monk E. Boy

    Monk E. Boy Network Guru Member

    802.11r is kind of not implemented, since you have to configure both clients & access points. Even Ubiquiti's fast roaming feature is being depreciated. The KRACK exploit was the last nail in 802.11r's coffin, even sites which had implemented it have backpedaled away.

    What places are doing though is a centralized controller which monitors which access points can see which clients and make APs disconnect clients who have latched onto it for too long. With Ubiquiti you need a cloud key to basically upload information about your clients and access points to Ubiquiti's servers which then do the heavy thinking about which clients need to be where and then inform the cloud key to actually do the work. Roaming isn't as instantaneous as it is with 802.11r or fast roaming but it is quick enough to cause little more than minor problems unless you've absolutely got to watch that episode of Macgyver and can't stand still to do it. It can cause a pause in some forms of streaming video, depending on how much data they buffer and where you're at in the buffer when the disassociation comes, but it'll pick right up again once the connection resumes.

    There is no centralized controller for Tomato, so clients try to maintain a death grip on APs long after they've exceeded their usefulness. Depending on how hard it is for you to turn WiFi off and on after you walk from one end of your house to the other this is either a bad thing or not.
    Madumi and eibgrad like this.
  4. Madumi

    Madumi Serious Server Member

    Thanks so much for replies... much appreciated info about roaming AP to AP.

    I'm curious about the Ubiquiti setup... I guess I understand them using the cloud for tracking devices over large scale networks, but it would seem easier/faster to use a LAN attached device (eg gateway router) to track this, no?

    Fast roaming seemed to be one of the often-talked-about features that set Ubiquiti AP's apart from Mikrotik, so that's an interesting development...

    Setting aside roaming AP to AP, are there other features that set apart good access points from excellent ones?
  5. Monk E. Boy

    Monk E. Boy Network Guru Member

    Ubiquiti is still supporting the fast roaming feature, but there are issues with it that apparently aren't being resolved and those people have said that the feature is planned on being phased out in the future - however the official word from UBNT is they're offering full support for it... I don't know if you've looked into it but the routers seamlessly roam clients by all using the same channel and MAC address which just seems so horribly wrong to me. Every device's MAC should be unique, dagnabbit. Being on the same channel means you have to minimize collisions by minimizing the number of routers, which makes having a solid and accurate site survey very important, which is hard to do for the average home (or even business) user.
  6. eibgrad

    eibgrad Network Guru Member

    Translation, it's all proprietary. Make of that what you will.
  7. Madumi

    Madumi Serious Server Member

    If it's helpful, the article eibgrad posted from ubnt indicates that zero hand-off (the ubnt roaming iteration that existed before fast roaming) used the same AP channel between AP's, and suffered congestion issues competing for airtime on this single channel. Although it doesn't say it explicitly, it implies that fast roaming uses multiple channels... Not sure about MAC addresses though.

    So... my understanding so far of enterprise AP roaming options is something like this:
    Ubiquiti: Fast Roaming
    Mikrotik: Use signal strength to kick routers off an AP, so client will scan for new AP
    Engenius: Use signal strength to kick routers off an AP, so client will scan for new AP
    Cisco/Meraki: 802.11r/PMKsa chaching/OKC enabled by default (roaming technologies)

    The 802.11r/Fast Roaming technology seems to provide the most seamless approach to roaming (Ubiquiti/Meraki). I don't have huge experience with Ubiquiti, but it seems harder to embed your own custom scripts (regrettably) & I'm assuming Meraki would be similar...

    Any other solutions I can look at, or corrections to this?
  8. Monk E. Boy

    Monk E. Boy Network Guru Member

    I know UBNT routers are Linux based, but they use MIPS CPUs, so CPU-based functions aren't particularly powerful (nominally better than Tomato since their MIPS are usually faster and dual core). Most of the router configuration is done through its own configuration language, which the website can build for you for simple things, but it's kind of an odd language that I've never come to terms with. The APs I haven't touched, but if you're using the cloud key then it's all website driven, similar to Meraki. I got to see Guardians of the Galaxy thanks to a Meraki event, none of the salespeople understood the credits stuff and kept getting interrupted by the movie. Nice stuff, but my employers just laughed at their prices.
    Madumi likes this.
  9. koitsu

    koitsu Network Guru Member

    Since we're talking about Ubiquiti devices and what CPUs etc. they use, here is what the UniFi UAP-AC-LITE uses. The 802.11 chips (for both 2.4GHz and 5GHz) are Atheros-based (2.4GHz is QCA9563, 5GHz is QCA988x), Ethernet NIC is Atheros AG71xx, Ethernet PHY is an Atheros 8033. 128MBytes RAM. Linux 3.3.8. Busybox 1.19.4, with a lot of common-use utilities removed.

    [    0.000000] Linux version 3.3.8 (builder@owrt1209-uap-qca956x) (gcc version 4.6.3 20120201 (prerelease) (Linaro GCC 4.6-2012.02) ) #1 Thu Jan 4 15:26:08 MST 2018
    [    0.000000] CPU revision is: 00019750 (MIPS 74Kc)
    [    0.000000] SoC: Qualcomm Atheros QCA956X rev 0
    [    0.000000] Clocks: CPU:775.000MHz, DDR:650.000MHz, AHB:258.333MHz, Ref:25.000MHz
    Linux UniFiAP 3.3.8 #1 Thu Jan 4 15:26:08 MST 2018 mips GNU/Linux
    system type             : Qualcomm Atheros QCA956X rev 0
    machine                 : Ubiquiti Networks Inc. (c) 2016
    processor               : 0
    cpu model               : MIPS 74Kc V5.0
    BogoMIPS                : 385.84
    wait instruction        : yes
    microsecond timers      : yes
    tlb_entries             : 32
    extra interrupt vector  : yes
    hardware watchpoint     : yes, count: 4, address/irw mask: [0x0000, 0x0ffc, 0x0ffb, 0x0ffb]
    ASEs implemented        : mips16 dsp
    shadow register sets    : 1
    kscratch registers      : 0
    core                    : 0
    VCED exceptions         : not available
    VCEI exceptions         : not available
    The UAC-AP-LITE is extremely stable, and wireless is quite reliable; it's resilient even in environments where there is a high amount of noise (from both other APs and unknown devices), such as where I reside (RF scan on 2.4GHz shows over 150 APs, and a large amount of interference from non-APs). Throughput is extremely high -- I believe I hit 600mbit/sec via 5GHz at one point -- despite it being a single-core 32-bit MIPS CPU. There must be a lot of very good hardware offloading for it to perform this well, and that deserves commendation.

    In short, it's a hell of a lot better as a WiFi AP than, say, an RT-AC56U / RT-AC56R, at least in my experience + in my region, especially considering the price.

    I only found two negatives:

    1. To access the AP, you need to run a Java-based application (referred to as their "UniFi Controller") on a desktop somewhere. The Controller requires JRE 8 and as of this writing, will not work with JRE 9. Once the Controller software is running, there's a button to launch a web browser at https://localhost:8443/ which of course requires exceptions be added to the browser due to invalid certificate name matching (will people ever realise that HTTPS everywhere is a stupid idea, case in point? :-( ). The Controller app, on my system, takes up about 570MBytes of RAM (you read that correctly). However, it doesn't auto-launch or act invasive in any way (i.e. when you exit it, it does in fact exit). App looks like this on W7 64-bit SP1: https://imgur.com/a/FTrBA -- everything else is in-browser and fairly well designed (I have found a couple general UI oddities, but nothing seriously annoying or broken/buggy).

    2. If you are sensitive to high-pitch electronic noise, during high throughput scenarios you may hear subtle electronic noise coming from the unit (not the external AC/transformer, but the actual AP itself). During normal throughput or common-use cases the unit is silent. General solution is just to place the AP in a location where it's not within 4-5 feet of a person, or behind some simple sheetrock or wood. This is common with a lot of today's hardware (desktop/server CPUs behave similarly), so it's not a problem unique to Ubiquiti devices, but it is something I noticed.

    Edit: fixing some of the Qualcomm device IDs/product strings. Sorry about that!
    Last edited: Feb 17, 2018
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice