Tag, You’re It!

Cover Image: Unmasked (detail), (Brian Wall, 2014)

Just this past week, Ekahau released the latest iteration of their excellent wireless network planning software, and with this version, they’ve added a few features that many of us have been wanting for quite some time. Of course, we always want more, and there’s only so much the elves at Ekahau can do! So this leaves us with building our own tools to extract the data we need out of the project file. (Hey, Ekahau, you know what would be really awesome? an SDK for doing this!)

Fortunately, Ekahau has been really good about building a standards-based project file format (and not encrypting it or doing things that make it a pain to use your own data). Since the Ekahau software is built in Java (cross platform on Windows/Mac!), it’s logical for the data file to be in something like XML or JSON, and they have chosen the latter, and have effectively built a relational database in JSON, and bundled the whole thing up into a convenient zip file. It’s almost like they understand that their core market is made up almost entirely of customers who like to tinker with things.

Disclaimers:

Naturally, manipulating this file is something to be done entirely at your own risk, and if you break it, don’t go crying to Ekahau, because they don’t support mucking with their data file outside of their application (nor should they be expected to!) Make sure you have backups, etc, etc.

Also, this post is in no way based on any inside information from Ekahau, nor is it anything official from them – this is simply an analysis of the contents of the project file that anyone could do, whose nature as a zipped file full of JSON has been known for quite some time.

“I’m gonna get some tags… This is f’ing awesome”

Probably the coolest new feature in v 10.2 is the ability to add key:value tags to stuff. You can apply these tags to APs, either just the tag by itself, or a tag with a value associated with it. The Quick Select also lets you select any APs that have a particular tag key (although somehow they missed the ability to refine based on tag value, which I hope will be corrected in the near future).

Why is this useful? This allows you to add free-form information to access points, whether simulated or measured, that allows Ekahau to be more than just an RF simulation tool, and extends it into a full blown planning and deployment tool. Tagged information can be any kind of metadata you wish. things like:

  • Mounting hardware
  • Wired MAC address
  • AP Group
  • Serial Number
  • Zone
  • Switch
  • Port
  • Cable
  • IDF
  • … and the list is nearly endless.

This is in addition to the already rich metadata that is associated with the AP that are directly relevant to the RF modeling, such as mounting height, mounting surface, antenna angles, power, channel, antenna types, and so forth.

So how does it work? Pretty simple: on an AP, simply open the sushi menu at the top right, select “Tag AP”. You can also do this from the Edit AP or bulk edit screen when doing multiple APs. This will give you a list of existing tag keys already associated with the project (as well as tags you’ve used before on other projects), along with a free form box to enter your own, or add a value.

As of right now, there’s not a whole lot you can do within the Ekahau software once you have those tags (I would LOVE a table view of my APs and all the metadata, as well as ability to import/export to CSV or Excel), nor is template-based reporting on those tags documented at this point (although I expect they’re working diligently to document this). One key weakness of the template reporting system is that it all has to go through Microsoft Word (with a whole bunch of limitations imposed by that format), and that gets really hairy once you start creating data tables, especially if you want them in Excel or something else.

Side note: Using Excel as a database is really a terrible use of a spreadsheet, but it happens all. the. time.

Which brings me to manipulating/extracting your data by building your own tools. Several people have been doing this unofficially for years, but Ekahau doesn’t offer anything for this… yet.

I mentioned earlier that Ekahau’s data is stored mostly in JSON, which makes it really easy to work with using Python (or, for that matter, Java or perl if you’re into self-flagellation). Every object in the data file has an ID that ties it back to other objects. And that’s the key thing (literally). There are about 2 dozen separate files that track various data, and that’s how they all tie together. Notes and tag keys are each kept in their own file, while the AP data file has a data object that contains a list of the note IDs, and another that keeps a list of tag IDs and the value associated with that tag:

accessPoints.json:

{
   "accessPoints": [
     {
       "location": {
         "floorPlanId": "b799747a-e2ed-49ad-8c5e-c9ea8c36fa61",
         "coord": {
           "x": 2475.397796817626,
           "y": 1537.8008975928194
         }
       },
       "name": "Simulated AP-1",
       "mine": true,
       "userDefinedPosition": false,
       "noteIds": [
         "37faa8ef-c5c8-4d9d-a882-916db175b935",
         "663419b4-ddb4-4ddb-b3f2-d50233743c5c"
       ],
       "vendor": "Aruba",
       "model": "AP-515",
       "tags": [
         {
           "tagKeyId": "59650f76-3e4b-4c40-b78b-2d0088f5b227",
           "value": "123456789"
         },
         {
           "tagKeyId": "5c9cb127-8ba2-4a60-84e5-75f47ce87f99",
           "value": "C-Suite"
         },
         {
           "tagKeyId": "991b12b7-dbb0-47de-9cd2-260ee064b3e3",
           "value": "aa:bb:cc:dd:ee:ff"
         }
       ],
       "id": "a0b90f2a-8b1b-4339-8362-dc51122931ed",
       "status": "CREATED"
     }
   ]
 }

tagKeys.json:

{
  "tagKeys": [
    {
      "key": "Serial",
      "id": "59650f76-3e4b-4c40-b78b-2d0088f5b227",
      "status": "CREATED"
    },
    {
      "key": "AP Group",
      "id": "5c9cb127-8ba2-4a60-84e5-75f47ce87f99",
      "status": "CREATED"
    },
    {
      "key": "MAC",
      "id": "991b12b7-dbb0-47de-9cd2-260ee064b3e3",
      "status": "CREATED"
    }
  ]
}

notes.json:

{
  "notes": [
    {
      "text": "This is another test note",
      "history": {
        "createdAt": "2020-06-08T16:25:11.868Z",
        "createdBy": "Ian Beyer"
      },
      "imageIds": [],
      "id": "663419b4-ddb4-4ddb-b3f2-d50233743c5c",
      "status": "CREATED"
    },
    {
      "text": "This is a test note",
      "history": {
        "createdAt": "2020-06-08T16:25:04.883Z",
        "createdBy": "Ian Beyer"
      },
      "imageIds": [],
      "id": "37faa8ef-c5c8-4d9d-a882-916db175b935",
      "status": "CREATED"
    }
  ]
}

simulatedRadios.json:

{
  "simulatedRadios": [
    {
      "accessPointId": "a0b90f2a-8b1b-4339-8362-dc51122931ed",
      "accessPointIndex": 2,
      "transmitPower": 0.0,
      "antennaTypeId": "bdf0702a-42be-456a-8891-4cf54940a5c2",
      "antennaDirection": 0.0,
      "antennaTilt": 0.0,
      "antennaHeight": 2.4,
      "antennaMounting": "CEILING",
      "radioTechnology": "BLUETOOTH",
      "spatialStreamCount": 1,
      "shortGuardInterval": false,
      "defaultAntennas": [
        {
          "radioTechnology": "BLUETOOTH",
          "frequencyBand": "TWO",
          "antennaTypeId": "bdf0702a-42be-456a-8891-4cf54940a5c2"
        }
      ],
      "enabled": true,
      "id": "c4f3c521-873c-40de-8076-b1f02b655993",
      "status": "CREATED"
    },
    {
      "accessPointId": "a0b90f2a-8b1b-4339-8362-dc51122931ed",
      "accessPointIndex": 0,
      "transmitPower": 8.000293592441343,
      "channel": [
        1
      ],
      "antennaTypeId": "785280d6-168c-4eab-9819-88e6010e2bef",
      "antennaDirection": 0.0,
      "antennaTilt": 0.0,
      "antennaHeight": 2.4,
      "antennaMounting": "CEILING",
      "technology": "AX",
      "radioTechnology": "IEEE802_11",
      "spatialStreamCount": 2,
      "shortGuardInterval": true,
      "greenfield": false,
      "defaultAntennas": [
        {
          "radioTechnology": "IEEE802_11",
          "frequencyBand": "TWO",
          "antennaTypeId": "785280d6-168c-4eab-9819-88e6010e2bef"
        },
        {
          "radioTechnology": "IEEE802_11",
          "frequencyBand": "FIVE",
          "antennaTypeId": "4ef1637e-06e5-415a-96fd-a97a82273242"
        }
      ],
      "enabled": true,
      "id": "bb7304d1-d564-4018-aa92-e6ca52cba37b",
      "status": "CREATED"
    },
    {
      "accessPointId": "a0b90f2a-8b1b-4339-8362-dc51122931ed",
      "accessPointIndex": 1,
      "transmitPower": 13.979400086720377,
      "channel": [
        36
      ],
      "antennaTypeId": "4ef1637e-06e5-415a-96fd-a97a82273242",
      "antennaDirection": 0.0,
      "antennaTilt": 0.0,
      "antennaHeight": 2.4,
      "antennaMounting": "CEILING",
      "technology": "AX",
      "radioTechnology": "IEEE802_11",
      "spatialStreamCount": 4,
      "shortGuardInterval": true,
      "greenfield": false,
      "defaultAntennas": [
        {
          "radioTechnology": "IEEE802_11",
          "frequencyBand": "TWO",
          "antennaTypeId": "785280d6-168c-4eab-9819-88e6010e2bef"
        },
        {
          "radioTechnology": "IEEE802_11",
          "frequencyBand": "FIVE",
          "antennaTypeId": "4ef1637e-06e5-415a-96fd-a97a82273242"
        }
      ],
      "enabled": true,
      "id": "4ab4a7e1-708d-4f18-b33e-d8891a808e9f",
      "status": "CREATED"
    }
  ]
}

One thing you can do with simulatedRadios.json is go through and adjust your antenna orientations to the nearest 5 or 15 degree increments – having decimal granularity in the antenna orientation isn’t really useful unless you’re doing some very long point to point shots, and it will make the maps look cleaner when your antenna is at 90° instead of 88.6367879° because you manually rotated it by dragging it with the mouse.

I’m also going to omit the antennaTypes.json here, but it’s worth noting that if you have any custom APs/Antennas in your Ekahau setup, that data is included in your project file for portability, and you don’t need that custom config replicated on the next machine that opens up this file, and aren’t limited to the APs and antennas that Ekahau offers by default (although it would be really nice if they made it easy to add custom APs/antennas that survived a code update)

So here’s the basic process to report on your tags and notes:

  1. bring in the list of access points from accessPoints.json. This will get you a list of notes, as well as the tag key IDs, along with that tag’s values.
  2. You’ll need to then cross-reference the tag key IDs from tagKeys.json to get the key values (this approach seems a little convoluted at first, but ensures that a key value can be consistent from one file to the next based on not merely the text in the key value, which will come in to play when merging multiple data files into one. Ekahau was very smart about designing it this way.)
  3. Extract any notes from notes.json.
  4. Cross-reference any additional radio-specific data you need (including orientation) by looking for the access point ID in simulatedRadios.json
  5. Cross-reference any antenna pattern data by looking for the access point ID in antennaTypes.json.
  6. information such as floor number lurks in buildingFloors.json and buildings.json.
  7. and so forth.

Hopefully you’re starting to get the general idea of how this data is put together. It should be a fairly straightforward matter of running a little code against the data file and being able to generate not only a drop list for your installation contractor, but also a big chunk of your configuration script for deploying against your wireless controller. If you’re feeling especially adventurous and saucy, you can even use your wireless system’s API for this and be able to orchestrate a large chunk of your configuration from within Ekahau.

Once I build some actual code, I’ll be sure to share it here.

Here is the big gnarly mind map of the Ekahau data file. It’s probably still very much incomplete and I don’t promise 100% accuracy of data types, but it gives a good visual reference of how the whole thing goes together:

Resolution got smashed by WordPress, so you can check out the full resolution version, or a PDF version.

Working From Home: Home Network

Continuing the series about working from home, today I’m going to talk about the network inside your home, after it gets to your side of the router.

I posted some time ago about solving home wifi woes, so you can read that piece if you’re just trying to fix Wi-Fi weirdness.

In the previous post about internet access, I talked about the router being the gateway between your home network and the rest of the internet. For many home users, your modem, your router, ethernet switch, and your Wi-Fi access point are all stuffed into the same box, which can lead to some confusion when troubleshooting. It also means that if one of those components fails, you likely need to replace the whole thing, which can be a pain. So I’m going to talk about the various components, but just remember that they can sometimes be separate, or sometimes all in that one box we call “router”.

Network Switches

The network switch is the first stop after the router. The switch is what allows you to connect multiple Ethernet devices together. This forms the basis for your entire home network, known as a Local Area Network, or LAN. If you need more ports (not uncommon, since most all-in-one router devices usually only have 4 ports), you can attach a network switch to another. I won’t get into the gory technical details, but this is what allows you to split your network connection among multiple devices. For some homes, 4 ports is enough. For others (such as my own, where I have seven switches comprising nearly a hundred ports), you need to add switches to connect everything.

As a general rule, if a networked device in your house doesn’t move (or is bolted to the structure of the house), you should connect it via a wire, even if it’s capable of wireless. This includes things like TVs, printers, desktop computers, gaming consoles, and so on. A wired network connection will always be more secure and perform better than wireless. If you are a gamer, the reduced latency (“ping”) of a wired connection is something you desperately seek.

Many switches (mostly enterprise grade, but there are growing numbers of small business and home office switches) can also provide DC power over the Ethernet connection – this is known as PoE (and it is spelled out, not pronounced as in “Edgar Allan”), and allows you to power a variety of network devices such as access points and IP phones from a single physical connection. If you have your PoE power source equipment (switch) on a UPS, it can keep all the devices on the network running during a power outage. PoE comes in 3 basic flavors: 15 Watts (802.3af/PoE), 30 Watts (802.3at/PoE+), and most recently, 60 Watts (802.3bt/UPoE). Most devices you’ll encounter at home are perfectly happy to use the 15W variety.

A quick note about network patch cables: Don’t buy into the “Cat 7” marketing hype. This standard doesn’t even exist in the IT world because it doesn’t add any benefit to Ethernet connections. Unless you’re a huge nerd like me, the most you’re ever going to use on your home network is going to be 1 gigabit, which only requires Cat 5e cabling. Buying a more expensive Cat 6, 6a, or 7 cable isn’t going to make your network run any faster (and be very wary of all advice from anyone who tells you otherwise, because they’re about to sell you a whole bunch of crap you don’t need. Cat6 is the norm these days, so it’s probably the cheapest and most common. It will also run 10 gigabit connections within the distances presented in most residential environments. In any case, you’re never going to need 10 gig at home. Not even if you’re a big nerd. See my post about cabling categories for more details.

Wireless

Your Wi-Fi is simply an extension of your home network (LAN) without wires. The device that provides the Wi-Fi signal is called an Access Point, or AP. (Some people still call it a “WAP” for Wireless AP, but that’s not really helpful, because the W could also mean “Wired”). Even inside your residential gateway/router, the access point is a separate piece of hardware that connects internally to the built-in network switch.

The major downside to having an all-in-one gateway device is that what is optimal placement for the gateway (usually where the ISP installer could get a wire through the wall with a minimum amount of effort and damage) is rarely the best place to put an access point. Access points should be centrally located, and the ISP/Cable tech usually likes to be on an outside wall. When you put your wireless there, you’re sending half your signal outside and into your neighbor’s house, especially if you have it turned up to full power to hit the other end of the house.

A recent development in residential Wi-Fi is the rise of “Mesh” devices. This is basically a system of multiple access points which are centrally managed as one system, which allows you to extend wireless throughout your house. “Mesh” refers to those access points themselves connecting to the network wirelessly, rather than using an ethernet connection. Remember what I said earlier about wiring in devices that don’t move? This applies to access points as well. If an access point has to connect wirelessly to your network, it’s going to suffer from all the same wireless problems as any other device. Wire it in unless you have no other option. It’s going to perform a LOT better that way. And, as I mentioned earlier, you may be able to centrally power the access point with PoE.

IoT

As we get more connected, we have more and more smart devices at home. These are collectively referred to as the “Internet of Things”, or IoT. It’s a broad category that includes everything from connected thermostats to smart appliances, wearables such as smart watches, and so on. This is more of a side note to the Work From Home discussion, as IoT is one of those things that potentially impacts a network, but is largely tangential. There’s a saying that “The S in IoT stands for Security”. You’re already saying to yourself, “but there’s no S in IoT!” That’s precisely the point. IoT devices can pose a major security threat on your home network because most of them were not designed with network security in mind. Bottom Line: Isolate them from everything else as much as you can.

Summary/tl;dr

This was just a quick review of your home network components and how they interact, even if they’re all inside the same box. As usual, comments and questions below!

Another cool use of the WLANpi

Recently, the nice people that employ me to be a wireless network engineer for them were kind enough to add a WLANpi to my toolkit (as well as that of several of my co-workers), and it is indeed a very handy gizmo for network engineering work.

The other day, I found yet another useful trick I could do with it: Software repository. Sounds basic, because it is. But useful nonetheless. Necessity is the mother of invention, after all.

The WLANpi, with a little customization

The situation was that I needed to update AirWave on a customer server, and the WLAN management network at this site is isolated from the rest of the world (and even if it wasn’t, a satellite connection is not a fun thing to download a couple of gigabytes over!) Fortunately I came prepared for this and while I was at home on my gigabit fiber connection, I downloaded a whole host of software images I might need and stored them on my laptop.

AirWave’s heavily locked down CLI does give you the option of uploading a file, but it does it in a strange way that is in fact initiating an SCP download from somewhere. There’s not really any way to push a file to the box. No worries, Macs are Unix-ish, and this should be trivial, right? Nope, in Mojave there appears to be a strange quirk where ssh won’t respond on anything but localhost. So, my plan to scp from my Mac was shot to bits. I needed a linux box, and didn’t want to download an install ISO over the satellite any more than I wanted to download AirWave (after all, AirWave is itself Linux-based). Then I remembered I had my WLANpi.

Like an increasing number of gadgets these days, the WLANpi’s USB port (used for power) also happens to be an OTG port, and presents itself to the host system as an “RNDIS Ethernet Gadget”, and sets up an Ethernet link over the USB. This allows gadgets like the WLANpi and the Ekahau Sidekick to easily communicate with the host without going through the brain damage of custom device drivers (incidentally, Aruba is taking a similar approach to IoT support on its APs). RNDIS handles the messy layer 1 and layer 2 stuff, sets up layer 3 (the WLANpi defaults to 192.168.42.1) and then the application only has to implement standard upper-layer network communications.

So all I had to do was open an ssh session to my WLANpi (I use Emtec’s ZOC, which I have been using since the days of OS/2!) to see if I had enough storage space on the device to hold the 2.5GB AirWave update (Narrator: it did). Then I fired up Transmit, my go-to file transfer application on MacOS (whatever your platform, anything that supports scp will fit the bill), and sent the Airwave update over to a newly created files directory in the WLANpi user’s home directory.

Once the file was on the WLANpi, I plugged the WLANpi’s Ethernet port into a VLAN that was accessible to the WLAN management devices (I used the AP management VLAN since it already had a DHCP server), and then opened an ssh session to the AirWave server from my existing session on the WLANpi, essentially using it as a jump box. This served to verify port 22 connectivity, and also meant I didn’t have to put my laptop on that VLAN either.

Once I was able to copy the file from the AirWave server, the process was a snap to get the thing upgraded.

I think I’m going to get a bigger SD card for my WLANpi and store a full set of code and images that I may need, and also set up a tftp server on there, and maybe a file manager for the WLANpi’s web interface.

What’s In That Survey Kit? (Fall 2019 Edition)

The life and contents of a survey kit is a dynamic one. Here’s what’s in my kit these days. The Pelican 1510 is airline carry-on size, because there’s no way they’ll let you check that stuff with the batteries (which are all just under the airline limit of 100Wh), and the contents are valuable enough that you probably don’t want it out of sight, or trust it to the airline baggage handlers. If you’re carrying this stuff, it’s because you need it at your destination. Downside is that the 1510 doesn’t allow the overhead bin to be closed on Embraer 135/145 regional jets.

Links go mostly to Amazon where I get all this stuff

All this fits inside the case…
See? Whole thing weighs a little over 20 lbs, and there’s room to spare. Bright yellow inside makes it harder to lose stuff in there. Tripod is held in place with some velcro straps screwed to the lid.

  • Floater items that go between kits:
    • BatPower PDE2 96Wh USB Battery Pack (Amazon has removed this item. The upcoming Accelerator 2.0 battery pack from AccelTex will have full power type C PD ports on it)
    • EU/US power plug adapter
    • Swift Body Platform Harness (for carrying survey laptop and avoiding Survey Elbow, the nerd version of tennis elbow)

Also, if you’ve started adding this up in your head, you can see why I carry this on instead of leaving it to the baggage system. Make sure your business has insurance, especially if you’re self employed. If you’re traveling overseas, you’ll need special insurance coverage. I used to carry audiovisual insurance (the kind news crews carry) when doing streaming, and those policies will even cover against force majeure and acts of God. I don’t know if there’s an IT equivalent.

How It Works: HTTP Live Streaming

For those of us that work on wireless systems with a strong guest access component, the fine folks at Wowza Media Systems posted earlier this month about the inner workings of HTTP Live Streaming (Apple’s proprietary streaming protocol, or HLS) which accounts for about 45% of all streaming traffic – which tracks pretty closely to Apple’s market share of mobile devices.

Prior to getting hot and heavy with wireless networks, I did a lot of streaming infrastructure implementation for Wowza’s customers (as many of this blog’s readers are well aware – just go look into the archives!) HLS, which was released with the iPhone 3Gs, is designed from the ground up to handle the highly variable bandwidth and delay conditions inherent to mobile connections on Wi-Fi and cellular, while delivering a good streaming experience to the end user. It also allows streaming providers to leverage existing HTTP-based content delivery infrastructure.

Older streaming protocols like RTMP and RTSP are particularly unfriendly to wireless networks as they require a constant data stream at the stream bandwidth. For a video stream, much like a VOIP call, this requires consistent and timely medium access, which is definitely not a sure thing on Wi-Fi the way it is on Ethernet. The tradeoff is that the delay from live on HLS (a minute or two) is much higher than it is on RTSP (a few frames/milliseconds) or RTMP (a few seconds).

When working down at Layer 2, it’s usually helpful to understand what’s going on up the stack, especially with regards to what kind of unholy things are being done inside HTTP (which we may or may not have visibility into because of encrypted packet and segment payloads). In terms of the ISO model, HLS is probably best described as Layer 5 (the HTTP segmentation) and Layer 6 (the video data).

My good friend Jim Palmer (Not the baseball player) spoke at the Wireless LAN Pros Conference last year about the effects of user bandwidth throttling in a guest wireless environment with heavy streaming usage (predominantly Netflix). Understanding how HLS works in this context is key to understanding why the network behaves the way it does when you do that throttling. His talk is well worth ten minutes of your time. He’s also had some informative appearances on the Clear To Send Podcast (Episode #136, on antennas and filters), the Wireless LAN Pros podcast (Episode 116 on Captive Portals), and WiFi Ninjas Podcast (Episodes 19 and 20 on Airport Wireless Design).

So, here’s the link to Wowza’s post on the subject. I hope they post one about MPEG-DASH soon (from an HTTP standpoint, DASH works in a similar fashion).

https://www.wowza.com/blog/hls-streaming-protocol

Hiding In Plain Sight

One of my favorite things to do when I’m at a Disney park is to play the wireless nerd’s version of Hidden Mickeys: Trying to spot the myriad creative ways in which Disney’s Imagineers have blended their excellent wireless network into the carefully contrived scenery. It truly is magical how they can make wireless everywhere while keeping it nearly invisible.

So naturally, when I’m wearing the wireless engineer hat and have a challenge where I get to flex some of that creativity, I’m all over it.

A few years back, I helped a church in Wichita overhaul their aging and underpowered WiFi by designing and installing a new Ruckus system. Last year, they embarked on a new project to add a chapel to their campus. Naturally they wanted to extend the wireless LAN to this new building.

But… It’s a chapel aimed at doing weddings and other sorts of events, so it was paramount that the wireless equipment not be visible, to maintain clean architectural lines with a minimum amount of obvious tech equipment. Some concessions had to be made for audiovisual, but visible access points were a (network) bridge too far.

After pondering the problem as well as observing drawings and renderings, I happened upon the architectural lighting elements in the plan that were mounted on each of the columns. I dug into the design of these and discovered that they were a pair of LED fixtures concealed inside some finish carpentry with a textured plastic surface. And most importantly, there was an empty space in the middle between the two light fixtures that measured about 20cm square by 40cm high, and centered approximately 8 feet off the floor. Not only was that low enough to keep the APs close to the clients, there was plenty of room to put in one of the Ruckus H510 Wall APs designed for the hospitality market (which I also currently have in my house running Unleashed, although they will soon make way for some of the Aruba AP303H units or their new Instant On AP11D counterpart). I’m a big fan of these in-wall units for many reasons.

I asked the electricians to give me a box and conduit to four of these columns, as well as a pair of data cables. I only planned to use two access points initially, but since running cable would be prohibitively difficult after the buildout, I wanted to keep my options open should capacity needs increase in the future.

After many months of construction (Summer of 2019 was an utterly awful weather summer if you were in the construction business), I finally got the green light to install these. I took a bit of personal time on my way down to another job in Oklahoma for my employer, and executed the plan. I’m pretty happy with the results.

The lighting fixture: two pieces of dark wood on either side floating 1″ off the wall with a textured face and tunable color temp LED fixtures facing up and down
The lighting fixture with the plastic face slid up (there’s a stop at the bottom). An electrical box was placed behind it and a 2″ hole drilled for cable access. The overall construction of this fixture is beautifully simple: a few pieces of solid oak and some stain. The overall look in this space is one of stone, wood, and glass, with 90° and 45° angles being dominant.
The Ruckus H510 bracket screwed directly to the finish carpentry. The mount could also have screwed to the electrical box but that was an unnecessary level of effort.
The Ruckus H510 access point mounted on the bracket.
The fixture with the AP mounted inside. The wood and textured face provide minimal attenuation, and in this environment, I’m using the attenuation constructively. The recess in white is where a large TV (in lieu of projection) will be mounted on a swing arm and can fold into the wall when not in use.
Side view – the gap was just enough to get a screwdriver in to secure the AP to the bracket using the provided T10 screws. I was concerned that this wouldn’t be possible.
Lighting fixture side view. Is this with or without the AP installed? If you can’t tell, that means I was successful.
The AP was mounted on the second column from the back of the room, near the sound booth. The corresponding column on the other side is wired for an AP if capacity requires one.
The AP was mounted on the third column from the front of the room, near the front of the stage. The corresponding column on the other side is also wired for an AP if additional client capacity requirements dictate it.

Solving Home Wi-Fi Woes

“My home wi-fi sucks, how can I fix it?”

“What router should I buy to fix my home wi-fi?”

And so it goes. I get questions like these all the time when it becomes known that I’m a wi-fi expert (really! don’t take my word for it, CWNP and a panel of my peers said I was!) Since I get asked this a lot, I’m creating this post as a handy guide to making your home wi-fi better. 

While by day, I’m a mild-mannered field engineer for a wi-fi consulting company, and deal mostly with large-scale enterprise systems (often fixing their bad wi-fi), many of the same principles apply, because it all boils down to best practices.

First, you’re going to need a couple of basic tools to see what your wifi environment looks like. 

  • Mac: Wifi Explorer Lite
  • Windows: InSSIDer
  • Android: Wifi Analyzer
  • iOS: AirPort Utility

All these tools do is give you a listing (usually with a graphical representation) of the wi-fi channels in use in your environment. 

What causes my wi-fi to suck?

Generally speaking, if you have bad wi-fi, it’s because the device and the access point can’t hear each other very well, or it’s so busy neither one can get a word in edgewise. Wi-Fi can only have one device on a channel talking at once. When it wants to talk, it listens on the channel to see if it’s clear, and if it is, it says its piece and gets off. If it’s not (because someone else is talking), it pauses for a moment and tries again. On a busy channel, that can take a while (and in terms of computer networking, “a while” may only be a few milliseconds, but any delay slows you down. Sometimes a device says its piece, and the intended recipient couldn’t acknowledge it because it was too noisy because of interference from something that isn’t wifi (like bluetooth, microwave ovens, zigbee, etc.)

Let’s get a little terminology out of the way, first, so we’re all speaking the same language. 

router in terms of home wi-fi is an all-in-one device that contains not only a router, but also an ethernet switch and an access point. the access point is the piece that actually does your wi-fi. They just happen to all be stuffed into the same box together. Sometimes they’ll stuff a cable modem or a DSL modem in there too…

mesh is a means of connecting other access points to the network wirelessly. You have probably seen home “mesh” systems that incorporate a couple of access points in some sort of plug and play fashion. 

Your wi-fi is a wireless local area network. It is not internet access. It is entirely independent of your internet access, even if the router box you got from your ISP does wi-fi (usually badly). 

So the first thing you’ll want to do is check out your channel environment. The tools listed above will highlight the channel and AP you’re connected to, and show all the others, with the signal strength of each. It’s doing this by listening for beacon frames that are sent out approximately 10 times per second by every AP on every SSID.

There are two things you’re looking for: YOUR signal above -65dBm, and everyone else’s BELOW -82dBm. In the 2.4GHz band, you also want to watch out for anyone on channels in between the non-overlapping channels of 1,6,11 (many devices will automatically choose channels that aren’t 1/6/11, which they need to stop doing). 

So what if one or both of those tests comes back outside of those parameters? There are a few things that affect your signal strength:

  • Proximity to the access point
  • objects between you and the access point
  • the access point’s output power
  • the access point’s antennas

Your access point should be located somewhere fairly central in your home. It often isn’t because the ISP/Cable company was lazy and put the cable outlet on an outside wall. It should also be out in the open and not behind anything (I’ve seen many stuffed behind a TV, which does nobody any favors). The top of a bookshelf in the middle of your house is a great spot. 

If it has external antennas, they should ALL be pointing vertically. This is not an art piece where they go every which way, and they are not magic wands where wi-fi comes shooting out the ends (in fact, the axis of the antenna has the weakest signal.) If you mount it on a wall, they should still be vertical. 

One caveat to this is that if the antennas are detachable, you can keep your access point near the edge of your home and get a directional antenna.

If your access point lets you set power levels, set it to the lowest you can go and still cover what you need to cover, and nothing more. This keeps your neighbors from getting your wi-fi, and having yours interfere with theirs. If you go too high, you may be able to reach the far corners of your house, but your AP won’t hear your device’s responses. 

Which brings me to extenders. There are many of these on the market, and they’re all junk. Because of the whole “one device may speak at a time” thing, you now have a conversation where another person is repeating it loudly for the people in the back. Don’t do it. If you need more coverage, get one of those residential mesh systems, but connect it up with wires if at all possible (otherwise they act mostly like repeaters and murder your performance). 

I mentioned channels earlier. If you’re on 2.4GHz, you should only ever be on channels 1,6, or 11. But really, you shouldn’t be on 2.4GHz at all. There are lots more channels to work with in 5GHz. If you must be on 2.4GHz, minimize your use of it, and whatever you do, don’t use a 40MHz channel unless you live in the middle of a cornfield with no neighbors. 

If you’re on 5GHz, try to avoid 80MHz channels, 40 is OK if you don’t have many neighbors, and 20 is best when you have lots of neighbors. Many devices default to channels 36/40/44/48 and 149/153/157/161. I’m gonna let you in on a little secret: there are a whole lot more channels you can use. If your device supports them, you can use 52/56/60/64, 100/104/108/112/116/120/124/128/132/136/140/144, and 165. Chances are those channels are WIDE OPEN where you are. use them! 

And now, for cutting through the marketing hype:

“Tri-Band” is NOT A THING. (at least, not as of late 2018 when this is being written) Those devices are all a 2.4GHz radio and two 5GHz radios. That’s only two bands. However, if you have a tri-band radio, your best use is to set up one of the radios with a dedicated SSID and channel for your streaming equipment like Smart TVs, AppleTV, Roku, etc, and use your general internet access on the other. 

Gigabit wifi is A BIG FAT LIE. At most, you’re going to see a couple hundred megabits on a channel. Many vendors’ marketing people like to add up the theoretical maximum of all the radios in the device and claim that as the maximum speed, which is why you see absurd things like “5300Mbps” and “6400Mbps”. Those speeds will NEVER HAPPEN, because wi-fi doesn’t add them up. 

More antennas does not mean a better AP. a 4×4 AP is all well and good, but most of your clients are 2×2 with a small handful of high-end Macs that do 3×3. This refers to the number of MIMO spatial streams. There is ONE 4×4 client device on the market from Asus, and it is a PCIe expansion card for desktops. 

Power levels are limited by FCC rules (in the US – national communications authorities in other countries impose similar limits) , mostly at 100mW. Any device claiming high power wifi is lying to you. 

The current generation of WiFi is 802.11ac (also called WiFi 5 – and is 5GHz Only). The previous generation is 802.11n (WiFi 4, and is the current generation for 2.4GHz). Anything older than that should be replaced. The upcoming 802.11ax (WiFi 6) standard is still being developed and won’t be official until at least late 2019. 

Questions? Comment below!

Morning Fog along the Flint Hills National Scenic Byway

Mist Deployment, Part Deux

Second in a series about our first deployment of a Mist Systems wireless network. 

In my last post, I gave you an overview of the various components of the Mist Wireless system. This post will go into some of the design considerations pertaining to this particular project.

Because we’re now designing for more than just Wi-Fi, there are a few additional things to factor in when planning the network.

Floor Plans

It’s not uncommon for your floor plans to have a “Plan North” that doesn’t always line up with “Geographic North”. Usually this isn’t a factor, but looking at it in hindsight, I would strongly encourage you to build your floor plans aimed at geographic north from the start, as the Mist AI will also use that floor plan for direction/wayfinding and the compass in mobile devices will be offset if you just go with straight plan north. You can also design on plan north, but then output a second floor plan file that is oriented to true north. Feature request to Mist: Be able to specify the angle offset of the plan from true north and correct that for user display in the SDK.

For this project, I had access to layered AutoCAD files for the entire facility, which (sort of) makes things easier in Ekahau Site Survey, but sort of doesn’t – the import can get a little overzealous with things like door frames. I had to go do a fair bit of cleanup afterwards, and might have been better off just drawing the walls in the first place. This was partly due to the general lack of any good CAD tools on MacOS that would have allowed me to look at the data in detail and massage it before attempting the import into Ekahau. The other challenge is that ESS imported the ENTIRE sheet as its view window, which made good reporting impossible as the images had wide swaths of white space. Having the ability to crop the CAD file would have been nice.

Density Considerations

View from the rear of the main sanctuary at College Park Church in Indianapolis.

Since one of the areas being covered is a large auditorium, we had to plan on multiple small cells within the space. We needed to put the APs in the catwalks, as we did not have the option of mounting the units on the floor because of the sanctuary being constructed onslab (and while the cloud controller allows you to specify AP height and rotation from plan north, there is no provision to tell it the AP is facing *up* and located on/near the floor). This posed a few challenges, the first being that we were well above the recommended 4-5m (the APs were at 10m from the floor), the other being that we needed to create smaller cells. For this, we used the AP41E with an AccelTex 60-degree patch antenna.

Acceltex 8/10 dBi 60° 4-element patch antenna

 We also needed to either run a whole lot of cables up to the theatrical catwalks, or place a couple of small managed PoE switches – we unsurprisingly opted for the latter, using two 8-port Meraki switches, and uplinked them using the existing data cabling that was feeding the two UniFi APs that were up there.

As an added bonus, the sanctuary area was built with tilt-up precast concrete panels, which allowed us to use that heavy attenuation to our benefit and flood the sanctuary space with APs and not worry about spilling out too much.

Capacity-wise, we used 10 APs in the space, which seats 1700. Over the course of several church designs, I’ve found that a ratio of one active user for every three seats usually works out pretty well – in most church sanctuaries, the space feels packed when 2/3 of the seats are occupied, which means that we’re actually planning for one client for every two seats. Now, we’re talking active clients here, not associated clients. An access point can handle a lot more associations than it can active clients. As a general rule, I try to keep it to about 40 or 50 active clients per AP, before airtime starts becoming a significant factor.

In an environment like this, you want as many client devices in the room to associate to your APs, even if they’re not actively using them – when they’re not associated, they’re sitting out there, banging away with probe requests (especially if you have any hidden SSIDs), chewing up airtime (kind of like that scene from Family Guy where Stewie is hounding Lois just to say “Hi.”). Once they associate, they quiet down a whole bunch.

In addition to the main sanctuary, there are also a couple of other smaller but dense spaces: the chapel (seats 300) and the East Room (large classroom that can seat up to 250). In these areas, design focused on capacity, rather than coverage.

Structural Considerations

As is often the case with church facilities, College Park Church is an amalgamation of several different buildings built over a span of many years, accommodating church growth. What this ends up meaning is that the original building is then surrounded on multiple sides with an addition, and you end up with a lot of exterior walls in the middle of the building, as well as many different types of construction. Some parts of the building were wood-frame, others were steel frame, and others were cast concrete. The initial planning on this building was done without an onsite visit, but the drawings made it pretty obvious where those exterior (brick!) walls were. Naturally, this also makes ancillary tasks like cabling a little interesting.

Fortunately, the church had a display wall that showed the growth of the church which included several construction pictures of the building, which was almost as good as having x-ray vision.

Aesthetic Considerations

Because this is a public space, the visual appearance of the APs is also a key factor – Sometimes putting an AP out of sight takes precendence over placing for optimal Wi-Fi or BLE performance.

Placement Considerations

Coverage Area

Mist specifies that the BLE array can cover about 2500 square feet. The wifi can cover a little more, but it doesn’t hurt to keep your wifi cells that size as well, since you’ll get more capacity out of it. In most public areas of the building, we’re planning for capacity, not coverage. With Mist, if you need to fill some BLE coverage holes where your wifi is sufficient, you can use the BT11 as a Bluetooth-only AP.

AP Height

Mist recommends placing the APs at a height of 4-5m above the floor, in order to provide optimal BLE coverage. The cloud controller has a field in the AP record where you can specify the actual height above the floor.

AP Orientation

Because the BLE array is directional, you can’t just mount the APs facing any direction you please. These APs are really designed to be mounted horizontally, the “front” of the AP should be consistently towards plan north, but the controller does have the ability to specify rotation from plan north in case mounting it that way isn’t practical. The area, orientation and height are critical to accurate calculation of location information.

AP Location

Several of the existing APs in older sections of the building were mounted to hard ceiling areas, and we had to not only reuse the data cable that was there, but also the location. Fortunately, the previous system (Ubiquiti UniFi) was reasonably well-placed to begin with, and we were able to keep good coverage and reuse those locations without any trouble.

There were also some co-existence issues in the sanctuary where we had to make sure we stayed out of the way of theatrical lighting and fixtures that would pose a problem with physical or RF interference. In the sanctuary, we also have to consider the safety factor of the APs and keeping them from falling onto congregants like an Australian Drop-Bear.

Planning for BLE

Since starting this project, I’ve begun working with Ekahau on testing BLE coverage modeling as part of the overall wifi coverage, and it’s looking very promising. I was able to go back to the CPC design and replan it with BLE radios, and it’s awesome. Those guys in Helsinki keep coming up with great ideas. As far as Ekahau is concerned, multi-radio APs are nothing too difficult – They’ve been doing this for Xirrus arrays for some time now, as well as the newer dual-5GHz APs.

Stay tuned for a post about BLE in Ekahau when Jussi says I’m allowed to talk about it.

Up Next: The Installation

 

Cover Image: Explore Kansas: The Flint Hills National Scenic Byway (Kansas Highway 177)

Misty valley landscape with a tree on an island

Mist Deployment (Part The First)

First in a series about our first deployment of a Mist Systems wireless network. Mist Systems Logo

Over the course of the past few months, I’ve been working with the IT staff at College Park Church in Indianapolis to overhaul their aging Ubiquiti UniFi wireless system. They initially were looking at a Ruckus system, owing to its widespread use among other churches involved with the Church IT Network and its national conference (where I gave a presentation on Wi-Fi last fall). We had recently signed on as a partner with industry newcomer Mist Systems, and had prepared a few designs of similar size and scope for other churches in the Indianapolis area using the Mist system. We proposed a design with Ruckus, and another with Mist, with the church selecting Mist for its magic sauce, which is its Bluetooth Low Energy (BLE) capability for location engagement and analytics.

Fundamentally, the AP count, coverage, and capacity were not significantly different with Ruckus vs. Mist, and Mist offered a few advantages over the Ruckus in terms of the ability to add external antennas for creating smaller cells in the sanctuary from the APs mounted on the catwalks, as floor mounting was not an option.

About Mist

Mist is a young company that’s been around for about two or three years, and they have developed a couple of cool things in their platform – The first is what they call their AI cloud, the second is their BLE subsystem, and the last is their API.

Their AI component is a cloud management dashboard (similar to what you would see with Ruckus Cloud or Meraki — many of the engineers that started with Mist came over from Meraki), where the APs are constantly analyzing AP and client performance through frame capture and analysis, and reporting it back to the cloud controller. The philosophy here is that a large majority of the issues that users have with Wi-Fi performance is actually related to performance on the wired side of the network (“It’s always DNS.” Not always, but DNS — and DHCP — are major sources of Wi-Fi pain). The machine learning AI backend is looking at the stream of frames to detect problems, and then using that to generate Wi-Fi SLA metrics that can help determine where problems lie within the infrastructure, and doing some analysis of root causes. An example of this is monitoring the entire Station/AP conversation during and shortly following the association process. It looks at how long association took. How long DHCP took (and if it was successful), whether 4-way handshakes completed, and so on. It will also keep a frame capture of that conversation for further manual troubleshooting. It also keeps a log of AP-level events such as reboots and code changes so that client errors can be correlated on a timeline to those events. There’s a lot more it can do, and I’m just giving a brief summary here. Mist has lots of informational material on their website (and admittedly, there’s a goodly amount of marketing fluff in it, but that’s what you’d expect on the vendor website).

Graphs of connection metrics from the Mist system

 

 

 

 

 

 

 

 

 

 

Next, we have their BLE array. This is what really sets Mist apart from the others, and is one of the more interesting pieces of tech to show up in wifi hardware since Ruckus came on the scene with their adaptive antenna technology. Each AP has not one, but *eight* BLE radios in it, coupled with a 16-element antenna array (8 TX, 8RX). Each antenna provides an approximately 45° beam covering a full circle. Mist is able to use this in two key ways. One is the ability to get ridiculously precise BLE location information from their mobile SDK, (and by extension, locate a BLE transponder for asset visibility/tracking) and the other is the ability to use multiple APs to place a virtual BLE beacon anywhere you want without having to go physically install a battery-powered beacon. There are myriad uses for this in retail environments, and the possibilities for engagement and asset tracking are very interesting in the church world as well.

Lastly, we have their API. According to Mist, their cloud controller’s web UI only exposes about 40% of what their system can do. The remainder is available via a REST API that will allow you do do all kinds of neat tricks with it. I haven’t had a chance to dig into this much yet, but there’s a tremendous amount of potential there. Jake Snyder has taught a 3-day boot camp on using Python in network administration to leverage the power of APIs like the one from Mist (Ruckus also has an API on their Cloud and SmartZone controllers)

Mist is also updating their feature set on a weekly basis – rather than one big update every 6 months that may or may not break stuff, small weekly releases allow them to deploy features in a more controlled manner, making it easy to track down any potential show-stopper bugs, preferably before they get released into the wild. You can select whether your APs get the early-release updates, or use a more extensively tested stable channel.

Much like Meraki, having all your AP data in the cloud is tremendously useful when contacting support, as they have access to your controller data without you having to ship it to them. They can also take database snapshots and develop/test new features based on real data from the field rather than simulated data. No actual upper-layer traffic is captured.

The Hardware

note: all prices are US list – specific pricing will be up to your partner and geography.

There are four APs in the Mist line. The flagship 4×4 AP41 ($1385), the lower-end AP21 ($845), the outdoor AP61 ($?) , and the BLE-only BT11 ($?). The AP41 also comes in a connectorized version called the AP41E, at the same price as the AP41 with the internal antenna.

The AP41/41E is built on a cast aluminum heat sink, making the AP noticeably heavy. It offers an Ethernet output port, a USB port, a console port, and what they call an “IoT port” that provides for some analog sensor inputs, Arduino-style. It requires 802.3at (PoE+) power, or can use an external 12V supply with a standard 5.5×2.5mm coaxial connector. In addition to the 4-chain Wifi radio and the BLE array, the AP41 also has a scanning radio for reading the RF environment. On the AP41E, the antenna connectors are located on the downward face of the AP.

The AP21 is an all-plastic unit that uses the same mounting spacing as the AP41, and has an Ethernet pass-through port with PoE (presumably to power downstream BT11 units or cameras). Like the AP41, it also has the external 12V supply option.

This install didn’t make use of BT11 or AP61 units, so I don’t have much hands-on info about them.

It’s also important to note that none of these APs ship with a mounting bracket, nor does the AP have any kind of integrated mounting like you would find on a Ruckus AP. Mist currently offers 3 mounting brackets: a T-Rail bracket ($25), a drywall bracket ($25) and a threaded rod bracket ($40). The AP attaches to these brackets via four T10 metric shoulder screws (Drywall, Rod), or four metric Phillips screws (T-Rail). More on these later.

The Software

Each AP must be licensed, and there are three possibilities: Wifi-only, BLE Engagement, and BLE Asset tracking. Each subscription is nominally $150/year per AP, although there are bundles available with either two services or all three. Again, your pricing will depend on your location and your specific partner. Mist recently did away with multi-year pricing, so there’s no longer a cost advantage in pre-buying multiple years of subscriptions.

When the subscription expires, Mist won’t shut off the AP the way Meraki does, however, the APs will no longer have warranty coverage. After a subscription has been expired for two months, Mist will not reactivate an AP. The APs will continue to operate with their last configuration, however, but there will no longer be access to the cloud dashboard for that AP.

Links:

Mist Systems

Jake Snyder on Clear To Send podcast #114: Automate or Die

Mist Product Information

Up Next: The Design

What’s In Your Go-Kit?

As I prepare for another trip to a customer site, I figured I’d post the contents of my wireless engineering go-kit for the benefit of others wanting to put one together. I’ve posted previously about my streaming go-kit, which has largely been retired as I’m not doing nearly as much streaming as before, having shifted over to Wi-Fi. Amazon links in this post are affiliate links, and it’s where I bought most of this stuff over the course the the last several years. Some of it was freebies from conferences like the Wireless LAN Professionals Conference.

What’s in the kit?

It will depend largely on the job I’m going to do, but I’ve got several sub-kits that go in it based on the needs of the job:

Frame Analysis Sub-Kit:

(this kit has largely been deprecated by my Macbook and Airtool)

  • 3 Netgear A6210 2SS 802.11ac adapters for use with Omnipeek – I don’t know if the 3SS version A7000 has requisite drivers for Omnipeek. Word on the street is that Metageek EyePA recently added support for these adapters. AirMagnet can also use these for surveys.
  • 1 AirPCAP Adapter for use with Omnipeek (pretty much obsolete at this point)

Site Survey Sub-Kit:

Spectrum Analysis Sub-Kit:

Pentest Sub-Kit:

Ethernet/Console Sub-Kit:

Test Tools:

Measurement/Installation Tools:

Miscellaneous:

Computing:

Software:

PPE/Safety

Depending on the combination of stuff, most of it goes in a Pelican 1510 carry-on case (yes, it all fits – other than the PPE – with some room to spare, especially if you add the lid organizer, which is great for keeping small things contained!) . Because some of the devices in there contain lithium batteries, I can’t check it – but in that case the scissors and the knife need to go in checked luggage – But if you do some mental calculations and add up what all this stuff costs, you’ll see that even without the computers and software, that’s not generally something I am willing to let out of my immediate control. I don’t bother with TSA locks, because those don’t provide any security.

If I only need some of the items, I put them in a smaller nylon case that used to be a carrying case for a projector, which does fit in a checked suitcase. The fiber kit has a dedicated Pelican 1490 case when not traveling in the 1510.

Wireless Engineering Kit in a Pelican 1510 case.