tree 69082cab59b05cc2b39f07fb20735f3e3ad72956
parent 5fa9cc4242c16400238d4ddf4ecfb204a1435150
author Denton Gentry <dgentry@google.com> 1482746467 -0800
committer Denton Gentry <dgentry@google.com> 1482971640 -0800

taxonomy: add several AP variants, iOS edition.

The contents of the Beacon alter the contents of the signature.
For example the presence of the Spectrum Management bit in
the Beacon from an AP causes iOS devices to include IE#70
(Radio Resource Management).

Gather signatures for a number of client devices using several
different APs with differing Beacons:
+ Fiber GFRG210
+ Google OnHub
+ Google Wifi

Also:
+ iPhone 6s+ and iPad Air gen2 use the same txpow value for 5GHz,
  and we now know they will therefore sometimes send the same
  signature as we've captured several. Switch back to using the
  hostname as a heuristic to distinguish iPad from iPhone for
  iPad Air gen2 5GHz.
+ format of the second half of dhcp.leases was not correct,
  all entries needed an additional column where the ClientID would
  go. We only noticed when trying to use the hostname for iPad Air
  gen2.
+ the earliest pcap files were not anonymized, as we wrote the
  the anonymize_pcap utility somewhat later. The new signatures
  in this CL are from some of those same devices, anonymize
  both the older files and the new.
+ the new pcap files in this CL contain:
  - the Beacon of the AP
  - the Probe Request from the client. We generally provide
    both a Broadcast Probe Request and a Probe directed at the
    specific AP's SSID, because some clients include different IEs.
    Qualcomm radios frequently include 802.11ac (VHT) IEs in their
    2.4GHz Probe if sent to the Broadcast SSID, as some kind of
    proprietary higher bitrate operating mode for 2.4GHz. When
    sending to our specific SSID apparently the right bits are
    not present in the Beacon, and the Probe does not contain VHT IEs.

    Notably, Apple iOS devices have never been seen to send a different
    Probe Request to Broadcast as to a specific SSID, we include both
    variants for completeness and to document that there is no
    difference.
  - the Probe Response from the AP
  - the Authentication packet in both directions
  - the Associate Request from the client and Association Response
    from the AP.
  - the EAPOL exchange for WPA2. Note that being able to analyze the
    collection of EAPOL messages in this archive isn't sufficient to
    discover the Wifi PSK, otherwise people would camp out in the
    parking lot gathering samples.
  - a few packets after joining the WLAN

  We're going to try to make a regular practice of this, to make the
  corpus of collected WLAN traces more useful in the future for
  development of new signature extensions.

Change-Id: I9287e2ee11276301ba03391c89b2cfc7ee10f4d0