SHAtastic “Features”

Over the past two weeks, I have been working on a deployment that “seemed” pretty straight forward.

  • Client has 250 APs in autonomous mode to be converted to Flex Connect
    • The motivation here is due to the APs being deployed across the globe
    • This sounds like a perfect use case for a vWLC
    • APs are a mix of 1142, 1242, & 2702

Sounds pretty cut & dry right? All we have to do is find a code rev that supports all the different AP models, and we should be good to go…

The saga started by deploying the .ova into the environment – easy peasy.

The APs from this decade (2702) joined right up, no problem at all. The REAL fun started when we tried to join the old 1242s to the vWLC. At this point, I was seeing an error from my test AP that read something like this;

“*Nov 11 18:07:36.000: %CAPWAP-5-DTLSREQSEND: DTLS connection request sent peer_ip: x.x.x.x peer_port: 5246
*Nov 11 18:07:36.033: Failed to get CF_CERT_ISSUER_NAME_DECODEDPeer certificate verification failed 000B
*Nov 11 18:07:36.038: %CAPWAP-3-ERRORLOG: Certificate verification failed!
*Nov 11 18:07:36.038: DTLS_CLIENT_ERROR: ../capwap/base_capwap/capwap/base_capwap_wtp_dtls.c:447 Certificate verified failed!
*Nov 11 18:07:36.038: %DTLS-5-SEND_ALERT: Send FATAL : Bad certificate Alert to x.x.x.x:5246
*Nov 11 18:07:36.039: %DTLS-5-SEND_ALERT: Send FATAL : Close notify Alert to x.x.x.x:5246
*Nov 11 18:07:36.040: %CAPWAP-3-ERRORLOG: Invalid event 38 & state 3 combination.”


I couldn’t for the LIFE of my figure this one out. So after 2 hours on the phone with TAC we found out an awesome bug feature. It turns out that for whatever reason, the old APs didn’t like MIC certificate that came native with the vWLC. The work around is that we have to deploy an older ( vWLC model, and then we can upgrade from there. It has something to do with vWLC having a MIC certificate that the old APs actually can play nicely with.

Fine. I’ll just get TAC to publish this older vWLC to me (as I can’t download it on CCO because its redacted) and we’ll deploy it in the environment – seems straight forward enough.

So we successfully deployed the vWLC, and now the old 1242 is fussin’ at me with the following;

The AP logger will show messages similar to the following:

*Oct 29 18:01:56.107: %PKI-3-CERTIFICATE_INVALID_EXPIRED: Certificate chain validation has failed.
The certificate (SN: 7E3446C40000000CBD95) has expired. Validity period starts on 14:38:08 UTC Oct
26 2021 Peer certificate verification failed 001A

*Oct 29 18:01:56.107: DTLS_CLIENT_ERROR: ../capwap/base_capwap/capwap/base_capwap_wtp_dtls.c:496
Certificate verified failed!
*Oct 29 18:01:56.107: %DTLS-5-SEND_ALERT: Send FATAL : Bad certificate Alert to
*Oct 29 18:01:56.107: %DTLS-5-SEND_ALERT: Send FATAL : Close notify Alert to

On the WLC side, you will only see a message like this:

*osapiBsnTimer: Oct 29 11:05:04.571: #DTLS-3-HANDSHAKE_FAILURE: openssl_dtls.c:2962 Failed to complete DTLS handshake with peer


Weeeeee! So now I get to reengage TAC and ask them what all this nonsense is about. It turns out that if you deploy a vWLC, it will start the MIC cert validity period to something like 8 hours AFTER the vWLC comes online. (Bug ID: CSCuq19142). This means that the NTP time on the vWLC, is before the MIC certificate becomes valid. This means that APs won’t be able to join..


So the workaround? For the first day or so the vWLC is online, you outright lie to the vWLC about what the time is.  I just changed the “year” field to 2019 – nothing like living in the future! *Note* I had to delete any NTP server configured on the WLC before the manual time change took effect.wlcTime


From here, the AP joined up just fine and behaved normally. I was also able to upgrade to without issue, because I started with a “correct” vWLC version. After 24 hours, I was able to sync the vWLC back to NTP as the MIC validity “start” time was sometime late last night.

Lots of us will ask “why do these folks have APs from last decade” and the answer is real simple – money.  Why would a company go out and replace a ton of equipment, that isn’t broken? If one dies, they can just replace it with a new one – all we have to do is ensure the vWLC can support both old AND new equipment. I’ve ran into the same exact issue with one of the worlds largest airlines as well – why fix something that ain’t broke?



Now that we have everything up and running, I certainly learned a lot from all of this. Most of it doesn’t make a whole lot of sense as to why they happen (ie; the SHA cert start date being set to some arbitrary value), but at the end of the day – as long as it’s all working – nobody really cares how you got there.

There are many ways to get to 5. Is 4+1 better than 2+3? And more importantly – the client/business owners don’t really care.





How far, is far enough?

Over the Christmas break, I wanted to compensate a few of my Proxim WiFi adapters so that I knew exactly how different they were when measuring RSSI. There are countless write ups detailing how and why we need to compensate our adapters, and the methodology behind doing so. The one thing that kept jumping out at me was how far do I have to be from the AP, in order to reliably compensate WiFi adapters? I read some articles that have said we need to be X distance, and other articles claim Y which is it? I live in an apartment and as such I don’t have a clear long 30′ hall to measure against in. Can I reliably compensate adapters at say, 10′ , but more specifically what is the actual distance required to be in the far field?

For starters, why do we need to be a certain distance from the AP to begin with? If an AP is mounted to a 10′ ceiling, is sitting directly under it too close to reliably compensate my adapters?

The answer lies in the math.

In order to properly be at the correct distance, we need to ensure that our receivers are located in what is called the Far Field. The Far Field is where we can predictably and accurately model the RF behavior with tools like CST, and its where the RF has “calmed down and normalized” – this is the zone that clients will live in.

Overall, the Far Field is the region that is far enough away from the antenna, that the behavior can reliably be modeled and calculated. This is the “normal operation zone” for antennas.

Lets explore the idea of far field so that we may be able to know weather or not we are truly in this “normal operating zone”.

In the world of antennas, there are lots of different types. From Patch Antennas, to Horns, Monopole, Dipole, the list goes on and on. For the scope of this post, I will concentrate around the traditional Half-Wave Dipole Antenna, its far field characteristics, & how to calculate the far field.

What exactly is a Dipole Antenna? This type of antenna configuration has 2 poles(ends) where AC current conducts through each pole 180° out of phase. A Half-Wave dipole is the most common type of Dipole utilized due to the physical space savings when compared to a Monopole.  The characteristic radiation pattern yields the main power lobe orthogonal to the radiating element.

Dipole Radation Pattern


Having the understanding of the basic radiation pattern, we can now look at the governing math behind a Hertzian Diploe.  The Hertzian dipole is a theoretical dipole antenna that consists of an infinitesimally small current source acting in free-space. Although a true Hertzian dipole cannot physically exist, very short dipole antennas can make for a reasonable approximation. The length of this antenna is significantly smaller than the wavelength:

small lambda

A surprising result is that even though the Hertzian dipole is minute, its effective aperture is comparable to antennas many times its size. This allows us to make calculations around characteristics such as the Far Field Conditions.

Field Regions


In order for us to know when we are actually in the far field, we have to actually find out where the far field is located.  We need to define the following;

  1. Wavelength λ @ 5.8GHz;
  2. Speed of Light; c = 3E8 m/s
  3. Frequency f5.8E9 Hz


Plugging in these variables into the above equation, we find that λ = .0516m, or 5.16cm. Half of this length is the dipole antenna length (as we are utilizing a half-wave dipole antenna) therefore, D~ 2.58cm

Far Field eqns

Being that were using a half-wave dipole, D= λ/2 = 2.58cm. For most cases, a half-wave dipole is going to have an antenna length between .33λ and 2.5λ. This means that we are finally in the far field region at 2.5λFor a 5.8GHz signal, 2.5λ= 12.9 cm. Thus, when we are right about 6in away from the AP, we are barely in the far field and will start to have predictable behavior as we move further away.

So what does all this really mean? Welp, you will see lots of heuristics out there that talk about how far you need to be in order to properly compensate WiFi adapters. Based on the mathematics involved, any distance greater than the 2.5λ value for a half-wave dipole should be fine for our receivers. Personally, I like using the 2-3m range. It’s relatively easy to eye-ball,  and my survey tripod just happens to extend up to 10′ – so this is my “minimum distance” that I use when compensate my adapters. It also just happens to be about the height of APs mounted to a drop ceiling in an office environment.

Happy Surveying!