Apple releases a new version of it’s mobile operating system annually. It is as anticipated by the developer community as much as the release of the new model iPhone is anticipated by the consumers. In June 2019, during the Worldwide Developer Conference, Apple announced iOS 13. Apple are considered an important device manufacturer in the Wi-Fi Professionals community as a marker for the uptake of new 802.11 standards. This is largely because the mobile device market from Apple's perspective is the least fragmented. Apple design and manufacture the hardware as well as the operating system of their mobile phones and tablet devices. This means that when they release a new feature as long as it can be supported within the hardware it is installed on it is generally available. There are two big announcements this year from Apple in terms of Wi-Fi capabilities. Arguably the most exciting one for Wi-Fi is the inclusion of 802.11ax (aka Wi-Fi 6) in all of the iPhone 11 models. This is less of a software thing and more a hardware reliant capability - the Wi-Fi chipset in the device must be sufficiently new enough and include the specifications to connect using Wi-Fi 6 features. The iPhone 11 is released with iOS13 pre-installed so it is probably a pre-requisite as well. The other impressive inclusion is support for WPA3. This is a software capability as it is bringing features to older model mobile devices without the requirement of new chipsets or hardware. WPA3, which is the successor to the Wi-Fi Alliance WPA2 certifications, brings major improvements in security and privacy of Wireless Local Area Networks (WLANs). In 2017 researchers published a vulnerability report which highlighted issues with WPA2. Wi-Fi Protected Access (WPA, more commonly WPA2) handshake traffic can be manipulated to induce nonce and session key reuse... It is important to assess the viability of using WPA3 for WLANs being deployed presently or in the future. WPA3 is highly recommended when device compatibility can be verified. Otherwise this should be reviewed frequently so WPA3 can be implemented as soon as possible.
Comments
If you follow a bunch of CWNP-associated Wi-Fi professionals on Twitter you would be familiar with the frequent, casual analysis of hotel Wi-Fi. Maybe you like to do a little bit of looking beyond the SSID when you're away from home? The shared findings help remind us all what to avoid when we setup Wi-Fi. Screenshots from inSSIDer (by Metageek) were commonly featured in these tweets to help visualise the frequency - especially when channel use was less than good. Historically the common culprit would be poor planning of the 2.4 GHz frequency space. I've seen examples of hotels using contiguous channels 1 through 11 (including the overlappers 2, 3... 8 etc.). It's common to have wide 40 MHz configuration - which is a terrible idea in 2.4 GHz anywhere there is more than a single radio (in a desert with a population of one). We see bad setups in the 5 GHz channels as well. Channel re-use is over-represented - sometimes hotel radios have no channel planning whatsoever. Having every access point using the same channel in 2.4 or 5 GHz is a bad idea. Contention for air-time can lead to a performance downgrade if too many people are using the Wi-Fi at the same time on the same frequency. It may cope to a certain amount but if the contention domain extends across a highly populated hotel it's likely to be bad. But outside of simple channel design issues there are other things that are worth investigating if you want to be thorough. Keith Parsons found an example of a hotel where he was able to connect to a Wi-Fi network with good 802.11 metrics - high MCS rate, 2 spatial streams and an outstanding signal to noise ratio - yet speed tests were terrible. Something beyond the Wi-Fi shaped his connection to 350 Kbps (possibly the Internet back-haul). The Internet bandwidth must be sufficient on any network to cater to the users requirements. Having a shiny Wi-Fi 5 or 6 (802.11ac or 802.11ax) capable infrastructure won't help anyone if the pipe out is smaller than a soda straw. If you're familiar with 802.11 protocol analysis you might try capturing Wi-Fi frames in a tool like Wireshark or Omnipeek. With the right filters you can visualise relative re-transmission rates on a channel in your location. When you study for Certified Wireless Analysis Professional you learn about many of the Information Elements in the 802.11 standard. Information Elements (IEs) hold key information about the capabilities or configuration of a particular BSSID. Sometimes it's a bit too much to get right into the weeds of wireless frame capture and analysis. But there is another way to inspect the IEs if you have an Apple Mac. Wi-Fi Explorer is a brilliant application brought to us by Adrian Granados. In the simple view it lists the nearby Wi-Fi networks that your Mac can detect. Within the Advanced Details tab the IEs are brought to you in a expandable tree of wonder. In my screenshot example above I have expanded the QBSS Load details of the BSSID to which I was associated. I am able to see there are currently 2 stations (including myself) connected. The Access Point even provides details about the channel utilisation which is useful if high contention is suspected. By looking at the IEs with Wi-Fi Explorer you could check what data-rates a BSSID was configured to support. I remember seeing a tweet where someone detected the hotel was rate-shaping clients by restricting association data-rates to 1 and 2 Mbps. This would most certainly result in counter-productive results as this is not the intended use of data-rate configuration. Low data-rates equal poor performance for modern Internet access. I definitely recommend Wi-Fi Explorer (I have the Pro version) as a day to day Wi-Fi professional tool - there is a lot more to it than mentioned here. Fast, Free and Frictionless... (@KeithRParsons) Here is a blog post about the Rules for Successful Hotel Wi-Fi from Keith Parsons. He wrote it way back in 2014 but it still holds true today!
As demonstrated it is not just about good channel design. There is more to inspect and always plenty to learn from each other. If you have any stories to share about bad hotel Wi-Fi please comment, and keep sharing your findings on Twitter. Airtime and contention domains can be a difficult concepts to grasp when studying Wi-Fi. We often think of Wi-Fi in cells or strict zones surrounding an access point and fail to think about the transmit radius of each client associated to that access point. Because of the way the 802.11 medium is accessed by a station (Access Point or client) we must consider the entire area of influence surrounding each station which transmits. It's not just simple circular patterns surrounding each AP. CSMA/CA is a very importants starting point for any learner of Wi-Fi, it is covered well in the Certified Wireless Network Administrator (CWNA) course. But there is much much more to learn... The best source I have found that expands on these concepts in detail is the Very High Density 802.11ac Networks Validate Reference Design Guide, written by Chuck Lukaszewski (CWNE #112) from Aruba Networks. The Theory Guide is a fantastic read but may take a few goes to understand if you are just starting out. When ever I present on Wi-Fi design I use some of the concepts out of this guide. Especially fitting is the reference to the Matrix in this guide. You really are jumping in to a whole new dimension of understanding by working through it. You're here because you know something. What you know you can't explain, but you feel it. You've felt it your entire life, that there's something wrong with the world. You don't know what it is, but it's there, like a splinter in your mind. The Theory Guide explains that the contention domain extends as far as a frame can be detected by another station. The range is a physical distance from a transmitter where the the legacy preamble can still be decoded. That happens to be a very long way. This graphic of two distinct Collision Domains is a very rare occurance. Unless these two Access Points operate on sufficiently seperate channels they would likely be very far apart. In most environments, especially high density environments collision domains of the same frequency overlap somewhat. It's more likely that the collision domain of two APs on the same frenquecy in essence extend the collision domain to cover the detectable distance of both of the APs. The guide delves further to show that even this is rudimentary. Clients must be considered also! Futhermore the time domain which is shown as the x-axis is also vital. This is your last chance. After this, there is no turning back. 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. Once you are at this point of the document you begin to realise how simplistic some of the planning tools we use in the Wi-Fi industry are and some of their shortcomings. I suspect the shotcomings will take a very long time to solve. In your Wi-Fi learning journey I highly recommend you take a wander down this path. Even if you don't work with Aruba products the Theory Guide profiles fantastic lessons for us all. The images in this blog are borrowed from here: https://www.arubanetworks.com/vrd/VHD_VRD_Collection/wwhelp/wwhimpl/js/html/wwhelp.htm#href=ChapT2.html#1045569 they are used for basic primers for the topics that are extensively covered in the Aruba Validated Reference Design Guide from where they originate. Wireshark filters help drill down to useful information among what can feel like a massive, overwhelming stream. Especially useful when doing 802.11 protocol analysis where the incoming frames can quickly accumulate to many thousands in a very short timeframe. My favourite Wireshark filter of all time is the WLAN Retry filter. My favourite way to use it is with the I/O Graph. I really like to understand the detected retransmitted frames vs the total number of frames captured. It's really easy to visualise this. First off - the filter for WLAN Retries is: wlan.fc.retry == 1 Using this filter as a display filter of a 802.11 frame capture will show only frames that have the Retry bit set in the Frame Control Field in the MAC header. If you have a frame selected you can tell if it is being re-transmitted by checking the flags exposed in the first IEEE 802.11 decode field below the 802.11 Radio Information - this is displayed in the Packet Details view within Wireshark. An example is shown below where the 'R' Flag is set on the currently selected Deauthentication frame. I've written about the Wireshark I/O Graph before. You can find this in the Statistics menu as I/O Graph. Within the I/O Graph window you are able to add custom filters which will be visualised. The default line graph shows 'All packets' which in this case represent every frame captured. Typically the y-axis of the graph represents Packets per second so the 'All packets' line indicates the number of 802.11 frames captured per second on the captured Wi-Fi channels. I like to add my WLAN Retries display filter as a new red line so I can see it in high contrast to the default 'All packets' line. See an exampled below. In this capture a high proportion of the frames captured had the Retry bit set. They were frames being re-transmitted many times by a Wi-Fi station.
A high retry rate can often indicate that something in the WLAN is unhealthy. This might be a particular station, the medium (the channel and associated frequency), an Access Point or something else. The retry filter is a useful tool in your Wi-Fi Professional tool-belt. Keep learning! Share your favourite Wireshark display filters below. Python is the programming language to learn if you are a Network Engineer. It’s just one of the new skills you’re going to need to stay relevant and to be more than just a simple worker that adds no value beyond basic config.
With Python scripts you can repeat complex tasks in exactly the same way as many times as you like. You can build in variations so that the same job is dynamic when the need arises. For example you could deploy 20 access layer switches with identical configuration except each might have a unique management IP address. Think of the benefits of this type of automation at scale - 1000 switches by CLI is asking for trouble with misaligned configuration and it’s just down right inefficient use of time. Old school engineers would promote Perl for network scripts and automation - but its old school, less popular and harder to read. Python, as I understand it, can do anything Perl could do and is a much more accessible language in that it’s easier to read and begin working with. The use cases for scripting or programming will extend far beyond just replacing the legacy technique for the same tasks we perform today. The network is full of useful data that can be extracted for use elsewhere or to help inform the decisions for design tomorrow. All good technology products or services should contain an API which is a very easy way to have Python scripts interact with devices and software. Aruba Networks have released ArubaOS-CX on a core/aggregation switching platform that will allow Python scripts to run right on the switches. The analytics and automated troubleshooting capabilities show huge promise. I’ve been learning Python to perform some work in real life scenarios. If you can do it that way, like with most learning opportunities, you will be able to make better associations with the new skills you learn with the benefits of those skills in hobbies and work. Along the way I have been posting examples of my work in the Aruba Airheads Community, they are relevant to the Aruba Meridian solution. Using the Meridian API: Output Beacons info to CSV Using the Meridian API: Checking Beacon Battery Levels Using the Meridian API: Storing the JSON Output (Local Caching) Using the Meridian API: Caching Beacons Data in a file Using the Meridian API: Caching Maps Data in a file The posts include python files and a step by step break down describing the lines of programming so you can learn how they work. My hope is someone might either make use of the python scripts in their entirety or be able to use sections (or particular functions) for their own projects. There are so many resources around to help you to get started with Python. If you’re using a MacOS X as your computer operating system then Python is even pre-installed. There are countless books and paid or free online tutorials and courses. Now is the time to get some experience, see if there is any way you could take one of your current tasks and include a bit or Python training in to it. If you read this post by Steven Iveson in April 2013 you might feel a bit late to the game. There is no time like now to start. https://packetpushers.net/programming-101-for-network-engineers-why-bother/ Search the web for "python for network engineers" and you'll come across countless Udemy courses and other sources. Let me know if you find any good ones. |
WifiHaxWe build and optimise networks. Continuous learning is our secret to being good. Along the learning journey we will share things here... Archives
November 2022
Categories
All
|