[Dataset] cmu/hotspot (v. 2009-04-15)

top

the initial version

@MISC{cmu-hotspot-2009-04-15,
  author = {Jeffrey Pang},
  title = {{CRAWDAD} data set cmu/hotspot (v. 2009-04-15)}, 
  howpublished = {Downloaded from http://crawdad.cs.dartmouth.edu/cmu/hotspot},
  month = apr,  
  year = 2009
}
					

We measured the performance and application support of all visible APs at 13 hotspot 
locations around University Avenue, Seattle, WA, near the University of Washington
over the course of 1 week.

Users expect Internet connectivity wherever they travel and 
many of their devices, such as iPods and wireless cameras, 
rely on local area Wi-Fi access points (APs) to obtain connectivity. 
Even smart phone users may employ Wi-Fi instead of 3G and WiMAX 
to improve the performance of bandwidth intensive applications 
or to avoid data charges. 

Fortunately, there is often a large selection of commercial 
APs to choose from. For example, JiWire (http://www.jiwire.com/), 
a hotspot directory, reports 395 to 1,071 commercial APs in each of the
top ten U.S. metropolitan areas. Nonetheless, some users report 
that some APs block applications and have poorer than 
advertised performance, so selecting the best commercial AP is 
not always straightforward. 

To verify these reports, we present a measurement study of commercial 
APs in hotspot settings. We measure APs from the perspective of a typical 
Wi-Fi user who is inside an establishment. Our study examines the 
performance and application support of all visible APs at 13 hotspot 
locations around University Avenue, Seattle, WA, near the University of 
Washington over the course of 1 week. 

All locations are single-room coffee or tea shops. Most APs we measured 
are not open. In addition to each hotspot’s official AP, the APs of 
hotspots nearby are also usually visible. APs of the free public seattle
wifi network are sometimes visible at all locations. APs belonging to 
the University of Washington network are sometimes visible due to 
proximity to campus buildings, though these were never the best 
performing at any location. Our study offers a lower bound on the number 
and diversity of APs, as more may become available.

We collected measurements with a commodity laptop with an Atheros 802.11b/g 
miniPCI card attached to the laptop’s internal antennas. We implemented 
a custom wireless network manager for associating to APs and performing 
measurements after association. Our implementation is based on the Mark-and-Sweep 
war driving tool, which is described in “Mark-and-sweep: getting the 
inside scoop on neighborhood networks” (IMC, 2008) by D. Han, A. Agarwala, 
D. G. Andersen and M. Kaminsky.

During each measurement trial at a location, we emulate a typical connection 
attempt by scanning for visible APs. We then attempt to associate and authenticate 
with each AP found (identified by its unique BSSID). If successful, we run our 
battery of measurement tests before moving on to the next AP. We manually obtain 
authentication credentials, if necessary (e.g., through a purchase).  Since 
many Wi-Fi drivers do not list APs with low signal-to-noise (SNR) ratios, 
we only attempt to connect to APs when they appear with an SNR > 10 dB. 
 
We performed measurements at typical seating locations in each hotspot. 
Although the exact same location was not used for all measurements in a hotspot, 
§5 shows how well we can distinguish performance at different locations. 

Since we want to know whether AP characteristics are predictable, we performed 
8 to 13 measurements at each location (with the exception of yunnie bubble tea, 
where we only performed 6 trials). These measurements were taken during 7 week 
days in October 2008. On each day, at each location, we performed 1-2 measurements 
at different times of the day, so we have at least one measurement during each 
2 hour time-of-day between 9AM and 6PM (or a narrower time window if the hotspot 
opened later or closed earlier).

All IP addresses and MAC addresses are hashed (using keyed version of SHA-1 and 
a single random key) to map them to random values. Distinct addresses are consistent 
throughout the dataset. We do not anonymize broadcast, multicast, null, loopback,
and netmask addresses. SSIDs of APs (collected from beacons) are not anonymized.

[Traceset] cmu/hotspot/sql_tables (v. 2009-04-15)

top

the initial version.

@MISC{cmu-hotspot-sql_tables-2009-04-15,
  author = {Jeffrey Pang and Ben Greenstein and Michael Kaminsky},
  title = {{CRAWDAD} trace set cmu/hotspot/sql_tables (v. 2009-04-15)}, 
  howpublished = {Downloaded from http://crawdad.cs.dartmouth.edu/cmu/hotspot/sql_tables},
  month = apr,  
  year = 2009
}
					

We measured the performance and application support of all visible APs at 13 hotspot 
locations around University Avenue, Seattle, WA, near the University of Washington
over the course of 1 week.

Measurements were performed as follows:

   * For each location (loc_persistent.loc_name), we performed a number
     of trials. Each trial is identified by trial.id.

   * During each trial, we sat down at the location, scanned for all visible
     BSSIDs with SNR > 10dB. Then, in serial, we performed a measurement test
     on each visible BSSID. Each measurement test is identified by ap.id.

   * During each measurement test, we performed a sequence of tests:

     1) We first attempt to associate and obtain a dhcp address. This test
        uses the wicrawl associate_and_dhcp plugin.

     2) If successful, we then check if there is a web portal that we
        must bypass to obtain Internet connectivity. We also perform a
        number of local scans to discover clients on the LAN (ARP
        scan, UPNP scan, bonjour scan, CIFs scan) This test uses the
        wicrawl portal_check plugin.

     3) Once we obtain Internet connectivity, then we perform the
        remainder of the tests with the following wicrawl plugins:
        bandwidth_up bandwidth_down tcp_bw traceroute natcheck
        port_check (udp upload, udp download, tcp up/down, traceroute,
        nat type, jitter+loss+port block checking, respectively)

All IP addresses and MAC addresses are hashed (using keyed version of SHA-1 and 
a single random key) to map them to random values. Distinct addresses are consistent 
throughout the dataset. We do not anonymize broadcast, multicast, null, loopback,
and netmask addresses. SSIDs of APs (collected from beacons) are not anonymized.

[Trace] cmu/hotspot/sql_tables/ap (v. 2009-04-15)

top

the initial version

@MISC{cmu-hotspot-sql_tables-ap-2009-04-15,
  author = {Jeffrey Pang and Ben Greenstein and Michael Kaminsky},
  title = {{CRAWDAD} trace cmu/hotspot/sql_tables/ap (v. 2009-04-15)}, 
  howpublished = {Downloaded from http://crawdad.cs.dartmouth.edu/cmu/hotspot/sql_tables/ap},
  month = apr,  
  year = 2009
}
					

Database table of each measurement trial on APs from 13 hotspot locations in Seattle, WA over one week.

Our measurement data is stored in several relational database
   tables.  It is distributed as an SQL file that you should be able
   to import into the relational database of your choice (we use
   MySQL). We assume in this document that the database is called
   wifi. The tables are as follows

   +------------------+
   | Tables_in_wifi   |
   +------------------+
   | ap               | - data on each measurement trial on APs
   | ap_persistent    | - unique AP BSSID
   | arp_devices      | - MAC addresses that responded to ARP queries
   | bad_measurements | - measurement trial data that is flawed
   | loc_persistent   | - data on each location
   | local_scans      | - local scan measurement data
   | plugin_output    | - actual wicrawl output (empty if anonymized)
   | tcp_ports        | - tcp port scan measurement data
   | trial            | - data on each trial at each location
   | udp_ports        | - udp port scan measurement data
   | wifi_info        | - estimated loss data (unused)
   +------------------+

Data from each measurement test is saved in ap, local_scans, tcp_ports, udp_ports, as follows:

   In the table ap:

   id                    - unique ID for measurement test
   random_mac            - unused (ignore this field)
   trial_id              - trial.id that this measurement belongs to
   scantime              - time scanning started
   bssid                 - BSSID of the AP that we are testing
   ssid                  - SSID of the AP that we are testing
   channel               - 802.11 channel that we are on
   power                 - median SNR of beacons that we measured
   kismet_packets        - number of beacons that we measured
   kismet_best_signal    - highest SNR of beacons that we measured
   kismet_mean_signal    - mean SNR of beacons that we measured
   kismet_best_noise     - lowest noise of beacons that we measured
   kismet_mean_noise     - mean noise of beacons that we measured
   kismet_median_noise   - median noise of beacons that we measured
   encryption            - AP's type of encryption
   rates                 - AP's supported rates
   output_file           - file in the filesystem with wicrawl output
   mitm_file             - SSL proxy log file (for portal login)
   pcap_file             - pcap file in the filesystem
   monitor_file          - monitor mode pcap file in the filesystem 
   associate_success     - true if association succeeded
   associate_tries       - number of association tries
   associate_fail_reason - reason association failed
   dhcp_success          - true if DHCP succeeded
   dhcp_tries            - number of DHCP tried 
   ip                    - IP address assigned to us
   gateway               - IP address of the gateway
   name_servers          - nameservers assigned to us
   domain_name           - domain name of the local domain
   realip                - external facing IP address (non-NATed)
   portal_exists         - true if there is a login portal to bypass
   portal_title          - title of the login portal HTML page
   portal_refresh_url    - HTTP refresh url for portal, if any
   portal_fetch_time     - time it took to fetch the portal page
   portal_tries          - number of tries to fetch the portal page
   google_fetch_time     - time it took to fetch google.com after portal page
   portal_success        - true if we bypassed the portal page (or none existed)
   portal_fail_reason    - reason we failed to bypass the portal page
   nat_type              - type of NAT, as reported by STUN
   udp_bw_up             - UDP upload measurement in Mbps
   udp_bw_down           - UDP download measurement in Mbps
   tcp_bw_up             - TCP upload measurement in Mbps
   tcp_bw_down           - TCP download measurement in Mbps
   ping_type             - type of ping used for RTT and loss measurements
   rtt_avg               - mean RTT to our measurement server
   rtt_std_dev           - stddev of the RTT to our measurement server
   loss_rate             - ping loss rate to our measurement server
   wifi_loss_ping_type   - type of ping used for estimating wifi loss
   wifi_loss_target_type - whether our wifi loss estimate pinged the AP (gw) or our measurement server (server)
   wifi_loss_rate_big    - ping loss rate with 1500B packets, 802.11 retries disabled
   wifi_loss_rate_small  - ping loss rate with 40B packets, 802.11 retries disabled
   dns_check1            - whether we succeded fetching a CMU DNS name
   dns_check2            - same as above (see port_check plugin)
   traceroute            - output of traceroute to our measurement server (null if anonymized)

[Trace] cmu/hotspot/sql_tables/ap_persistent (v. 2009-04-15)

top

the initial version

@MISC{cmu-hotspot-sql_tables-ap_persistent-2009-04-15,
  author = {Jeffrey Pang and Ben Greenstein and Michael Kaminsky},
  title = {{CRAWDAD} trace cmu/hotspot/sql_tables/ap_persistent (v. 2009-04-15)}, 
  howpublished = {Downloaded from http://crawdad.cs.dartmouth.edu/cmu/hotspot/sql_tables/ap_persistent},
  month = apr,  
  year = 2009
}
					

Database table of unique AP BSSID from 13 hotspot locations in Seattle, WA over one week.

Our measurement data is stored in several relational database
   tables.  It is distributed as an SQL file that you should be able
   to import into the relational database of your choice (we use
   MySQL). We assume in this document that the database is called
   wifi. The tables are as follows

   +------------------+
   | Tables_in_wifi   |
   +------------------+
   | ap               | - data on each measurement trial on APs
   | ap_persistent    | - unique AP BSSID
   | arp_devices      | - MAC addresses that responded to ARP queries
   | bad_measurements | - measurement trial data that is flawed
   | loc_persistent   | - data on each location
   | local_scans      | - local scan measurement data
   | plugin_output    | - actual wicrawl output (empty if anonymized)
   | tcp_ports        | - tcp port scan measurement data
   | trial            | - data on each trial at each location
   | udp_ports        | - udp port scan measurement data
   | wifi_info        | - estimated loss data (unused)
   +------------------+

We also summarize information about each AP BSSID that we ever saw
   in ap_persistent:

   bssid                 - BSSID of AP
   ssid                  - SSID of AP
   encryption            - encryption of AP
   associate_successes   - number of association successes over all trials
   dhcp_successes        - number of DHCP successes over all trials
   portal_exists         - true of AP has a login portal
   portal_successes      - number of portal click-through successes over all trials
   requires_payment      - true of AP requires $$$ to use
   requires_purchase     - true if we have to buy something to use the AP
   requires_membership   - true if we have to be a member of some organization to use the AP (typically this means University of Washington)

[Trace] cmu/hotspot/sql_tables/arp_devices (v. 2009-04-15)

top

the initial version

@MISC{cmu-hotspot-sql_tables-arp_devices-2009-04-15,
  author = {Jeffrey Pang and Ben Greenstein and Michael Kaminsky},
  title = {{CRAWDAD} trace cmu/hotspot/sql_tables/arp_devices (v. 2009-04-15)}, 
  howpublished = {Downloaded from http://crawdad.cs.dartmouth.edu/cmu/hotspot/sql_tables/arp_devices},
  month = apr,  
  year = 2009
}
					

Database table of MAC addresses that responded to ARP queries, from 13 hotspot locations in Seattle, WA over one week.

Our measurement data is stored in several relational database
   tables.  It is distributed as an SQL file that you should be able
   to import into the relational database of your choice (we use
   MySQL). We assume in this document that the database is called
   wifi. The tables are as follows

   +------------------+
   | Tables_in_wifi   |
   +------------------+
   | ap               | - data on each measurement trial on APs
   | ap_persistent    | - unique AP BSSID
   | arp_devices      | - MAC addresses that responded to ARP queries
   | bad_measurements | - measurement trial data that is flawed
   | loc_persistent   | - data on each location
   | local_scans      | - local scan measurement data
   | plugin_output    | - actual wicrawl output (empty if anonymized)
   | tcp_ports        | - tcp port scan measurement data
   | trial            | - data on each trial at each location
   | udp_ports        | - udp port scan measurement data
   | wifi_info        | - estimated loss data (unused)
   +------------------+

The ARP scan also produces auxiliary information that lists all MAC
   addresses that responded to the arp scan during each measurement
   test in the arp_devices table:

   mac                   - mac address that responded
   ap_id                 - ap.id that identifies this measurement test

[Trace] cmu/hotspot/sql_tables/bad_measurements (v. 2009-04-15)

top

the initial version

@MISC{cmu-hotspot-sql_tables-bad_measurements-2009-04-15,
  author = {Jeffrey Pang and Ben Greenstein and Michael Kaminsky},
  title = {{CRAWDAD} trace cmu/hotspot/sql_tables/bad_measurements (v. 2009-04-15)}, 
  howpublished = {Downloaded from http://crawdad.cs.dartmouth.edu/cmu/hotspot/sql_tables/bad_measurements},
  month = apr,  
  year = 2009
}
					

Database table of flawed measurement trial data from 13 hotspot locations in Seattle, WA over one week.

Our measurement data is stored in several relational database
   tables.  It is distributed as an SQL file that you should be able
   to import into the relational database of your choice (we use
   MySQL). We assume in this document that the database is called
   wifi. The tables are as follows

   +------------------+
   | Tables_in_wifi   |
   +------------------+
   | ap               | - data on each measurement trial on APs
   | ap_persistent    | - unique AP BSSID
   | arp_devices      | - MAC addresses that responded to ARP queries
   | bad_measurements | - measurement trial data that is flawed
   | loc_persistent   | - data on each location
   | local_scans      | - local scan measurement data
   | plugin_output    | - actual wicrawl output (empty if anonymized)
   | tcp_ports        | - tcp port scan measurement data
   | trial            | - data on each trial at each location
   | udp_ports        | - udp port scan measurement data
   | wifi_info        | - estimated loss data (unused)
   +------------------+

Finally, there were known errors in some measurements and we list those
   in the bad_measurements table:

   ap_id                 - ap.id that identifies this measurement test
   associate             - true if association test has errors
   dhcp                  - true if DHCP test has errors
   portal                - true if portal test has errors
   nat                   - true if NAT test has errors
   udp_bw_up             - true of UDP upload test has errors
   udp_bw_down           - true if UDP download test has errors
   tcp_bw_up             - true if TCP upload test has errors
   tcp_bw_down           - true if TCP download test has errors
   ping                  - true if ping RTT/jitter/loss test has errors
   wifi_ping             - true if wifi loss test has errors
   dns                   - true if DNS check test has errors
   traceroute            - true if traceroute has errors
   upnp                  - true if UPnP scan has errors
   mdns                  - true if mDNS scan has errors
   arp                   - true if ARP scan has errors
   tcp_ports             - true of TCP port block check has errors
   udp_ports             - true if UDP port block check has errors
   comments              - user entered comments about errors

[Trace] cmu/hotspot/sql_tables/loc_persistent (v. 2009-04-15)

top

the initial version

@MISC{cmu-hotspot-sql_tables-loc_persistent-2009-04-15,
  author = {Jeffrey Pang and Ben Greenstein and Michael Kaminsky},
  title = {{CRAWDAD} trace cmu/hotspot/sql_tables/loc_persistent (v. 2009-04-15)}, 
  howpublished = {Downloaded from http://crawdad.cs.dartmouth.edu/cmu/hotspot/sql_tables/loc_persistent},
  month = apr,  
  year = 2009
}
					

Database table of data on each location from 13 hotspot locations in Seattle, WA over one week.

Our measurement data is stored in several relational database
   tables.  It is distributed as an SQL file that you should be able
   to import into the relational database of your choice (we use
   MySQL). We assume in this document that the database is called
   wifi. The tables are as follows

   +------------------+
   | Tables_in_wifi   |
   +------------------+
   | ap               | - data on each measurement trial on APs
   | ap_persistent    | - unique AP BSSID
   | arp_devices      | - MAC addresses that responded to ARP queries
   | bad_measurements | - measurement trial data that is flawed
   | loc_persistent   | - data on each location
   | local_scans      | - local scan measurement data
   | plugin_output    | - actual wicrawl output (empty if anonymized)
   | tcp_ports        | - tcp port scan measurement data
   | trial            | - data on each trial at each location
   | udp_ports        | - udp port scan measurement data
   | wifi_info        | - estimated loss data (unused)
   +------------------+

Each location is described in the loc_persistent table:

   loc_name              - cannonical name of location
   latitude              - GPS latitude (arbitrary from measurements)
   longitude             - GPS longitude (arbitrary from measurements)
   trials                - number of trials taken at this location
   duration_mean         - average time to complete a trial
   duration_min          - min time to complete a trial
   duration_max          - max time to complete a trial
   official_ssids        - comma-separated-list of "official" SSIDs for hotspot

[Trace] cmu/hotspot/sql_tables/local_scans (v. 2009-04-15)

top

the initial version

@MISC{cmu-hotspot-sql_tables-local_scans-2009-04-15,
  author = {Jeffrey Pang and Ben Greenstein and Michael Kaminsky},
  title = {{CRAWDAD} trace cmu/hotspot/sql_tables/local_scans (v. 2009-04-15)}, 
  howpublished = {Downloaded from http://crawdad.cs.dartmouth.edu/cmu/hotspot/sql_tables/local_scans},
  month = apr,  
  year = 2009
}
					

Database table of local scan measurement data from 13 hotspot locations in Seattle, WA over one week.

Our measurement data is stored in several relational database
   tables.  It is distributed as an SQL file that you should be able
   to import into the relational database of your choice (we use
   MySQL). We assume in this document that the database is called
   wifi. The tables are as follows

   +------------------+
   | Tables_in_wifi   |
   +------------------+
   | ap               | - data on each measurement trial on APs
   | ap_persistent    | - unique AP BSSID
   | arp_devices      | - MAC addresses that responded to ARP queries
   | bad_measurements | - measurement trial data that is flawed
   | loc_persistent   | - data on each location
   | local_scans      | - local scan measurement data
   | plugin_output    | - actual wicrawl output (empty if anonymized)
   | tcp_ports        | - tcp port scan measurement data
   | trial            | - data on each trial at each location
   | udp_ports        | - udp port scan measurement data
   | wifi_info        | - estimated loss data (unused)
   +------------------+

Data from each measurement test is saved in ap, local_scans, tcp_ports, udp_ports, as follows:

   In the local_scans table:

   ap_id                 - ap.id that identifies this measurement test
   before_portal         - true if we performed the scan before bypassing the login portal (sometimes we test before and after)
   upnp_ips              - number of distinct IPs advertising UPnP services
   upnp_total            - total number of UPnP services advertised
   mdns_ips              - number of distinct IPs advertising an mDNS name
   mdns_workstations     - number of ._workstation._tcp.local mDNS names
   mdns_total int,       - number of mDNS names total
   smb_hosts int,        - number of responding CIFs clients (samba)
   arp                   - number of distinct local IP addresses responding to ARP (excluding our IP and the AP's IP)
   arp_macs              - number of distinct MAC addresses responding to ARP (excluding our MAC and the AP's MAC)
   arp_scanned           - number of local IP addresses scanned in the ARP scan
   upnp_output           - output of UPnP scanner (null if anonymized)
   mdns_output           - output of mDNS scanner (null if anonymized)
   smb_output            - output of SMB scanner (null if anonymized)
   arp_output            - output of nmap ARP scanner (null if anonymized)

[Trace] cmu/hotspot/sql_tables/tcp_ports (v. 2009-04-15)

top

the initial version

@MISC{cmu-hotspot-sql_tables-tcp_ports-2009-04-15,
  author = {Jeffrey Pang and Ben Greenstein and Michael Kaminsky},
  title = {{CRAWDAD} trace cmu/hotspot/sql_tables/tcp_ports (v. 2009-04-15)}, 
  howpublished = {Downloaded from http://crawdad.cs.dartmouth.edu/cmu/hotspot/sql_tables/tcp_ports},
  month = apr,  
  year = 2009
}
					

Database table of tcp port scan measurement data from 13 hotspot locations in Seattle, WA over one week.

Our measurement data is stored in several relational database
   tables.  It is distributed as an SQL file that you should be able
   to import into the relational database of your choice (we use
   MySQL). We assume in this document that the database is called
   wifi. The tables are as follows

   +------------------+
   | Tables_in_wifi   |
   +------------------+
   | ap               | - data on each measurement trial on APs
   | ap_persistent    | - unique AP BSSID
   | arp_devices      | - MAC addresses that responded to ARP queries
   | bad_measurements | - measurement trial data that is flawed
   | loc_persistent   | - data on each location
   | local_scans      | - local scan measurement data
   | plugin_output    | - actual wicrawl output (empty if anonymized)
   | tcp_ports        | - tcp port scan measurement data
   | trial            | - data on each trial at each location
   | udp_ports        | - udp port scan measurement data
   | wifi_info        | - estimated loss data (unused)
   +------------------+

Data from each measurement test is saved in ap, local_scans, tcp_ports, udp_ports, as follows:

   In the tcp_ports and udp_ports tables:

   ap_id                 - ap.id that identifies this measurement test
   udp###                - y if some probes to port ### succeeded, n otherwise
   tcp###                - same as above, but r if redirected to a man-in-the-middle
   udp###_time           - RTT of probes to port ###
   tcp###_time           - time to setup the tcp connection to port ###

[Trace] cmu/hotspot/sql_tables/trial (v. 2009-04-15)

top

the initial version

@MISC{cmu-hotspot-sql_tables-trial-2009-04-15,
  author = {Jeffrey Pang and Ben Greenstein and Michael Kaminsky},
  title = {{CRAWDAD} trace cmu/hotspot/sql_tables/trial (v. 2009-04-15)}, 
  howpublished = {Downloaded from http://crawdad.cs.dartmouth.edu/cmu/hotspot/sql_tables/trial},
  month = apr,  
  year = 2009
}
					

Database table of data on each trial at each location from 13 hotspot locations in Seattle, WA over one week.

Our measurement data is stored in several relational database
   tables.  It is distributed as an SQL file that you should be able
   to import into the relational database of your choice (we use
   MySQL). We assume in this document that the database is called
   wifi. The tables are as follows

   +------------------+
   | Tables_in_wifi   |
   +------------------+
   | ap               | - data on each measurement trial on APs
   | ap_persistent    | - unique AP BSSID
   | arp_devices      | - MAC addresses that responded to ARP queries
   | bad_measurements | - measurement trial data that is flawed
   | loc_persistent   | - data on each location
   | local_scans      | - local scan measurement data
   | plugin_output    | - actual wicrawl output (empty if anonymized)
   | tcp_ports        | - tcp port scan measurement data
   | trial            | - data on each trial at each location
   | udp_ports        | - udp port scan measurement data
   | wifi_info        | - estimated loss data (unused)
   +------------------+

For each trial, we save the following data:

   id         - unique ID for the trial
   unixtime   - time the trial started
   success    - whether the trial succeeded or was marked a failure by the user
   latitude   - GPS latitude
   longitude  - GPS longitude
   duration   - how long it took to run all the measurement tests
   loc_name   - where the trial took place (refers to loc_persistent.loc_name)
   comments   - any user entered comments about the trial
   mac        - measurement client's mac address
   ifconfig   - the output of ifconfig after the trial
   iwconfig   - the output of iwconfig after the trial
   netstat    - the output of netstat after the trial
   group_name - group that this trial belongs to (usually groups trials by day)
   dir        - directory in the filesystem with the log files from this trial

[Trace] cmu/hotspot/sql_tables/udp_ports (v. 2009-04-15)

top

the initial version

@MISC{cmu-hotspot-sql_tables-udp_ports-2009-04-15,
  author = {Jeffrey Pang and Ben Greenstein and Michael Kaminsky},
  title = {{CRAWDAD} trace cmu/hotspot/sql_tables/udp_ports (v. 2009-04-15)}, 
  howpublished = {Downloaded from http://crawdad.cs.dartmouth.edu/cmu/hotspot/sql_tables/udp_ports},
  month = apr,  
  year = 2009
}
					

Database table of udp port scan measurement data from 13 hotspot locations in Seattle, WA over one week.

Our measurement data is stored in several relational database
   tables.  It is distributed as an SQL file that you should be able
   to import into the relational database of your choice (we use
   MySQL). We assume in this document that the database is called
   wifi. The tables are as follows

   +------------------+
   | Tables_in_wifi   |
   +------------------+
   | ap               | - data on each measurement trial on APs
   | ap_persistent    | - unique AP BSSID
   | arp_devices      | - MAC addresses that responded to ARP queries
   | bad_measurements | - measurement trial data that is flawed
   | loc_persistent   | - data on each location
   | local_scans      | - local scan measurement data
   | plugin_output    | - actual wicrawl output (empty if anonymized)
   | tcp_ports        | - tcp port scan measurement data
   | trial            | - data on each trial at each location
   | udp_ports        | - udp port scan measurement data
   | wifi_info        | - estimated loss data (unused)
   +------------------+

Data from each measurement test is saved in ap, local_scans, tcp_ports, udp_ports, as follows:

   In the tcp_ports and udp_ports tables:

   ap_id                 - ap.id that identifies this measurement test
   udp###                - y if some probes to port ### succeeded, n otherwise
   tcp###                - same as above, but r if redirected to a man-in-the-middle
   udp###_time           - RTT of probes to port ###
   tcp###_time           - time to setup the tcp connection to port ###

[Tool] tools/collect/802.11/Wifi-Scanner (v. 2009-04-15)

top

the initial version.

@MISC{tools-collect-802.11-Wifi-Scanner-2009-04-15,
  author = {Jeffrey Pang and Ben Greenstein and Michael Kaminsky},
  title = {{CRAWDAD} tool tools/collect/802.11/Wifi-Scanner (v. 2009-04-15)}, 
  howpublished = {Downloaded from http://crawdad.cs.dartmouth.edu/tools/collect/802.11/Wifi-Scanner},
  month = apr,  
  year = 2009
}
					

Wi-Fi network scanner/wardriving tool used in the authors' MobiSys 2009 paper 
[pang-wifi-reports]. The main difference between Wifi-Scanner and other war 
driving tools is that it has a more complete Wi-Fi Network Manager that supports 
logging into WEP/WPA networks, remembering passwords for these networks, supports 
login through AP portal/splash pages, and performs a battery of measurement tests 
after you login.

See the indicated files for licensing terms for each of the following
packages:

gpsd:       gpsd-2.37/COPYING
kismet:     kismet-2007-10-R1/GPL
madwifi:    madwifi-0.9.4/COPYRIGHT
mdns:       mdns-scan-0.5/LICENSE
mitm-proxy: mitm-proxy-1.0/LICENSE
nuttcp:     nuttcp/nuttcp-5.5.5.c
stund:      stund/client.cxx
wicrawl:    wicrawl-0.4a/doc/LICENSE

All other components are licensed under the following terms:

(c) 2008-2009 Benjamin Greenstein, Damon McCoy, Jeffrey Pang

Permission is hereby granted, free of charge, to any person obtaining a
copy of this software and associated documentation files (the "Software"),
to deal in the Software without restriction, including without limitation
the rights to use, copy, modify, merge, publish, distribute, sublicense,
and/or sell copies of the Software, and to permit persons to whom the
Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in
all copies or substantial portions of the Software.

The names and trademarks of copyright holders may not be used in
advertising or publicity pertaining to the software without specific
prior permission. Title to copyright in this software and any associated
documentation will at all times remain with the copyright holders.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
DEALINGS IN THE SOFTWARE.

INSTALLATION

   The easiest way to install Wifi-Scanner is to (as root) run the following:

   (1) Create the directory root/tw
   (2) Move mark-and-sweep (part of this package) to $HOME/tw/mark-and-sweep
   (3) Move mywifi (part of this package) to $HOME/tw/mywifi
   (4) Run the prepare.pl script in the mark-and-sweep directory. If you have
       a bluetooth GPS, edit the line at the top of the script to match your
       GPS's MAC address. Otherwise, comment out the config_gps() line.
       
   In order to perform some of the measurement tests, you need to run a few
   daemons on a Internet-accessable server that you control.

   (1) Enter mark-and-sweep/port_checker and run 'make'.
   (2) Enter mark-and-sweep/udp_test and run 'make'.
   (2) Enter mark-and-sweep/nuttcp and run 'make'.
   (3) Copy mark-and-sweep/port_checker/port_checker,
       mark-and-sweep/simple_web_server/webserver.pl,
       mark-and-sweep/nuttcp/nuttcp-5.5.5, and
       mark-and-sweep/udp_test/udp_test to
       /usr/local/sbin/ on the server machine.
   (4) Copy mark-and-sweep/init.d/mark-and-sweep-server to the server machine.
   (5) Copy mark-and-sweep/xinet.d/nuttcp to the server machine at /etc/xinet.d/
   (6) Run the mark-and-sweep-server script.
   (7) Restart xinetd on the server.
   (8) On the measurement client, you will need to modify a number of files:
       mark-and-sweep/wicrawl-0.4a/plugins/*/plugin.conf
       So that the config variables point to the IP address of your server.
       The plugins that you need to modify the config file for are:
       bandwidth_up bandwidth_down tcp_bw traceroute port_check

Before measurements:

    * Create a list of locations (one location per line) in
      /root/tw/mark-and-sweep/loc_manager/data/location-list.txt

    * Enter /root/tw/mark-and-sweep and type 'make install'

   Go to one of these locations and then (as root with a X-Windows display):

    1. Enter /root/tw/install/bin

    2. Type './doit'

    3. Select your location from the list.

    4. Click 'Try'. (DO NOT CLICK MORE THAN ONCE) To abort, click 'Ignore'.

    5. Wait for the measurement tool to run. It is done when the output
       screen says '[**] End plugin-engine'.

    6. When the tool is done, close the window and return the to
       location list window. If the run was successful, click
       'SUCCESS', if it failed and you don't want to try again, click
       'FAIL'. Click 'Ignore' to ignore everything that happened
       (nothing will be saved). Click 'Try again' to label the
       previous run a failure and try again.

    7. Repeat at another location.

After measurements:

    1. Save the directory /root/tw/mark-and-sweep/install/var. (The log
       directories are called log.*)

    2. See mark-and-sweep/scripts/README for how to process this data
       and a description of its format.

    3. Delete the file
       /root/tw/mark-and-sweep/install/var/loc_manager/location-status.txt.
       This will reset the location list so that no entries are grayed
       out (usually they get greyed out after you measure them).

Measurement details:

    * During the measurement run, the tool will pop up a firefox
      browser when it detects a portal page. You have to manually
      login or click through. Then close firefox and it should
      proceed. If it still can not proceed, it will ask you in a
      dialog box if you want to try again (either using a measurement
      proxy or not) or if you want to give up and skip this AP.

    * For APs that are encrypted, a WEP/WPA dialog box will pop
      up. You can either enter the password for those APs that you
      know it or choose to skip it. If you click 'ignore permanently'
      then it will not ask you about that AP for any future runs. You
      can undo the 'ignore permanently' status by deleting that AP's
      file in /root/tw/mark-and-sweep/install/var/keydb. Also, all
      successful passwords will be saved so you don't have to type
      them in in the future.

    * If there are SSIDs that you are sure you never want to measure
      you can add them (one per line) in
      /root/tw/mark-and-sweep/install/var/skip_ssids

Wifi-Scanner is a tool for scanning and measuring properties about
   visible 802.11 access points (APs). The intended use is as follows:

   1) Make a list of locations you intend to measure.
   2) Go to each location, run the tool. The tool will prompt you if
      user input is required (e.g., to add a password or bypass an
      AP portal page). Measurements will be taken automatically.

   The main difference between Wifi-Scanner and other war driving
   tools is that it has a more complete Wi-Fi Network Manager that
   supports logging into WEP/WPA networks, remembering passwords for
   these networks, supports login through AP portal/splash pages, and
   that it performs a battery of measurement tests after you login.

[Author] Jeffrey Pang

top

[Author] Ben Greenstein

top

[Author] Michael Kaminsky

top

[Paper] pang-wifi-reports

top

Wi-Fi clients can obtain much better performance at some commercial hotspots 
than at others. Unfortunately, there is currently no way for users to determine 
which hotspot access points (APs) will be sufficient to run their applications 
be- fore purchasing access. To address this problem, this paper presents 
Wifi-Reports, a collaborative service that provides Wi-Fi clients with 
historical information about AP perfor- mance and application support. The key 
research chal- lenge in Wifi-Reports is to obtain accurate user-submitted 
reports. This is challenging because two conflicting goals must be addressed in 
a practical system: preserving the pri- vacy of users' reports and limiting 
fraudulent reports. We introduce a practical cryptographic protocol that 
achieves both goals, and we address the important engineering chal- lenges in 
building Wifi-Reports. Using a measurement study of commercial APs in Seattle, 
we show that Wifi-Reports would improve performance over previous AP selection 
ap- proaches in 30\%-60\% of locations.