Sniff Wi-Fi

One of my favorite things to do is teach Wi-Fi, and one of my favorite tools for teaching is Savvius  OmniPeek .  The good folks at Savvius were nice enough to provide OmniPeek for the Wi-Fi classes I oversee at Global Knowledge , and so I want to offer a taste of how OmniPeek can be used to learn about Wi-Fi device behavior, specifically with the iPhone X. Savvius OmniPeek is what I call a hardcore protocol analyzer.  The "hardcore" adjective comes from the fact that OmniPeek encourages the user to view frame (aka "packet") traces.  Non-hardcore protocol analyzers focus on providing statistics and graphs.  I am a big fan of all types of protocol analyzers, but the beauty of OmniPeek is that it offers options for viewing statistics and graphs, while making its frame traces simple to navigate. One of the things I like using OmniPeek for when teaching is illustrating the different ways that Wi-Fi devices and APs use the 802.11 standard.  An example is what happen

In some circles, Apple Wi-Fi devices are knows to have problems with lost connections.  iPhones and iPads will unexpectedly miss incoming calls, have delays in receiving push notifications and even be forced to reauthenticate. There is a solution to Apple devices' connection problems, and as with most "device problems", the fix resides on the infrastructure.  The DTIM setting needs to be increased.  ( Apple recommends a setting of 3 or higher .)  Here's why: Some Apple Wi-Fi connection problems stem from Apple iOS devices' use of 802.11 power management.  To understand what Apple devices are doing with power management, one must first understand how 802.11 power management works. Let's start with unicast data.  The 802.11 standard allows devices' Wi-Fi radios to enter the Doze state in order to conserve battery life.  Wi-Fi radios in the Doze state are unable to receive data from the AP, so APs buffer all unicast data that has a destination MAC addr