Wi-Fi

You Should Care About DHCP Option 51

Edit 4 Jan 2019 – It has been pointed out to me that instead of packets, these are frames.  You can read more about how I was mistaken here.  The link to RFC 2131, Dynamic Host Configuration Protocol, can be found here.  I’m not going to go through and change all the words, just replace them in your head as you read through!

Dynamic Host Configuration Protocol, or DHCP, is one of the first things you learn about with IP devices and the super basics of how they work; even before you learn binary and MAC addresses and layer 3’s and LAN vs WAN and, and, and, and…

Hopefully you get where I am going with this.  DHCP is one of the building blocks of IP networking, and most people know just enough to survive.  As WLAN Professionals maybe you have heard of DHCP Option 43 (Vendor Specific information) or Option 60 (Class ID) but did you know about Option 51?  It’s OK, neither did I. 

The point of this diatribe is to point out how much most people, including me, don’t know about DHCP and the different options that are defined within the protocol itself, and how this can affect clients on a WLAN.  My interest in this was piqued by a conversation on the WLAN Pro’s Slack site (more on that at the end) and how Apple devices negotiated their DHCP lease.  Didn’t know that there was a negotiation during the DHCP process?  Neither did I.  Let’s get at it.

Basic Options

Some of the basic options that most people already know about, but probably didn’t know their defined option numbers are:

  • Option 3 – Router
  • Option 1 – Subnet Mask.
  • Option 4 – Time Server.
  • Option 6 – Domain Server.
  • Option 15 – Domain Name.
  • Option 51 – Address Time.
  • Option 53 – DHCP Message Type.
  • Option 138 – CAPWAP Access Controller Address

Honestly, the list of options that are available, and what they do, is pretty astounding when you start to dig into it.  It makes me think about some of the different things I could configure on my DHCP servers to try and help my clients negotiate the network easier and faster, improving customer experience.  At least that’s the “pie in the sky” thought.  The honest answer is the ever classic and pervasive It Depends™.  Hence the conversation on Slack about Apple devices and how they “negotiate” their DHCP lease from the DHCP server.

There are a myriad of things that happen within the DHCP process, starting with the typical 4 way exchange that most are aware of:

  1. DHCP Discover (A client transmitting an initial BootP packet)
  2. DHCP Offer (The intitial response from the DHCP server)
  3. DHCP Request (The client requesting the IP offered in Step 2)
  4. DHCP Ack (the DHCP server confirming the IP as being assigned to that client)

What surprised me was the number of options and things that happen within those 4 “simple” packets and how they differed between vendors.  Now as anyone who has dealt with client devices can attest, different vendors can wreak havoc within an infrastructure, but did you realize how much it can do just to a DHCP scope?

Option 51

With just a little bit of experience, and some time staring iPad DHCP Discoverat packet captures, this is a pretty easy exchange to watch, and then take for granted.  For the sake of this conversation, I performed a bunch of captures on my test DHCP server (pfSense – I should probably do a post about that) and focused on Option 51.  This is the part where an Apple device will “negotiate” its lease time.  On the right is a look at my new iPad as it starts the DHCP process with a DHCP Discover message (Option 53).  Notice the time in Option 51?  This is in the initial packet of the process and this Apple device is requesting 90 DAYS (!) for its lease.  I tested this with multiple Apple products and found this to be the same across the board.  Every time an Apple product that I tested sent a discover packet to the DHCP server, it asked for 90 days.

Greedy buggers!

Conversely, the Android devices I tested asked for what the leaseWindows DHCP Req Packet time was as part of the Option 55 section (Parameter Request List), but never asked for a time as a specific option.  Windows devices, pictured here, never even inquire about Option 51; either as a standalone option request or part of the Option 55 Parameter Request List.  This becomes critical when we get to the “DHCP Request” packet or #3 in the process. 

Now while a lot of the parameters requested in this DHCP Request packet on the right aren’t configured on my test DHCP server, the device is still asking for them.  That’s fine, the server will only respond with what it knows.  The cool thing about a pfSense DHCP server is that it knows about TWO different timers for the DHCP Lease Time.  A “default time” and a “maximum time.”  These are configurable through the the GUI and until recently, I never knew why this was such an important thing.

Apple Devices and Option 51

Enter the Apple discussion on Slack that I referred to earlier.  The conversation centered around the fact that Apple devices didn’t like having short lease times for its DHCP.  I don’t have the conversation to post, but I need to give credit to Kristian Roberts for originally bringing light to this subject.  I couldn’t find him on Twitter but he is on Slack (more at the end.)

What Kristian discovered, and I confirmed, is that Apple products will always request for 90 days.  What gets weird is when it request 90 days.  As part of the standard 4 packet exchange, the discover and request (1 & 3) in the exchange come from the clients, the offer and acknowledge (2 & 4) come from the server. An Apple device will only request the 90 days in the discover packet of an initial DHCP process.  In the request packet, it doesn’t include Option 51 for the initial request.  Where this changes is the renewal that happens at the half life of the lease time as defined in the last packet of the exchange, the acknowledge packet.

In my scenario with 2 different lease times defined, this is what an Apple Mac Book Pro looks like from a DHCP scenario:

mbp 75 min dhcp overview

Mac Book Pro DHCP Summary

I did the math for you, and 7,776,000 really is 90 days.  3,600 seconds is an hour that the server responds with, which in pfSense is defined as the maximum lease time.  Notice that the request packet (#3) has no value?  Apple devices don’t request a time in their initial  DHCP request packet so the server responds with 1,800 seconds, or the default time of 30 minutes.

900 seconds after the first DHCP ACK from the server, the client sends a DHCP Request packet when it starts the renewal process; half life of the 30 minute lease that both the server and client respect from the first ACK packet.  If the client didn’t respect that value, the renewal wouldn’t have come in until later.  What I want to call your attention to is the IP Address Lease Time for packet numbers 5 through 10.  In the initial request packet (line 3) the Mac Book Pro didn’t ask for a time but in every subsequent request it asks for 90 days.  The server, programmed with a maximum lease time of 60 minutes, keeps offering it.  The other oddity happens at line 7.  The request comes 900 seconds after an ACK with a 3,600 second (1 hour) lease.  The source and destination IP address revert to a broadcast like the initial request, but it’s a renewal.  This time, however, the client “accepts” the 3,600 second lease because the renewal at line 9 happens 1,800 seconds (30 minutes) later.

The one thing that I can state is that Apple definitely has some “negotiation” happening within their DHCP process.  What I saw above I saw on multiple Apple products so it’s not just a one off.  When the same type of test is compared to a Windows laptop, it’s easy to see the similarities, and the differences.

Windows and Option 51

After examining the Apple products in depth, I wanted to contrast that to other devices.  In environments that support a mix of devices and can’t just focus on a single vendor, this might come in handy in the future.  What I learned, and have alluded to earlier, is that Windows and Android devices just don’t care about Option 51.  This is why, in my opinion, that Windows DHCP servers don’t offer a second lease time in the normal configuration.  We are still playing around with the Windows server to see if we can add a max lease time, but for now I can’t find it.

windows 75 min dhcp overview

Windows Laptop DHCP Summary

 

What we have here is the same test as before, but this time with a Dell laptop running Windows 10.  The only things that changed was the client device and the time of day.  While the general look is the same; starting with the standard 4 packets and then going into the renewal process.  The first thing that jumps out is there isn’t 90 days anywhere in the IP Address Lease Time (Option 51) so even though the server will allow a lease of 3,600 seconds, it only ever offers the 1,800 second lease.  At no point in this test does the laptop EVER request a time.  The only time values come from the server.  The test I did with an Android device looks identical to the summary above.  The only way to tell the difference is to look into the request packet and see that the Android device included Option 51 in the Option 55 Parameter Request List.

That’s it.  Windows and Android devices just don’t care to use Option 51 the way that Apple does.

The last thing that I can draw from comparing the 2 summaries above is why the DHCP Request during the renewal process every once in a while comes as a broadcast from 0.0.0.0 to 255.255.255.255.  For both Apple, Windows, and Android, even though the packet is a DHCP “renewal”, the device still remembers the initial lease time.  When you see the request from 0.0.0.0 without a preceding offer packet, it means that it is the end of the initial lease period.  I’m pretty sure that if I went and read an RFC it would explain that, but I learn so much better doing it this way!

Conclusion

So what does all of this mean?  That’s an easy answer!

It Depends™

I spent a bunch of time digging into what was really happening with Apple devices on my network, and made an adjustment to allow those devices to eventually gain a longer lease.  I don’t have empirical evidence it made a difference, but I feel like it did.  I still have some more work to do, but one thing I can tell you is I have a much better idea of what happens during this process than I did two weeks ago.  All it took was some free software, some time, and a bunch of different wireless devices to play around with.

In an environment with almost all Apple, I could see some benefit to having 2 different lease times, and adjust those to find a sweet spot based on how long the clients stay in the environment.  If you only have Windows or Android, this won’t help you.  What I hope it does is to prod you to do your own testing and see what options you can use for your environment.  It’s not difficult, just takes some dedication and some curiosity.

If you aren’t on the Wi-Fi Pros Slack and want to be, contact the infamous Sam Clements and he can hook you up.  The conversations are more detailed and thorough, and you can even meet Kristian Roberts!

My site won’t let me upload the actual packet captures I collected during my research, but if you want them send me a message and I will work to get them to you.

Thanks for reading!

Advertisements

Aerohive and their 802.11ax Roadshow

A couple of days (now weeks) ago I had the opportunity to attend an Aerohive roadshow that was focused on the new 802.11ax standard.  My reason for attending was to listen to Aerohive’s “Senior Technical Evangelist”, the great David Coleman, CWNE #4 and also the co-author of the Sybex CWNA Study Guide, of which the 5th edition was recently released.  If you haven’t seen it, just take a gander at it.  All told, the page count is north of 1,000 pages!  Anyways, I went because I wanted to hear more about the new 802.11ax standard, listen to Mr. Coleman, and get out of the office, pretty much in that order.  It’s OK, I even put that on my comment card so this isn’t news to anyone involved.

As an event, it was very well done.  My previous experience with Aerohive was limited to knowing they had a “HiveManager” but not knowing anything about it and their little stress ball “bees” that my granddaughter loves to play with.  My biggest fear was that the whole discussion was going to de-evolve into a marketing talk about Aerohive, but with David Coleman involved, I was pleasantly surprised.  David is super smart, and he was able to keep the topic centered on the IEEE standard (that as of November 2018 hasn’t been ratified yet) with just enough marketing to keep the people footing the bill happy.  I was also happy to see that there were administrators of other vendors present; all there just to learn about 802.11ax.  Kudos to Aerohive for keeping the proper mix of technical and marketing, I never felt the pressure of a sales pitch, just good ol’ fashioned arguing about the finer points of Wi-Fi!

Technical Learning

Since I was there primarily to learn more about 802.11ax, I was happy with the technical part of the afternoon.  I also heard other attendees say the same thing so I know it wasn’t just me that thought that.  My biggest takeaways from what I learned, and not just what I knew already is this:

  1. 802.11ax is officially known as “802.11ax High Efficiency Wi-Fi.”  I knew that while marketing people were banging away at the 1024 QAM modulation scheme that provides a jillion bytes per second of throughput the real improvement was centered around improving spectral efficiency.  The fact that someone was smart enough to to include that in the name was a pleasant surprise.11ax RU chart
  2. Resource Units (RU’s) are at the heart of Orthogonal Frequency Division Multiple Access (OFDMA) which is the 802.11 change that allows 802.11ax to be highly efficient.  This was “borrowed” directly from how LTE works, so it’s not like this is a new concept in the RF world, just in the 802.11 world.  As far as the standard goes, the smallest allocation of these Resource Units is 26 subcarriers (or tones).  I’m not going to get into subcarriers here but I will include a link at the end if you want to read more.  It’s nice to know that there is a standard to point to when vendors start to stray from that to improve their marketing jargon.  Why 26 subcarriers being the smallest resource units allowed is important because in the future as this will be akin to the 20 MHz channel width that we know today.  When looking at the chart above, it looks similar to what we know about the channel graphs that go from 20 MHz wide channels to 160 MHz wide channels.  Hopefully this reinforces the idea that 802.11ax is about going smaller to better utilize the spectrum, not going bigger.
  3. There are some new frames that have been introduced in the 80211ax Trigger DL Trigger.11ax standard called “trigger frames.”  On the surface these trigger frames seem innocuous but upon deeper inspection, you come to find out that these new frames actually provide a level of control that previously hasn’t been seen in previous 802.11 standards.  AP’s can now use these trigger frames to learn what type of data, and how much of it, a client wants to send so it can calculate how many Resource Units the AP needs to allocate to each client and make a plan on who it can combine together into a single time slot.  This is at the heart of the high efficiency and I can’t wait to dig deeper into these trigger frames.  All told there are 7 different types of these new trigger frames and I believe will provide additional features going forward.  That’s mere speculation on my part, but I can see how these frames could be leveraged once 802.11ax hits the mainstream.
  4. BSS “Coloring“. This will come as a surprise to no one, but “coloring” is a marketing term, not a technical term.  There are actually numbers for each “color” but it’s easy to see why they added color to the slide so it’s easier to show non-techie people.  What coloring actually does is focus on spatial reuse and the Clear Channel Assessment (CCA) that exists in the 802.11 today.  This new coloring introduces a new “color bit” into the PHY header that can only be interpreted by 802.11ax clients.  This also introduces two new terms to the lexicon known as intra-BSS and inter-BSS transmissions.  Intra-BSS transmissions are both on the same color so nothing changes from what happens today.  Inter-BSS transmissions are when a device determines that what it heard was actually from a different color BSS and treats the medium as busy “only for the time it took to determine the color bit was different.”  Understanding this from a textbook perspective is one thing, it will be really interesting to see what happens when this is deployed in real world scenarios.  Stay tuned in 18 months when we finally have AP’s AND clients available to test this one out!
  5. While PoE is nothing new to WLAN folks, the new AP’s that are being announced are coming with new bells and whistles and are going to require more power to operate.  What has just now started to become an issue with 802.11ac AP’s is only going to get worse.  Designers and engineers are now going to have to pay special attention to power requirements per port, total power per switch, power supplies for the switch, and then UPS requirements for these new higher power demands on the switches.  If you have gotten rusty on your understanding of Ohm’s law, it’s time to break that out and dust it off!

Aerohive Marketing

I knew this couldn’t be avoided, but was happy that it was kept at a respectable level.  If you are avoiding going to this because you don’t want to sit through a bunch of marketing, that’s a mistake.  Don’t get me wrong, it’s there because someone has to pay for it, but David does a good job keeping it from being overwhelming.

One of the things that was interesting to see was the mounting solution that Aerohive has.  I am a big fan of vendors who pay attention to the little things like mounting.  You don’t really understand why until you are standing on the top step of a 10 foot step ladder at 4 AM trying to hang the last AP before you are shut down and some hokey mounting solution slows you down.  It’s frustrating and I always like to look at that when I can.

The other thing I learned about Aerohive is they are going to support WPA3 SAE (the “upgraded” WPA2-PSK) before the end of 2018 and allow older hardware to support it with a code upgrade.  WPA3 Enterprise will also be supported but sadly Opportunistic Wireless Encryption will not be something Aerohive will support unless it becomes mandatory.

I know, I talked with David Coleman about this at length both before and after his presentation, and we parted agreeing to disagree.  While I don’t like the stance that Aerohive has taken in this regard, at least I know their reasoning.  Aerohive supports PPSK and feels that this is the best option for guest Wi-Fi security options.  For 95% of the applications, they are right.  PPSK is a better option and it’s something they support today. Why re-invent the wheel?  Sadly, I fall into the 5%.  I get it, I ALWAYS fall into that 5% outlier so I fight the uphill battle everyday.  I know that in a perfect world every vendor would support every option, but it ain’t happening.

Summary

While I won’t advocate that everyone should run out and purchase Aerohive gear to deploy everywhere (simply because I am firmly in the “It Depends™” camp) it was a pleasant surprise to learn about Aerohive, their gear, and to meet David Coleman in person.  Another pleasant surprise, albeit one I should have expected, was meeting some folks in my area that also work in Wi-Fi.  Sometimes, sitting out here where I do, I forget there are other folks who do Wi-Fi for a living in the city I work in.  Honestly, look at a map, where I work is technically “in the city.”  I will give you that it takes some crazy gerrymandering map work to make it happen, but it is in the city.

Now, if you want to learn more, here are some links that I promised earlier.

  1. Read more about David Coleman’s take on 802.11ax.
  2. Get the Aerohive 802.11ax book for dummies.
  3. Learn more about Aerohive and their gear here.

802.11ax is a thing (WiFi 6) so if you don’t take advantage of great resources like this then you are really missing out!

Meraki Is Now In The “F’ACK” Game

I live in Colorado, and for the past couple of years, Fracking has been a HUGE issue, both physically and politically.  I don’t really understand it, but that’s OK, I’m not going to talk about that in this post.  It’s a rabbit hole I don’t want to go to down.  I bring this up because during Mobility Field Day 3, #MFD3, Meraki introduced “FAST-ACK” and the first thing I thought of, both in name and potential impact, was fracking.

For those of you that don’t know what fracking is or didn’t click on the link earlier, fracking is the process of injecting high pressure liquid into rock deep underground to release trapped natural gas that are in tiny pockets that makes traditional drilling financially unfeasible.  It’s easy to reason both the pros and cons to this (pro = access to natural resources, con = “you are doing what?!?!”) but nonetheless, it’s a thing and it is happening.  As I sat in the Meraki presentation during #MFD3 this immediately sprang to mind.

Now that I have covered natural gas extraction using fracking, let me get to the technology of “FAST-ACK” which was quickly reducing to any number of shorter versions, but other than my witty title we are going to stick with FAST-ACK.  FAST-ACK is a patented technology that Meraki introduced at #MFD3 as a way to speed up your wireless network.  To really understand it, you need to be aware that in a traditional Ethernet connection, there is an ACK packet to a TCP packet, and that has always been there.  In wireless, there is an ACK to most frames as wireless professionals are well aware of, but there will still be a TCP ACK that happens; not to a received frame but from the client to the remote end to acknowledge that it received the TCP payload.  In wireless, it’s not flagged as an ACK, it’s a normal frame.  You would need to dig into the payload to figure out that it’s a TCP ACK.Screen Shot 2018-10-06 at 7.58.58 AM

Meraki’s approach to this is quite simple from a high level.  In order to speed up the delivery of content from a remote device (like a Netflix server), the AP will proxy the TCP ACK from wireless client to the remote end based on the fact that it received a Layer 2 ACK from the wireless client.  While the wireless client is processing the received payload to verify that it can send a TCP ACK, the remote end has already received that proxied TCP ACK and is queuing up the next batch of packets to send to the client.  This means that by the time the wireless client is ready to receive the next batch of traffic, that traffic is already cached in the AP, waiting to be sent.  Over time, this saves time and will get the client the movie they are wanting to download FASTER than the traditional manner.  According to Meraki, TCP FAST-ACK offers up to 38% improvement in throughput!  If you know me, I am a huge fan of getting people their content faster, so now you have my attention!Screen Shot 2018-10-06 at 8.09.59 AM

Now, if you are anything like the group that was in the room when all this was explained, there are some immediate questions that spring to mind, as well as additional questions that arise the more you think about it, just like with fracking in the oil and gas business.  One of the first questions, and this was covered during the presentation, was what about roaming?  Meraki has thought about that and the AP that processes the original TCP frames will cache the next batch until the client is ready to receive them.  If the client roams, the AP will transfer that TCP data to the next AP so that the new AP is ready to send it the moment the client is ready.  So that is covered, no problem.  My lingering question surrounding that is what does that do to the price of an AP when it is discovered that the AP will need additional storage to cache more and more data in certain venues, like LPV?  I could see a highly mobile environment with clients downloading a lot AND moving around a lot, there might be problems.  Time will tell, and I’m afraid that only time will tell about that.  Maybe this means that in certain environments, FAST-ACK shouldn’t be turned on.  Does that limit the market for Meraki?  Again, only time will tell.

After the presentation, as the delegates were packing up and talking, the majority of the conversation was focused on FAST-ACK and potential ramifications of this new technology.  Just like with any wireless centric conversation, there were multiple opinions and just like normal, none of them were wrong, per se, they were just different.  What happens if the client doesn’t send the TCP ACK to the remote end but asks for that payload again?  Does the AP send the next batch and then waits for the repeat batch?  All this TCP payload is numbered, so it will be received out of order, but that’s one of the reasons that TCP number is there to begin with.  If that happens, what is the trickle down effect of that?  What else suffers?  Is that throughput performance improvement worth the risk?  Again, only time will tell, because I don’t think we know what that risk is in the wild.  Too many times I have been burned with technology that works great in a lab setting or in an environment that was hand picked for testing, only to find out that in the wild, it’s not really worth the time and investment.  I’m not saying that is what is going to happen with FAST-ACK, I’m just being cautiously optimistic for the time being.

To watch the full Meraki presentation, go here and see for yourself.  To really understand the impression that FAST-ACK made on me, notice that the FAST-ACK portion doesn’t start until the 15 minute mark.  Before that there was a conversation about external antennas for ALL the radios in an AP – client serving, scanning and BLE.  If you know me at all you know that I love antennas so the fact that my first post about the Meraki presentation wasn’t about the fact that they are dealing with one of my pet peeves but instead introducing a mechanism to speed up the TCP flow should tell you something.

I still think that only time will tell on the real impact of Meraki’s FAST-ACK so if you like to be on the bleeding edge of technology, jump in and tell me how the water really is after you have done a couple laps, I am really interested in how this plays out.

In the mean time, I think I need to re-think the name of my blog.  The fact that I typed an entire blog post centered around TCP ACK’s might mean that maybe I DO know squat about networking.

Damn.

Why the Wi-Fi Alliance Numbering Scheme “Matters”

So yesterday, the 3rd of October, 2018, the Wi-Fi Alliance announced a new numbering scheme to define their certifications instead of the traditional 802.11a/b/g/n/ac/ax terminology everyone as used for the past 20 years.  Had you given me a heads up I could have predicted how the Wi-Fi professionals I associate with would respond, and I wasn’t disappointed.  In grand fashion, the majority of them lambasted the Wi-Fi Alliance for coming up with such a needless and pointless “thing” and questioned why they were wasting their time on such a thing when they could be doing things Wi-Fi professionals have been begging for for years.  If you haven’t seen the actual release, you can read about it here.

As the day wore on, there were some voices in the crowd that started to question the outrage and jokes and general negative comments that came out.  Questions like “why do you care, this isn’t intended for you” and “why can’t you just deal with this?”  After getting a not as restful sleep as I would have hoped for, I want to tackle this question today with an argument I have been using for years.

What you say actually matters!

Here is my argument, and I use it on people who understand networking much more than wireless, because that’s who I deal with on a day to day basis.  When someone plugs a network cable into a network switch and a device, generally it will auto-negotiate the connection speed.  The speed that is negotiates at is set at a pretty small number.  The traditional speed chart you can see on a switch looks something similar to this:

10/100/1000BaseTX

On my newer “M-Gig” switches, it actually looks like this:

100/1000/2.5G/5G/10GBaseTX

Now, counting up the different numbers we see, we can safely say that these devices will negotiate a connection speed of one of six possibilities.  Somewhere between 10BaseTX and 10GBaseTX, but that rate has only SIX possible answers.  Guess what, there is an IEEE standard for each of those, but only the geeky among the wireless community knows what those are (802.3ab for 1000BaseTX if you care; I had to Google it.)  I bet if I asked some of the route / switch CCIE’s in my office they could tell you what each standard was (maybe, I didn’t ask) because that is their business.

Since no one in the general public buys network switches, no one cares what 802.3ab is.  There isn’t some alliance out there trying to promote some “certification” using 802.whatever to sell stuff.

Wireless is different.

I mean it’s somewhat different, but different enough that it really, REALLY matters.  Every year there are launch parties for new consumer devices that tout the latest and greatest device and how it is so much better than it’s competitors.  Up until yesterday, the Wi-Fi part of those new devices were relegated to using 802.11acW2 or 802.11ax, or “802.11an” (not a real thing, it supposed to show 802.11n that is 5 GHz capable.  See the confusion?)  Now, thanks to the Wi-Fi Alliance, all we have to say is “Wi-Fi 5″ or Wi-Fi 6” to say what the capabilities are.  From my Mom’s point of view, that’s easy for her to understand.  “6 is better than 5, so I go with 6.”

One slight problem with that.  Remember the 802.3ab comment from 2 paragraphs ago?  How wired switching only negotiated at 6 different speeds (more like 3 but I want to give the wired guys as good a shot as possible)?  Ever really looked at the wireless connection speed negotiation table?  If you haven’t, it looks like this: Notebook-Resources-001This is from the Wireless LAN Professionals Custom Field Notebook, and it is so cool that if I really like you, this is what I will be giving you for Christmas this year.  If you don’t want to wait to see if I really like you, go buy one here.  I use mine multiple times a week, much more than I originally thought.

Anyways, to save you the trouble of counting the different negotiated speeds, the table lists 232 possible connections speeds, based on 11 different criteria.  232 for wireless, 6 for wired.  If you are a marketing professional, this is the type of table that serves exactly ZERO purpose for you.  If you are a wireless professional, you use this table almost every day.

Different responsibilities, different use cases, different requirements.

Marketing people can’t sell a chart with 232 possibilities based on 11 different criteria.  They needed something much more simple, and the Wi-Fi Alliance delivered.  Yes, it wasn’t for professionals, but this is why we care, and more importantly, why it matters.

As Wi-Fi professionals we have to talk to the people that this is intended for.  We have to answer questions when the executive gets back from their latest conference and asks what will it take to get to “Wi-Fi 6” or better yet, “Wi-Fi 7” because they need to out perform their associates on LinkedIn.  Maybe you work for a VAR and your angst comes from having to answer an RFP that lists these in the criteria, but nothing about security.

Bottom line – professionals like to keep things very detailed and technical because that’s how it works.  It’s not a secret, there are books and classes out there for those inclined to learn all the details.  Just like any other profession, you can learn what all of it means if you put in the time and the effort.

We don’t ask building architects or structural engineers to dumb down their profession for the average person on the street; we trust them to do their job correctly.  If not, there are major ramifications.  Of course architects and structural engineers don’t need to market what they do to the average person on the street, but Wi-Fi professionals have to, albeit in a round about sort of way.

Are the new naming conventions going to go away?  Of course not, they are already out there.  Will someone use them?  Of course they will, it shows how smart they are.  Will Wi-Fi professionals complain about it?  Of course we will, we complain about everything.  Bottom line – let us complain because we know at the end of the day, it’s just one more thing we will get to explain to people about the magic that we do.

Aruba Takes The Lead With WPA3

Let’s just call a spade and spade.  And by that I mean that Aruba Networks played their trump card at Mobility Field Day 3 (MFD3), and it was the Ace of Spades.

For three days, delegates of MFD3 listened to vendors talk about A.I. and machine learning and analytics and location and BLE and a little on 802.11ax.  What wasn’t talked about much is the new WPA3 standard/certification that we have been waiting on since WPA2 was first introduced back in 2004.  WPA2 is now a surly teenager in human years but in the world of technology has now been likened to a pensioner heading into retirement.  14 years is a LONG time to have anything in technology a standard.  In the 802.11 realm, it’s just slightly younger than 802.11g!

Let that sink in for a second.

Then comes along this company called Aruba Networks as the last presenter at MFD3.  They started with the standard quick introduction and then talked about a new product that is intended to be used as a Point-To-Point (PTP) link with dual radios; one at 5 GHz (802.11ac) and the other at 60 GHz (802.11ad) that by itself is cool enough to stand on it’s on.  You can watch that presentation here if you want to learn more about it (which you should, it’s cool) and then a quick hit on their 802.11ax stuff.  Again, pretty cool along with a good slide about dates surrounding 802.11ax.  If it wasn’t for what came next, this would be my focus but the next topic changed everything for me, so their hardware will have to wait for a different post.

The next presenter was a gentleman named Chuck Lukaszewski, and he brought the goods.  Chuck presented on Aruba’s efforts in the realm of security, WPA3, and more importantly, Opportunistic Wireless Encryption (OWE).  OWE was recently changed from a requirement by the Wi-Fi Alliance for WPA3 certification to an optional feature, much to the chagrin of wireless professionals everywhere.  The general consensus was if it’s optional then no vendor is going to put any effort into it because why would they?  Chuck changed all of that with this slide:

Aruba WPA3 Summary

I’m sure that myself and others will talk about these other new terms, “SAE” and “Suite B/CSNA” which are still part of the required certifications, but I want to focus on OWE, the optional part that we all wanted but had given up hope on.  If you watch the presentation, it’s easy to pick up on how excited we all were to not only know that this wasn’t dead, but that Aruba was actually able to demo this in action, live, and in front of a technical audience.  802.11ax might promise crazy QAM rates (1024 QAM to be precise) along with BSS coloring and OFDMA (allowing clients to utilize LESS than a full channel if they don’t need it, LOVE that one by the way) but sometimes the improvements that are needed are not always the sexy and marketing bullet points that C-Series executives want to see on their hit sheets.  1.21 JiggaBytes Per Second (JBPS, I just made that up) is much cooler on a marketing sheet than “hey, we did something that is cool but your will never be able to tell because it is seamless to you” but let me assure you, it’s the one thing that we NEED in the wireless industry.

Everyone knows that you don’t use the Wi-Fi in public places because you are going to get hacked by the guy sitting a couple of chairs away and your life will be in shambles.  Guess what OWE solves?  Exactly!  This feature is not meant to authenticate the user, nor account for what they are doing.  That will always be left to the Enterprise version of the WPA2 and now WPA3 standard, this is meant purely for the guest client/user that you want to allow onto your Wi-Fi and you want to ensure that no one can sniff their traffic while they are onsite.  This doesn’t interrupt captive portals (shudder) since that operates further along the network path so you can still stop users from accessing the internet; no, this is intended as a feature that shores up the bane of the Wi-Fi world – guest Wi-Fi is insecure due to the open nature of the network.Aruba OWE Protocol Flow

I call this my “Mom” feature.  My mom uses technology, but she doesn’t understand much more than other mothers of her generation.  She doesn’t understand why having a 4 Way Handshake (seen above) right after the association packets is a good thing, but I don’t need her to know why or understand.  All she needs to know is that if she selects a device that supports OWE from the WPA3 certification and is at a location that supports OWE, she can now have some level of assurance that when she surfs the internet and sees the lock symbol in the upper left, she doesn’t have to call me freaking out.  People not calling me freaking out is a good thing by the way.

So what’s next?  Good question.  Start by going and watching Chuck’s presentation at Mobility Field Day 3.  Watch the reaction from the delegates at what they presented, and then watch the video again to let it sink in of what you just saw.  GCMP/CCMP protected data over the air on a guest Wi-Fi network.  The user only has to select the network and the protocols then take care of the rest.

Next, start bothering your infrastructure vendor of choice to find out what they are doing in the realm of OWE.  Is it on their roadmap?  When are they going to be releasing something about OWE?  If it’s not something they working on, why not?  Aruba has taken the lead on getting this into the public space, it’s now inherent on us, especially those of us in the Large Public Venue (LPV) realm to push ALL vendors to support this.

After the infrastructure vendors, start working on the client side.  Remember, you need a client side device that can do this, or the ability to add it, to make this work.  Ask Apple, Samsung, Motorola, LG, Dell, HP, and all the others, what their roadmap is for supporting this.  Predictions are we will see 802.11ax clients next year and I really hope they have the supplicant side ability to do this.  If not, as an industry we are missing a HUGE opportunity here and I for one won’t sit idly by and watch this opportunity slip away simply because we don’t have to.

I am sure I will harp on this subject more in the future, I think that it’s just that important.  When and if I come up with anything new I will make sure that I share it, but for now I want to thank Aruba Networks and their engineers for taking the lead in this effort.

It’s not the new features you thought you wanted, it’s the features that you didn’t think you needed!

**Disclaimer – I have not received any financial compensation or consideration from Aruba Networks for my thoughts here.  These are my thoughts and opinions alone and Aruba Networks is not responsible or forewarned about what you read.**

Mobility Field Day 3 – A Delegate

So I just finished my first Mobility Field Day 3, #MFD3, put on by Tech Field Day (Gestalt IT.)  It was one of the most amazing experiences in my life!

At this point, you are probably thinking “well, here comes the book report on each presentation and how I was ‘blown away’ by all the vendors that presented” so I will stop reading now.  Sorry to disappoint you but this is not one of those.  Don’t worry, I took many notes and thanks to the way that Tech Field Day is recorded, there are video recordings of all the presentations so I can go back, review the tape and write extensive novels on every presentation and bore you that way.  War and Peace wasn’t written in one weekend (maybe it was, I’m too tired to check right now) so give me some time.

What I want to discuss is the behind the scenes, the “sausage making” that I was completely unaware of, and the rest of the delegates that joined me in our merry jaunt through Silicon Valley (or “Silicone Valley” as one person called it.)

First up is Gestalt IT (@GestaltIT) and the team that was here on the ground with us.  If you don’t know, Gestalt IT is the company formed by Stephen Foskett (@SFoskett) to facilitate getting people together and discussing the topic of the day.  The Gestalt IT team for my first MFD was made up of Tom Hollingsworth (@networkingnerd) and Ben Gage (@BenTGage).  With detailed emails before the event and then from the moment each delegate touched down at the airport, they had everything under control and guided the two new people, me and Scott Lester (@theITrebel) with what we needed to do and wrangled the veterans like the herd of wild cats they are.  I’m pretty sure that without their patience, understanding and just the right amount of snarkiness and sass that none of this would work.  At least not with the crowd I was fortunate enough to join.  Luckily it didn’t take Scott and I very long to shake the newness and jump right into the herd of wild cats to ensure that Tom and Ben had a full compliment of crazy, irreverent wireless geeks to wrangle through the rough and tumble streets of technology town and not just 10.

You’re welcome Tom and Ben!

For three days they tried to get us to focus on the task at hand and behave like adults that we have fooled people into thinking we are.  All I can say is if you watched the live stream and the videos posted on YouTube and Vimeo after the fact it looked they they did a fantastic job with their task; it’s because they did.  Off camera we lived up to the wild cat moniker.  Me personally, I loved it.  More than one time the group had me laughing so hard I cried.  To reveal a secret, even Tom Hollingsworth joined the wild cat pack at times.  Luckily Ben Gage was there to keep us inline.  Ben’s a musician so I find it funny that the musician was the adult of the group.  Tell me how many times you get to say that!  Seriously, Ben deserves an award after our group!

Now for the delegates.

You can go read about them on the site but I want to round this up by filling you in on a few surprises I found out by hanging with the rest of the delegates.

  1. Robert Boardman – I’ve known Rob as the quirky part of the Wi-Fi of Everything duo of him and Rowell Dionicio (I have a man crush on Rowell, and he was here as a delegate as well, but this is about Rob.)  In one of the bigger surprises for me this week, Rob is actually really smart!  My perception of him completely changed when the camera went live and the heat was on.  His questions and understanding of the vendors and the technology was impressive and I have a new found respect of him. Don’t get me wrong, he stilled delivered comedy relief while the camera was on, and he can be an even bigger dork off camera, but my whole perception of Rob has changed for the better because of this.
  2. Jennifer Huber – Jennifer worked a project for us one time a while ago, and I always thought of her as a proper wireless expert and very knowledgeable.  I’m sorry Jennifer, but I might even say a little “boring.”  She teaches yoga and eats healthy, and I really thought we wouldn’t get along much.  Boy was I wrong!  First day we sat next to each other through the Apple product launch, and she can turn on the angry woman in a flash!  The words I heard coming from the professional sitting to my left was impressive!  By the end of the Apple product launch I realized that I could really dig sitting next to her for the next three days and listen to her go off.  Major props Jennifer!
  3. Keith Parsons – Everyone knows Keith, and everyone loves Keith.  I have written many blog posts that talk about Keith and his role in my wireless journey, but this isn’t about that.  I sat next to Keith a couple of times and I don’t know why this surprises me, but this is what I learned about Keith.  That man can multi-task!  I would look over and he would be doing something on his computer that made me think he wasn’t paying attention and then BANG!  Keith would be asking tough questions about the presentation and taking their experts to task on what they said, and never letting them hide.  One more thing to add to his myriad of skills and why it’s good to be friends with him.
  4. Lee Badman – Lee, from #WIFIQ fame, is the crotchety Wi-Fi man that you think of when you think of the hero of the suffers of bug infested wireless code.  What I didn’t realize about Lee until this week is the man has a dry sense of humor that I find very appealing.  That guy, if you give him the time, has some of the funniest ideas that I heard all week.  I don’t want to give them away, but I really hope he follows through with the idea he presented during lunch on the last day.  Lee, please help out the community and move that idea to the top of the list.  It’s what the community needs, even if they don’t know it.

As for the other delegates, please don’t get me wrong, they were all the rock stars you think of when you hear their name.  No disrespect to Amy Arnold, Johnathon Davis, Mitch Dickey, Rowell Dionicio, Sam Clements, Scott Lester, and Stew Goumans for not making my list above.  Every single time there was something that needed to be said, a point made, calling out a vendor for not answering a question, whatever, they were always willing to step up and say what needed to be said.  Sam was the gracious expert that I needed, Rowell was the quiet professional you think of, Stew was the 802.11eh representative we lacked.  Amy was the star of the wired side when we needed the support for that subject, JD was constantly there keeping things moving and Mitch was the SCA champion you know him to be (and the Red Bull champion of the week, hope your heart is ok!) and Scott was always ready with a question or additional guidance and input.

I know that without the full compliment of delegates that the team was able to assemble, my week wouldn’t have been as great.  In the end, I got just as much from the group that I traveled with as the vendors that presented.  My hope is that as the group of delegates, we were able to represent the community at large and did our best to ensure that those that didn’t attend in person were able to benefit from our work as well.

MFD3 Group pic_jpg

 

A Story of Three Companies

During Mobility Field Day 3, we were fortunate enough to visit with three different companies that were in different stages of mergers/acquisitions.  To be fair, the third company, NETSCOUT, hadn’t announced anything while we were onsite, it was business as usual.  This post is being written with the benefit of hindsight.  Luckily for me, it bookends my thoughts nicely so winner-winner, chicken dinner for me!  I’ll get back to NETSCOUT here in a bit.

In chronological order, we met with Arista first.  I know that some might ask why the Mobility Field Day delegates met with Arista.  Some might know why and some might ask who is Arista.  For those not in the know, you can get caught up here.  Shortest story is Arista acquired Mojo last month, so now they are a “cognitive Wi-Fi” company.  I don’t know what that means, and honestly after sitting through a 2 hour presentation with mostly Arista folks and not enough Mojo folks, I still don’t know what that is supposed to mean.  I get why they presented, but I know that as a group we were mostly confused on what was going on during the first hour.  As a first time delegate I didn’t know if the majority of the presentations were going to be this dry and wandering or not.  (Luckily for me, they weren’t.)

My thought after the presentation was here was a company that wanted to be able to support full stack across the enterprise with some version of Artificial Intelligence (A.I.) or Machine Learning (M.L.) that I am still not clear about.  Either way, they wanted/needed a wireless product they could slap their name on and go forth and prosper.  Granted, until they get an access layer switch that provides PoE (RIGHT?!?!) that won’t happen, but I suspect it won’t be too long before that is announced.  At least that is my hope after our feedback.

The next day we met with Fortinet.  Most everyone knows about the Fortinet acquisition of Meru since it did happen back in May of 2015.  What I want to discuss is how their presentation went during #MFD3 and what was learned.  After WLPC 2018 in the US, Mitch Dickey of @Badger_Fi fame wrote an open letter of displeasure to Fortinet asking them to step up and do a better job of explaining what they were as a wireless company, not just a security company.

Boy did they listen!

Fortinet did a great job presenting how their wireless product integrated with the rest of their portfolio and how it was more than something bolted on as an afterthought.  They also announced (OK, it has always been a thing, they just pointed it out) that the Fortinet wireless line was cable of running in both SCA AND MCA configurations!  I know for some of the delegates in the room, this was a new thing to learn.  I also know from some phone calls since #MFD3 that others didn’t know that as well.  The message that was delivered by the Fortinet team was smooth and eye opening.  As we left their facility at the end of the day, the general consensus was that Fortinet listened, changed their approach, and delivered with a great presentation at #MFD3.  While I agree they did a great job with their presentation and everyone was impressed, I want to point out that they didn’t really announce anything new or groundbreaking while we were there.  More on that later.

The next morning we went to NETSCOUT for their presentation.  We didn’t know it at the time, but the ENTIRE product line that they presented on was almost 2 feet out the door.  Think about this; they presented Friday morning at 9 AM PDT and when I woke up at 6:30 AM PDT on Monday they had already made the announcement.  As far as I know the ink was dry on the deal on Friday and they were just waiting for the approval on the press release wording.  Their presenter, Julio Petrovich, did a great job talking about their product line for 2 hours all while having to have some inkling, or concrete knowledge, that something was afoot.  You should go back and watch his presentation, I’ll add the links at the end, and keep in mind of what he might have known or assumed all while presenting.  Got to give the guy some props for that!  One other key piece of information is that I know that Julio will be moving with the Handheld Network Test (HNT) product line as it is “carved out” of NETSCOUT.

All of this to bring me to my point.  While I know company acquisitions and mergers and such are common place in “The Valley” (HP Enterprises bought Aruba in 2015 as a point), for me it was interesting to see such a different approach to their presentations, and possibly a lesson to be learned for whatever the HNT line that was spun out of NETSCOUT will be called.

For three years after Fortinet acquired Meru, I would say they languished in misinformation and confusion about what they were as a wireless company and what they could offer to the wireless community.  I would say that Mitch calling them out after WLPC, other feedback from the community and with the efforts of a gentleman named Christopher Hinsz, Fortinet turned their message around.  I give Chris a lot of credit because he did a nice job while he was at NETSCOUT and it was readily apparent that he had a big hand in the presentation Fortinet did at #MFD3.

To both the “TBD” handheld network testing company that we just found out about on 17 September 2018, and to the team over at Arista, you are both on the same journey, just a couple of weeks apart.  Take a page from what they did at Fortinet (just don’t take Chris, I like him at Fortinet) and learn that the wireless community is always there to help.  That was what we tried to do at #MFD3, and the community at large is always willing to chime in (some better than others) on the good and the bad that a company is doing.

Lastly, and I hate to say this, this is all about your messaging.  Not marketing, we can smell that out with both eyes tied behind our back, but your actual message.  Fortinet was able to redeem themselves by presenting a concise, cohesive message to the wireless community, and that means something.

Be honest.  Admit when things are still in the works but not ready yet.  As a community we are all used to things not going our way (ever heard of client drivers?) and are generally forgiving, especially early on.  Listen to the feedback we give on social media and at conferences, it will go a long way as you try to navigate the world of people that MIGHT have been exposed to just a little more radiation than is really recommended.

You can find all the videos from #MFD3 on YouTube