THE BLOG ★ Ramblings on WiFi & stuff.

Ep. 004: PCAP'n with Eddie! Multi Channel Wireless Packet Capture on the LINUX!


Now we move on to Linux! Learned myself how to do multi-adapters on Ubuntu with Wireshark. I am sooooo excited!😬 There's more. ⬇

Ubuntu 2019.3

Wireshark 3.0.5

Netgear A6210

HANDY COMMANDS:

INSTALL AIRCRACK-NG

sudo apt-get update

sudo apt-get install aircrack-ng

SET NICS TO MONITOR MODE

sudo airmon-ng check (Checks for possible interfering processes.)

sudo airmon-ng check kill (Kill ‘dem processes!)

sudo airmon-ng start interface-name (Start monitor mode)

sudo airmon-ng stop interface-name (Stop monitor mode)

START NETWORK MANAGER

sudo systemctl start NetworkManager.service

REMOVE AVAHI-DAEMON

sudo apt purge avahi-daemon

CAN'T CAPTURE IN WIRESHARK?! 😱

sudo dpkg-reconfigure wireshark-common
(press the right arrow and enter for yes)

sudo chmod +x /usr/bin/dumpcap


Add a Custom AP + Antenna Combination in Ekahau

Shout out to @WiFiNigel for helping me figure this one out. I'm sure there are other folks out there that have figured this out, but I never did... until now.

So, I'm in the middle of a design in Ekahau Site Survey (ESS) for a fairly large manufacturing facility (about 1.2 million square feet) and I'm using a specific AP with various antennas types depending on the use-case at the facility.

When you place an AP in ESS the next time you place a new AP on the map it uses the last AP you placed, and it saves you previous configs such as TX power, antenna hight, and angle. However, if you customize an AP - like I did - by selecting an AP from the dropdown and then changing the antennas to a 3rd party antenna -the next time you place an AP it DOES NOT use that - it uses the default from the dropdown.

This is a bummer if you're a.) adding a lot of APs, and/or b.) are switching between antennas types (like say a patch for racks, and dipoles in open areas, etc). Every time you place an AP you have to manually go in and change EVERYTHING - the TX power, the antenna hight, the angles, and of course - the antennas themselves.

I knew you could make changes to the ESS conf files for adding custom antennas and APs, but I had never actually done that - until now. I edited the "accessPointTypes.xml" file and added the AP with the antennas I wanted. The antenna already existed in ESS, it just wasn't paired with the AP I wanted to use. I figured this was all I needed to do to get it to work.

Upon opening my project file in ESS I saw that the new customized version of the AP was there in the list! (Yay!) But, when I placed it I saw only the generic antennas matched with it. (Boo.)

Nigel then made the brilliant observation that I may just need to look at the antenna conf files and add the AP + ANT combination there - and when I looked at the antenna files I noticed that's exactly what Ekahau did. They had AP + the 2.4 and 5 GHz versions of the antennas there:

So, it was quite simple really - I just copied each of the antenna files I wanted (2.4 and 5 GHz) and then pasted them back into the same folder. Now I had version of each (with the "copy" appended at the end) and all I had to do was rename the file by adding the AP name "+" the antenna name and remove the "copy" at the end. I then edited the "accessPointTypes.xml" again, this time I used the name of the antenna file as the name of the AP and saved the file.

Lo, and behold, when I restarted ESS, there it was! When I added the AP it had the correct antennas for 2.4 and 5 GHz, and when I added the next AP it matched the antennas as well as all the setting changes I made for the first one (TX power, ANT height, angle, etc.). I was pretty stoked - so I wrote this blog.

So, if you have a project where you have lots of APs with a 3rd party antennas, and don't want to edit EVERY. SINGLE. ONE - try this:

* NOTE: This is NOT the "Custom AP" that shows up in ESS. You should never use that.

This is for creating your own existing AP and Antenna combinations.

When you add an AP and change the antennas type in Ekahau, the next time you add the AP it will not have the same antennas, or settings. You have to manually edit the AP everytime you add it if it's not a combination that already exists in the dropdown.

You can edit the config files for antennas and APs so that you can create custom AP/ANT combos for use in all of your projects.

* EDIT 05-31-2016  I forgot to mention that you'll need admin rights to edit anything in that folder. Just right-click on the folder and give yourself full-rights.

*IMPORTANT! @WJComms on the Twitters made a good point: BACKUP YOUR CONFIG FILES AFTER YOU EDIT THEM. If you don't they'll be written over when you update ESS and you'll lose your changes. Back them up somewhere else and copy the changes to the updated config files after you update.

Aruba Clarity. 'Cuz Wi-Fi ain't always the problem.

It’s interesting that Aruba showed off “Clarity”, a new feature in its network management product AirWave, at Atmosphere. It’s interesting because it seems that lately there have been discussions about users blaming Wi-Fi for non-Wi-Fi related issues. I even blogged about it myself a few weeks back. And recently, Lee Badman posted the "soon to be famous cocktail napkin" he drew, to explain how wireless issues are more complicated then they appear. When users are connected to Wi-Fi, and they can't get to a webpage, or get an IP address, or that fancy captive portal you spent so much time customizing, the assumption is, “the Wi-Fi’s broke” ¯\_(ツ)_/¯. And the user is right… well, as far as they know, or care. And that’s where Clarity comes in.

What Clarity does is offer a window into what may be affecting the wireless user experiencing a problem. Clarity gives you a "heads up" letting you know there are issues with DHCP, or DNS queries, association, and authentication failures, by showing you an overview in its dashboard. Also, it gives you a "real-time" view of a client experience. Maybe it's taking too long for a client to associate to an AP, or the captive portal is not working, and you see DNS issues on the clarity dashboard - insight into what the REAL issue could be.

The fact is many help desk calls about wireless, are not wireless problems. The problems lay elsewhere in the infrastructure. Knowing where to start your troubleshooting helps you find resolution faster. Clarity is another tool in the help desk arsenal to help you get customer complaint resolution quicker, and more efficiently.

But, that's not all. Clarity also offers "Synthetic testing". Essentially, it allows you to simulate user activity on the WLAN, by using an access point as a client. You can then use that simulated client to run tests on the WLAN. If there are service affecting issues you have an opportunity to find them, and fix them, before you actual users arrive.

In a scenario we were shown you would go to the VisualRF tab and select the location you would like to perform the test. You then click on the AP you would like to act as your client and perform tests that simulate a client connecting to the WLAN. This test should expose issues with DHCP, DNS, captive portals, etc.

In theory, this should help predict, or rather, REVEAL problems that could occur once the real clients arrive onto the WLAN. This is what we as WLAN professionals do when we perform validation surveys after a deployment. You do perform validation surveys after all your deployments, right?  It's a very appealing idea to be able to perform tests, maybe even SCHEDULE tests, on a regular basis, to head off those issues at the pass.

This is what I would love to see - a mobile app that can be installed on a client, that can perform those same tests. This would be an improvement to the already great option of testing with an AP or an AM (Air Monitor), but here's the difference - it's an ACTUAL client. It's not an AP, on a ceiling (where there are no clients), with super RX sensitivity. It could be a single-stream mobile device, or 3-stream MacBook Pro, and you can run test AS THE CLIENTS THEMSELVES WOULD. Run test in multiple clients at the same time - like you would see with REAL clients.

Well, Aruba is already working on that. It will initially be an Android only app, that will allow you to perform Clarity tests from the client itself. There is no word on a release date, but I am hopeful that it will come in a timely manner.

At introduction, Clarity will be available only for Aruba controller-based platforms.

Aruba Clarity with real-time monitoring will be available as part of the Airwave 8.2 release coming out in the next few weeks. Synthetic testing will soon follow.

WLPC, here I come!

Estimated reading time: 1 minute, 24 seconds. Contains 280 words

 

Well, it's that time of year again - Wireless LAN Professionals Conference (WLPC). This is the 3rd (U.S.) conference, and my 3rd as well. I look forward to this gathering of Wi-Fi geeks all year. I tell anyone who asks about learning wireless - if you can only go to ONE conference - this is the one.

My first WLPC was in 2014 in Austin, TX, and other than following WLAN pros on Twitter, I knew no one. I was overwhelmed at the knowledge, and people, I had access to. I got to listen in on conversations with people like Keith Parsons, GT Hill, Devin Akin, Andrew Von Nagy, Chuck Lukaszewski, and others.

I was a total fish out of water. I had just gotten my CWNA a few months before, but I really didn't know how far I would go. This conference was the impetus to start my blog, get involved in the WLAN community, and set a goal of achieving CWNE.

I was encouraged by all the people I met. People like me, who were relatively new to the wireless thing, and those who were well entrenched. Meeting other 'newbies' was encouraging, because I wasn't the only one who felt insecure in their Wi-Fi proficiency. Meeting the 'Pros' was encouraging because they were welcoming and open to sharing their knowledge and expertise with those of us that were new.

I encourage all WLPC first timers to get in the thick of it. Make an effort to get to know people, ask questions, listen in, and get involved. Push aside any timidity you may have, because the folks at WLPC are more than willing to welcome you in and share the knowledge.

DFS implications for hidden networks and roaming

UPDATE: See the comment below by Andrew Von Nagy. It clarifies what I said about hidden SSIDs and DFS.

 

I'm a huge advocate of using DFS channels in most medium to large deployment scenarios. But, you should always validate your channel plan and make sure it doesn't cause issues with you WLAN. By that I mean verify that your devices actually do support DFS. It’s possible certain devices support DFS, but not ALL DFS channels. Checking manufacturer documentation, Google, or site like clients.mikealbano.com can help you figure that out.

Case in point: Hidden SSIDs. Most wireless folks recommend against using hidden SSIDs. It doesn't provide any security, requires more work to connect devices to, and some NIC drivers don't like hidden networks and won't, or have trouble, connecting to them.

There are practical reasons to hide an SSID - to avoid confusion between networks, or to simplify your network advertisement. But, security isn't one of them, the AP is still beaconing, clients probe more (so you're wasting airtime and announcing the SSID anyways), and the SSID is sent in plaintext in association requests anyway, so it's not that difficult to find them.

But, there's yet another reason to avoid hidden SSIDs - especially if you want to take advantage of DFS (Dynamic Frequency Selection) in your WLAN:

I'll admit to doing "little contemplation" on this. Fortunately, I don't run into hidden networks that much these days (thank goodness), but I've also spent little time considering the consequences of DFS and hidden networks. Using hidden networks on DFS channels can cause unforeseen connectivity issues.

Clients can't actively probe on DFS channels. Active Probing is when a client send a "Probe Request". Clients  send probes on a channel to discover any potential APs. Since ACTIVE probing is not allowed on DFS channels, clients will do Passive Probes - which simply means they listen for beacons on a channel. Well, if they just happen to listen BETWEEN beacons, they’ll miss what they don’t see.

This also has implications for voice and roaming. If the clients can't probe for new APs then roaming times will be longer, and real-time data starts having issues. Many hospital deployments don't use DFS because of these issues.

Just food for thought. If you need frequency re-use (and these days who doesn't?) you'll need DFS. And DFS does not play well with hidden SSIDs. So, just stop hiding your SSIDs. Another thing you can do is mix your channel plan up so you don't have all DFS in an area. Always have non-DFS channel options available in case the device doesn’t have enough time to find the channel, or it doesn’t support it.

One final note, if roaming is important, you should be using 802.11r and devices that support it. And in conjunction with 11r use 11k/v to help speed up channel discovery. Of course, make sure your infrastructure and your devices support these features, and test them thoroughly to insure there are no compatibly issues when enabling them.

 

UPDATE: See the comment below by Andrew Von Nagy. It clarification  hidden SSIDs and DFS.

 

Actually, that isn't correct. Clients can't initiate transmissions on DFS channels, which prohibits most of the benefits of probing... namely faster discovery of the APs operating on the channel. But hidden SSIDs have no impact on this. Once a client hears a beacon on the channel by a "master" device (that must conform to radar scanning regulations) then it is safe for a client to probe.

So the real issue is two fold with DFS and client scanning:

1) Longer initial AP discovery time due to waiting until it hears a beacon (102.4ms intervals) instead of probing immediately (discover within just one or a few ms), and

2) Longer scanning time when roaming, especially for latency sensitive applications such as voice.

Whether or not the beacon populates the SSID IE field is irrelevant.


Cheers,
Andrew


Hotspot 2.0 in the wild →

So, it seems public Wi-Fi may finally be coming of age big time. LinkNYCs blog has a write up of their "Secure" public WiFi:

 via Medium:

LinkNYC has two free Wi-Fi networks, ‘LinkNYC Free Wi-Fi’ and ‘LinkNYC Private.’...
 
The ‘LinkNYC Private’ network goes a step further, offering state-of-the-art encryption via HotSpot 2.0 and WPA to secure all wireless communications between devices and the Link, regardless of whether a website uses SSL security. This means that even casual browsing is protected from snooping. The network is one of the first in the country to offer an encrypted public network at this scale.

 

Hotspot 2.0, or 802.11u, OR "Wi-Fi Certified Passpoint" (Blerg.) is an amendment that specifies internetowrking between external networks. Per the amendment:
 

support for external authentication, authorization and accounting, together with network selection, encryption, policy enforcement and resource management.


At launch it will only support Apple mobile devices (of course), but will add other device support over time.

Hotspot 2.0 has been a thing for a while, and this is not the first network to provide it, but with all the attention this project is getting, I have the feeling Hotspot 2.0 may actually have it's day - like legit.

But, there's more! Fierce Wireless is reporting "AT&T in process of upgrading Wi-Fi in NYC parks with Passpoint". "Passpoint" is the Wi-Fi Alliance's marketed name for Hotspot 2.0. That's pretty huge. Two major wireless initiatives in the largest city in the U.S. rolling out secure public wireless.

For those unfamiliar with Hotspot 2.0 I refer you to this blog post by Ruckus Wireless' Dave Wright.


via @BLAKEKRONE: Where's Waldo? (or, The case of the missing wireless engineer.) →

Blake Krone, via his blog →

What do I mean by a skilled wireless engineer? Do I mean they are CWNE or CCIE or AC[]X? No, not at all. I simply mean someone that understands wireless and the challenges it brings when trying to design. It’s the person that knows about Co-Channel Interference and Adjacent Channel Interference, someone that understands when and how to use 20/40/80MHz channel widths, the person that knows you have to do a survey to get things right, etc.

I think sometimes we (myself included), as wireless engineers, make it seem impossible for people to think they can unlock the "secrets of Wi-Fi". No doubt there are some complicated things, but no more so than some other enterprise technologies out there as Blake points out. He thinks it's the PERCEPTION of wireless be too high an entry level and I tend to agree.

Maybe we need to preach some more "bare bones" wireless for the network folks out there that don't have the budget, or support, to access the expensive tools we all desire. Things like knowing WHAT to look for when doing a wireless scan, or basic understanding of channel management could go a long way to helping the many over-burdened IT individuals out there saddled with the task to install a WLAN. At the very least enough knowledge to know when to call in an "expert". In the end what we really need is to bring more people into the wireless fold.


FCC: The Next Step for LTE-U: Conducting Limited LTE-U Performance Tests

From the FCC blog: →

Today, the FCC’S Office of Engineering and Technology is taking an important step by granting a special temporary authority (STA) to Qualcomm to conduct very small scale performance evaluation tests of LTE-U equipment at two Verizon sites in Oklahoma City, OK and Raleigh, NC. OET routinely grants STAs and experimental licenses for parties to evaluate the performance of products and conduct testing, subject to the condition that no harmful interference is caused.


I've been quite outspoken about my concerns with LTE-U and it's co-existence mechanisms with Wi-Fi. Wi-Fi has become a pretty integral part of our economy, business-life, and our lives in general, and the dangers I see with letting LTE-U go live without testing and validating it's use in 5GHz I believe are real.

So, I'm glad the FCC is granting the STA so testing can happen in earnest. The Wi-Fi Alliance will has some involvement in the testing methodology and how it should be done. 

Previous tests by Qualcomm have been blown out of proportion by stating that it works better with Wi-Fi than Wi-Fi and would actually improve wireless networks - which was non-sense. The tests were conducted in ways that did not reflect how wireless networks are typically deployed especially in Enterprise environments.

I am not against LTE-U, I just think before a new technology that could be detrimental to another very vital communications technology is deployed, it should be properly tested and vetted.


“Gigabit” Wi-Fi Hits the Big Apple?

Estimated reading time: 1 minute, 47 seconds. Contains 359 words

Recently, I’ve been intrigued by the LinkNYC Project. It sounds like a pretty fantastic thing: Free, high-speed, Internet for everyone in New York City. They are also rolling out Hotspot 2.0 with this as well, so this peeks my interest even more. Of course, being a wireless professional, and nit-picky, there are things that beg questioning.

The first is the use of the term “Gigabit Wi-Fi”, which is brought up a multiple times in this article and interview with Engadget. Of course, the first thing to happen, when they go live, is Twitter will blow up with, “I’m using the LinkNYC Wi-Fi and I'm not getting a Gigabit! What a bunch of liars!!!”, or something to that affect. Because, no one is ever going to see those speeds, regardless of how awesome it's purported to be. 

It’s not that they don’t have the backhaul for it - they do. Fiber is being run to all the kiosk locations - with some exceptions for areas where it's not an option. But, this is the same message we get from wireless vendors that market their "Gigabit" Wi-Fi products, and as we all know - that’s not the reality for many reasons:

  • Half-Duplex requiring CSMA/CA which adds overhead and thus reduces actual throughput to ~60% of the link rate.
  • The massive number of users that will be connecting to each AP. Remember, this is a SHARED medium. "One ping, Vasili. One ping only."
  • The various device capabilities
  • Link rate for clients that vary on their distance, etc.

The other thing that concerns me is this:

I don’t get this image. That’s cleary a Ruckus AP. But, it’s upside down - isn't it? And, it’s surrounded by metal. Maybe they weren’t finished with the install? But, it looks like it’s pretty well mounted, and won't be moving anywhere.

Don't get me wrong - I'm loving this whole concept. I think it's fantastic, and would love to see this spread to other communities. I'm just wondering if there were any wireless engineers involved in the design and deployment of this endeavor. It SEEMS like that's not optimal placement for that AP - which I assume is a down-tilt omni. Is that just some meI, or am I COMPLETELY wrong?

Seriously, I'm asking!


Life After the Red Pill. (or, CWNP & Me)

Estimated reading time: 7 minutes, 8 seconds. Contains 1427 words

To start off 2016 I wanted to give you an idea of my life before CWNP (Certified Wireless Network Professional), the benefits I have seen from the program, learning the intricacies of 802.11, and its affect on my business, and customers.

THE KNOWN UNKNOWNS

In 2007 I was hired by a large cabling company to start a new voice & data services business. I had been in voice since 1994, installing and maintaining large Nortel PBXs, as well as Windows Server Management (Active Directory, Exchange, ISS, etc.). The cabling company eventually decided they wanted to sell Wi-Fi so they asked me to research various vendors to partner with - and so I did. That was my introduction to wireless.

After deciding on our vendor I proceeded to take the prescribed classes and learned how to "program" their system. There was no discussion of RF in these classes, or encouragement to learn about such things. I got a paper that certified I knew what I was doing - so I figured I actually did. How hard could it be? It did not take long to realize it was pretty hard.

My first deployment was for a large Restaurant/Comedy Club/Event Facility and I "designed" the WLAN the way any normal, intelligent person would - I walk into the facility pointed to where I wanted the APs and marked it on a floorpan. The cabling techs ran the cable mounted the APs and I configured the system as I was taught.

When the inevitable problems arose upon the first event I was on the phone with TAC trying "fix the problem". Clearly their system was not doing what it promised. TAC enabled all various types of features to try to get things working. But, no matter what we did the wireless would fail.

It's only with hindsight, and experience, that I now know that APs don't work well from the concrete room where the sound guy is, or that two APs WILL NOT support 450 people no matter what the manufacturer tells you, or that setting APs to max power is not the answer to bad-fi. But, I digress...

INTO THE GREAT WIDE OPEN

I started my career in wireless in 2007, and then I started my own company in 2009. But, it wasn't until 2012(ish) that I hit the brick wall that set me on the path I now find myself. Because that's when I found a Web site called WLANPros.com, and a man named Keith Parsons, that seemed to know a lot about wireless. He mentioned things like, "RF", and "co-channel interference", and something called, "CWNP". By this time I had begun to think of myself as a wireless guy rather than a Voice, or Server guy and I was intrigued by people who understood wireless. Not my vendor of choice, but wireless - that invisible stuff that had alluded me for so long.

I started reading blogs, and finally making use of Twitter by following people such as Keith, Devin Akin, and Andrew von Nagy, among others. I started realizing just how little I knew about wireless, and how far I was from where I needed to be. And now I had the bug. I had to know wireless and its secrets.

My first step was to call Keith Parsons. I asked him about classes that he taught and told him that I wanted to learn more. He asked me questions that made me extremely uncomfortable, such as: "How do you survey?", "What tools do you use?", "Have you read the CWNA book?", among others. I finished that call knowing that I had left a path of poorly "designed" WLANs in my wake, and that I loved wireless. I purchased the CWNA Study Guide and started reading.

The results were immediate. I called up past customers and told them I would like do a free "wifi cleanup". I would go to their location and correct the wrongs I had done using the information I was learning from the CWNA book. Even relocating APs at my cost! I did this for a while and bought the book for new employees (and customers) so they could learn.

To me, getting the CWNA certification seemed unattainable - never mind CWNE, but in 2013 I signed up for a CWNA class taught by Robert Bartz. There were two things I learned in that class:

  1. I knew stuff! The past few years of reading and correcting my mistakes were really paying off.
  2. I knew nothing, but I wanted to learn more.

In December of 2013 I became a CWNA. I was now part of something I thought was out of my reach - a WLAN Professional.

DOWN THE RABBIT HOLE

alternate text

"You take the blue pill, the story ends. You wake up in your bed and believe whatever you want to believe. You take the red pill, you stay in wonderland, and I show you how deep the rabbit hole goes."

―Morpheus

I was now getting to be known as "that guy who fixes wi-fi". I was being called in to fix, validate, design, because I knew how to get it done right. It was only yesterday that I was on the phone with TAC trying to figure out what button to press, what checkbox to check, to fix everything. Now, with the knowledge I had gained I was "the Fixer". I was "the Architect". I was the "Professional".

Then, at WLPC 2014, I made the decision to try for CWNE. In a year, no less! Sure, I would never make it - that was for the real professionals, but would I learn a lot. So I proceeded to study through the CWNP program.

I started with the CWAP. Packet Analysis was by far a weak point for me, and I knew if I could learn this secret code it could help me in the field. So, I bought the book and started reading. Within a few weeks I was at a Community College troubleshooting an issue with new HP clients not being able to connect to the WLAN, but only at one specific building. No better time than the present, so I open my packet analyzer and started capturing.

At first I didn't understand what I was seeing, but like Neo in the Matrix, it started to come together. I noticed the clients were sending disassociation frames to the APs. They did not want to stay connected. I looked at the beacons where the clients could connect. I looked at the beacons where the client could not connect. They were different. The beacons in the new building with the new APs showed they had the "RN Enabled Capabilities" Tag. The beacons where they could connect did not have 802.11k enabled.

I had done my first real-world, wireless packet analysis. And just like Neo, I could see into the Matrix and knew right away, "these client do not support 802.11k”, and they didn’t like connecting to a WLAN that did. One of the techs had enabled it on the new AP group because he heard, "it does something with roaming". The solution was to simply disable 802.11k and instantly the clients connected.

THE GIST OF IT ALL

That's CWNP to me. It's the Red Pill that let's you see the Matrix for what it is. But, it's not for everyone. Most don't want to travel that far down the rabbit hole and are happy with what the vendors tell them. "Check this box to fix roaming", "toggle that switch to increase your WLAN speeds by 50%", or "our APs are 175% faster than Cisco, Aruba, HP, & Ruckus... COMBINED".

Over the course of the following year I purchased the CWDP and CWSP and started reading those as well. My goal was now to run the gauntlet by WLPC 2015 in Dallas. In December 2014 I took another class with Robert Bartz and got my CWAP. Through January 2015, I self-studied for, took, and passed the CWDP and CWSP exams.

I had done it. What I thought was impossible for me - passing all the CWNP exams - was a reality. Thanks to the help and encouragement of an amazing community of wireless enthusiasts I had done in a year what I thought would take me 3, or 4.

Going through the CWNP program has resulted in a career I never thought I'd have. My customers have reaped the benefits of having someone who understand the fundamentals of why WLANs work, and I have seen the benefits in the growth of my business, and reputation, and a decrease in the Bad-Fi. I owe it all to the WLAN community and CWNP.