Friday, April 10, 2020

A Python Mist API module

Recently I've been working with some fine developers to come up with a Python module to interface with the Mist API.

It was designed to be user-friendly and extensive. Hopefully you'll find it such, but since it's public we invite you to help us develop it further and make it even better.


pip install mistifi


pip3 install mistifi

and give it a shot.

You'll find more documentation on the GitHub link below.

Please visit the project on GitHub and contribute. No contribution is too small, and even just documenting a few things will help, not to mention bringing you into the coding world, like it did me.

Monday, November 19, 2018

You CAN change MCS rates

I've heard before that you should NEVER play with MCS rates on 11n and 11ac as they usually lead to instability on the network, but usually no one backs them up with any evidence (guilty of that myself). So I've decided to give it that theory a try and write a short blog about it.

Recently I was working on an upgrade to a very old warehouse system that is built in a very 3D way. There a rows of 20m metal aisles stacked up about 20m high, full with products ranging from cereal to metal cans. There are shuttles picking those products on both sides of the aisles and they rely on a timely delivery of RS-485 data via WLAN. For this a MOXA W2150A model is used, which supports 1x1 11n (a fuller feature set can be found here).

In such environments a designer can very easily come across a multipath problem, which causes many retries due to the signal getting bounced around so much that the higher data rates become almost useless and in fact a hindrance to timely packet delivery. In order to alleviate that problem designers often disable the high data rates, so to save the client devices the agony of shifting down through the "fast" rates (ballpark above 24Mbps) to the "working" ones (ballpark up to 24Mbps).

But as mentioned above, MOXA does support 11n, and 11n has some really good features that help with efficiency and packet delivery. I'm mainly talking about LDPC, STBC, block ACKs, etc. Plus the higher speed of lower rates compared to 11a/g would be good. (For reference on those click here and here).

The idea was to imitate the current working 11a deployment, where rates 6, 9, 12 and 18Mbps are used, which means using MCS rates 0, 1 and 2.

On Aruba, you set these parameters under the HT profile

wlan ht-ssid-profile <PROFILE_NAME>
   supported-mcs-set 0-2
You verify the rates by capturing a beacon frame from an AP that is broadcasting the SSID

The 0000 0111 means that the lower most MCS rates (the ones we've set) are being advertised and will be used for all transmissions in both directions.

Finally check that the device is connecting and transmitting packets and data, with a trivial connection test, and most importantly if shuttles are still moving.

So I'd suggest the next time someone tells you you should never do (or always do) something, you'd be smart as to ask why. Then you can either believe them and NEVER/ALWAYS do something, or ask them to provide some evidence as to why that's so.

Monday, April 17, 2017

Generating Aruba SSH login keys and certificate

I came across the need for one of my scripts to connect to an Aruba controller the other day and although I could have used a username/password option I decided on certificate based authentication just to learn something new.
The process is quite straightforward, but it took me a while to figure out. I chose Aruba as that is the vendor of choice where I work, but I'd say that the process would be similar for other vendors' gear (at least the certificate generation part).

To an Aruba controller you can only upload certificates not RSA signatures, so you must make a cert from a public/private key pair that we generate with the ssh-keygen command and then use openssl to generate the certificate from this pair that can be upload. (If anyone has a foolproof solution for doing this with only one these, please share it.)

Creating the key pair and certificate

1. First we create the priv/pub keys with ssh-keygen, where we provide the name for the key (ex. ssh-id_rsa). When asked for a password for the key I left it empty as that would mean that it would need to be entered every time the script would be run, which I didn't want.

Generating public/private rsa key pair.
Enter file in which to save the key (/Users/primoz.marinsek/.ssh/id_rsa): ssh-id_rsa              >>>>>> PROVIDE A NAME FOR THE KEY HERE
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in ssh-id_rsa.
Your public key has been saved in
The key fingerprint is:
SHA256:v0ImnCOiUhFQhe8/DlE6jA8bPaJb+nZosjiJuRPHJu0 p.m@XXXYYYZZ.local
The key's randomart image is:
+---[RSA 2048]----+
|.o.o.            |
|  o              |
|   o  .          |
|  .+.o           |
| o=oB. .S        |
|o.B*o+= o.       |
|o@oooo =  .      |
|@+E ..o .  .     |
|BX.. ... ..      |

2. Next we need to create a certificate that we will upload to the controller. For this we use openssl to create a PEM public certificate from the private key "ssh-id_rsa. I gave it a life of 3650 days or 10 years in this example. When asked about the information to enter it's your choice whether you want to fill it in or not.
openssl req -x509 -new -key ssh-id_rsa -days 3650 -out ssh-id_rsa-cert.pem
You are about to be asked to enter information that will be incorporated
into your certificate request.

With these 2 steps you have now created the key pair and a certificate that you can upload to the controller.

Uploading and enabling the user for login

Next steps involve uploading of the certificate you just generated and creating a user to go with it. I'll continue with step 3 below, which starts with enabling using public key architecture for SSH-ing into the controller

Note that some steps involve using the WEB GUI to upload the certificate. I've gotten used to CLI in recent times and I use scp quite a bit, but I haven't found an elegant way of uploading things to a controller yet. I seem to be running into some cypher mismatches there.

3. This step involves enabling certificate option for SSH, which must be performed on a master controller ONLY. Enabling it on a local controller will not be allowed either from WEB GUI or CLI. 
You need to either ssh or browse to the controller via WEB GUI and under 
Management :: General :: SSH (Secure Shell) Authentication Method the 
Client Public Key 
needs to be enabled or alternatively do it much simpler over CLI as below

ssh mgmt-auth public-key

4. On controllers WEB GUI and go to Management :: Certificates and select tab Upload and fill in the fields as below. Note that this has to be done on every MASTER AND LOCAL controller in your topology.
  • "Name" of choice for the cert (ex. Aruba-mgmt-user-crt)
  • Select the file from your disk
  • Select PEM as "Certificate Format"
  • For "Certificate Type" select "Public Cert"
  • click "Upload"
5. Create a new user and use the SSH key for login (same as before MASTER AND LOCAL)
  • Go to Management :: Administration 
  • Add a new user under "Management Users"
    1. Under User Name input "ssh-global"
    2. Select the "Certificate Management" radio button
    3. Diselect "WebUI Certificate"
    4. Select "SSH Public Key"
      1. For Role select "root"
      2. For Client Certificate name select the previously uploaded certificate (Aruba-mgmt-user-crt then click Apply

Below is the CLI command that does this
mgmt-user ssh-pubkey client-cert "Aruba-mgmt-user-crt" "ssh-global" "root" 


6. I don't know why, but when my script logged into a controller it wasn't put directly into the "enable mode", but when logging in straight from the console I didn't have that issue. To not run into this issue run the below few commands to make sure you won't have problems there.
configure t
enable bypass
write mem

Authentication test

To test the connection follow the below procedure
  1. You must copy the "Aruba-ssh-id_rsa" key into your ".ssh" directory
  2. Run the below command and check you are logged in to the controller. Check the name of the controller
    ssh -i ~/.ssh/Aruba-ssh-id_rsa ssh-global@<the_controller>

If this doesn't work you might need to change the permission on the key with
chmod 400 Aruba-ssh-id_rsa

Hope this post helped in some way in your scripting endeavours and don't forget to share if it did, or if it didn't.

Monday, January 25, 2016

APs are... not HUBs!?!?

I come across a lot of misconceptions about WLAN networks and how they work in my day-to-day wireless business. This in the end leads to sub-par WLAN designs.

One of the biggest issues contributing to that is the lack of understanding of how the 802.11 protocol actually works. The channel occupation part that is.

As Keith Parsons (@KeithParsons) likes to say: "APs are HUBs!". And while the statement does drive the point of how you should think of wireless communication home, it's only half true (or at least not completely true).

Let's first look at what hubs are. Hub is simply multi port repeater. It's an archaic networking component which upon receiving bits on one port simply repeats that exact sequence on it's every other port. That means only one node can send bits at one time, all the other nodes receive those bits and process them if they are meant for them (if their hardware address is in the frames) otherwise they discard them.

This method of going networking is greatly inefficient and results in very slow speeds, so hubs have long been replaced by switches that have incorporated much better logic and far better hardware. Switches actually separate that one collision domain into as many new collision domains how many ports they have, greatly increasing efficiency and throughput.

What about the wireless world? Considering the hub explanation you might expect that ther's also repetition going on somewhere and that APs might be in charge of that, but you would be wrong. When a client device, associated to a particular AP, sends packets to a destination it sends it through that ap by setting the receiving MAC address of that AP in the frame, but the AP does not repeat those bits sent over the air. What does happen though is that those same bits, due to the the medium being unbounded, go everywhere and this is very important to understand.

In fact that's the way it must work! When a station, either an AP or a client, send out frames, every other station on that channel MUST hear those packets so they can set their timers to not "speak" at the same time. If it does, that's when you get those pesky hidden nodes that negatively impact your networks good-put.

So why is Keith saying that? Well it's a good one-liner that explains the situation and when talking to not technical people it's the one I use also, but as an engineer you should know what it really means.

So understand that APs are in fact not HUBs! They don't repeat the bits sent to them by client stations associated to them. It is rather the channel itself that is the HUB, and it must be that way for your network to function properly.

Thank you for reading my posts.

Tuesday, June 30, 2015

802.11ac – Evolution or revolution

There has been much talk of 11ac W2 recently. After getting into one such discussion and giving my own view on it, someone said to me, I must hate 11ac, which is definitely not the case. I definitely like it, but what I seriously dislike is the faceless user exploitation of some of the marketing practices that are branding 11ac as something it definitely is not and probably will not be, and making it seem that it’s a solution for all our woes. It was the same with 11n before it came out and then after it did, we immediately started looking for the next thing.
Using words as switch-like, gigabit wireless and what have you are wrong and don’t represent the technology correctly at all. I thought I’d give it my own view on what 11ac means to me and what I expect and not expect from it.
For a much deeper understanding into the below list of functions I seriously suggest you get the book "802.11ac A survival guide" from Matthew S. Gast.

Prior to 11ac the highest modulation was 64-QAM which is 4 times lower. This increased the throughput by about 20% which is always welcome, but the problem here is achieving it and consistently. Those who have done extensive tests on it say that the distance from the AP where this modulation can be achieved is only a few meters. This makes it very unpractical for almost all uses. The only one I can think of is a high density deployment where APs are placed under users, like under seats, tables or floors where the distance to users is very short and even then the only users that will probably be able to use it are the once in the immediate vicinity that don’t have the signal blocked by theirs or others body mass.

Wider channels
11n brought us 40MHz wide channels, which is a 2 fold increase to before and 11ac gives us 160MHz wide channels which is a 4 fold increase to 11n capability.
The question here is why anyone would ever go beyond the 40MHz mark for regular enterprise use or even home use. I can see 80 and 160MHz channels maybe being used in P2P links but other than that not really. Even having a Gigabit link is a rare case.
In the sense of channel widths 11ac is not revolutionary neither evolutionary, it will probably prove to be self-destructive.

11n brought us multiple-in-multiple-out radio architecture. In fact it defined that a radio chain can be designed of up to 4 radios, hence the 4x4 nomenclature. This is an increase of times 4 to 11a/b/g. 11ac evolved from that to allow for up to 8 such chains which is a factor of 2 compared to 11n.
The gains of having more than 4x4 is highly questionable due to power requirements, design, return of investment and ugliness of such APs. But the more chains an AP has the more options it has with regards to beamforming, but I have reservations about that also.
So having more radios will not bring anything new to WiFi so it’s hard to call it even an evolution. IT’s just something the standard allows I guess.

Spatial streams
Prior to 11n WiFi was a one stream to one client affair, but 11n brought with it the ability to send 4 distinct streams to one station at a time, which is an increase of 4 times. 11ac continues with this trend and evolves an option of 8 simultaneous streams, which is an increase of 2 times of 11n.
But one needs to understand much more than just numbers here and realize that most client devices are at most 2x2. So whatever your AP is it will basically at best only match what the client is capable of, which means that majority of chains are wasted most of the time if APs don’t employ a different technique of sending data through redundant chains like STBC, and getting stable 3x3:3 connection to even capable clients is difficult and costs power and most APs and/or client devices will rather disable a chain or two or at most employ MRC to enable a better reception.
Another thing to also realize is that phones and phablets will only ever be 1x1 devices due to size and also power restrictions. Tablets will be at most 2x2 devices for the same reason. To integrate more radios and therefore antennas a device has to be the right size for it to even work and integrating an 8x8 chain the size of the device has to be enormous and even then it wouldn’t matter much.
Having more that 2x2 chains is marginally useful so in that respect 11ac is not a revolution at all, it’s hardly an evolution.

Beamforming was introduced with 11n as a big revolutionary idea that would increase the signal strength at the client device and/or would lower the amount of RF propagation lowering CCI an AP causes. But as the standard didn’t specify which BF method to use no one used any.
The only thing 11ac changed in that respect is that TxBF (as it’s called) now has a standard way of defining how to get information on a channel to employ proper weights to each radio in the chain. The catch here is that client devices must support it, which again is still rare, but given that there is only one way defined in 11ac as opposed to about 9 that were defined in 11n maybe we could see something there in the future.
As a side note I have my doubts about beamforming actually contributing in any big way in the real world either by lowering CCI or providing higher RSSI, but I don’t have much data to go on here. It’s more of a hunch and I could be wrong.

Throughput and efficiency
With 11n speeds increased from a “mere” 54Mbps to up to 600Mbps of throughput, a factor of about 10. 11ac promises speeds of up to 7Gbps which is s factor of 12. So 11ac hit and passed the Gigabit mark, a revolutionary step indeed… or is it? The fact is that these speeds can only be achieved through the use of multiple radio chains, spatial streams, wider channels and higher coding rates, all of which are very hard or should I say impossible to achieve due to many restrictions like power and size requirements, price and just pure laws of physics. So don’t expect 11ac capable devices to reach the Gigabit mark anytime soon if at all. But what one should be always striving at is to optimize their network to get devices on and off the medium as fast as possible with as little retries as possible and in turn get the highest average speed possible.

MU-MIMO is a very revolutionary idea. Up until now all standards defined PHY operation as one station occupying the channel at one time which with 11ac they would like to change through the use of MIMO and beamforming to get a better channel reuse.
The trick with this one is for all the receiving stations to be able to differentiate between different streams because every receiving station will receive every others data too. The analogy here is one of identical twins (or triplets) and being able to know which one is which. If one can’t tell the difference from them, how will they know from whom they need to take the data to get the information that’s meant for them?

Band operation
11n operates in both bands, whereas 11ac operates only in the 5GHz band. Although 80 and 160MHz channels can’t even be used in the 2,4G band (they don’t even fit there), 20 and 40MHz can and IEEE could have made the amendment stay in the “dead-band”, but took the opportunity of a new standard and decided against it.
This is a very big thing and for me it’s revolutionary. Even if you don’t agree it’s at least a very big evolutionary step.

Chipsets, as mostly everything anywhere else, evolve. But the rate of evolution is always dependent on outside factors. In that respect 11ac at least sped up this rate and with it every AP and client device that supports it is better off by it. If every node on the network can get on and off the channel faster more can use it and therefore speeding up the network for all.
Nothing revolutionary there but the speed of evolution was probably helped by 11ac introduction and that’s a very good thing for sure.

At the end of the day everyone is looking for more speed. At the start of 11n days it was touted as the cure for all our woes standard, due to the much higher speeds all the bells and whistles brought with it. And I would agree the throughput increase and the efficiencies put in the amendment solved some issues, but those speeds can only be achieved IF proper design principles are employed which, let’s be honest, are still few and far between. The real revolution won’t come with technology, but with realizing that knowledge is the essential ingredient that enables higher throughput, reliability and in the end happy users… or you can talk to your local sales representative to give you the right low-down.

Definite improvement:
  • Chipsets will evolve faster which means better with regards to RF characteristics that will enable faster throughput
  • Mandatory use of 5GHz only

Marginal improvement:

  • Beamforming is standardized, but requires sounding which requires bandwidth and I have reservations about beamforming effectiveness in general
  • Throughput will be higher but only if networks are designed properly
  • 256-QAM

Most likely useless features:

  • 80/160MHZ channels – self-destructive; maybe useful only in P2P links
  • Radio chains beyond 4x4 are unlikely due to power requirements, investment return and just shier ugliness of such APs
  •  MU-MIMO – possible to achieve in the long run, but what's the volume of scenarios where employed

Friday, November 7, 2014

Power comparison of ETSI channels in the 5GHz spectrum

If you are a WLAN engineer in the EU you probably need to know something about channels in the 5GHz band. Three main reasons come to mind. First is that being a WLAN engineer requires you knowing it, the second is that you probably get frequent "What is the max power your APs operate at?" and the follow up "How much do your APs cover compared to vendor X?" questions.

For the sake of pragmatism I'll be naming these two bands as 2,4G and 5G.

I've been asked this quite a bit in my time and I've found that the answer isn't as straight forward in the 5G as it's in the 2,4G band and for the WLAN designer adds a few variables to consider when planing a WLAN network.

I've come across a formal document specifying the use and operation of the UNII spectrum in the ETSI regulatory domain and what I found was intriguing. The FCC in the USA devides the 5GHz band into 4 subsets: UNII-1, UNII-2, UNII-2e and UNII-3 sub-bands. In the EU, to the best of my knowledge, we only use 1, 2 and 2e combined into 2 blocks. The UNII1 and 2 being in one block (A) and 2e in another (B). The two blocks have different usages, with block A permitted indoors only and block B permitted indoor or outdoor.

Each sub-band has a different number of channels available with 1 and 2 having 4 20MHz channels and 2e having 11 20MHz channels. The most intriguing thing I found were the EIRP allowances of those bands. As you can see from the below graph UNII-1 has a max EIRP of 23dBm (200mW), UNII-2 20dBm (100mW) and UNII-2e a whopping 27dBm (500mW). Below is the picture I painstakingly constructed with all the channels, EIRP, DFS and even boundaries - feel free to share.

The power difference among sub-bands means you can expect cell sizes to vary depending on the current channel used by a particular AP. 

But today's WLAN implementations aren't about how much you cover, but rather the capacity and rate-over-range (RoR) characteristics each cell has to be able satisfy different types of devices and services running on them. A sharp drop off at the edge is also very important to limit co-channel interference (CCI) as much as possible. So planing with this graph in mind wouldn't be too bad of an idea.

Another thing to consider here is the comparison with the EIRP in the 2,4G ISM band. Under ETSI max EIRP for 2,4G is 100mW (20dBm) (there might be exceptions) which is the same as the UNII-2 sub-band. The difference between 2,4G and 5G is roughly 6dB which means UNIIs 1 and 2 are somewhat handicapped. This lower EIRP means that the "coverage" of a particular AP working in those bands compared to 2,4G will be lower, maybe even to a point where you will need a second AP working just on 5G to produce the same coverage. Although that said, the noise floor will dictate that also and since 2,4G is getting more and more congested, the difference might not be that great these days.

But jumping on UNII2e wagon isn't as straight forward as well, since one has to consider other factors, like the fact it's under DFS rules and stations that don't support 11h can't probe which can make it a challenge for VoWiFi.

So I hope I've given you something to think about when designing your next WLAN and/or when troubleshooting an existing one. 

Comments and discussions are welcome as always.

Tuesday, September 30, 2014

Make a wall in Ekahau Site Survey

If you consider your self a WLAN designer, you're going to have to use a Site Survey tool and knowing how to construct walls in it will be the key to success. In this post I'll explain how to make a wall in Ekahau Site Survey software tool which as of this writing is on software version 7.6.2.

Ekahau Site Survey (ESS for short) comes predefined with a couple of walls but I'm yet to use any of them for a simple reason that no 2 walls are alike. This is due to the fact that walls in ESS are 3D modelled and any difference in thickens and/or attenuation value per meter will impact the result when modelling RF signal penetration through it.

To fully understand why this is important you can imagine an AP in front of a 10cm thick wall with some kind of attenuation level, for ex. 50dB/m. When a narrow beam of RF signal from the AP penetrates the wall perpendicularly i.e. hits the wall head on, it will loose a certain amount of energy while passing through those 10cm of wall material. But when another narrow beam of RF signal from the same AP hits the same wall at an angle, that distance traveled through the wall will be greater. If we take an example of 45° angle the distance traveled through the wall would be just over 14cm or 40% more than when the beam would hit it straight on.

So to compare the attenuation of the two beams:
- the head on beam would attenuate by 5dB
- the 45° beam would attenuate by 7dB.

Now if we were to use a predefined wall from ESS that would be for example 15cm instead of our 10cm with 50dB/m the following would be true:
- the head on beam would attenuate by 7,5dB (Δ of 2,5dB to the example above)
- the 45° beam would attenuate by 10,5dB (Δ of 3dB to the example above)

So it is important to get your measurements right in order to construct a proper wall in ESS and be able to make the right WLAN design for the building.

This post is only relevant if you are still using a version of ESS before v8. As of ESSv8 constructing a wall is made so much easier in the GUI. Ekahau indubitably made this change in response to this post. A fact which they will surely deny in public, but one that is true. OK, that last sentence is probably a fiction of my imagination, but that won't stop me from putting it in my CV.

Where to start?

To construct a wall you'll need to edit 2 files in your ESS installation directory. In the "/conf" directory you'll find various object types and properties files. That's where you'll also find the 2 files that you'll need to edit. These are "wallTypes.xml" that holds the actual data properties of a wall and the "" which is the key-to-name mapping file. The name in this file is the name that you'll see in ESS when selecting the wall button to draw the wall.

The "wallTypes.xml" file

The wallTypes.xml file consits of an xml schema. Each wall type is defined inside the <type> elements that house 4 other elements and a comment at the beginning. The comment here is especially useful in clearly explaining the properties of your wall and I suggest you use it too. The whole wall schema looks like the one below

<type id="wall_id">
        <!-- wall Xm YdB = Z dB/m -->
        <width>some width in meters</width>
        <absorption>attenuation per meter</absorption>
        <color>color HEX</color>

So you can just copy/paste one of the schemas and edit it. The elements inside the type element are pretty self explanatory but I'll go through them here:
  • key is the element used to map the wall property to the name of your property in the "" file
  • width is the actual width of the wall you are creating
  • absorption is the amount of attenuation the wall presents
  • color is the color you want it to appear in your ESS
I'm yet to understand what the id value in the type element is used for but you can make it the same as your key element just in case. 

The "" file

The key-to-name mappings file is pretty straight forward with lines of "key = name" mappings for each wall type that you make. Note here that ESS will add a dB attenuation value next to the name in brackets but not the width so I would suggest you name your wall with the width parameter, just so you'll know it. For example

my_key = My wall 10cm

and the wall will be visible like so

Don't forget to merge

There is one caveat of this feature. A new wall type will appear only for new projects you start after you have edited and saved both "wallTypes" files. For existing projects you have made before you edited those files you will need to use the File > Merge feature in order to be able to see the new wall in the drop down list of the wall. Then you can overwrite your previous project.

Final thoughts

Hopefully wall construction will become easier in the future as editing files is just not practical, plus there is a bug that appears whenever you make a change in an existing wall type ESS will show a duplicate of that wall in the GUI, but for now you know how to make a wall to fit the needs of the building you are planing the WLAN network for.