WLAN general

WPA2-Personal Encryption is Now Pointless.


“It is a secret in the Oxford sense. You may tell it to only one person at a time.”

– Lord Franks (1905-1992) English academic, diplomat and philosopher



In the world of telecommunications and technology, nothing lasts forever.  When it comes to the issue of security, nothing is ever truly secure and nothing stays unbroken.

Consider the case of good old Hashing Algorithm SHA-1.  For years researchers have been warning that SHA-1 is weak, and have been actively urging people not to use it for securing their websites and any other encrypted traffic.  Earlier this year, some researchers at Google managed to break it in practice, defining the end of SHA-1’s useful life and forcing many to update their security policies.


A similar problem has been ominously looming over the WLAN industry for several years.  It has to do with WPA2-Personal, a method widely used to limit access to and encrypt Wi-Fi networks at homes and at workplaces around the world.

For the less technical, WPA2-Personal is also known as WPA/WPA2 Pre-Shared Key, used to control access to the network and encrypt Wi-Fi traffic between a Wi-Fi client and the Access Point using a simple passphrase.  This is the de facto method by which small business owners, home owners, and many other network owners secure and encrypt their networks.

“What’s the password for the Wi-Fi?” is a common refrain in hotels, restaurants, homes, coffee-shops and many other social gathering places all over the world.

WPA2-Personal is extremely popular as it allows you to use an easy to remember passphrase to access your home network.  If someone you know (and trust) needs access, it is as simple as typing in the passphrase.  The encryption algorithm itself (CCMP using AES-128) is strong and the use of unique, dynamic keys, negotiated using a four way handshake between the client and AP to encrypt traffic, keeps things reasonably secure.

What is the Problem?

The problem with WPA2-Personal comes in when you start telling people the passphrase.  To be precise, the problem with WPA2-Personal is not that the encryption algorithm itself is weak like in the case with SHA-1 above.  The problem is that the single key that unlocks everything, spreads by word of mouth.  Eventually, you need to expect that password will land up in the wrong hands.

For those of you into the sciences, think of your WLAN passphrase (all passwords actually) as having a kind of half-life.  As time goes by, their security level decays.

Problems caused by unknown, untrusted people having access to your WLAN’s WPA2-Passphrase come in two general flavors.

1. Easy Access

First of all, we have all, always known that gaining access to a WPA2-Personal secured Wi-Fi network is trivial if you know the key.  It’s built that way by design!  It is supposed to be convenient and easy to gain access.  Once you know the key you can gain full and unfettered access to the wireless network.  If there are no further security policies in place (typical in a small business/home WLAN scenario) you can move around in the network and use whatever resources you want.  Copy some data from the Network Attached Storage, start a peer to peer session with a laptop across the hall, access some sensitive files, it’s all right there.

If you connect to my home WLAN, you have access to everything in my home network.  You can see my NAS drives, my Apple TV, my laptops, my phones, everything.  These networks are typically not built to be secure, they are built to be convenient, to provide plug and play functionality.  An attacker can run port scans on any device in the network, test for open services and vulnerabilities, and inject their own programs, malware etc into the devices on the network with impunity.

2. Easy Decryption

Here is a second, lesser known fact about WPA2-Personal encryption.  Even though your device uses the WPA2 Pre-Shared Key to negotiate unique dynamic keys which are used for strong encryption, that too can be easily decrypted.  As long as the Pre-Shared Key is known and the four-way handshake between your device and the AP has been recorded, your communications are vulnerable.  If I don’t have a capture of the four way handshake, no matter, I can simply de-auth you from your own network, and listen for it as you reconnect.

In this scenario, an attacker would be able to capture and decrypt all of your real time communications that are not encrypted at a higher layer.  It also opens the ability for the hacker to conduct more intrusive attacks that would not have been possible before.  For instance a Man In The Middle Attack mimicking the AP would allow an attacker to observe your online communications and decrypt HTTPS / SSL secured web traffic.

If you ever use a hotspot in a coffee shop and think that it is secure because it has a password, think again and keep the VPN app on your devices running!

Making it Worse

For those focused on securing networks with more sensitive information than the average home, WPA2-Personal has always been considered a non-starter.  It is widely accepted that no network that requires strong security policies and access controls should be using it.

WPA2-Personal has been deemed suitable for home snd small office use due to the fact that typically, passwords in the locations spread more slowly, and only amongst small groups of trusted individuals.  If an unwanted neighbor or visitor starts hogging the Wi-Fi, change the password and start again.  It’s a simple system to manage, and not too arduous or risky.

More recently however, there have been some developments that have prompted me to state flatly that WPA2-Personal is simply no longer good enough, even to secure your home network.

First came Wi-Fi sense, a magical feature in Microsoft Windows 10 that shared Wi-Fi passwords with your contact list and social media connections.  The problem with Microsoft’s move (even though they later removed the feature) is that it automatically allowed a large audience of people access to your network without your explicit permission.

In the iOS 11 release, the implementation of Wi-Fi password sharing is more limited and only activated with the explicit permission of someone who has the key.  Lord Franks would be proud!  I consider this implementation to be not completely irresponsible, but the original problem of passwords being slowly spread, one unauthorized person at a time is still there!

Crypto-Wi: Hold My Beer!

Enter Crypto Wi, a new crypto-currency startup and experts of computer aided voice overs.  Crypto-Wi have launched a scheme that puts even Microsoft’s naivety to shame.

Their idea?  Monetize the sharing of Wi-Fi pass-phrases.

Thats right, you heard me.

With the Crypto-Wi app you will be able to not only share a Wi-Fi password, but get paid with a crypto currency to do so.  Every time someone connects to the network you shared, you will earn a little bit of dosh!  You can head over to their website and check out the app here.

On the surface this looks like a fantastic, innovative project for enabling people to buy and sell cost effective Wi-Fi Access.  I am fairly sure the three founders of this endeavor are working with the best of intentions, but the potential adverse effects from the disruption they are proposing reach far deeper, into a much more cynical place.

Not only do we live in a world where it is becoming easier and easier to carelessly/maliciously share a WPA2 password, we live in a world where people can actually profit off of it.  It is now being incentivized.

Password Sharing Scenarios

Let’s say that you decide to rent out your home WLAN access, that’s pretty cool, and pretty nifty.  But remember, unless you’ve taken extra security measures like an internal firewall, whoever is on that network, can get into your whole home network.  People you don’t know, who have never entered your home, can pay a small amount to use your Wi-Fi, and get to the internet.  They can also scan your local area network and start freely withdrawing and depositing information at will.  Still feeling comfortable?

What about when one of your friends comes over and he/she brings another friend.  They both use the Wi-Fi and later on, your friend’s acquaintance sells your Home WLAN access on Crypto-Wi?

  • Would you even be aware that there was a problem?
  • How do you get rid of all of the free-loaders?
  • Change the password?

Yeah that used to work, and it might give you some respite for a couple days until your friends come back, but it is not the solution it used to be!

What about a scenario where you own a business, say a restaurant, and a non-technical, foolish employee sells off the internal wireless access on the side?  It was never in that person’s interest to do this before, but now that they can make some money from it, why not? The boss will never know, right?

The list of scenarios like this goes on and on.  I am sure you can think of a few on your own.

A Shifted Paradigm

Truly the only thing holding WPA2-Personal from being declared completely and utterly pointless is that passwords typically take some time to spread, one person at a time.  We know that passwords spread through family homes and small businesses, but at least it is somewhat contained.  With a service like Crypto-Wi that whole paradigm of thinking gets blown out of the water!

In this paradigm, using WPA2-Pre-Shared Keys is actually worse than having an open network!  At least with an open network a business owner may have a hotspot portal or some other form of control that limits access!

In this paradigm, anybody can come and go and the business owner will have little idea that it is even happening until the data cap is mysteriously maxed out over night.  Or perhaps the Internet connection will get so clogged and slow that they will call out a technician to come and “fix it”.  In most scenarios, even the technicians won’t realize the real source of the problem.

In a darker and more likely scenario the problem won’t get caught until the business’s bank accounts are emptied or the branch gets a call from the franchise’s head office notifying them that their shop network was the entry point of a global hack of the PoS systems.

In any of the situations above, any malicious party could now easily use Crypto-Wi’s app and pay an anonymous person to join a network without even raising an eyebrow.  They wouldn’t even have to enter the venue and ask for the damn password.

Effectively, Crypto-Wi has built a fantastic business model for dismantling what little security Wi-Fi ‘s WPA2-Passwords once granted.  They have found a way of sharing the Pre-Shared Key indiscriminately and widely enough that it has made the security offered by the actual encryption algorithm irrelevant.  We could use AES-256 and it would make no difference.

The best part is that they have demolished the security of WPA2-Personal in a way that allows them to profit from it without paying a single cent for any of the potential costs of the access they sell or the damage their service will enable.

But is it (really) Dead?

It is my experience that ideas like this do not go away.  Even if Crypto-Wi’s service dies, or never reaches the mainstream market, there will be some implementation of this idea somewhere else.  This kind of application cannot be regulated and will be impossible to police.  Crypto-Wi or any other group with the same idea would have little way of verifying network owners even if they wanted to.  Enforcing restrictions on verified contributors who add networks would simply leave space for another less ethical party to attempt the same service with a lower barrier to entry.

In the case of SHA-1, we chose to accept that evidence of a single practical collision in the hashing function was sufficient to finally declare it dead.  In the case of WPA2-Personal it is not the encryption algorithm itself that is at fault, but rather the way key management is executed and how the ground underneath some assumptions made 13 years ago has suddenly shifted.  It is now possible to share a network key with a wide audience, instantaneously, for direct monetary gain.  Sure, you may work in a company full of responsible adults.  You may trust your friends.  But you can’t trust everyone, and everyone who wants to, can now potentially buy your password.

As far as I am concerned, you can stick a fork in WPA2-Personal.  It is now in the same box as WEP and WPS.  If someone wants to break it, it is rapidly becoming trivially easy to do so.

Thats all for now!

WLAN general

Is LTE-U Really Wi-Fi’s Great Challenger?

So I will admit I am writing this in a fit of pique.  Today Bloomberg published this preposterous piece of marketing flimflam claiming that LTE-U has the potential to replace or drown out Wi-Fi.  I am not sure if the consultants quoted in that article are drinking kool-aid together, but I certainly feel like they have missed some key points.

So I am going to ask one very simple question:

What does LTE-U enable that Wi-Fi doesn’t?

Answer: The ability to seamlessly charge a customer for its use, without any knowledge, or intervention required by the customer.

OK, so that’s a pretty big carrot for the mobile operators! I mean imagine.  They could give a customer an unlimited data plan, the subscriber can move anywhere around the mobile network, indoors and outdoors.  Mobile operators finally get to remove the need to deploy Wi-Fi and the motivation for subscribers to use it in the first place.  LTE-U keeps them on the mobile network and they can do it cheaply with the unlicensed 5GHz spectrum!

Holy crap! Wi-Fi is dead yo! We comin for you Wi-Fi!  Cry ‘havoc!’ and let slip the dogs of war!

Ahhh. Indeed. This is exactly the kind of blinkered thinking demonstrated by mobile operators, the 3GPP and anyone involved in mobile telecommunications that causes me to sneer.

Let me ask another question:

What does Wi-Fi provide that LTE-U doesn’t?

I hope you’re ready.  School is commencing.

Local Area Networking

Contrary to the opinion of those who move exclusively in mobile operator circles, Wi-Fi networks are actually not only built to handle Internet bound traffic from hotspot users and subscribers.  In fact that is likely an incidental service that resulted from what they were actually developed to provide.  The primary purpose of a Wireless LAN is to allow mobility over a venue’s own local area network.  Services enabled by Wi-Fi or WLANs include:

  • Corporate / Operational Communications
  • Security Systems / Services
  • Video Surveillance
  • Building Automation
  • Internet of Things Applications
  • Voice over IP
  • Touch to Talk services
  • Real Time Location Services (Security Personnel, Doctors, Nurses, Asset Tracking…)
  • Digital Advertising Boards
  • Point of Sale Terminals
  • Ticketing Machines
  • Medical Devices
  • Back Office Connectivity for Stores / Shop Fronts
  • Location Based Services / Location Tracking (location analytics, more asset tracking etc)
  • Public Internet Access (The ONE thing LTE-U actually currently enables)
  • Targeted Digital Advertising
  • Customer Engagement
  • Marketing Campaigns
  • … and any other service you recently used on or integrated with a Wireless LAN.

LAN connectivity is a fundamental and critical function that LTE-U simply cannot provide in its current form.  Wi-Fi allows you to setup a radio and plug it directly into your Enterprise LAN.  LTE-U can’t do that.  LTE-U traffic must go via the mobile operators’ Packet Gateways which means all traffic gets hoovered up, sent into some operator’s core network and is then popped out on a public IP in some APN based on who your sim card says you are.  Good luck getting back to the LAN with a reasonable latency.  Also, please explain the complicated architecture, SLAs, agreements, firewall rules / VPN tunnels and identity management that a mobile operator would have to implement to get a heterogeneous group of SIM authenticated users back into a venue’s LAN from multiple APNs.

LTE-U is coming and it is indifferent to your Enterprise LAN, distinctly unfriendly to your Wireless LAN and it could arguably interfere with the very wireless networks that most venues depend upon to operate on a day to day basis.  Which brings me to my next point.

Value to the Venue/Business Owner

Time for another question…

If you were a venue owner, with a WLAN that you used for a mixture of corporate, operational and public access use cases, would you be happy about LTE-U being installed in your building?

What value does LTE-U actually add to a venue?  Sure people will be walking around with smiles on their faces as they stare obliviously at their phones.  But what do I get out of allowing LTE-U in my Office, School, University, Warehouse, Logistics Center, Hospital,  Shipping Port, Airport, Care Facility, Residence, Stadium, Convention Center, Mall, Coffee Shop or Train Station?  I’ll probably get a ticked off IT engineer and a slew of complaints from all my tenants who are currently using Wi-Fi for business related functions.  I have no doubt, LTE-U will find some use in public venues.  But in my office? Where it effectively DOS attacks my WLAN with radio interference on a duty cycle determined by the mobile operator?

When LTE-U is allowed into a venue, the venue owner will ultimately have to accept some form of performance degradation on the Local Area Network, for which they could charge a sizeable rental fee.

LTE-U deployments are likely to be hobbled by high rental costs and restrictions on the density of their deployments, in an effort to mitigate interference with existing WLANs in the building.  It also means that operators will likely have to share LTE-U installations using Neutral Host architectures.  Limitations on deployment density and spectrum usage enforced by the venue owner and tenants will cause LTE-U deployments to suffer congestion just like the outdoor macro network does.  Don’t like it?  The venue owner has every right to show you the door.  You’re not hobnobbing it at MWC anymore Dorothy.  Site acquisition is hard when you’re pissing people off.

Ubiquitous Device Support

Many of the top end smartphones like the iPhone 7, Galaxy S7, Google Pixel and others already contain LTE modems with support for LTE-U.

Here are some useful links:

But these are the latest, greatest phones.  And it’s just the phones.  There is no major existing use case outside of it.  If you want your new technology to wipe out Wi-Fi, you need to be in every phone, every tablet, every laptop, every mini PC, every gosh darned thermostat, camera, doorbell, pet cam, smart plug, tv and a bazillion other things that didn’t come up on Google’s suggested search items.

Connect Devices without Sim Cards

At this point, if you don’t have a sim card, you can’t connect to LTE-U.  Market researchers IDC expect cellular connected tablet devices in 2019 will still account for less than half of all tablets.  Granted many consumers will simply tether their devices,  but that would ultimately load the LTE-U cell to the point where consumers will want to cut back over to a faster Wi-Fi network on a different channel.  Multefire is one technology which could remove the need for a sim card, but nobody seems to be rolling that out just yet and device support is still a problem.

Low Cost Wireless Access

In the article above there is a claim about the cost of LTE-U small cells.  The estimate is that deploying approximately 24 LTE-U radios is comparable to the cost of deploying 80 Wi-Fi access points.  Which Access Points?  High End Enterprise APs that are worth ±$1500 each?  Or low end SMB entry level APs that sell for around $150 each?  There is a big range in price points for Wi-Fi Access Points and that is a great thing! It means that just about anyone can find something that will work and fit their budget.   There is no such range of pricing and features on LTE-U today.  I am also certain nobody would be investing in this technology if the starting price of the first LTE-U AP to market was only $450 (wink).

Cheap International Roaming

This is hardly a technical constraint. but still a valid one when considering the use cases of LTE-U.  If you want to hop onto an operator’s LTE-U network overseas, sure go right ahead, so long as your home operator has a roaming agreement that doesn’t utterly annihilate your bank balance with fees as high as $10.00 per Megabyte.  Quite seriously, where I come from, if you don’t activate a special “travel saver” option for about $3 per day, they hit your bank account with the Hammer of Thor.  Who on earth connects to a mobile operator overseas with data roaming enabled when you know there is free Wi-Fi somewhere?

Obviously, the solution to this particular problem is a simple business decision (har har), just make cheaper roaming agreements.  Some of you reading this may not have this problem.  But really if the operators wanted to do this internationally, they would have done it already.

Mass Customization

One of the most overlooked advantages of using a Wi-Fi network anywhere is that Venue / Business Owners are free to build an almost infinitely customizable network for all of their internal IT needs and public access services.  Business owners can choose from a plethora of architectures, vendors and solutions providers to build something that meets their exact requirements.

The only initiative that could enable this is the Multefire Alliance who have only just recently released their 1.0 specification. They have some a reasonably impressive member list,  but I’ve seen groups with impressive member lists before.  Importantly there are other technologies out there like Ruckus Wireless’ OpenG that uses the CBRS band for Neutral Host Small Cells and opens up new spectrum!  Either way, LTE-U initiatives have a lot of ground to make up and a big ecosystem to develop within two years before 802.11ax comes wandering round the corner.

Thus far with only Ericsson and Nokia having approved equipment in this space I cannot see how LTE-U will deliver a remotely attractive enterprise use case to snuff out the venerable Fi.

In Conclusion

To think that LTE-U could somehow match Wi-Fi’s depth and breadth of applications for the enterprise in only a few short years is a pipe dream.  Mobile Operators generally have no business interests in common with business / venue owners and typically want as little to do with their enterprise business needs as possible.  You’re never going to be happy with the one size fits all approach that a mobile operator will take to solving what they see as their biggest problem.

The most interesting technology in the LTE-U space right now is actually MulteFire which really could enable something like LTE-U or LAA (which doesn’t affect Wi-Fi as badly) for enterprise use cases.  But there is little evidence right now to demonstrate that this technology will truly get off the ground before the marginal performance gains it delivers over Wi-Fi are matched by newer generations of Wi-Fi equipment.  Until that point, LTE-U and LAA are going to be relegated to the Service Provider segment which by all accounts is only a fraction of the overall WLAN landscape and operators trying to install it will have an uphill battle with venues who already have a WLAN that delivers business value.

That’s it, Rant Over.

It is also worth mentioning that Dean Bubley did a great job of breaking the same topic down here.

Linux WLAN general

Using the ODROID C2 as a WLAN Testing Tool – Part 3: Some Exploring and Installing wicd

Previous Articles in this series:

  1. Install & Preconfigure DietPi
  2. DietPi, First Boot

In the previous posts in this series I took a look at how I installed and configured DietPi on my ODROID C2.  I also went through the settings and some software packages that I wanted to install on the first boot.  I should re-iterate here that one of the goals of this series is not to blandly show the reader how to do things, but also to try and learn more about how a machine like this fits together.  So as I go along you may see me point out some things that have more to do with Linux or DietPi or other topics.  They may also seem obvious to you or not worth explicit mention.  I am doing this is in the spirit of sharing the totality what I learn along the way, so that you the reader may benefit.   I am also doing it so I can come back and read it later when I forget… (it happens more often than not!)

Initial Exploration

Right so, at this stage, you have booted your ODROID or other SBC (Single Board Computer) for the first time, you have logged in and you are now at the command prompt.  I am assuming you weren’t adventurous enough to add a desktop and you are simply booting into the standard command line.  You may still have the ODROID connected to your screen and keyboard, and that’s fine too.  Go ahead and login (if you haven’t already) and let’s take a look around.


You should be at the User@HostName~:# prompt.  Let’s have a look at our present working directory and a few other things…

root@Droid-01:~# pwd

Ok, so our home directory is /root.  Let’s go up to the top of the directory structure…

root@Droid-01:~# cd /
root@Droid-01:/# pwd
root@Droid-01:/# ls -a
. .. bin boot dev DietPi etc lib lost+found mnt opt proc root run sbin srv sys tmp usr var

Let’s go back to the home folder and have a look inside there…

root@Droid-01:/# cd
root@Droid-01:~# pwd
root@Droid-01:/# root@Droid-01:~# ls -al
total 10
drwxr-xr-x  4 root root 1024 Feb 25 17:29 .
drwxr-xr-x 20 root root 1024 Feb 25 16:58 ..
-rw-------  1 root root  212 Mar  3 23:24 .bash_history
-rw-r--r--  1 root root 3526 Feb 25 17:29 .bashrc
drwxr-xr-x  3 root root 1024 Feb 25 17:29 .config
drwxr-xr-x  2 root root 1024 Feb 25 17:29 .local
-rw-r--r--  1 root root  140 Feb 25 17:29 .profile

Neat OK, so we have a 1000 mile view of where we are and what we are dealing with (actually, at this point we really have no idea!)

DietPi Tools

One of the cool things that DietPi OS comes with is a set of menu based tools for configuring your SBC and for installing optimized versions of software.  Let’s go and find out where those are…

root@Droid-01:~# cd /
root@Droid-01:/# ls
bin boot dev DietPi etc lib lost+found mnt opt proc root run sbin srv sys tmp usr var
root@Droid-01:/# cd DietPi
root@Droid-01:/DietPi# ls
boot.ini config.txt dietpi dietpi.txt
root@Droid-01:/DietPi# cd dietpi
root@Droid-01:/DietPi/dietpi# ls
boot             dietpi-backup     dietpi-cleaner    dietpi-cpuinfo dietpi-drive_manager dietpi-letsencrypt dietpi-obtain_hw_model dietpi-ramlog   dietpi-survey finalise misc
conf             dietpi-banner     dietpi-cloudshell dietpi-cpu_set dietpi-funtime       dietpi-logclear    dietpi-process_tool    dietpi-services dietpi-sync   func
dietpi-autostart dietpi-bugreport  dietpi-config     dietpi-cron    dietpi-launcher      dietpi-morsecode   dietpi-ramdisk         dietpi-software dietpi-update login

The three main applications you will use are:

  • dietpi-launcher: A full menu for optimized software selection, HW config, autostart settings, cron jobs, management of external drives and updating dietpi
  • dietpi-software: Allows you to run configuration and select software for dietpi to install.  Also available in the dietpi-launcher menu.
  • dietpi-config: This allows hardware configuration changes and optimizations.  Also available in dietpi-launcher and dietpi-software menus.

Go ahead and try each of them, you will realize you’ve already used them to install other software during the first boot!

Pre-Installed Software

After the first boot and configuration, you should already have some network tools installed.  You should be able to use iftop, iptraf, iperf, mtr, nload and tcpdump.

You should also have access to some useful text editors, I only have Vim and Vim-Tiny installed (I don’t need both, I was just being greedy!)

If you want to check out what other executable programs are included in your DietPi system, use cd /bin to open the /bin directory and use the ls command to have a look what’s there.

root@Droid-01:~# cd /bin
root@Droid-01:/bin# ls -a
.       bzip2recover dash          fbset      ip         login       mount            ntfscat       pidof     setfacl    systemd-ask-password           udevadm         zdiff
..      bzless       date          fgconsole  journalctl loginctl    mountpoint       ntfscluster   ping      setfont    systemd-escape                 ulockmgr_server zegrep
bash    bzmore       dd            fgrep      kbd_mode   lowntfs-3g  mt               ntfscmp       ping6     setupcon   systemd-inhibit                umount          zfgrep
bunzip2 cat          df            findmnt    kill       ls          mt-gnu           ntfsfallocate ps        sh         systemd-machine-id-setup       uname           zforce
bzcat   chacl        dir           fuser      kmod       lsblk       mv               ntfsfix       pwd       sh.distrib systemd-notify                 uncompress      zgrep
bzcmp   chgrp        dmesg         fusermount less       lsmod       nano             ntfsinfo      rbash     sleep      systemd-tmpfiles               unicode_start   zless
bzdiff  chmod        dnsdomainname getfacl    lessecho   machinectl  netstat          ntfsls        readlink  ss         systemd-tty-ask-password-agent vdir            zmore
bzegrep chown        domainname    grep       lessfile   mkdir       nisdomainname    ntfsmove      rm        stty       tailf                          wdctl           znew
bzexe   chvt         dumpkeys      gunzip     lesskey    mknod       ntfs-3g          ntfstruncate  rmdir     su         tar                            which
bzfgrep con2fbmap    echo          gzexe      lesspipe   mktemp      ntfs-3g.probe    ntfswipe      rnano     sync       tempfile                       ypdomainname
bzgrep  cp           egrep         gzip       ln         modeline2fb ntfs-3g.secaudit open          run-parts systemctl  touch                          zcat
bzip2   cpio         false         hostname   loadkeys   more        ntfs-3g.usermap  openvt        sed       systemd    true                           zcmp

Of course, you can learn about these commands all by simply typing their name and –help at the end!

Installing New Software

The DietPi OS we are using is a stripped down variant of Debian OS and so it uses the apt-get command line interface for installing and managing software.  If you want to learn more about apt-get, simply type apt-get –help into your command line on your SBC.  We are going to be using apt-get to install some useful software packages on the ODROID

wicd & wicd curses

At this point in my installation, I want to start being able to connect to other types of networks and I want an easy way of configuring them.  Linux typically uses the wpa_supplicant program to act as a network connection controller / manager and it is a very powerful tool.  But there is a catch.  The wpa_supplicant software comes with two front end programs to allow you to manage your network connections.  The first, wpa_gui offers a graphical user interface that I assume should be eas(ier) to use, but I cannot test as it is not included in DietPi and besides, I am using the command line user interface exclusively at this point anyway.  The second front end program wpa_cli offers a command line user interface.  Don’t get me wrong,  wpa_cli does have a help file, but learning all those commands right now seems a little ambitious.  If you want to see what I mean try:

root@Droid-01:~# wpa_cli --help | less

The “less” command is a great tool for showing terminal output only one page at time!

Back to the point: easily changing my network settings with a wide array of choices and settings. ENTER wicd and wicd-curses!  The key part about wicd is that it supports both a fully featured console interface as well as a graphical user interface and it should work across almost all Linux distributions!  So let’s get this installed, the commands you will want to run are below!

root@Droid-01:~# apt-get install wicd
root@Droid-01:~# apt-get install wicd-curses

DING! All done, so let’s go and have a look shall we?  Let’s open the console interface:

root@Droid-01:~# wicd-curses

You will see something like this.

Notes: When you enter the prefs menu, you will need to use something for page up / page down to tab between high level menus, best to Google that for your keyboard layout!  I have also found that if you are accessing your SBC remotely via SSH, and you open up wicd-curses and start playing with the network connections you are quite likely to interrupt the ssh session.  This is seems like a good tool to use with a display, keyboard and mouse… (cue my disappointed face!)

With that limitation in mind, feel free to wander around and use the tool to scan for networks (use the Refresh function), you can also set various preferences and configurations for different connections.  Enjoy exploring! Interestingly enough in this setup, ODROID-1 is set to use WPA-Personal / AES and ROBROBSTATION is set to use WPA2-Personal / AES, but wicd reports both as WPA2 because they both use AES.   You will also notice that wicd also gives you the ability to select the bssid that you want to connect to! That is VERY useful indeed.

That’s all for now… 🙂

Linux WLAN general

Using the ODROID C2 as a WLAN Testing Tool – Part 2: DietPi, First Boot

In the Previous Post,  I went through the basic steps of installing DietPi on an SD Card / eMMC card using the MAC OS terminal and preparing the network settings for the first boot.  If you are reading this post, you should have DietPi installed on your eMMC / SD Card and it is time to boot your SBC for the first time (if you haven’t already).   As a reminder, I am using the ODROID-C2 and will just refer to it as the ODROID from now on.

When the ODROID completes its boot sequence, you will be presented with a login prompt.  Enter the default username and password.  The ODROID will now enter an auto install mode and pop up with a console menu titled “DIETPI- SOFTWARE”.  We are going to use this console to configure our machine before it boots for the first time and see if we can save some time on installing software later!

We will go through the following steps:

  1. Configure the DietPi OS (Display, Locale, Language, Root password, network options…)
  2. Select Software to be installed
  3. Configure other settings (SSH Server, File Server, Log System, Web Server)
  4. Install the System.

Configuration Tasks

Enter the “DietPi-Config” context (Feature-rich configuration tool for your device).  These are the basics that you may need to configure on your device!

Display Options

I am using a Dell SE2416H 16:9 widescreen display, with resolution set to 1920x1080p @60Hz.  The ODROID can happily handle anything up to a 4K display, so you should be covered here.

Language / Regional Options

  • Set the locale to your local language preference.  Spacebar allows you to select/deselect any given locale.  TAB will move you to the <Ok> button to complete your selection.  I set the system to use the following locales:
    • en_GB.UTF-8 UTF-8 (You MUST keep this locale selected!)
    • en_US.UTF-8 UTF-8
    • en_ZA.UTF-8 UTF-8
  • I set en_ZA.UTF-8 UTF-8 as the default locale for the system.
  • Now set the Time Zone of the System
  • Now set the Keyboard Language Setting (my settings below)
    • Keyboard Configuration: Generic 102-Key (Intl) PC
    • Keyboard Layout: English (US)
    • AltGr Key: default
    • Compose Key: no compose key

Security Options

  • Change your root password from “dietpi”
  • Change the Host Name

Network Options: Adapters

You can set your Ethernet and Wireless networking configuration here.


  • Plug in your Wi-Fi adapter (if it isn’t already plugged in)
  • Enable the Wi-Fi (if it isn’t already enabled)

Re enter the Wireless Network options menu: (my choices for my location in bold)

  • Set the country code: ZA
  • Mode: DHCP / Static
  • Select “Scan and Connect” to join a WPA / WEP capable network.
    • Enter the Passphrase
  • OR Manually Set Wireless Details
    • Enter the SSID
    • Enter the Passphrase

NOTE: Only WPA-Personal & WEP WLANs are supported at this point!

Apply your changes, wait to re-enter the menu, you should see the IP address of the wireless interface now along with the PHY rate and Signal Strength.  Exit the Wireless Network Options menu by using  the <back> button.

That’s it for “DietPi-Config”.

Software Optimized:

We aren’t going to add anything from this list just yet.

Software Additional:

Enter the “Software Additional” Context, scroll down to “Network Tools”

Network Tools:

We are going to install all of the available Network Tools. Why? Because you’d rather have it and not need it right??


This is a useful text interface tool that shows network traffic flows on a given interface.  It shows the amount of traffic in each direction for each pair of hosts whose traffic is flowing through the interface.

Check it out once you’re up and running by typing iftop –help at the command prompt.


IPTraf is an “IP networking Statistics Utility” and is actually supremely powerful if you are trying to get an understanding of what is happening on the network interfaces of your device.  It’s like a simple text based version of Wireshark available straight off the command line!  I am not going to spoil it, go and play with this.  Just shoo.. go on now…

Check it out once you’re up and running by typing iptraf at the command prompt.


IPerf, the venerable network throughput testing tool.  This is version 2.0.5 (08 Jul 2010).  Check it out once you’re up and running by typing iperf –help at the command prompt.


This is a useful little tool that replace the ping tool and traceroute tool for network diagnostics.  It has a text based interface that auto refreshes showing you the latest ping times to various hosts on the way to your final destination. Check it out once you’re up and running by typing mtr <destination FQDN/IPAddress> at the command prompt.


This is a tool that simply shows the volume of traffic passing through an interface.  Check it out once you’re up and running by typing nload devices wlan0 at the command prompt.  That will show you traffic passing over your USB WLAN adapter.


Ahh yes, tcpdump the de facto tool for packet captures.  If you’re a networking professional and you don’t know this one, just click the link and read.

Now that you’ve selected all of those, lets scroll down the DietPi Software Selection menu to Text Editors.

Text Editors:

The default method of editing text in the Linux command prompt is by using the Vim text editor.  You can choose either Vim and/or Vim-Tiny for installation.  The DietPi OS comes with the nano text editor by default though, so if you hate Vim keep on moving.  You can also choose to install Emacs or Jed which is useful for coding.

Other Settings

I have left most of these as defaults, I did change the web server to Nginx.

  • SSH Server: Dropbear
  • File Server: None
  • Log System: DietPi-Ramlog #1
  • Web Server: Nginx
  • User Data Location: SD / EMMC | /mnt/dietpi_userdata


At this point you should be ready to go ahead and hit the install button.  Don’t forget your new root password…

Linux WLAN general

Using the ODROID C2 as a WLAN Testing Tool – Part 1: Install & Preconfigure DietPi

This series is inspired by the “Maker Session” conducted at the WLAN Pros Conference last year in Budapest.  During the Maker Session each one of the attendees was given an ODROID C2  single board computer along with a battery pack and various other accessories including an 8GB eMMC , eMMC reader, WLAN Adapter etc.  The session went through the steps of installing a customised image of DietPi that included some very handy WLAN tools included in it.  You can see a summary of the hardware, software, tools and the setup process that we followed here.

It was a hell of a lot of fun! AND I went home with some cool toys to play with.

Let’s fast forward 5 or 6 Months.

After spending some time playing with the device since the maker session I have come to realize that  I don’t actually understand very much about how all of the magic inside this little beast fits together.  My knowledge of the Unix/Linux command line is rudimentary and I don’t really know much about the underlying OS.  I understand what the various bits and pieces do but I have no idea how to do this from scratch.  I also want to be able to add some of my own tools to the mix and I want to be able to customize things a little.  So I thought… well… I mean how hard can it be?  Why don’t I build this up from scratch so I understand a little more, and maybe other folks can do this too?

So without further ado, I present part 1 of what I am guessing may be a long learning process littered with errata and edits:

Installing DietPi on your ODROID-C2

This part is actually extremely simple there is a great step by step guide on the DietPi website here.

I am using a Macbook Air running MacOS Sierra (10.12.3) and these are the steps I followed:

  1. Download the correct version of the DietPi OS
  2. Extract the Zip File into a Folder -> Inside the Folder is the .img file
  3. Connect your eMMC / SD Card
  4. Open Terminal
    1. Run the command: diskutil list
      Host-Name:~ User$ diskutil list
      /dev/disk0 (internal, physical):
         #:                       TYPE NAME                    SIZE       IDENTIFIER
         0:      GUID_partition_scheme                        *500.3 GB   disk0
         1:                        EFI EFI                     209.7 MB   disk0s1
         2:                  Apple_HFS Macintosh HD            424.4 GB   disk0s2
         3:                 Apple_Boot Recovery HD             650.0 MB   disk0s3
         4:       Microsoft Basic Data BOOTCAMP                74.6 GB    disk0s4
         5:           Windows Recovery                         471.9 MB   disk0s5
      /dev/disk1 (internal, physical):
         #:                       TYPE NAME                    SIZE       IDENTIFIER
         0:     FDisk_partition_scheme                        *128.3 GB   disk1
         1:               Windows_NTFS 128GBBaseQi             128.3 GB   disk1s1
      /dev/disk2 (external, physical):
         #:                       TYPE NAME                    SIZE       IDENTIFIER
         0:     FDisk_partition_scheme                        *7.8 GB     disk2
         1:                 DOS_FAT_32 boot                    134.2 MB   disk2s1
         2:                      Linux                         7.7 GB     disk2s2
    2. You can see that in this example,  the 8GB eMMC Card is listed as /dev/disk2
    3. Before you proceed, make sure you have the right drive path… (any screw up here is gonna hurt)
    4. Run the command: diskutil unmountdisk /dev/disk2  (Make sure you use the correct path for YOUR drive)
      Host-Name:~ User$ diskutil unmountdisk /dev/disk2
      Unmount of all volumes on disk2 was successful
    5. Now go to the folder in which the .img file is kept using the cd / command
    6. Run the command: sudo dd if=DietPi_v145_OdroidC2-arm64-\(Jessie\).img of=/dev/rdisk2
      2. DON’T FORGET THE “r” in /dev/rdisk2
      3. Learn more about the dd command here.
      4. You can use Ctrl+t to view the progress of the copy process.
        Host-Name:DietPi_OdroidC2-arm64-(Jessie) User$ sudo dd if=DietPi_v145_OdroidC2-arm64-\(Jessie\).img of=/dev/rdisk2

        (I press Ctrl+t here…)

        load: 2.85  cmd: dd 2687 uninterruptible 0.01u 0.42s
        8984+0 records in
        8983+0 records out
        4599296 bytes transferred in 3.951183 secs (1164030 bytes/sec)

        (And Again)

        load: 2.70  cmd: dd 2687 uninterruptible 0.03u 0.87s
        17842+0 records in
        17841+0 records out
        9134592 bytes transferred in 7.831405 secs (1166405 bytes/sec)
    7. Once the process is finished (around 5 Minutes), congratulations, you have installed DietPi onto your eMMC / SD-Card.

Two Useful Files

At this point you should have a SD Card / eMMC card mounted on your laptop with the title of “boot”.  If you open up the drive you should see a folder structure similar to the below:

Host Name:/ User$ cd /Volumes
Host Name:Volumes User$ ls
128GBBaseQi    BOOTCAMP    Macintosh HD    boot
Host Name:Volumes User$ cd boot
HostName:boot User$ ls -l
total 81558
-rwxrwxrwx  1 User  staff  12952112 Feb 25 15:29 Image
-rwxrwxrwx  1 User  staff      5816 Feb 25 15:29
-rwxrwxrwx  1 User  staff   2912668 Feb 25 15:29
-rwxrwxrwx  1 User  staff      2316 Feb 25 15:29 boot.ini
-rwxrwxrwx  1 User  staff    111438 Feb 25 15:29 config-3.14.79+
-rwxrwxrwx  1 User  staff      2027 Feb 25 15:29 config.txt
drwxrwxrwx  1 User  staff      3072 Feb 25 15:29 dietpi
-rwxrwxrwx  1 User  staff      7953 Feb 25 15:39 dietpi.txt
-rwxrwxrwx  1 User  staff   4258601 Feb 25 15:29 initrd.img-3.14.79+
-rwxrwxrwx  1 User  staff     29280 Feb 25 15:29 meson64_odroidc2.dtb
-rwxrwxrwx  1 User  staff   4258667 Feb 25 15:29 uInitrd
-rwxrwxrwx  1 User  staff   4258667 Feb 25 15:29 uInitrd-3.14.79+
-rwxrwxrwx  1 User  staff  12952112 Feb 25 15:29 vmlinuz-3.14.79+
Host Name:boot User$

There are two VERY useful files in this directory that we are going to discuss very briefly.


If you open this file up, you will see that it contains the settings for the HDMI display and other peripherals like Raspberry Pi Camera Module, the GPU RAM Split, maximum USB Current etc.  At this point, you really shouldn’t need to edit this file at all.


This file contains settings that are used on the first boot of the device and can be very useful for the following:

  • configuring networking settings & host name
  • automated installation for DietPi software
  • selection of software packages to provide specific services (SSH, File Server, Logging mode, Web Server)
  • Language and Regional Settings
  • Custom Scripts to be run after DietPi installation.

The file also contains OS configuration and Software configuration information that we will dig into at some point.

Network Connectivity

The first time you boot the ODROID with DietPi installed, it will require Internet connectivity to complete the installation and pull data from the repositories at  If you do not have a connection to the Internet you will be asked to change your network settings and try again.  (So no fear if you get this part wrong! You will have an opportunity to fix it!)

Configuring the network connection settings for the first boot of the ODROID will be done by editing the dietpi.txt file.   Right so, lets open that up with a normal text editor.

Ethernet Network Connection with DHCP

These are the default settings that should be in the dietpi.txt file already. Just to confirm, this is what should be in the file (important fields are in bold):

# >> Networking Options -----------------------------
#If both Ethernet and Wifi are enabled, Wifi will take priority and Ethernet will be disabled.
# 1=enabled

#Enter your Wifi details below, if applicable (Case Sensitive).

#Enter your Static Network details below, if applicable.

You should be able to tell that at this point the settings have Ethernet enabled, Wi-Fi is disabled, and the network is configured to use DHCP.

Ethernet Network Connection with Static Addresses

If you plan on using a static IP address for the Ethernet connection, simply set the Use_Static flag to 1 and enter the necessary information for IP Address, Subnet Mask, Default Gateway and DNS Server.

# >> Networking Options -----------------------------
#If both Ethernet and Wifi are enabled, Wifi will take priority and Ethernet will be disabled.
# 1=enabled

#Enter your Wifi details below, if applicable (Case Sensitive).

#Enter your Static Network details below, if applicable.

Wireless Network Connection

What if you don’t have easy access to a wired connection?

No problem! You CAN connect via Wi-Fi, however the ODROID-C2 board does not come with a built in Wi-Fi card and you will have to connect a Linux compatible USB Wi-Fi adapter.  I strongly recommend using the 802.11n Wi-Fi Module 4 or 802.11ac Wi-Fi Module 5 for this project as they will work with linux operating systems out of the box with no additional effort and they are GREAT adapters.   Obviously if you’re going to buy one, don’t mess about, just get the 802.11ac Wi-Fi Module 5.

# >> Networking Options -----------------------------
#If both Ethernet and Wifi are enabled, Wifi will take priority and Ethernet will be disabled.
# 1=enabled

#Enter your Wifi details below, if applicable (Case Sensitive).

#Enter your Static Network details below, if applicable.


In my testing I have found that the USB Wi-Fi adapter will fail to associate if the network is using any other form of authentication & encryption apart from WPA-Personal / AES.  WPA2-Personal with AES does not work.  It looks like the scripts that use the dietpi.txt file for initial boot expect the WLAN to use WPA-personal with AES encryption.  I have not found any way to configure other authentication and encryption types at this stage.   I solved this problem by configuring my home WLAN to publish a second SSID using WPA/AES and the ODROID associated and got an IP on the WLAN with no problem.

If you know how to edit the dietpi.txt configuration file to allow other WLAN authentication / encryption types, please leave it in the comments!

So, to be clear: make sure your network is using WPA-personal with AES encryption and simply replace the Wifi_SSID and Wifi_Key with your network settings and off you go.


At this point you are pretty much done, your ODROID should be able to get Internet connectivity somehow and you can go ahead and unmount the eMMC / SD Card from your laptop (eject) and go ahead and plug it into your ODROID C2.  Don’t forget to plug in the USB WiFi adapter or Ethernet cable before you boot up!

For the next steps to continue the configuration, you will also require a screen with HDMI and a USB keyboard!

WLAN general



Nowadays when you speak with a WLAN professional you will often hear the suggestion of setting or restricting minimum PHY rates to optimise your WLAN’s  performance.  Many professionals nowadays consider this to be one of the basic tasks that must be completed in the process of configuring and optimising a WLAN.

Configuring the minimum rates in a WLAN can have many benefits to your network’s performance including reduction of management overhead, removal of unnecessary RTS/CTS frames, better airtime utilisation, and enhanced throughput in the Extended Service Set.  It is an especially useful tool in High Density scenarios like big convention halls, sports stadiums, large lecture theatres and any other environment with many clients in a relatively small space.  Personally I set the minimum rates on all HD designs especially in the 2.4Ghz band!

(Yes, I have used 2.4Ghz in High Density deployments.  No I am not a magician.)

If done incorrectly however, or without a fundamental understanding of what you are actually changing, you may find that your optimisation does not always have the desired effects.  For instance, setting minimum data rates and then expecting this to somehow magically limit the coverage area of your AP… well that’s just a recipe for disappointment.

So let’s go through some of the basics of the various PHY Specifications, what minimum rates are, why we can and should set them to different levels and what EXACTLY we are changing with different settings.

PHY Specifications

WLANs work using the IEEE 802.11 standard and its amendments.  Some of these amendments are known as PHY specifications and define the modulation and coding of Wi-Fi signals that WLAN stations can use to communicate with each other.  The table below summarises the available data rates of each 802.11 PHY specification:


802.11 Amendment Frequency of Operation Supported Data Rates


802.11 (original) 2.4GHz

1, 2 Mbps


802.11b 2.4GHz

1, 2, 5.5, 11 Mbps


802.11g 2.4GHz

6, 9, 12, 18, 24, 36, 48, 54 Mbps


802.11a 5GHz 6, 9, 12, 18, 24, 36, 48, 54 Mbps
HT-OFDM (Greenfields) 802.11n 2.4GHz / 5GHz

6.5 to 600Mbps

VHT-OFDM 802.11ac 5GHz

6 to 6933.3 Mbps

If you want a full breakdown of 802.11n/802.11ac MCS rates you can see them here

Backward Compatibility

802.11g (ERP-OFDM) has a minimum PHY of 6Mbps, but is also required to be backward compatible with 802.11b and 802.11 which both use the same 2.4GHz spectrum.  Even though the specified minimum data rate for 802.11g is 6Mbps, in practice a 802.11g radio will often use a minimum rate of 1 Mbps for the sake of backward compatibility with older clients that could be required to associate to the BSS.  Even a 2.4GHz 802.11n Access Point must be compatible with previous radio generations and client types and will often exhibit a minimum rate of 1 Mbps.

Thankfully a 5GHz 802.11n AP must only be backward compatible 802.11a and so the minimum PHY rate is 6 Mbps.  802.11ac APs only support 5GHz and so also have a minimum rate of 6 Mbps in an effort to maintain backward compatibility to 802.11a.

Preamble & PHY Header

Every single 802.11 frame (regardless of the PHY Specification) carries the same basic format.  The first thing to be transmitted is the preamble.  This is just a sequence of scrambled 1’s (DSSS / HR-DSSS) or simple waveforms (OFDM based PHY Specifications) that allows the listening station to synchronise with the incoming transmission.  It’s like having a code word or a sentence that makes someone aware that you want to talk to them.  AHEM! HEY YOU! LISTEN HERE! I’M TALKING!

The second thing that comes along is the PLCP Header.  Once the receiving stations have perked up and are now listening for the incoming message, the PLCP header gives the receiving stations some more information about the incoming transmission including:

  • The PHY Rate of the transmission of the 802.11 frame (MPDU)
  • How long the transmission will take (DSSS, HR-DSSS Only)
  • How much data is in the transmission (OFDM, ERP-OFDM, HT-OFDM, VHT-OFDM)

The PLCP Headers of 802.11n and 802.11ac carry a lot more information than the above, but it is out of scope for this discussion.

But wait, if the PLCP header defines the rate of transmission for the 802.11 frame, then…  Which rate does the PLCP Header use? Well, it depends on which PHY Specification you’re using.  The Preamble and PLCP Header are ALWAYS sent at the lowest rate defined for the relevant PHY Specification!

A table summarising the Modulation and Coding of the Preamble and PHY Header for different PHY Specs is shown below:

Modulation & Coding

PHY Data Rate

PHY Specification


PLCP Header

PLCP Header




1 Mbps

HR-DSSS  (Long PPDU format)


(Short PPDU format)



1 Mbps



2 Mbps



BPSK R=1/2

6 Mbps



BPSK R=1/2

6 Mbps

HT-OFDM (HT-Greenfield)


BPSK R=1/2

6.5 Mbps



BPSK R=1/2

6 Mbps

The DSSS / HR-DSSS Preamble is actually made up of a Sync Field and a Start of Frame Delimiter (SFD).  The Sync Field and SFD are both constructed of randomised 1’s as modulated bits and so have Modulation / Coding information associated with them.

In comparison, the training sequences sent with the ERP-OFDM / OFDM / HT-OFDM / VHT-OFDM preambles are not actually modulated bits.  They are simply a sequence of specific waveforms or symbols that must be correctly interpreted by the receiver to synchronise with the transmitter.  This is why they don’t have modulation / coding associated with them.

Observation #1:

The PHY Rate of the Preamble and PLCP Header is ALWAYS sent at the rate defined for the relevant PHY Specification!  It doesn’t matter if you set your minimum rate to 48Mbps.  The first part of every transmission, the Preamble and the PLCP header will be sent at the MOST ROBUST modulation scheme defined by the PHY Specification you are using.  That means if you are using a 2.4GHz 802.11n AP with full backward compatibility, the MOST ROBUST modulation and coding rate will be DBPSK with a PHY data rate of 1 Mbps.

The MAC Header

Immediately after the PLCP Header, comes the 802.11 frame or Mac Protocol Data Unit (MPDU).  The 802.11 frame or MPDU is sent at the Data Rate specified in the PLCP header.  Every MPDU starts with a MAC Header that contains the MAC Layer Addressing  information (where the frame is from and where it is headed) and a Duration/ID field.  The Duration/ID Field warns any stations that can decode the MAC Header to update their NAV and remain quiet for any future frame transactions that are required after the current frame.

What does Setting the Minimum Rate Change?

The MAC Protocol Data Unit and the MAC Header are sent at the rate specified by the transmitting station in the PLCP Header.  When you set the Minimum Rate for a BSS, you are effectively only setting the minimum rate that may be used for transmitting the MPDU, NOT for the Preamble or PLCP Header.

  1. Setting minimum rates does NOTHING to the size of the coverage area of the BSS.
  2. The PLCP Header will still be sent out at the lowest possible rate defined by the PHY Specification.
  3. You will still cover just as great an area as if you had not touched the minimum rates for the BSS.
  4. Every time a station transmits, every other station that can decode the PLCP Header will be silenced by the transmission.
  5. The number of stations affected by channel contention by other stations HAS NOT CHANGED.
  6. The only thing that has changed is the speed at which we send the MPDU.  Put another way, the only thing we have changed is the maximum amount of Airtime we use sending a specific amount of data.  We’ve improved our efficiency and thereby increased the capacity of the channel, but we have not reduced the CONTENTION AREA.

Ok so I gave minimum rates a bit of a bad rap there.  They might sound quite useless after that list, but hold on a second.

Setting the minimum rate can have a great effect on your WLAN’s performance when trying to limit the amount of air time used up by Management Frames sent on the Wireless LAN and by stations sending data.  Remember that in a BSS, Beacons, Probe Requests and Probe Responses are all sent at the lowest common rate supported by the AP and Client.  This means that if we set our minimum rate to 6Mbps instead of 1 Mbps we will reduce the amount of airtime used for management overhead.  This leaves us with more free airtime to send actual user data!  The biggest effect of changing this setting will be seen in High Density environments with multiple SSIDs that are all beaconing on the same channel.

Setting the Minimum Rate Too High

I have heard some WLAN engineers talk about pushing the minimum rate of a BSS to 24Mbps or 48Mbps.  In my view this can be a bad idea for the following reasons:

  1. The useable coverage area of the AP can become much smaller prompting APs to be placed closer together.  However the area of contention covered by the AP’s PLCP Header remains the same.  This actually increases contention and interference between APs!
  2. Management overhead is typically sufficiently minimised in Very HD environments using a 12Mbps minimum rate, even on 2.4GHz Radios. (I’m talking about a Stadium here)
  3. Management Frames can become hard to decode in some locations, causing clients to drop their connections or miss notifications for queued/buffered traffic etc.
  4. There is also little evidence in my experience that setting high minimum rates prompts sticky clients to roam between APs,  it simply helps them drop more packets.
  5. Wireless is a dynamic medium with many stochastic events and effects on the channel.  Limiting the data rate selection algorithm to only higher rates can cause an AP to suffer higher re-transmit rates and suffer more dropped frames to clients which is exactly what we DON’T want.  Remember, a frame sent at 12 Mbps once is WAY, WAY better than a frame sent at 24Mbps twice or worse one sent at 48 Mbps 4 times or more!

How to Limit the Range of the Preamble and PLCP Header.

Up until now I have only addressed the effects of setting Minimum Rates.  In this section, we will see how we can control the modulation of the Preamble and PLCP Header.

So here is the first thing, you can’t really limit it all that much.  The only way to limit the preamble and PLCP Header is to force the AP not to respect any kind of backward compatibility with older standards.  This may offer you quite considerable shrinkage in the area covered by a preamble and PLCP Header provided you are in a Free Space environment with no obstacles.   if you are indoors however, it may offer less benefit.  Even with any shrinkage, you will still be using BPSK R=1/2 modulation and coding and the range of the PLCP Header will STILL be much greater in comparison to the useful range of the cell.

Let’s look at an example.  Assume that we designed our network to cover to -65dBm to clients throughout the coverage area.  We want to see where our furthest preambles will be heard by our own APs.  Assume we use a high end 4×4:4 802.11ac Wave 2 AP in our design.  This AP has a receive sensitivity of 1Mbps at -101dBm and 6Mbps at -95dBm.  Sure, I have gained about 6dB, which in an outdoor environment equates to halving the coverage range of the PLCP Header.  But indoors, that difference in coverage area may not be as great due to the absorptive effect of physical obstacles like walls, cabinets, furniture etc.

Enabling OFDM-Only Mode

This is by far THE MOST powerful tool in your arsenal.  By simply setting a 2.4GHz 802.11g/n radio to “OFDM-Only” or “802.11g-Only” mode (the naming of this setting differs between vendors) you will immediately accomplish the following:

  1. Force the preambles / PLCP Headers of ALL Management and Data frames to use the OFDM format only.
  2. Banish all 802.11 / 802.11b clients from connecting to your WLAN.
  3. Reduce the use and need of RTS/CTS frames for protecting legacy clients.
  4. Set the minimum rate of the WLAN to 6 Mbps, preventing associated STAs from negotiating DSSS/CCK rates.
  5. All management frames will also be sent at 6Mbps by default, reducing management overhead.

This setting will give you both the ability to set the Preamble and PLCP Header modulation type (OFDM, BPSK, R=1/2) and will also ensure that MPDUs are sent at 6Mbps saving you airtime.

EDIT: Primoz Marinsek, Jim VajdaAndrew von Nagy, and Keith Parsons got me to think about the above very carefully.  This is a revised list after their input.  I would like to thank them for their contributions.  Secondly, if you’re wondering when RTS/CTS modes can be activated by older clients, check out my article about 802.11 PHY Compatibility.

If you are a Ruckus Wireless customer, you can set this for each WLAN from the GUI of the SmartZone Controller.  Just tick the box that says “Enable OFDM-only”.  You should do this in EVERY 2.4GHz network you deploy except when a caveman in a forklift waves an old PSION scanner at you.

Note: I do not intend to insult  men driving forklifts, their technique with a wooden club is generally unmatched.

Enabling N-Only / HT-Greenfields Mode

This used to be a setting I liked using on the 5GHz radios of my WLANs unless I had to support a specific client device.  I would force the 5GHz radios to use only the HT-GreenField PPDU format, preventing 802.11a only stations from associating to the 5GHz WLAN.  My logic here was that very few 802.11a stations are in circulation and those that do support 802.11a are usually dual band.  So I’d force old clients to 2.4GHz.  The value of operating in HT-greenfields mode is marginal in comparison to HT-Mixed mode and doesn’t offer as great a leap as OFDM-Only mode above.


All the new APs I deploy today are 802.11ac, which defines a single PPDU format that is backward compatible with 802.11n and 802.11a.  I don’t use N-Only mode on my 5GHz WLANs anymore, simply because the option does not exist for an 802.11ac AP.

Management Tx rate

Before I sign off this blog, I feel I should mention my least favourite option for configuring minimum rates simply for the sake of it.  Setting the Management Tx Rate is similar to setting the minimum rate for the BSS, except it does not place any limitation on the minimum BSS rate for client devices.  The management Tx rate simply sets the minimum rate used for the MPDU in management frames.  It can be useful for reducing management overhead without limiting the available rates for clients.  For example you could set the management rate to 2Mbps which would effectively halve your management overhead from beacons.  Personally, I dislike this feature as it can introduce a disparity between the useful range of management frames and clients if you make the difference large enough.

I generally just stick to using OFDM-Only and then setting the minimum BSS rate to a value of 6 or 12 Mbps depending on remaining management overhead.

Anyway, thats all for now folks, hope this helped!


WLAN general

802.11 PHY Compatibility – Basic Overview

802.11g <–> 802.11 / 802.11b:

When 802.11g (ERP-OFDM) was released in 2003, we needed a way to co-exist with the large installed base of older 802.11 (DSSS) and 802.11b (HR-DSSS) based networks and equipment out there.  The solution to the problem used RTS/CTS control frames to silence the channel before an 802.11g station used any of the higher modulations.  Before transmitting a frame using OFDM modulation, the transmitting station would initiate an RTS / CTS exchange with the receiving station.  The RTS/CTS exchange uses a PHY rate of 1 Mbps using DBPSK modulation as specified by DSSS, silencing all legacy stations in the coverage area.  This is an awful co-existence mechanism and it chews up valuable airtime silencing the channel before any 802.11g station tries to talk!

As per’s CWAP text and the IEEE 802.11 2012 standard:

RTS/CTS protection is activated by all the STAs in a BSS when the “Use Protection” bit of the ERP Information Element is set to 1 in Beacons and Probe Responses.  The following MUST trigger the “Use Protection” bit to be set:

  1. A legacy client that does not support ERP-OFDM associates to the BSS.
  2. A beacon from a neighbouring legacy BSS (that does not support ERP-OFDM rates) is detected.
  3. Any management frame (excluding a probe request) is detected coming from a neighbouring legacy BSS.

The above list is defines when the Use Protection bit MUST be set to 1. The IEEE 802.11 standard left it open to vendors to choose other scenarios when it is suitable to activate protection mode.  For example, some vendors will set the Use Protection bit as soon as they receive a probe request from a legacy non-ERP station.

802.11g / OFDM-Only Mode

802.11g Radios can be configured to use only ERP-OFDM rates making them incompatible with DSSS / HR-DSSS radios.  This is named differently per vendor but is usually something like “802.11g-only” or “OFDM-only” mode.  This basically configures the radio to ignore probe requests from legacy clients that only support DSSS/CCK rates.  The legacy clients will be prevented from associating to the BSS, removing the need for RTS/CTS for older client stations.  It does not however absolve the OFDM-Only BSS from RTS/CTS completely, we still have to be polite to an legacy DSSS/HR-DSSS cells nearby as per points 2 and 3 above.

Thanks again to Primoz Marinsek, Jim VajdaAndrew von Nagy, and Keith Parsons for making me look deeper.

802.11n <–> 802.11a/g:

Later on with the introduction of 802.11n, the IEEE learned from the horror of RTS/CTS and implemented THREE new PPDU formats to enable more seamless compatibility with either 2.4GHz 802.11g (ERP-OFDM)  or 5GHz 802.11a (OFDM) stations.  The PPDU Frame formats are summarised as follows:

  • non-HT Format: Used when communicating with either an 802.11g or 802.11a station.  The Preamble and PLCP Header are exactly the same as the legacy communications.  802.11n stations can understand the older PPDU formats and keep quiet during transmission.
  • HT-Mixed Format: Used when communicating with an 802.11n (HT-OFDM) station on either band in the presence of 802.11g or 802.11a stations.  This PPDU format starts with the same preamble and PLCP Header as defined for 802.11a/g and then adds a second PLCP Header afterwards that enables 802.11n transmission of the MPDU.  This allows 802.11a/g clients to recognise the impending frame transmission’s properties and keep quiet.
  • HT-GreenField Format: Only has the HT-OFDM defined Preamble and PLCP Header.  Used in networks that do not support backward compatibility.  Does not allow older stations to recognise the impending frame transmission.  This should only be used where no 802.11 a/g stations exist.

2.4Ghz 802.11n radios also interoperate with 802.11/802.11b radios by using RTS /CTS in the same way as 802.11g radios do and are capable of decoding DSSS modulated signals from legacy stations.

Greenfield Mode

802.11n radios have the option of only working in “GreenFields” mode.  This mode only allows 802.11n capable stations to join the BSS and does not use the non-HT or HT-Mixed PPDU formats.  It also does not perform any RTS/CTS for legacy clients using 802.11 / 802.11b.

 802.11ac <–> 802.11a/n

The 802.11ac standard actually only defines a single PPDU frame format for the 802.11ac standard called the VHT PPDU format.  This frame format is compatible with 802.11a (OFDM), 802.11n (HT-OFDM) and 802.11ac (VHT-OFDM) stations all in one go.  802.11ac has no “11ac Only” or greenfield mode like 802.11n does.  In my opinion forcing compatibility with 802.11a only stations was a little silly since they are so rare.

WLAN general

What does 802.11 Contention Look Like (Part 3) – Probabilities & Our First Model

In my previous blog posts in this series I covered the inherent problem with CSMA/CA and how it loses efficiency as more stations make use of a channel.  I also covered some of the basic rules of how CSMA/CA works as implemented by 802.11 Wireless LANs.

As I mentioned at the beginning of this blog series, my intention here is to build an argument and the logic for describing what WLAN contention actually looks like in the real world.  We’ve gone over some of the rules of how WLAN contention works.  But now it is time to start building some simple mathematical models of its effects on the medium and then to carefully evaluate how those models stack up against the real world operation of 802.11 WLANs.

First, some background on probabilities

When you are working with system that uses a random or stochastic component and forms a stochastic process, it becomes very hard to build a deterministic model of how that system works.  There is an inherent uncertainty built into the system and we cannot predict the outcome with 100% accuracy.  It becomes necessary to start attaching a probability to any one of the possible outcomes.  Let’s start with an example.

If you have two people in a room, and you ask both people to choose a random number between 0 and 15.  What is the chance that they will choose the same number?

The first person chooses a random number and the second person has a 1 in 16 chance of choosing the same number.  Therefore the chance of both people choosing the same number is 1/16 or 6.25%.  If we want to put it another way, the chances of the two people NOT choosing the same number are 15/16 or 93.75%.  We can also write 15/16 as (1-1/16).

What if we have three people?  Well, then the problem becomes slightly trickier and we have to ask ourselves what we want to know!

There are two things we can calculate:

  1. The possibility that person 2 or person 3 will choose the SAME number as person 1. (A = B or A = C)
  2. The chance that any two clients have chosen the same number. (A = B, A = C, or B = C)

A = B or A =C:

The chance of choosing the same number in this case becomes a little harder to calculate.  We know that as the number of people selecting numbers increases the chance of selecting the same number as the first person must increase, but how?

By looking only at the chances of choosing the same number, we struggle to find a single intuitive equation that can tell us how the chance increases.  Well, at least I do.

As it turns out, we can solve the problem by evaluating the chance of NOT choosing the same number.  The chance of A and B NOT choosing the same number = 93.75%.  If we allow C to choose a number, the chances of also avoiding a collision with A are 93.75% of 93.75%.  What are the chances that both B and C avoided a choosing the same number as A?  We can say P* is the possibility of NOT choosing the same number:


Therefore P the chance of choosing the same number:
Screenshot 2016-06-14 13.02.35

We now have an intuitive equation that gives us the possibility of person B or C choosing the same number as person A.

Generalizing to N people

But what if we had more than 3 people? We can also generalize this equation for N People as follows:

Screen Shot 2016-06-13 at 9.44.50 PM

Therefore if we had 4 People, the chances of persons B, C, or D choosing the same number as A would be:

Screen Shot 2016-06-13 at 9.44.59 PM

Generalizing the number of possible choices

Up until this point, we have examined only the scenario where the random number chosen by N people exists within the range of 0 to 15, i.e. there are 16 different possible outcomes with each choice. What if the number of options is larger?

We can generalise our equation to reflect the number of possible outcomes with each selection by labeling the number of possible outcomes as . The Possibility P(N) of a collision with Person 1 therefore becomes:

Screen Shot 2016-06-13 at 9.45.13 PM

In summary, this generalised equation gives us the probability that the random number chosen from different options by a specific person in a group of N people will also be selected by at least one other member of the group of N people.

A = B, A = C, or B = C

In this case we are trying to find the scenario where any choice is the same as any other choice in the group of people.  Put another way, in a group of people of a certain size, what is the chance that any person chose the same number as any other person?

First we can start with the trivial example of two people in a group choosing a random number out of x different options.  The probability of them NOT choosing the same number is easily seen to be:

Screen Shot 2016-06-13 at 9.45.20 PM

What about the case of three people choosing a number? Let’s go through it slowly.

In this case, the first person to choose a number has a 100% probability of not selecting the same number as anyone else, since nobody has selected a number.  The second person has a (1-1/x) chance of no collision with the first.  The third person has a (1-2/x) chance of not colliding with either of the other two.  So we can say that for three people the probability of NO collision is equal to:

Screen Shot 2016-06-13 at 9.45.28 PM

The probability of a collision occurring is therefore equal to:

Screen Shot 2016-06-13 at 9.45.36 PM

Generalizing to N people

What if we had more than three people? The equations from above can be generalised for N people.  The probability of NO collision is equal to:

Screen Shot 2016-06-13 at 9.45.44 PM

Simplifying the equation and multiplying everything out, we can see that the equation becomes:

Screen Shot 2016-06-13 at 9.45.55 PM

Screen Shot 2016-06-13 at 9.46.03 PM

Screen Shot 2016-06-13 at 9.52.12 PM

The probability of a collision occurring is complementary to the probability of no collision, so the probability of a collision is given by:

Screen Shot 2016-06-13 at 9.52.26 PM

where N is the number of people, and x is the number of possible choices.

In summary, this second generalized equation gives us the probability that the random number chosen from x different options by ANY person in a group of N people will also be selected by at least one other member of the group of N people.

Our first model:

For our first model of 802.11 channel contention I have built a simple spreadsheet using the formulae above and the rules laid out in my Second Post in this series.  It shows the possibility of a client experiencing a collision given a variable number of active 802.11 STAs.  I have included the different Contention Window values for different QoS Access Categories and I have also included some of the effects of 802.11 PHY Type on the Contention Window Size.  Feel free to download it here.

For the purposes of keeping things simple the model has the following restrictions / limitations:

  1. Number of total STAs cannot exceed 101 – this is a limitation with Excel mathematical capabilities – I’ll work around that later!
  2. Assume DSSS and HR-DSSS PHY Types do not support QoS.
  3. All STAs are using the same PHY Type.
  4. All STAs are transmitting traffic in the same QoS Access Category
  5. All STAs are contending for medium access 100% of the time (100% Duty Cycle)
  6. All STAs are using the same Contention Window size.
  7. This model  is turn based.  It assumes that once an STA has chosen a random back-off and transmits a frame, the same STA cannot interfere with the remaining STAs until everyone has sent a frame.  So it is only applicable for low traffic  / duty cycle environments.
  8. The BSS does not suffer from Near/Far problems (i.e. if two stations Tx at the same time, both will experience a collision, one cannot overpower the other and get through).

So as we can see from this model, it is pretty limited but it does give your customers an idea about why you cannot support more than a specific amount of VoIP clients on a WLAN.  It will also lend significant credence to the argument by Ben Miller about why many Wi-Fi Calling Apps are better off using Video priority in HD environments with multiple active clients.  You can fidget with the numbers here too and play around.

As for our modeling journey, well it is version 0.1 so we have a long, long way to go before we have something that even closely resembles the real world.  But we’ve cast the first stone.

In my next blog post I will discuss a method that I used to try and improve upon this model, and I’ll discuss its differences with this model and also its limitations.


WLAN general

What Does 802.11 Contention Look Like (Part 2) – How contention works:

802.11 Medium Access Control implemented with the Distributed Co-ordination Function (DCF) and Enhanced DCF Channel Access (EDCA) methods, uses a random back-off counter to help ensure that clients do not transmit their data at the same time, but rather take turns to send their data one after the other.  This is the “Collision Avoidance” part of CSMA/CA.

When two (or more) 802.11 stations both have data to send on the same channel and both have established that the channel is clear, both stations will select a random number, wait a pre-defined period called a DCF Interframe Space (DIFS) and then start counting from the random number to zero. The first station to reach zero transmits its frame. The other station hears the PHY & MAC header of the frame transmission and returns to idle state until the transmission is completed. Once the transmission is over and it is time for the second station to contend for the medium again, it will go through the process again and simply start counting down from where it left off. The first station, if it has more data to transmit, will select another random number and contend for the medium again.

The first important observation

It is important to realize early on, there is a possibility here that the first station could choose a random number lower than the one that the second station is on. Think of the scenario where the first station chooses a random back-off value of 4 for its first transmission, and a back-off value of 7 for its second transmission (12,4% probability). If the second station chose a random back off of anything greater than 11 for its first transmission (26% probability) then the first station will send two frames before the second station has even sent one! Statistically however, this should happen an equal number of times to both stations ensuring roughly fair access to the medium! This is why we say WLAN is a BEST EFFORT protocol. There is no guaranteed access to the medium as there is with “Telco” wireless access technologies! (WiMAX, iBurst, 2G, 3G, LTE etc)

An Analogy

You can think of 802.11 channel contention like randomly choosing a number to find your position in a queue in a bank. You pick a number and join the queue in that position and wait until it is your turn to be served by the teller.  If there is a person in front of you, and that person goes to the teller, you take a few steps forward then stop and hold your place in the queue until it is your turn to be served.  If the person ahead of you has any further business requests they join the queue in a new random position and wait their turn again.

EDIT: A point of clarity from Devin Akin here:

“When the CCA is returned as BUSY, then the remaining number of slot times are held during frame transmissions from other STAs/APs, which could each take a long time if they are large aggregate data frames.”

Let’s say there are two people in the queue, and you pick position 7 and another picks position 3.  Both of you will walk forward 3 steps toward the teller.  The other person will get to the counter first, you will see that the teller is busy and you will hold position 4 until that person is done.  This could take some time!  Imagine if the person talks very slowly?  Once the person is done, then they will rejoin the queue in a random place and you will start walking forwards again from the position you were in.


Now the trick is, if the range of numbers you can choose is finite, let’s say between 0 to 15, then there is a chance of you choosing the same position in the queue as someone else. This chance obviously increases with the number of the people joining the queue.

If you choose the same random number as someone else, you would both arrive at the front of the queue at the same time. The bank clerk serving the queue would be unable to answer both of your requests simultaneously and would refuse to acknowledge either of you.

You have just had a “collision”.

According to the rules of 802.11 WLAN channel access, both of you would have to pick a NEW random number and rejoin the queue, but with a slight twist. In order to try and reduce the chance of people choosing the same random number and resultant position in the queue, those that suffer a collision would choose a number between 0-31. That is, you would double the range of random numbers you could choose from.

With each consecutive collision you experience, you will double the range of the random numbers you select from. So if you experience a collision and select a random number between 0 – 31 and you reach the counter at the same time as someone else again, you go back (again), select a random number between 0-63 and rejoin the queue and try again, and so on and so forth.

If you succeed in getting to the front of the queue alone, then your request will be served. For your next request you will return to using the original number range (0 – 15).

A second important observation

Just because a specific station has experienced a collision (or several) does not mean that another station has had the same experience. This means that while one station is choosing numbers from 0-31 or 0-63 or even higher after several collisions, there are other stations choosing from 0-15 at the same time!

The Contention Window

In 802.11 WLANs, we call the random number range that stations can choose from the “Contention Window” (CW). The contention window can be calculated by the equation CW = 2N-1. In OFDM Based WLANs with traffic in the Best Effort or Background Access Categories the starting value of N is 4.

802.11 client devices and APs (both referred to as Stations or STAs for short) will typically attempt to re-transmit their data up to 7 times before giving up and dropping the frame. With each successive collision the value of N is incremented until a successful transmission occurs. This means that the Contention Window will typically follow the pattern below:

Attempt # N Value Contention Window (2N-1)
1 4 0-15
2 5 0-31
3 6 0-63
4 7 0-127
5 8 0-255
6 9 0-511
7 10 0-1023
8 NA Give Up. (Dropped Frame)

If the Transmitting STA succeeds in sending the frame and receives an ACK from the receiving station, or to follow our analogy above, gets to the front of the queue alone then N resets to 4 and it returns to using the smallest contention window size (0-15) on the next attempt.

CWmin and CWmax

According to the IEEE 802.11 standard and its amendments, the Contention Window has a minimum and a maximum value.   The example above shows a CWmin of 15 (N = 4) and a CWmax of 1023 (N = 10).   This is true for any 802.11a/g/n/ac WLANs using the Best Effort or Background QoS Access Categories.

802.11 and 802.11b

Any WLAN that uses DSSS (802.11) or HR-DSSS (802.11b) technologies uses a slightly larger CWmin with the N-Value set to 5. This means that the CWmin value for 802.11 and 802.11b WLANs is 31. The CWmax value is still 1023 (N=10)

802.11e QoS:

The 802.11e amendment introduced the ability to prioritize traffic based on 4 different Access Categories. The goal in this case was to ensure that higher priority traffic gained access to the medium faster and ahead of traffic from lower priority Access Categories. The CWmin and CWmax values for the different access categories are shown below.

Access Category CWmin CWmax
VIDEO 7 15
BEST EFFORT – Default for most WLAN traffic 15 1023

Slot Times

Before we get too far ahead of ourselves it is sensible to just cover how long it takes each STA to count down the randomly selected back off. Each unit in the random back-off countdown lasts for a specific Slot Time as shown in the below table:

PHY Type Slot Time
OFDM 9μs

It is also important to note that 2.4GHz 802.11g/n networks may only use the 9us slot times when there are no DSSS / HR-DSSS STAs associated to the Basic Service Set. This information enables us to see the actual time delay introduced by the random back-off countdown.


In this blog post, I really wanted to put a spotlight on the random back off timer and its specifications. I know I haven’t looked at the Interframe Spaces very carefully and I also have not looked at other aspects of traffic flow like TXOP etc. For now I am focused purely on looking at how the random back off affects WLAN contention. We have made some interesting observations and drawn some interesting conclusions:

  1. There is a chance that one STA can successfully transmit two frames or gain access to the medium twice before another STA using the same Contention Window value can gain access to the medium once.
  2. There is a chance that two STAs can pick the same random back off number and collide.
  3. When STAs suffer a collision and don’t receive an ACK they double the size of the contention window and re-contend for the medium.
  4. STAs in the same BSS can all be using different contention Window values at the same time depending on the result of their most recent attempted frame transmission.
  5. STAs will re-transmit up to 7 times, using a contention window of up to 1023 slots (up to 9,2 milliseconds!) before giving up and dropping the packet.
  6. Once a STA has successfully tranmistted a frame and received an ACK, it goes back to the original Contention Window (CWmin) and commences the process again for the next packet.
  7. In QoS enabled networks, Voice and Video traffic use smaller contention windows than Best Effort and Background traffic to guarantee faster access to the medium and also do not increase the N value by more than 1 increment in their re-transmissions.


Now that we know the above things, we can start to build some simple models that show the likelihood of a collision under different circumstances. That will come in the next blog post though!


WLAN general

What Does 802.11 Contention Look Like? (Part 1)

The IEEE 802.11 Wireless LAN protocol uses Carrier Sense Multiple Access with Collision Avoidance (CSMA/CA) with a fairly robust arbitration mechanism to allow WLAN Stations (STAs) to gain access to the wireless medium based on their traffic priority.

The central problem with CSMA/CA and the 802.11 arbitration mechanisms is that the chances of a collision occurring between two stations increases seemingly exponentially with the number of active stations contending for the wireless medium.  This means that as more and more stations use a given channel, the efficiency of the channel decreases quite dramatically.

Many engineers I have met have questioned this and have wondered why the IEEE Standards Body and 802.11 Working Group did not consider more “efficient” methods of medium access.  Why not TDMA, CDMA or OFDMA?  Now, I am not here to get into a discussion about which medium access method the IEEE or vendors should have chosen to develop way back when in 1990-whatever.  Maybe we can discuss channel access methods and their properties on another day after I have read more on the topic!   The truth is though, the IEEE 802.11 Working Group defined several methods of medium access. As it turns out, vendors only ever really developed their products to use the Distributed Co-ordination Function (DCF) and its 802.11e-defined successor, the Enhanced DCF Channel Access (EDCA) method also referred to as the Hybrid Co-ordination Function or HCF for short.

I have often wondered as a WLAN engineer what CSMA/CA actually LOOKS LIKE in the real world.  As designers of Wireless LANs we are often asked to perform capacity calculations and predict what performance level a given design will achieve for a specified application type.  We have the tools to perform a coverage analysis very well, but sadly the tools for capacity prediction fall short of expectation in my opinion.

I agree that there are some good tools out there that get us into the right ballpark and remove a fair amount of guesswork.  But I have yet to come across any tools that can accurately model the effects of WLAN contention and its effect on capacity from first principles.  Most capacity calculators and models I have ever used will cover for the effects of contention using a simple  “RF environment” setting that reduces the amount of airtime efficiency by a certain factor to account for higher collisions in noisier and busier environments.  While this gets us closer to an estimated value of capacity, it still does not give us a definitive answer.  It also IGNORES the underlying mechanics of what is truly going on, making our calculations susceptible to unforeseen errors.  Don’t get me wrong – errors are present in all calculations and can be worked around, but we need to know what they are or at least see where they may come from!  Oftentimes, if we get pushed to reveal the source of some values used in our current capacity calculators, we often have to admit that it is based largely on empirical evidence, or past experience.  Sometimes that will work, other times it might not.

There are also newer technologies like 802.11ax with OFDMA channel access methods that promise to introduce a new “High Efficiency” mode of operation to the 802.11 Standard.  It would be useful then to understand exactly why and under what circumstances the current standard and its amendments are inefficient!  We also need to build a model that can show the potential improvements brought forth by new amendments.

This is the source of  my motivations for starting this blog series.  And before you say it…

Yes, I know The Birthday Problem

When you mention the term 802.11 Contention or CSMA/CA most WLAN engineers will talk about THE BIRTHDAY PROBLEM, and we all understand that this calculates the overall chance of a collision given a certain number of clients.  But it still doesn’t really give us a clear picture of how it works.  It’s kind of like saying “There is a 15% chance of rain today”, which is useful to tell whether to walk outside with an umbrella, but it doesn’t give us any insight into how the clouds form, or when it will rain, or for how long, or if there will be a monkey’s wedding, or if it will involve a romantic couple kissing in a park.  Ok, maybe I took it too far, but you get my gist.  We want details! Details are important.  Details bring insight and understanding.

So what am I going to attempt?

In this blog series I intend to try and model the 802.11 arbitration process to show how certain factors can affect contention overhead in a Wireless LAN.

I will spend some time outlining the mechanics of what I am trying to model and some of the various approaches I have taken to visualize it.  I will also show how those methods are limited and why they are only an approximation of reality.

Let’s start (and end Part 1) by defining exactly what I am trying to visualize.

I want to explore what 802.11 contention LOOKS LIKE in the real world.  Given N active stations using a given WLAN channel:

  1. What is the likelihood overall of one (or more) collisions occurring given N active clients? (This is the answer given by The Birthday Problem).
  2. What is the likelihood of a specific station experiencing a collision at any given time?
  3. How many collisions should we expect a client to have before successfully transmitting a packet?
  4. Do the number of collisions fluctuate or settle into a relatively stable dynamic equilibrium?
  5. Can the number of collisions “snowball” into a state where the medium becomes unusable?
  6. What (really) is the maximum number of active clients that can be supported on a single WLAN channel before the system becomes unstable and the protocol breaks down?
  7. How do different 802.11 technologies (E.g. DSSS, HR-DSSS) affect the number of collisions?
  8. How does traffic volume affect the likelihood of a collision?
  9. What is the effect of an unequal split of upstream Vs. downstream traffic on the number of collisions?
  10. How does setting QoS values alter the number of collisions?
  11. How can we characterize and model application traffic streams?
  12. How does airtime efficiency and the negotiated PHY Data Rate affect the number of collisions?
  13. How does the effect of contention affect our WLAN capacity calculations?
  14. Most importantly, given this insight how can we minimize the number of collisions to get the best possible network capacity?

Right, well that’s a pretty solid list of items to try and answer. I am not sure we will be able to get to all of them at once, but now that we’ve written down what we want to see, we can move on to Part 2!