Thursday, 18 May 2017

Odroid Based Speedtest

Sometimes it would be great to have your own, independent speed-test service to test performance inside your network. In this article, I look at a free speed-test utility that can be installed onto an Odroid platform so you can have your very own network speed-test service.


Back in February 2017, I attended the Wireless LAN Pros conference in Phoenix. Among the many interesting sessions provided was a “maker” session where we all got to build a whiz-bang gizmo based on an Odroid computer board. This is quite similar to a Raspberry Pi, that you may be more familiar with, but it has a bit more processing horsepower and, most importantly, a gigabit Ethernet connection, rather than being limited to the 100mbps of a Pi.

Among the many features that the Odroid provided for us was speed-test software from I’m sure you’ll be familiar with this type of service is you’ve used or some other similar web-based speed testing utility. You simply browse to the speed test service, hit a button and a series of tests are run to test your upload and download speeds.

Many organizations tend to use web-based speed-test services as a test in situations when “there’s a problem on the wireless network”. It can provide a quick check of the end user wireless experience. Unfortunately, this approach is fundamentally flawed as a test of wireless connectivity. As it’s hosted on a service across the Internet, it’s subject to the potential challenges and inconsistencies of an organization’s Internet pipe or the target service itself (no, it might not be the wireless after all!).

There are other test utilities such as iperf3 that can probably do a slightly better job for us techies, but for a quick and easy test that users can easily perform with no additional software, a browser-based speed-test service is massively convenient.

The reason I was interested in the Odroid-based speed test is that it provides the opportunity to host your own speed test service within your own network. This obviously cuts out the variables introduced by having to traverse the Internet and therefore provides a better test of your local network infrastructure. The Odroid is a reasonably capable piece of hardware and comes with a very reasonable price-tag.

Although the pre-installed utility on the Odroid supplied at WLPC is great, it has a slight drawback as it requires that the user has access to the Internet to pull various browser components from the OpenSpeedtest site itself to function. This could be an issue in scenarios such as:

  • Genuine issues with the Internet connection, making it difficult to get the required components from the speed-test site
  • Trying to test a guest environment for an unauthenticated session
  • Lab and other isolated environments
  • The speed-test service itself has issues, which is difficult to verify

Having your own speed-test service is quite desirable, as there is far more control over the server and the target zone of any fault detected is significantly reduced compared to an Internet based service. If there is an issue detected with your own hosted speed-test service, it’s more likely that the issue IS on your network.

One other side-benefit is that there are no ads on your own hosted service.

Installing The Files

To achieve a speed-test service that could be hosted on our trusty Odroid platform, I had a dig around on GitHub and found a very nice project from Federico Dossena that is a HTML5 speed-test project. This means it will work on most modern mobile devices (all the tablets & phones I’ve tested worked OK). All the hard work to bring you this utility has been done by Federico and the contributors to the project, so I can’t take any credit for this great resource.

To get it going, it’s pretty much just a matter of copying the correct files to the webserver directory of the Odroid and pointing your browser at it.

Here are the steps you’ll need to carry out. I’ve wrapped the required files up into a consolidated mini distribution for ease of use, but they’re all available from the project site.

  1. Download this zip file which is an archive with all of the files you’ll need: download
  2. Unzip the file. This will create a folder called “speedtest”
  3. Use scp to copy the ‘speedtest’ folder to the ‘/var/www’ folder of your Odroid (the login details of your Odroid are shown on its screen)

That’s it!

Now browse to “http://<Odroid IP>/speedtest”. You should see the screen below.  I’m sure you will be able to figure out how to use it from this point onwards.



If you deploy this on a live network, it’s worth remembering that its performance is going to be impacted if it’s being constantly thrashed by hordes of disgruntled users. But, as an occasional testing service, it's more than capable, particularly for wireless users who are likely to be hitting it at lower speeds than an average wired user.

Many people reading this article who don’t have an Odroid are probably wondering: “Hmmm…can I run this on my <insert Linux based device>?”. It’s very likely this would run up on pretty much anything that has an Apache web server and PHP Installed. One caveat to remember is that the results achievable will be limited by the horsepower of your device, particularly its Ethernet port speed (e.g. Raspberry Pi will top out at 100mbps). According to docs on the project web site, you may also have to tweak the Apache web server to allow large file uploads, as this may be restricted by default.

I hope you have fun with this. If you do deploy it on a network though, don’t forget to secure the platform and keep it up to date (don’t just stick it in a comms rack and forget about it…).


Monday, 15 May 2017

Wireshark Custom Columns For Wireless Captures

In previous articles, I’ve covered a few aspects of wireless frame capture using Wireshark, looking at subjects such as frame colourization and radio tap headers. In this article, I look at another way of improving the visualization of wireless frame captures by adding columns to our Wireshark frame summary, including customised columns that use 802.11 frame field values.


By default, a typical 802.11 capture in Wireshark looks something like the screen-shot presented below (assuming you added the colourization rules I previously blogged about):

Although we get a nice summary of the frame types that are whizzing by, it would be useful if we could get a little more summarized information, before we dive into the detail of each frame. In a wireless environment, there are many more considerations compared to the wired world when we’re looking at frame captures. In addition to the information around frame timings, addressing, types etc. I’m always interested to know wireless-specific information such as:

  • What signal strength was this frame seen at?
  • What PHY types are being used on this network?
  • Are the QoS data frames being correctly marked in the 802.11 frame headers?
  • What physical speeds are being used on this network?

By applying some customisation to Wireshark, we can summarise these pieces of information in our frame summary through the addition of new columns.

Pre-defined Column Headers

So, how do we perform this magic and improve our frame capture summary?

First, let’s add a couple of pre-defined column headers that are already easily available without too much effort within Wireshark.

To customize the columns displayed, right click on column bar and select “Column Preferences”, or use the Wireshark menu-bar option: Edit > Preferences > Columns. Once selected, the panel below will be displayed:

We’d like to add new columns to show the RSSI (Received Signal Strength Indicator) and transmission rate of each frame. Follow these steps to add the two new columns:

  • Hit the “+” button
  • A new entry will appear displaying the following information: Title: New Column, type: Number.
  • Double click on the “New Column” field and enter the name of “RSSI”
  • Double click on the “Number” field and change the type to “IEEE 802.11 RSSI” using the drop-down that appears
  • Hit “+” again. Another new entry will appear
  • Repeat the process, but add a title of “TX rate” and a type of “IEEE 802.11 Tx rate” from the drop-down options.
  • Finally, drag the two new column definitions so that that appear above the “Info” field in the column listing, as shown below:

Finally, how hit the “OK” button and see the new columns appear in your Wireshark display:

Custom Column Headers

There are a couple more columns I’d like to add to the frame summary, but they aren’t available as pre-defined column values within Wireshark. Luckily, Wireshark has a superb feature that allows us to select any field value within our capture and turn it into a custom column. We’ll use this to create two additional columns to show us the PHY type of each frame and the QoS setting of our data frames.

For this operation, we need to initially select a QoS Data frame in our frame summary, then perform the following operations (see figure below):

  • In the decode panel, snap open the “802.11 radio information” section of the decode
  • Select the “PHY type” field
  • Right click and select “Apply as Column” using the pop-up panel that appears

  • Snap open the “IEEE 802.11” section of the decode panel
  • Snap open the “QoS Control” section
  • Right click on the “Priority” field and add this as a column:

Our Wireshark display should now look like this, showing our new 2 columns:

If we now go back to our column preferences, we can see our new column definitions and re-order and rename them if desired. (Edit > Preferences > Columns):

One caveat to the information process presented in this article is that the fields that are available may vary slightly depending on your capture environment. For instance, you should see all the fields relating to 802.11 frame headers and content, but the 802.11 Radio and Radio Tap header information is specific to the capabilities of your capture setup and the additional frame information it can (or cannot) provide.

Obviously, the custom column feature can be used to provide a wealth of additional summarized information. By selecting any field within a frame capture, it’s possible to add columns to make the frame review process more informative. I’ll leave it up to the reader to experiment with this feature, but other valuable fields in a wireless environment include: retry bit, channel width and channel number. Enjoy!


Final Columns View


Thanks to Eddie Forero for telling me about this...I don't really know much about Wireshark, but guys like him make me look smarter by sharing their knowledge! :)

Saturday, 13 May 2017

Preserving Your Survey Gear: Hub Holster

If you carry out wireless survey activities, you’ll be painfully aware how much your precious survey kit cost you. And, I’m pretty sure you want to keep it in pristine, working condition. Here is a great little add-on for your kit that can help preserve your survey laptop and your survey wireless NICs.

The Problem

Yes, I know it’s not fashionable to use the word “problem” anymore, but if you’ve ever been surveying on site and had a passing pedestrian or unexpected filing cabinet damage one of your wireless survey NICs, then you know that it’s a “problem”.

Fig.1 - This is never going to end well...

When performing on-site surveys to measure Wi-Fi network coverage or performance, there is generally a requirement to have one or more wireless NICS or dongles attached to a survey laptop. These cards gather data to feed into survey software as a survey engineer moves around a coverage area.

However, plugging the cards into the standard USB ports on your laptop can mean that they are protruding from the sides of your laptop, making them fair game for getting bent or ripped out by unseen items of furniture and passers-by. Also, many laptops may not have a sufficient number of USB ports for survey purposes. Many survey engineers have taken the sensible step of getting hold of a USB hub and mounting it on the lid of their survey laptop to keep things out of harm’s way and provide sufficient USB ports for their requirements .

Attaching a USB hub to the laptop can be something of a challenge. Well-known methods include gluing velcro strips onto your survey laptop lid and using wire twists that have been fashioned into a supporting loop. Neither are particularly “robust” over time when used on a frequent basis.   

The Solution

Enter the “Hub Holster” to save the day!

The Hub Holster is a great solution to mitigate issues around securing your USB hub to your survey laptop. It allows USB hub mounting without any of the glue or other damaging attachment methods. It simply clips onto your laptop screen, providing a firm, robust support bracket for a USB hub during surveys.

Fig. 2 -  A handsome, practical solution for fixing your USB hub

Hub Holsters are produced by Robert Boardman. As each laptop model has slightly different dimensions in terms of screen thickness, bezel size etc., Rob produces a range of his 3D printed brackets for various laptop models and a range of commonly used USB hubs. If you send him the dimensions for your laptop screen he can even print you a custom Hub Holster for your particular laptop (which he did for me!).

I bought a pair of Hub Holsters for my Macbook Pro and my Lenovo laptop and they are excellent.

Fig. 3 - This is what they look like out of the packet

I personally think the Hub Holster is a very worthwhile investment. No more sagging velcro mounts, no more glue on your laptop lid, no more NICs sticking out at 90 degrees and no more twisty bits of wire to try and hang the hub on your laptop lid. And, far less chance of any damage to your precious survey kit. For more info, please see the links provided below (and order yourself a me):

Fig. 4 - One more pic, this time without the dongles

Wireless Engineer Locator Tool

If you’re looking for a wireless survey engineer for a forthcoming Wi-Fi network project, or you’re a wireless survey engineer who’d like to snag a few new customers, here is a great site you’ll want to check out!

I was lucky enough to attend the Wireless LAN Professionals Conference in February of this year (2017). Among the feast of Wi-Fi presentations and products was a very nice survey kit offering from a company I’d not heard of before called HiveRadar. They offer a complete survey kit in a flight case for survey engineers. The beauty of this kit is that it has everything you need to perform an on-site, “AP on a Stick” survey packed into one, robust flight case (yes...even the survey pole!). If you’re a Wi-Fi engineer, this is certainly an offering you will appreciate, particularly if you have to do plenty of plane journeys.

Fig1. Engineer Locator

However, in addition to their great products, one thing that really caught my eye was an “engineer locator” tool that is available on their web site. The locator shows a map of the world, with little “HiveRadar” pins sprinkled across various countries. Each pin represents the location of a wireless engineer. If you click on any of the pins, you can access the engineer details, including their bio, qualifications, experience, and vendor expertise. It also provides a  contact form so that you can get in touch directly with the engineer so that perhaps you can talk to them about possible engagements etc.

Fig2. Engineer Details

If you’re a wireless engineer, you might assume that this superb service is only available to HiveRadar customers. But, no, you’d be wrong! HiveRadar make this service available to any wireless engineer (for free!) who’d like to submit their details and sign-up. There is a slight delay between sign-up and appearing on the locator page, but I assume this is due to a checking process.

If you’re a wireless engineer, I’d strongly recommend you get along to the HiveRadar site and register yourself on their locator page - who knows who may be looking to get hold of your services!?. Similarly, if you’re looking for a wireless engineer to help you out with your next Wi-Fi project, this is a great place to check out engineering talent in your area.  


Tuesday, 28 March 2017

Cell Edge Specification Notation (CESN)

When it comes to designing WLAN RF environments, everyone seems to have their favourite cell edge signal level that they like to shoot for. Common figures include -67dBm for voice grade WLANs, maybe -60dBm for higher 802.11ac speeds and perhaps -72dBm for general data traffic coverage. Each vendor and wireless consultant seems to have their own preferred cell edge design target that will vary with WLAN requirements. However, these figures are meaningless without some type of explanation or context. If you rely solely on these types of figures, you are very likely designing incorrectly....

Around 18 months ago, I was involved in a project that required the deployment of a new wireless LAN network at many sites around the globe. The project required that all sites would be subject to the same standard of RF parameters to provide a consistent design approach at all sites.

A team was sent to the first site to perform an “AP on a stick” survey using an AP of the same model that would be deployed for the final solution. The results from the survey report looked very good - we were hitting the coverage and capacity levels we were hoping for. We had a well defined threshold for (amongst other parameters) the cell edge signal level we wanted to achieve (let’s call it -62dBm).

Another team was sent to a second site in another part of the globe to perform another survey, using the same survey thresholds. They were using the same survey software, the same type of survey AP (with the same settings) and were working to the same cell edge figure of -62dBm.

Both buildings were primarily large, modern, open plan offices.

However, the results in the two survey reports were hugely different in terms of the cell coverage achieved for the same AP transmit power. The physical cell size for each AP cell (at the same cell edge threshold) in the second survey was 50% or less of that observed in the first survey. We would would need twice as many APs for the second site even though they were being designed to the same RF standard.

This couldn’t be right..could it? Two surveys done with the same software, in similar environments, using the same survey thresholds with twice as many APs required in one survey compared to the other? Something just didn't make sense. We would expect similar AP cell sizes and similar AP densities at both sites.

After lots of head-scratching, configuration checking and re-surveying the culprit of the huge difference in survey results came to light: the two teams had surveyed with different wireless NICs in their survey rig. One had used Proxim adapters, while the second team had used Netgear adapters. Both were valid adapters supported by the survey software, but they gave wildly different survey results due to their different RF characteristics.  

Which adapters were giving the correct results? In the absence of any other data, then they were both, arguably, correct.

Which Clients Are You Designing For?
The fundamental flaw in this survey approach was the lack of specification of the wireless NIC to be used to perform the survey.

Each model of wireless NIC is likely to have very different RF characteristics in terms of antenna capabilities and RF sensitivity. As a minimum, the model of wireless NIC to be used for the surveys should have been specified. This would have perhaps at least ensured that the surveys would achieve reasonably comparable results and a more consistent RF design.

(Note: even models of the same wireless NIC may vary from device to device due to manufacturing tolerances, so there will still be a variation of a few dB between devices)

The solution to this issue was to ensure that all survey teams used the same type of Proxim adapter. The results from the different survey teams were far more comparable once this standard approach had been agreed.

However, even this approach had flaws. The survey cell-edge threshold was provided by a 3rd party, based on their previous general design experience. A better approach would have been to design for the RF behaviour of a specific device or devices, based on customer requirements.

The best-practice approach is to understand the behaviour of one or more of the clients that will use the wireless LAN and tailor the RF environment for those devices (as closely as possible). This is incredibly difficult to achieve in the real world, as there are likely to be many different types of client with a variety of RF capabilities and behaviours. The choice of which RF characteristics to design for will have to be a judgement call based on business requirements and priorities.

Once a decision has been made around which device will be used for the design decisions, then the RF survey criteria will need to be decided.

As an example, let’s assume that the primary device on our WLAN is an Apple iPad Mini 4, as we have many deployed across our network for a mission critical service . It also happens (in this theoretical scenario) that a few other devices on our proposed WLAN will have quite similar characteristics, so this RF design will suit quite a few other devices too.

We have also seen from a vendor wireless design guide that a useful cell edge design threshold is -70dBm for Apple devices. Therefore, we will use this as our cell edge threshold.

However, we will be performing our survey with a Proxim wireless NIC. The iPad Mini 4 is not able to run our wireless survey software, so we have to run it on our laptop with the Proxim adapter.

We suspect our Proxim adapter is going to have very different RF characteristics to our iPad Mini 4. But, we want to design our WLAN network with cell edges of -70dBm, as seen by an iPad Mini 4 (not a Proxim adapter).  Cell sizes at -70dBm for a Proxim adapter are likely to be very different to those of an iPad Mini 4.

Therefore, we need a way for the Proxim adapter to see the RF world in a similar way to the iPad Mini4. This is generally done using a “compensation” technique.

In summary, when we compensate for our survey adapter in a survey report, we add (or subtract) a dB  offset to/from our survey data to account for the different in the survey NIC and the required client that we are trying to emulate.

For instance, we might set up a test access point and measure the signal level we observe at a distance of 6 metres (20 feet) with the Proxim adapter. We would then measure the signal level with a wireless client (e.g. our iPad Mini 4) at the same distance. The difference between the two signals observed is the offset we need to apply to our survey data.  

As an example, if the survey NIC showed a signal level that was 5dB stronger than the client, we would have to apply an offset of 5dB to signal levels in the survey data. If we were aiming for the -70dBm cell edge we previously discussed, the cell edge shown in our report would be -65dBm, as we know that this would be observed as -70dBm by our wireless client.

Signal Level Specification
Hopefully, the discussions above will underline need for some form of context or reference when specifying a signal level for an RF design cell edge. Simply stating that we need to: “design for voice to cell edge of -67dBm” is meaningless without further information. The key piece of information missing is the specification of which device observes the cell edge.

There is a common (often unspoken) rule around cell-edge signal level specifications among wireless LAN pros. A signal level is generally accepted to be that observed by the client device that is in-use. For instance, if a design guide specifies that a cell edge of -67dBm for voice handsets be used, experienced WLAN pros will assume that this signal level is measured with the actual voice handset.

However, this assumption is not widely understood or is often unknown. Many people performing a wireless design will not even consider that there may be a difference between their survey rig and the clients that will use the final deployed WLAN.

I believe there needs to be a better, unambiguous way to specify signal levels, particularly for cell edge measurements in WAN survey work.

Signal Level Notation
SIgnal levels need to be expressed in a less ambiguous format. The information about the expectation of how the signal level is to be measured needs to be embedded in a standardized notation.

If we consider the case of “AP on a stick” surveys, we have two methods of specifying the cell edge signal we’d like to aim for:

  • A signal level as seen by a specific client type (e.g. -70dBm as seen by an Apple iPad Mini 4)
  • A raw signal level value that we’d like to use with our survey adapter (e.g. we know that our adapter works well for many Apple devices at -65dBm from previous work or compensation testing, so we’d like to use that specific value)

We may also have a third method of specifying signal levels if performing predictive modelling with a wireless survey tool. Predictive models will generally provide “raw” signal levels based on Free Space Loss, which will not account for an adapter or client type. With some of our own real-world vs predictive testing, we may be able to specify a suitable predictive signal level which is suitable for our purposes.

To meet each of these three scenarios, I’d like to propose the following notation specification:

<signal level in dBm> (<measurement type>: “<device type”)

The ‘measurement types’ would be specified as:

UC = Un-compensated
CF = Compensated For
PM = Predictive Model

Here are three signal levels, specified using the proposed notation:

  • -65dBm (UC: “Ekahau USB-300”)
  • -65dBm (CF: “Apple iPad Mini 4”)
  • -65dBm (PM: “FSPL”)

These translate to

  • -65dBm (UC: “Ekahau USB-300”) : a signal level of -65dBm that is a raw (un-compensated) measurement made with an Ekahau USB-300 NIC
  • -65dBm (CF: “Apple iPad Mini 4”): a signal level that has been compensated for a value that would appear as -65dBm to an iPad Mini 4 device
  • -65dBm (PM: “FSPL”): a signal level that uses a free space loss measurement as represented in a predictive model.

RF design for wireless LANs  is a complex topic, which is very difficult to “get right” in the real world.

However, it is very easy to “get it wrong” through simple misunderstandings and the lack of standardized reference points for RF measurements.

Although the proposed signal level notation adds a little more complexity to the mix when creating an RF design, it does removes a level of ambiguity from signal level specifications. This will hopefully provide a more consistent WLAN design methodology across the industry.

I’d be very interested to hear your thoughts on this.