Tuesday, May 30, 2017

Always something new to learn

"Forgive me. I am just a fledgling learning to fly" - Koro to Paikea, Whale Rider


In a recent post, I described what I thought to be odd behavior of an iPhone probing on channel 52. Channel 52 requires DFS, and a client device shouldn't probe unless it can hear an AP on the channel. I wasn't seeing anything on the channel but probes, and it was quite a mystery.

I removed the post, because I now know that wasn't what was happening. To summarize:

  • I saw probes on channels 52 and 56, but not 60 or 64. 
  • No other traffic on 52 or 54. 
  • iPhone was right next to IAP-315 I was capturing with. 
  • When I captured on channel 48, the probes were about 40 dB stronger than the probes I saw on 52. Probes on 56 were only about 1-2 dB weaker than those on 52. 
  • It wasn't just the iPhone; it was my Moto G4, and the laptop I was running Wireshark on. 
Here's a picture of the test setup:

Cozy!
 Here's another picture related to this story

OFDM Spectral Mask

My original post generated a lot of discussion on Twitter, with questions on iOS versions, DFS rules, and more. I researched the FCC report on the iPhone SE, looked into DFS rule changes, but couldn't find anything that would explain the behavior. Then Ben Miller suggested this:



This was the most plausible explanation of what I was seeing. The probe requests that I captured on 52 were actually transmitted on 48. The phone and AP were so close to one another that there was enough energy on the adjacent channel, 20 MHz away, to be decoded on channel 52. Looking at the spectral mask, it explains the 40 dB drop in power, and why I saw not only the iPhone, but also my laptop probe on 52.

To test further, I started capturing on 52, with the iPhone right next to the AP. I saw probe requests at -75 dBm. I left Wireshark running, and switched the capture channel from 52 to 48. I picked up the iPhone and moved it about 4 meters away from the AP. I saw probe requests at -61 dBm. Even though the phone was much farther away, the signal was received 14 dB stronger. To confirm things, I switched the capture back to channel 52 with the phone still 4 meters away. I saw no frames at all.


The first frame is from my laptop, right next to the AP. Note the receive power. The next frames are from the iPhone, which uses a randomized MAC when probing. The phone was placed next to the AP when probes were seen on 52, and 4 meters away when seen on 48.

There's been some discussion lately about APs that have dual-5 GHz radios, and why that can be a bad thing. After what I experienced, I tend to believe it. It's also a cautionary tale on how you setup your captures.

Thank you to Ben and all who viewed the blog and commented on Twitter. Ultimately, I was wrong, but I learned a lot.

-Mark

Sunday, May 28, 2017

Are iOS Devices Breaking DFS Rules?

NOTE: What I thought were probes on channel 52 were actually not transmitted on channel 52. They were transmitted on channel 48. The transmitting devices were close enough to the capturing device that the OFDM signal was strong enough off-channel to be decoded. Click here for the updated blog that explains what really happened. What follows below is my (incorrect) interpretation of what I saw.

I was looking at my Twitter feed not too long ago, and there were a few tweets from a webinar that I was not able to attend. The webinar was hosted by Ekahau, and the presentation was by the excellent Jerome Henry. The slides are available here.

One of the slides describe the channel scanning behavior of iOS clients, particularly how they scan the U-NII-2e channels 100 - 144. The slide indicated that these channels must be scanned passively: the client must dwell on the the channel and listen for beacons, since DFS rules prevent it from sending probes.

The first question that came to mind when I saw the slide: what about U-NII-2, channels 52 - 64? These channels also require DFS, but were not listed on the slide. I thought that it was just an omission. I did some testing with my Motorola G4 and saw that it will not probe out on 52 - 64 unless it hears a beacon. Were iOS devices different? I had to test for myself.

I setup an Aruba IAP-315 in sniffer mode on channel 52 and captured in Wireshark. I used a display filter to see only beacons and probe requests. I took an iPhone SE running 10.3 and removed saved networks to simulate the phone being in a new environment. I turned on Wi-Fi on the phone and placed it less than a foot away from the IAP. This is what I saw:


No beacon frames, but probes from an unregistered MAC address received by the AP at -69 dBm. Keep in mind the phone is less than a foot from the AP. For comparison, I sniffed on channel 36 and saw probes from the same unregistered MAC at -30 dBm.

Next I ran a capture where I switched the channel from 52 to 56. Probe requests where seen on both channels, again with no beacons.


You can see from the time column that enough time is elapsing to see beacons. I didn't see any. I also captured on channels 60 and 64, but did not see any traffic on these channels at all.

So what is happening here? It looks like a client device is transmitting on a DFS channel without first hearing a beacon from a master AP on that channel. I don't think the phone is listening for radar, like an AP; because I see a probe on channel 52 within a second or two of turning Wi-Fi on.

Are DFS rules being broken?