All In All, You’re Just Another Brick In the Wall

August 29, 2019 |   |  1 Comment  |  Uncategorized

How I learned to stop worrying and love predictive modeling

Due to this topic coming up regularly in the community, I’m posting this slightly edited version of one of the project documents I submitted as part of my CWNE application. The building in question has since been completed, but I have not had a chance to go see how the wireless ended up being implemented.

When I was working at Servant42, we were approached by another wireless integrator that we had met at a conference, and I was tasked with taking a preliminary design for a $125M academic research building currently in the early stages of construction, and come up with a usable wireless design in order for the integrator to plan cable placement. The RCDD who did the initial cabling design had put together a grid overlay of access points over each floor, and requested an outlet at each one. The integrator knew this wasn’t going to provide for functional Wi-Fi, and sent over the plans, with a note to pay very close attention to some of the wall types. 

The prints were exceedingly detailed, and the wall type schedule alone covered multiple sheets. Not having any real-world walls in this facility to measure attenuation with, I had to rely on published materials regarding attenuation of each type of common construction material. A valuable resource in developing this attenuation model was a 2002 paper[1] published by Robert Wilson (then a graduate student at USC, now a staff engineer at Qualcomm). Based on the various wall types listed on the sheet, I painstakingly added up all the attenuation values and created a wall type for each one in Ekahau Site Survey Pro, labeled to match the callouts on the prints. It wasn’t perfect, but it would get me within about a dB. Some of the walls I had to deal with:

  • 2-hour rated walls, with double-thick 5/8” drywall on each side, filled with fiberglass
  • Single layer drywall on only one side, open on the other, or wrapping a column
  • Filled concrete block
  • Cast concrete
  • Security walls (more on that in a minute)
  • Low-E glass curtain walls
  • And so on…

Each of these wall types was also found in varying thicknesses throughout the building. As it turned out, the walls the client was telling me to pay special attention to were the security walls. Several areas of this building were slated to house medical laboratories, and as part of the security specification, it called for steel strapping, “to prevent penetration of a 100mm sphere.” This oddly specific requirement sounded like they were trying to stop small cannonballs, and I was more than a little curious because the specification didn’t mention anything about the velocity of said sphere.

The prints showed 6” wide 54mil steel straps spaced 3.75” apart (95mm) all the way up to the ceiling. And there were a LOT of these walls in the building. The nature of these walls is also such that they were certainly going to be grounded: 

A strapping young specimen of a wall.

So I start digging back into the recesses of my brain where the RF theory is stashed, and consulted an RF engineer colleague, where he gave me a refresher on the RF transparency of various openings, where odd numbers of quarter waves are opaque to an RF frequency and even numbers are transparent. Some quick calculations told me that my 95mm openings were almost exactly ¾ wave on 2.4GHz. And because they ran horizontally, the gaps were about 16” wide between studs. So these lovely security walls were going to be opaque to 2.4GHz, but only one way. And transparent to 5GHz. Welcome to my nightmare! How in the heck was I going to model this? Ekahau didn’t give me the option for different attenuation values for frequencies or polarization. 

Wilson’s paper also didn’t make any mention of this sort of thing. And I still couldn’t go out into the field to measure it, nor did the client have the budget or the time for us to set up a model of the wall and test that. 

As I’m trying to figure out my next move, I get a call from the client, and he tells me they’re starting to build those security walls on one of the lower floors. And then he sends me this picture. Sure enough, they deviated from the version of the plans that I had, and used an entirely different construction material on the security walls: an expanded metal diamond mesh rather than strapping, the type once commonly used as lath for plaster walls in the 1940s after wood lath fell out of favor (I’ve had to add data drops to those walls and cut in boxes, it’s NOT fun.)

The Mesh. Not that kind of meshing.

So now my calculations are out the window and I have to start over. I try to estimate the size of the holes in this mesh. I come up with about 6mm based on some rudimentary photogrammetry. This hole works out to 1/8 wave in 5GHz, and 1/16 wave in 2.4GHz. As far as the Wi-Fi is concerned, these might as well now be brick walls. I still don’t have a true idea of the actual attenuation. So I assume at this point that a layer of this stuff is going to stop the signal dead and dump it to ground, and put in 20dB. But at least I can model these now. 

Now that I can put all my walls in, I build the model in Ekahau (and I was really wishing for a CAD file at this point) and I’m able to model the existing planned AP locations, show the numerous coverage problems caused by the security walls, and then re-plan the whole building (four occupied floors and a basement, including a few high-density lecture halls). Coverage was defined by the client for Cisco 3802i APs with -67dBm primary coverage, -75dBm secondary coverage, and not to worry about voice. Lecture halls needed to assume 2 client devices per seat. 

In several locations, I was having to place an AP just to cover a small pair of offices, because they were wrapped on three sides with these security walls. In a few cases, the office itself was fully wrapped in these secure walls, with a solid core door and safety glass window to the hall. I decided not to model the window and doors into the outer halls as the RF spilling from them would not be relied on for coverage outside the office. I made the recommendation to run these APs at lowest possible output power and specified a separate AP to cover these halls, preferably with a directional antenna. In other places, I had to place APs to cover RF shadows left by these walls. 

Once complete, the client was then able to go back to the RCDD and request the additional cabling drops for the access points (the AP count through the entire building increased by nearly 50% just to deal with these Wi-Fi-eating walls)

[1]Wilson, Robert, “Propagation Losses Through Common Building Materials: 2.4GHz vs. 5GHz”

Solving Home Wi-Fi Woes

November 9, 2018 |   |  3 Comments  |  networking, Wireless

“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. 

a 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…

a 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

May 10, 2018 |   |  Comment  |  Church IT, Hardware, IT, networking, Wireless

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)

May 8, 2018 |   |  2 Comments  |  Church IT, Cloud Computing, Hardware, IT, networking, Wireless

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?

May 6, 2018 |   |  5 Comments  |  Hardware, Uncategorized, Wireless

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.

On Network Models

March 31, 2018 |   |  1 Comment  |  nerd, networking, Wireless

One of the most fundamental concepts underlying modern data networking is that of the network

“stack”, which consists of individual “layers” that allow one to describe a network without actually getting lost in the weeds of specific underlying technologies. There are two models that are in common usage (there are several others as well but are less common):

  • the seven-layer OSI Model (which is largely theoretical), published in 1984 as ISO standard 7498 and officially known as the “Open Systems Interconnection Reference Model” (Kansas connection: the OSI model’s designer, Charles Bachman III, was born in Manhattan, the son of the head football coach at K-State at the time)
  • the four-layer TCP/IP Model (which is a more practical model owing to the widespread use of the internet). The TCP/IP model predates the OSI model and can trace some of its roots to BBN’s early work on internetworking in the late 1960s.

One of the key principles of the model is that each layer is carried by the layer below it. The layers each have their own methods and protocols, which are (for the most part) independent of the layers below that are carrying them from A to B. In the TCP/IP column, I’ve also indicated what type of system operates at that layer.

Network Model
OSI TCP/IP OSI Protocol data unit (PDU) Function
Host
layers		 7. Application Application

(Computer)

 Data High-level APIs, including resource sharing, remote file access
6. Presentation Translation of data between a networking service and an application; including
5. Session Managing communication sessions, i.e. continuous exchange of information in the form of multiple back-and-forth transmissions between two nodes
4. Transport Transport

(ISP)

Segment

 Reliable transmission of data segments between points on a network, including segmentation, acknowledgement and multiplexing
Media
layers		 3. Network Internetwork

(Router)

 Packet Structuring and managing a multi-node network, including addressing, routing, and traffic control
2. Data link Link

(Switch)

 Frame Reliable transmission of data frames between two nodes connected by a physical layer
1. Physical Bit Transmission and reception of raw bit streams over a physical medium

The importance of understanding these network models comes into play is when you are designing or troubleshooting a network. Understanding at what level your problem is happening is a major step towards solving it. I’ve seen and answered countless questions on Quora about “why doesn’t X” work, or “can someone on the internet trace me by my MAC address?” and various other questions that can be enlightened by an understanding of the network models. As a general rule, the lower you are in the model, the more physically localised you’re dealing with.

It’s probably difficult to wrap your head around if you’re not used to this kind of stuff. So let me offer up an example of how this same network model manifests itself in the real world, completely unrelated to computer networking. You’ve almost certainly seen it in action. You’ve benefited from it in your life. I give you: Container Shipping.

Container shipping relies on a standardized set of steel containers (also defined by the ISO) that can be used to haul goods efficiently around the world.

Here’s what the Transport Layer looks like:

Notice that the container is itself full of smaller containers (plain cardboard boxes: The session layer) – which themselves may contain additional boxes for retail (presentation layer), which contain an actual product (application layer). When the container is closed and sealed, its contents go wherever it goes.

But how does it get there? It makes use of the Network Layer. This is where it goes through one or more shipping companies (like ISPs) that get the contents from the factory in China (server) to the buyer (client). As in computer networking, This transportation company can use multiple types of ways to get it there, such as trucks, trains, ships, and airplanes. These are Layer 2, the Link Layer, and are all capable of carrying these containers.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Each of these Layer 2 conveyances rides on a different physical medium: Roads (land), Rails (land), Shipping routes (sea), flight paths (air).

It’s also worth noting that two of these physical media are bounded media (roads and rails) which constrain the path the vehicle takes. This is akin to a wire or fiber optic cable.  The other two (sea and air) are unbounded, which means the vehicles can take any path they choose. This is akin to free-space optical transmission and wireless RF transmission – it also means those are more susceptible to interception (hijacking/piracy).

I mentioned earlier that a layer 3 device is a router. Its job is to get the data from one network to another. What does this look like in container shipping? One of these giant cranes that remove the containers from one conveyance, to be loaded onto another. Sometimes, it will buffer them in a container yard before sending it on to its destination.

 

Once the container gets to its destination, it is signed for (an ACKnowledgement in the network world), and the signature is sent back to the shipper to confirm that it arrived at its destination – this is a transport layer function, as it is the shipper’s responsibility to make sure stuff gets there on time. The buyer and shipper (Layer 7) don’t really care *how* it got there, just that it did.

 

EC2 Monitoring with Raspberry Pi

May 4, 2017 |   |  2 Comments  |  Cloud Computing, Code, Hardware, nerd, networking

I’ve been doing a little Raspberry Pi hacking lately, and put together a neat way to have physical status LEDs on your desk for things like EC2 instances.

The Hardware

In its most basic form, you can simply hook up an LED and a bias resistor between a ground line and a GPIO line on the Pi, but that doesn’t scale especially well – You can run out of GPIO lines pretty quickly, especially if you’re doing different colors for each status. Plus, it’s not overly elegant.

The solution? Unicorns!

No, really. The fine folks at Pimoroni in Sheffield, UK have made a lovely little HAT device for the Pi called a Unicorn. Its primary purpose is lots of blinky lights to make pretty rainbows and stuff, hence the name. However, this HAT is a 4×8 (or an 8×8) array of RGB LEDs, addressable via the I2C bus, which doesn’t eat up a line per LED (good thing, otherwise it would require 96 analog lines). The unicornhat library (python3-unicornhat) is available for Python 2 and Python 3 in the Raspbian repo. When installed onto the Pi, the Unicorn will fit within a standard Raspberry Pi case.

The Code

This is my first foray into Python, so there was a bit of a learning curve. If you’re familiar with object-oriented code concepts, this should be easy for you. Python is much more parsimonious with punctuation than PHP or perl are.

For accessing the EC2 data, we’ll need Amazon’s boto3 library, also available in the Raspbian repo (python3-boto). One area where boto3 is really nice is that the data is returned directly as a dict object (what users of other languages would call an array), so you don’t have to mess with converting JSON or XML into an object structure, and it can be manipulated as you would any other associative array (or a hash for you old-timers that use perl). AWS returns a fairly complex object, so you kind of have to dig into it via a few iterative loops to extract the data you’re after.

From there, it’s a matter of assigning different RGB values to the states. I chose these ones:

  • stopped: red
  • pending: green
  • running: blue
  • stopping: yellow(ish)

I also discovered that I needed to assign a specific pixel to each instance ID, otherwise they tended to move around a bit depending on what order AWS returned them on a particular request.

Here’s what the second iteration looks like in action:

import boto3 as aws
import unicornhat as unicorn
import time

# Initialize the Unicorn
unicorn.clear()
unicorn.show()
unicorn.brightness(0.5)

# Create an EC2 object 
ec2 = aws.client('ec2')

# Define colors and positions
color = {}
color['stopped']={'red':255,'green':0,'blue':0}
color['pending']={'red':64,'green':255,'blue':0}
color['running']={'red':32,'green':32,'blue':255}
color['stopping']={'red':192,'green':128,'blue':32}
	
pixel = {}
pixel['i-0fa4ea2560aa17ffd']={'x':0,'y':0}
pixel['i-06b95cd864acb1a8c']={'x':0,'y':1}
pixel['i-0661da0f50ffb604c']={'x':0,'y':2}
pixel['i-063ec151e0f44ef9b']={'x':0,'y':3}
pixel['i-02c514ca567d8a033']={'x':0,'y':4}

# Loop until forever
while True:

	response = ec2.describe_instances()
		
	
	statetable = {}
	resarray = response['Reservations']
	for res in resarray:
		instarray = res['Instances']
		for inst in instarray:
			iid = inst['InstanceId']
			state = inst['State']['Name']
			# print(iid)
			# print(state)
			statetable[iid] = state
	
	
	for ec2inst in statetable:
		x = pixel[ec2inst]['x']
		y = pixel[ec2inst]['y']
		r = color[statetable[ec2inst]]['red']
		g = color[statetable[ec2inst]]['green']
		b = color[statetable[ec2inst]]['blue']
		# print(x,y,r,g,b)
	
		unicorn.set_pixel(x,y,r,g,b)
		unicorn.show()


	time.sleep(1)

For the moment, this is just monitoring EC2 status, but I’m going to be adding checks in the near future to do things like ping tests, HTTP checks, etc. Stay tuned.

Streaming to multiple simultaneous destinations

April 16, 2017 |   |  3 Comments  |  Cloud Computing, streaming, Wowza

Live streaming has been a “thing” for some time. I work with many churches to help them solve their streaming challenges and develop their technology strategy for streaming. One of the most frequent questions I hear is, “can I stream to Facebook Live and still keep my other stream?” Fortunately, this is a lot easier than it used to be. There are variations on this question, but they all boil down to wanting to know how to send one stream to multiple outlets to expand audience reach.

Method 1:

Multiple outputs from your encoder

Several software encoder platforms support multiple outputs. The easiest among these is probably Telestream’s Wirecast software. (The free/open-source Open Broadcast Studio does this as well, but I don’t have much experience with it, and I prefer the Wirecast interface, which is much more polished.) With Wirecast, it’s merely a matter of adding the additional outputs to the various streaming services that are supported. The downside to this approach is that you’ll need more bandwidth, as you are sending the same stream multiple times.

Screenshot 2017-04-16 09.56.42

Method 2:

The Cloud

1. Teradek Core

This is a vendor-specific approach that integrates with Teradek‘s pro-grade encoders (Cube, Bond, Slice, and T-Rax). It provides a single pane of glass that lets you manage your entire fleet of encoder devices (and control/configure them remotely), and then virtually patch the output of those encoders to one or more outputs. You can also use their Live::Air apps for iOS as an input (stay tuned for a post about using Live::Air). If you are using a Bond product, the input is via their Sputnik server, which allows you to spread the stream across multiple connections for extra bandwidth and redundancy, and then it’s reassembled before sending it on to the next step.

In this example, I’m taking an input stream from the Live::Air Solo app on my iPhone, and sending it to Wowza Streaming Cloud, and Facebook Live, all while recording the incoming stream:

Screenshot 2017-04-16 07.10.22

This is a simple drag and drop operation: Drag a source on the left into the workspace, and then drag one or more destinations from the left – this can be:

Teradek decoders (this is great for a multisite church scenario)

Channels (which are external stream destinations):

Screenshot 2017-04-16 09.49.05

Groups (a combination of the above):

Screenshot 2017-04-16 09.50.31

If you click the “Auto” box on the outputs, it will start that output automatically when the stream is available from the input.

When you create stream destinations for social sites, it will authenticate you against that site and keep that authentication.

You can manage a lot of inputs and outputs this way. This example from Teradek’s marketing department shows the scale:

core-management-platform-user-interface_e811873e-7cfb-4514-a465-1467d487d8d7

 

2. Wowza Streaming Engine/Streaming Cloud

Similar to Core, but not tied to a specific vendor, Wowza Streaming Engine provides Stream Targets as of version 4.4 (although the functionality has been in the software since sometime in version 2, as the PushPublish module, Stream Targets integrates it into the UI). Facebook Live support has been an option since almost the very beginning of Facebook Live. YouTube Live support is there, but as a standard RTMP destination.

Similarly, Wowza Streaming Cloud also offers this capability under the “Advanced Menu”:

Screenshot 2017-04-16 10.07.49

From there, you can create a stream target:

Screenshot 2017-04-16 10.08.02

 

Once that target is created, simply go into a transcoder output and add it (you can also create a target directly from there):

Screenshot 2017-04-16 10.12.26

 

As with Core, you can add multiple destinations to a transcoder output – Generally speaking you’ll want to send your best output to places like FB Live, YouTube, etc, as they do their own internal transcoding.

Screenshot 2017-04-16 10.13.31

 

Method 3:

Multiple Encoders

This is the obvious one, but also the least efficient both in terms of hardware and bandwidth. Each encoder goes to its own destination. This generally requires signal distribution amplifiers and other extra hardware.