CRAWDAD dartmouth/campus (v. 2007-02-08)

Syslog, SNMP, and tcpdump data for 5 years or more from wireless network at Dartmouth College.Note: This dataset has multiple versions. The dataset file names of the data associated with this version are listed below, under the 'Traceset' heading and can be downloaded under 'Dataset Files' on the right-hand side of the page.This dataset includes syslog, SNMP, and tcpdump data for 5 years or more, for over 450 access points and several thousand users at Dartmouth College.last modified :2008-09-12release date :2007-02-08date/time of measurement start :2001-04-11date/time of measurement end :2006-10-04collection environment :The Dartmouth College campus has over 190 buildings on 200 acres. Dartmouth College has about 5500 students and 1200 faculty, and during our study there were approximately 3200-3300 undergraduates on campus. Students are required to own a computer, and most purchase a computer through the campus computer store. Wireless laptops increasingly dominate those purchases, making up 45% of the total in 2000, 70% in 2001, 88% in 2002, and 97% in 2003. Assuming that students obtaining computers elsewhere choose laptops in the same proportion, we estimate that over 75% of the undergraduates owned laptops at the time of our study.network configuration :476 Cisco 802.11b access points (APs) were installed in 2001 to cover most of the campus. Since then, APs have been added to increase coverage and to cover new construction, and there are currently 566 APs. The compact nature of the campus means that the signal range of interior APs extends to cover most of the campus' outdoor areas. All APs share the same SSID, allowing wireless clients to roam seamlessly between APs. On the other hand, a building's APs are connected to the building's existing subnet. The 188 buildings with wireless coverage span 115 subnets, so clients roaming between buildings may be forced to obtain new IP addresses. Clients obtain IP addresses using DHCP (lease times were 6 or 12 hours at different points in the trace).data collection methodology :We used three techniques: syslog events, SNMP polls, and network sniffers (tcpdump). We also derived movement history data from the syslog data.sanitization :All data has been sanitized to protect the privacy of our users. We have resanitized the data (2004-11-08) so that there is a consistent MAC address mapping and a consistent IP address mapping across all of the traces. In other words, the sanitized IP address 111.222.333.444 will correspond to the same raw IP address in all of our traces. Similarly, the sanitized MAC address aa:bb:cc:dd:ee:ff will always correspond to the same raw MAC address in all of our traces. Note that these may not represent the same physical device, due to DHCP, MAC spoofing, etc.Tracesetdartmouth/campus/syslogTimestamped, sanitized syslog records from Dartmouth wireless network.files: syslog-v3.3.tar.gz, syslog-2005-2006-cisco.tar.gz, syslog-2005-2006-aruba.tar.gz, syslog-2005-2006-merged.tar.gzdescription: The traceset of nearly continuous recording of the syslog records produced by the access points, from 2001-04-11 to 2004-06-30, and from 2005-09-01 to 2006-10-04. UNIX timestamps have been added to each log record, and MAC addresses and AP names sanitized.measurement purpose: Usage Characterization, User Mobility Characterizationmethodology: We configured the access points to transmit a syslog message every time a client card associated or disassociated with the access point (We configured the Cisco APs and the Aruba APs differently. Please see the traces dartmouth/campus/syslog/01_04 and dartmouth/campus/syslog/05_06 for more details). Dartmouth currently has no authentication to associate with the network, so we do not know the identity of users, and the IP address given to a user varies from time to time and building to building.last modified: 2007-02-08dataname: dartmouth/campus/syslogversion: 20070208change: A new syslog trace (collected from 2005-09-02 to 2006-10-04) has been added.release date: 2007-02-08date/time of measurement start: 2001-04-11date/time of measurement end: 2006-10-04hole: We have not released syslog trace collected from 2004-07-01 to 2005-08-31.dartmouth/campus/syslog Traces01_04: Timestamped, sanitized syslog records from Dartmouth wireless network.format: timestamp, AP name, the MAC address of the card, and type of message description: The trace of nearly continuous recording of the syslog records produced by the access points, from 2001-04-11 to 2004-06-30. UNIX timestamps have been added to each log record, and MAC addresses and AP names sanitized.last modified: 2007-01-31dataname: dartmouth/campus/syslog/01_04version: 20041218change: Syslog trace is newly created.release date: 2004-12-18date/time of measurement start: 2001-04-11date/time of measurement end: 2004-06-30file: syslog-v3.3.tar.gzhole: We only have a list of these holes in fall 2001. We had ``spatial holes'' because many APs did not send syslogs. [Configuration mistake.] And temporal holes, because our syslog recording server(s) failed. You may refer to note for details. It also appears that the engineering school's APs, building name ''cummings'' did not send any messages after they installed a firewall in early 2002 until I noticed the problem and asked them to open a hole in the firewall in late 2002. We do not release the syslog trace collected from 2004-07-01 to 2005-08-31.limitation: Since syslog messages are sent from the APs to a relaying server (ns1), and from ns1 to our syslog recording servers, as UDP messages, it is possible for them to be lost or reordered along the way. The timestamps are applied by the syslog daemon on our host, so the timestamps are monotonically increasing. But, the events may have been recorded out of order, and some may be missing. We believe this effect is small enough to be negligible. We have two syslog recording servers, and we do not see the same event with different timestamps in the two servers. From 10/19/2003 this no longer applies.sanitization: Every MAC address has been sanitized, and the IP address or host name of client machines has been removed. To sanitize the MAC address, we randomized the bottom six hex digits. We collected every MAC address from all of our syslog, SNMP, an tcpdump traces, and built a huge table mapping real MACs to randomized MACs, ensuring that all mappings are unique. Each access point name has been blinded in the form: AcadBldg10AP3 where this indicates the third AP in the tenth building of type 'Academic.' The building types are Adm (Admin), Ath (Athletic), Lib (Library), Oth (Other - mainly sysadmin test APs), Res (Residential) and Soc (Social). Refer to note for details.05_06: Timestamped, sanitized syslog records from Dartmouth wireless network for the period 2005 - 2006.configuration: [Cisco APs] We configured the Cisco access points to transmit a syslog message every time a client card authenticated, associated, reassociated, disassociated, or deauthenticated with the access point. Each message contains the AP name, the MAC address of the card, and the type of message. [Aruba APs] On our campus, we deployed Aruba wireless networks with an Aruba 5000 switch as a master switch, which controls the wireless network in centralized manner. The configuration has a three-level hierarchy (master-switches-APs) such that a number of switches are attached to the master switch, and likewise a number of APs are attached to each switch. We have three models of Aruba APs: 52, 61, and 72. The wireless network is virtually divided into several zones (subnets), each of which has a controller that controls a set of APs. Aruba syslog messages come from either the master switch (the central controller) or each zone controller. Since different zone covers different set of APs, separate syslog messages come from each zone controller. The Aruba system is able to configure multiple ESSIDs on each AP. At the time of collecting these syslog data, we used four ESSIDs - "Kiewit Wireless", "Kiewit Video", "Kiewit Voice", and "Hanover Inn". Among those ESSIDs, Kiewit Video/Voice are NATed and use private (RFC1918) addresses. We do not have L2 assoc/disassoc/auth/deauth messages in the Aruba syslog trace because the Aruba switch does not give us those. What we do have are "station up" and "station down" messages which indicate when the switch sees a client connect with a BSSID. Though we do not know what these station up|down messages equate to in the 802.11 FSM, for most analyses it should be possible to more or less correlate these messages with the assoc|disassoc messages in the Cisco syslog.format:Directory and files This trace consists of three tarballs (directories): 'syslog-2005-2006-cisco', 'syslog-2005-2006-aruba', and 'syslog-2005-2006-merged'. 'syslog-2005-2006-cisco' and 'syslog-2005-2006-aruba' directories contain syslog records from cisco APs and Aruba APs, respectively. 'syslog-2005-2006-merged' directory contains syslog records merged from 'cisco' and 'aruba' syslog records, sorted by timestamps. Each directory contains syslog trace files for each day during the measurement period. File name follows the format YYMMDD.HHMMSS.{syslog or aruba or merged}. The time used for file name is in UTC. For Aruba syslog trace, we represent each access point name as location id (with the format [building_id.floor_id.ap_id] like 15.1.1). Under the trace root directory, we provide a file called 'aruba_locid_table.csv' containing a mapping between location id and sanitized AP name (e.g., a pair of 15.1.1 and AcadBldg10AP3). Format of Cisco syslog records is as follows: unix_timestamp timestamp1 AP_name1 timestamp2 counter AP_name2 timestamp2 syslog_message unix_timestamp : UNIX timestamp in UTC timestamp1 : the time that the syslog message was received AP_name1 : the (sanitized) hostname of the host that sent the syslog counter : internal counter AP_name2 : the (sanitized) hostname that the AP thinks it has. Sometimes AP_name1 and AP_name2 don't match. timestamp2 : the AP's clock. Sometimes timestamp1 and timestamp2 don't match. syslog_message : syslog message content The following is a sample line in Cisco IOS syslog trace. 1157014202 Aug 31 04:50:02 AcadBldg33AP1 14375: AcadBldg33AP1 Aug 31 08:50:01: %DOT11-6-ASSOC: Interface Dot11Radio0, Station 0016cbf7ca65 Associated KEY_MGMT[NONE] Format of Aruba syslog records is as follows: unix_timestamp timestamp ip_address1 year [ip_address2] syslog_message unix_timestamp : UNIX timestamp in UTC timestamp, year : the time that the syslog message was received ip_address1 : the (sanitized) IP address of the controller ip_address2 : the (sanitized) IP address of another controller that sent this message. Sometimes the messages don't come directly from the controller, they come from a controller further down the tree. syslog_message : syslog message content The following is a sample line in Aruba syslog trace. 1159954944 Oct 4 05:42:24 50.32.208.194 2006 [50.32.208.195] authmgr[510]: station down bssid 00:0b:86:d3:ab:80, essid Kiewit Voice, vlan 2242, ingress 0x1168 (tunnel 264), u_encr 1, m_encr 1, loc 15.1.1 slotport 0xfc7 This message means that a user connected to an AP is removed from the user table. Previously it was connected to VLAN 2242 at location 15.1.1. The reason for the disconnection might be one of the following: - User moved out of the network - The user is logged out of the network.description: The trace of nearly continuous recording of the syslog records produced by the access points, from 2005-09-01 to 2006-10-04. UNIX timestamps have been added to each log record, and MAC addresses and AP names sanitized.last modified: 2007-02-08dataname: dartmouth/campus/syslog/05_06version: 20070208change: This 2005-2006 syslog trace is newly created.release date: 2007-02-08date/time of measurement start: 2005-09-01date/time of measurement end: 2006-10-04sanitization: Every MAC address has been sanitized by randomizing the bottom six hex digits, and we mapped all IP addresses using a prefix-preserving sanitizer. [Cisco syslog] Each access point name has been blinded in the form: AcadBldg10AP3 where this indicates the third AP in the tenth building of type 'Academic.' The building types are Adm (Admin), Ath (Athletic), Lib (Library), Oth (Other - mainly sysadmin test APs), Res (Residential) and Soc (Social). [Aruba syslog] Each access point name is represented as location id ([building_id.floor_id.ap_id] like 15.1.1). We also provide a file called 'aruba_locid_table.csv' containing a mapping between location id and sanitized AP name (e.g., a pair of 15.1.1 and AcadBldg10AP3).dartmouth/campus/snmpRecords of SNMP polling at Dartmouth College.files: fall01.tar.gz, spring02.tar.gz, fall03.tar.gzdescription: The traceset of polling every AP every five minutes, during Fall term 2001, Spring term 2002, Fall term 2003 and Winter term 2004. The Fall 2001 data was used for [MobiCom 2002 paper]. The 2003/4 data was used for [MobiCom 2004 paper]. We recommend only using the 2003/4 data. See this important note about problems with the 2001/2002 SNMP dataset. Any questions about the 2001/2 data will go into our LBE (Less than Best Effort) queue, i.e., they may not be answered... please use the 2003/4 data instead.measurement purpose: Usage Characterizationmethodology: We used the Simple Network Management Protocol (SNMP) to poll each AP every five minutes, querying AP and client-specific counters. AP-specific variables included inbound/outbound bytes, packets and errors, and the clients associated with a given AP. Client-specific variables included MAC and IP addresses, signal strength and quality.sanitization: To sanitize the data, we randomly (but consistently) mapped the MAC address field into a randomly chosen MAC of the same vendor, and we mapped all IP addresses using a prefix-preserving sanitizer.last modified: 2008-09-12dataname: dartmouth/campus/snmpversion: 20041109change: SNMP Traceset is resanitized.release date: 2004-11-09date/time of measurement start: 2001-09-14date/time of measurement end: 2004-02-28limitation: We have no way to distinguish periods with no clients from periods when the AP was off or unreachable. We also have no way to detect an AP reboot or reset, which reset all of the per-client counters reported here. Thus it is critical to take care when interpreting the per-client byte counts... a counter can be reset or roll over between two polls, and the delta can thus appear to be negative (or, in unsigned math, a very large number).hole: There were unfortunate gaps in the data collection, generally caused by power failures.error: In 2001/2 data, the perl scripts that performed the SNMP queries suffered from some problems, in that they queried inappropriate SNMP values, or misunderstood the meaning of other values. This data was also used in a subsequent analysis. The same scripts were used to collect data for a subsequent study of another wireless network. See http://www.cs.dartmouth.edu/reports/abstracts/TR2003-480/dartmouth/campus/snmp Tracesfall01: Records of SNMP polling during Fall term 2001.configuration: The job of polling all access points was divided among two machines: agentnews and klebb. Each of those hosts has a directory here. In each directory there is a number of subdirectories, one for each day, and in each of those subdirectories there are a number of SNMP log files.format:There are two types of file. The first type of file has one file for each access point. Each file gives information about each interface for each poll. Most of the interfaces are irrelevant; you only care about the wireless interface (the one with ifSpeed=11000000).Here is an example: V1.0ap timestamp,ap,ifIndex,ifInOctets,ifOutOctets,ifSpeed,ifInErrors,ifOutErrorsNotice the periodic restatment of the file format version and the description of the MIB variable names used in the lines that follow.The second type of file occurs once for each AP and each date. The file name conveys the blinded name of the AP, e.g. AcadBldg10AP3 where this indicates the third AP in the tenth building of type 'Academic.' The building types are Adm (Admin), Ath (Athletic), Lib (Library), Oth (Other - mainly sysadmin test APs), Res (Residential) and Soc (Social). Each data file contains all of the data for that access point on that date. Below is a sample of the top of one file. The top two lines are documentation; the first indicates the file format version (always V1.0). The second identifies the column headers for each of the data lines. After the timestamp (standard Unix time in seconds), the remaining fields are MIB variables from the AWC MIB (Aironet Wireless Communications is the name of the company that developed our access points; Aironet was bought by Cisco who then branded and sold the APs under their name).V1.0 timestamp,awcTpFdbAddress,awcTpFdbClassID,awcTpFdbSrcOctetsImmed,awcTpFdbDestOctetsImmed,awcTpFdbIPv4Addr,awcTpFdbDdpProdDevID,awcTpFdbDdpRadioDevID,awcDot11TpFdbAID,awcDot11TpFdbTxShortRetries,awcDot11TpFdbLatestRxSignalQuality,awcDot11TpFdbCapabilities 1001908847,003065d1eb95,clientStation,1276264,1986728,000.000.000.000,-15,unknown,state2,73,73 1001909056,003065d1eb95,clientStation,1276264,1986728,000.000.000.000,generic80211Client,unknown,state2,73,73 1001909266,003065d1eb95,clientStation,1276264,1986728,000.000.000.000,-15,unknown,state2,73,73 1001909476,003065d1eb95,clientStation,1276264,1986728,000.000.000.000,broadcast,-16,state2,73,73 1001909683,003065d1eb95,clientStation,1276264,1986728,000.000.000.000,broadcast,-16,state2,73,73 1001909892,003065d1eb95,clientStation,1276264,1986728,000.000.000.000,generic80211Client,unknown,state2,73,73 1001910102,003065d1eb95,clientStation,1276264,1986728,000.000.000.000,generic80211Client,unknown,state2,73,73 1001910311,003065d1eb95,clientStation,1276264,1986728,000.000.000.000,ethernetAP,34,state2,73,73 description: The trace of SNMP polling every AP during Fall term 2001.last modified: 2008-09-12dataname: dartmouth/campus/snmp/fall01version: 20041109change: SNMP trace is resanitized.release date: 2004-11-09date/time of measurement start: 2001-09-14date/time of measurement end: 2002-01-10file: fall01.tar.gzerror: During the fall there were some access points with old, buggy firmware that sometimes filled our SNMP data files with garbage entries. Any code you write to parse the data must be very robust. Unfortunately the code that I used was hacked on by two or three different students and is not currently in presentable form. See http://www.cs.dartmouth.edu/reports/abstracts/TR2003-480/.spring02: Records of SNMP polling during Spring term 2002.configuration: The job of polling all access points was divided among three machines: agentnews, klebb, and molari. I used molari only briefly until I was able to accomplish the same thing on one of the other two (access points cummings-* were missed for a week, because they are behind a firewall, and eventually I set up molari inside the firewall, and eventually I was able to add a hole in the firewall so that agentnews and klebb could poll through the firewall). Each polling machine has a directory. Each such directory has a subdirectory for each date. In each date, there is a file for each access point polled by that machine on that date. In the file are several types of lines. Below is a sample from the top of one file. Notice that it uses a comma-separated format suitable for import into spreadsheets, or easy parsing with AWK or perlformat: The first five lines are comments. The first gives basic information:V2.1: file format version 2.1, timestamp of file creation, AP name, and date code YYMMDDAll timestamps are standard Unix timestamps (seconds since 1970). The other four comment lines describe the format of lines that occur later in the file. Other than the timestamp and AP name, the rest of these fields are MIB variable names. After the five comment lines comes a series of polls. Each poll consists of one ''sys'' line, one ''if'' line describing stats of the the wireless interface, and zero or more pairs of ''c1'' and ''c2'' lines, each pair describing a currently connected client. The c1 and c2 lines are a collection of MIB variables from the AWC MIB (Aironet Wireless Communications is the name of the company that developed our access points; Aironet was bought by Cisco who then branded and sold the APs under their name).V2.1,1018929767,AdmBldg27AP2,020416sys,timestamp,AP,sysUpTimeif,timestamp,AP,ifIndex,ifType,ifSpeed,ifInOctets,ifInUcastPkts,ifInErrors,ifInDiscards,ifOutOctets,ifOutUcastPkts,ifOutErrors,ifOutDiscardsc1,timestamp,AP,awcDot11TpFdbAddress,awcDot11TpFdbClientState,awcDot11TpFdbLatestRxSignalStrength,awcDot11TpFdbLatestRxSignalQualityc2,timestamp,AP,awcTpFdbAddress,awcTpFdbClassID,awcTpFdbSrcOctetsImmed,awcTpFdbDestOctetsImmed,awcTpFdbIPv4Addr description: The trace of SNMP polling every AP during Spring term 2002.last modified: 2008-09-12dataname: dartmouth/campus/snmp/spring02version: 20041109change: SNMP trace is resanitized.release date: 2004-11-09date/time of measurement start: 2002-03-25date/time of measurement end: 2002-06-09file: spring02.tar.gzerror: PLEASE NOTE THAT THERE ARE ERRORS in dartmouth/campus/snmp/fall01 and dartmouth/campus/snmp/spring02 data sets. See http://www.cs.dartmouth.edu/reports/abstracts/TR2003-480/ .fall0304: Records of SNMP polling during Fall term 2003 and Winter term 2004.configuration: We only used one machine for SNMP polls in this period. The SNMP poller was rewritten to be more robust and more efficient, and so we only needed one machine to poll all ~ 560 APs on campus. We queried more counters in this trace. The variables are listed at the beginning of each file. For more details see the MIBS: ftp://ftp-sj.cisco.com/pub/mibs/v2/AWCVX-MIB.my ftp://ftp-sj.cisco.com/pub/mibs/v2/IEEE802dot11-MIB.my At the time of this data collection, Dartmouth mainly used Cisco 340 and 350 APs. These used to run the VxWorks operating system. During December 2003 to May 2004, our 350 APs migrated from running VxWorks to the Cisco IOS (the APs didn't originally run IOS as they were made by Aironet, a company that was later bought by Cisco). IOS uses completely different SNMP MIBs to VxWorks, and so the variable names and their order are slightly different. When the upgrades started taking place, we incremented the log version number to "V3.1" (the first line of each log) to indicate the new variables being queried. We also folded both the "c1" and "c2" client-specific lines into one "cl" line (this made the parser code easier to maintain).format:The first five lines are comments. The first gives basic information: V2.1: file format version 2.1, timestamp of file creation, AP name, and date code YYMMDD All timestamps are standard Unix timestamps (seconds since 1970). The other four comment lines describe the format of lines that occur later in the file. Other than the timestamp and AP name, the rest of these fields are MIB variable names.After the five comment lines comes a series of polls. Each poll consists of one ''sys'' line, one ''if'' line describing stats of the the wireless interface, and zero or more pairs of ''c1'' and ''c2'' lines, each pair describing a currently connected client. The c1 and c2 lines are a collection of MIB variables from the AWC MIB (Aironet Wireless Communications is the name of the company that developed our access points; Aironet was bought by Cisco who then branded and sold the APs under their name). V2.1,1018929767,AdmBldg27AP2,020416 sys,timestamp,AP,sysUpTime if,timestamp,AP,ifIndex,ifType,ifSpeed,ifInOctets,ifInUcastPkts,ifInErrors,ifInDiscards,ifOutOctets,ifOutUcastPkts,ifOutErrors,ifOutDiscards c1,timestamp,AP,awcDot11TpFdbAddress,awcDot11TpFdbClientState,awcDot11TpFdbLatestRxSignalStrength,awcDot11TpFdbLatestRxSignalQuality c2,timestamp,AP,awcTpFdbAddress,awcTpFdbClassID,awcTpFdbSrcOctetsImmed,awcTpFdbDestOctetsImmed,awcTpFdbIPv4Addrdescription: The trace of SNMP polling every AP during Fall term 2003 and Winter term 2004.last modified: 2006-11-14dataname: dartmouth/campus/snmp/fall0304version: 20041109change: SNMP trace is resanitized.release date: 2004-11-09date/time of measurement start: 2003-11-01date/time of measurement end: 2004-02-28file: fall03.tar.gzdartmouth/campus/tcpdumpPacket headers from every wireless packet sniffed in 27 buildings on Dartmouth College campus.files: fall01, spring02, fall03, README.voipdescription: The packet headers from every wireless packet sniffed in four (Fall01), five (Spring02), or 18 (Fall03) buildings on campus. The Fall 2001 data was used for [MobiCom 2002 paper]. The Fall 2001 and Spring 2002 data was used for [WiNet 2005 paper]. The 2003/4 data was used for [MobiCom 2004 paper]. This fall03 data also contains a list of device types, as determined using the OS fingerprinting tool p0f. Note that the MAC addresses in this list are only devices that we saw associate with an AP (i.e., that appeared in the syslog or SNMP data). Thus it does not include non-wireless client MAC addresses, such as routers or spoofed MACs that do not appear in syslog. The total compressed datasets are over 200 GB, so they are too large to post as tarballs. The best option is to use an http tool like curl or wget to download the whole Fall01, Spring02, or Fall03 directory from the web site. Or you can arrange to send us a USB or firewire drive (>250GB) and we can ship it back to you with all of our data on it. You can get the README, some of my analysis software, and the output of my own analysis programs listing the amount of traffic seen at each sniffer for each port number for each day, that is available as a small (660 KB) tgz file. NB: this is for the 2001/2 data.measurement purpose: Usage Characterizationmethodology: We used network ''sniffers'' to obtain detailed network-level traces. Due to the volume of traffic on the wireless network, it was impractical to capture all the traffic. Moreover, the structure of our WLAN, with several subnets, meant that there was no convenient central point for capturing wireless traffic. Instead, we installed 18 sniffers in 14 different buildings; in some large buildings, we needed multiple sniffers to monitor all of the building's APs. The buildings were among the most popular wireless locations in 2001, and included libraries, dormitories, academic departments and social areas. In total, our 18 sniffers covered 121 APs. Each sniffer was a Linux box with two Ethernet interfaces. One interface was used for remote access, to maintain the sniffer and to obtain the data for analysis. The other interface was used for collecting (''sniffing'') data. In each of the 18 switchrooms we attached the APs to a switch, and set another port on the switch to ''mirror'' mode, so that all the traffic on that switch would be sent to this port. The sniffer's second interface was attached to this mirrored port. We used tcpdump to capture any wireless traffic that came through these APs and their wired interfaces..sanitization: To sanitize the MAC address, we randomized the bottom six hex digits. We collected every MAC address from all of our syslog, SNMP, an tcpdump traces, and built a huge table mapping real MACs to randomized MACs, ensuring that all mappings are unique. [We did not change either the MAC address 000000000000 or FFFFFFFFFFFF, they remain as they were.] We applied this mapping consistently across all data files of all types, so if you see a MAC address in the tcpdump files, and see it again in the SNMP trace, you can be sure it's the same client. We used a prefix-preserving IP address sanitizer, see Xu, J., Fan, J. Ammar, M., and Moon, S. ``On the Design and Performance of Prefix-Preserving IP Traffic Trace Anonymization'', Proc. of 10th IEEE International Conference on Network Protocols (ICNP 2002), Paris, France, November 2002. What this means is that you can compare the prefixes of the sanitized IP addresses, i.e. if two IP addresses share the same k-bit prefix, the sanitized addresses will also share the same k-bit prefix.last modified: 2006-11-14dataname: dartmouth/campus/tcpdumpversion: 20041109change: TCPDUMP traceset is resanitized.release date: 2004-11-09date/time of measurement start: 2001-09-25date/time of measurement end: 2004-02-28limitation: In both Fall01 and Spring02 datasets we lose a little data each day. We restarted tcpdump once a day, to cause it to begin a new log file. We killed the tcpdump process, then started a new one; as a result, some tcpdump data files end with partial packets, and no doubt we lost a few packets in the transition. We missed any traffic between two clients associated with the same AP, as this would not be sent via the AP's wired interface, but we believe this occurred rarely.hole: There were unfortunate gaps in the data collection, generally caused by power failures.error: The Fall01 data in particular suffers from a lot of corruption. It appears that older versions of tcpdump have a serious bug that causes them to record the MAC address of many frames incorrectly. In the Spring we used a newer tcpdump that did not have this problem.dartmouth/campus/tcpdump Tracesfall01: Packet headers from every wireless packet sniffed on Dartmouth College campus during Fall 2001 term.configuration: We collected data from four sniffers around the Dartmouth campus. Each sniffer was connected to a hub, along with the building's access points. The four buildings are representative: 1. Sudikoff (AcadBldg16): the Department of Computer Science (6 APs). 2. Brown (ResBldg100): a dormitory with many first-year students (2 APs). 3. Berry (LibBldg2): the main campus library. Due to the size of the building and the switched nature of its network, we were only able to sniff 5 of the 13 APs. 4. Collis/Thayer (SocBldg1): two buildings, the student center and dining hall, containing five cafes, several lounge areas, several meeting rooms, and some offices (total 9 APs).format: tcpdump formatdescription: The packet headers from every wireless packet sniffed in four (Fall01) buildings on campus. The Fall 2001 data was used for [MobiCom 2002 paper] and [WiNet 2005 paper].last modified: 2006-11-14dataname: dartmouth/campus/tcpdump/fall01version: 20041109change: TCPDUMP trace is resanitized.release date: 2004-11-09date/time of measurement start: 2001-09-25date/time of measurement end: 2001-12-10directory: fall01hole: % Sudi 3 GAPS of about 21h:17m:46s % Brown 15 GAPS of about 213h:10m:33s % Berry 7 GAPS of about 139h:17m:29s % Collis 8 GAPS of about 337h:1m:59slimitation: We lose a little data each day. To keep file sizes small, and to be able to backup and manipulate the data more easily, we restarted tcpdump once a day, to cause it to begin a new log file. We killed the tcpdump process, then started a new one; as a result, some tcpdump data files end with partial packets, and no doubt we lost a few packets in the transition. [We note that newer versions of tcpdump have a roll-over mechanism built in; too bad it didn't exist for our tracing.] In the fall, we restarted tcpdump at midnight;error: Data in particular suffers from a lot of corruption. It appears that older versions of tcpdump have a serious bug that causes them to record the MAC address of many frames incorrectly. These bogus MAC addresses, specifically 0:0:0:0:0:0, 0:0:0:0:0:1, 1:0:0:0:0:0, or 1:0:1:0:1:0, occurred in about 78% of all frames in the Fall data. For frames containing IP packets, we examined the source and destination IP address; if the IP address was associated with a valid, wireless MAC address in a recent IP packet, then we assumed this packet used the same MAC, and treated it as a wireless packet. We fixed about a third of bad MACs this way.spring02: Packet headers from every wireless packet sniffed on Dartmouth College campus.configuration: We collected data in the same way, in the same four locations, but added another sniffer on the 8 APs in Whittemore, which is a dormitory at the Tuck School of Business. This data is much cleaner than the fall data.format: tcpdump formatdescription: The packet headers from every wireless packet sniffed in five buildings on campus. The Spring 2002 data was used for [WiNet 2005 paper].last modified: 2006-11-14dataname: dartmouth/campus/tcpdump/spring02version: 20041109change: TCPDUMP trace is resanitized.release date: 2004-11-09date/time of measurement start: 2002-03-25date/time of measurement end: 2002-06-09directory: spring02hole: Berry (LibBldg2): 2 GAPS of about 0h:6m:34s Brown (ResBldg100): 0 GAPS of about 0h:0m:0s Collis (SocBldg1): 5 GAPS of about 27h:24m:22s Sudikoff (AcadBldg16): 0 GAPS of about 0h:0m:0s Whittemore (ResBldg83): 1 GAPS of about 12h:28m:15slimitation: We lose a little data each day. To keep file sizes small, and to be able to backup and manipulate the data more easily, we restarted tcpdump once a day, to cause it to begin a new log file. We killed the tcpdump process, then started a new one; as a result, some tcpdump data files end with partial packets, and no doubt we lost a few packets in the transition. [We note that newer versions of tcpdump have a roll-over mechanism built in; too bad it didn't exist for our tracing.] We restarted at about 4AM when traffic was lightest.fall03: Packet headers from every wireless packet sniffed on Dartmouth College campus during Fall 2003 term.configuration: We increased the number of sniffers again, this time to 18, spread among the same buildings as before, but also with more dorms and social buildingsformat: tcpdump formatdescription: The packet headers from every wireless packet sniffed in 18 buildings on campus. The 2003/4 data was used for [MobiCom 2004 paper]. This fall03 data also contains a list of device types, as determined using the OS fingerprinting tool p0f. a list of device types, as determined using the OS fingerprinting tool p0f (note that the MAC addresses in this list are only devices that we saw associate with an AP (i.e., that appeared in the syslog or SNMP data). Thus it does not include non-wireless client MAC addresses, such as routers or spoofed MACs that do not appear in syslog.). There is also a brief note about the VoIP data included in this trace.last modified: 2006-11-14dataname: dartmouth/campus/tcpdump/fall03version: 20041109change: TCPDUMP trace is resanitized.release date: 2004-11-09date/time of measurement start: 2003-11-02date/time of measurement end: 2004-02-28dartmouth/campus/movementTwo-year records showing the location (AP association) of each wireless card seen on campus.files: movement.tar.gz, movement-v1.3.tar.gz, APlocations.csvdescription: Over three years of nearly continuous records showing the location (access-point association) of each wireless card seen on campus. We used this data for our study of location predictors, published in [INFOCOM'04 paper] and a subsequent, expanded [technical report]. This data is derived from the syslog data. The trace used for this paper is gzipped tar file [51MB]. An updated movement history dataset (up to 2004-06-30) is gzipped tar file [166MB].measurement purpose: User Mobility Characterizationmethodology: We extracted user traces from dartmouth/campus/syslog. Each user's trace is a series of locations, that is, access-point names. We introduced the special location 'OFF' to represent the user's departure from the network (which occurs when the user turns off their computer or their wireless card, or moves out of range of all access points). The traces varied widely in length (the number of locations in the sequence). Users with longer traces were either more active (using their card more), more mobile (thus changing access points more often), or used the network for a longer period (some users have been on the network since April 2001, and some others have only recently arrived on campus).sanitization: same as dartmouth/campus/sysloglast modified: 2007-01-31dataname: dartmouth/campus/movementversion: 20050308change: An updated movement history trace (up to 2004-06-30) is added.release date: 2005-03-08limitation: same as dartmouth/campus/sysloghole: same as dartmouth/campus/syslogdartmouth/campus/movement Tracesinfocom04: Two-year records showing the location (AP association) of each wireless card seen on campus.configuration: This trace is derived from the trace dartmouth/campus/syslog/01_04.format: timestamp, associated APdescription: Over two years of nearly continuous records showing the location (access-point association) of each wireless card seen on campus. We used this data for our study of location predictors, published in [INFOCOM'04 paper] and a subsequent, expanded [technical report]. This data is derived from the syslog data. The trace used for this paper is gzipped tar file [51MB]. .last modified: 2006-11-14dataname: dartmouth/campus/movement/infocom04version: 20040805change: Infocom04 movement trace is newly createdrelease date: 2004-08-05file: movement.tar.gz01_04: Three-year records showing the location (AP association) of each wireless card seen on campus.configuration: This trace is derived from the trace dartmouth/campus/syslog/01_04.format: timestamp, associated APdescription: Over three years of nearly continuous records showing the location (access-point association) of each wireless card seen on campus. This updated movement history dataset (up to 2004-06-30) is gzipped tar file [166MB].last modified: 2007-01-31dataname: dartmouth/campus/movement/01_04version: 20050308change: This trace is newly added.release date: 2005-03-08date/time of measurement start: 2001-04-01date/time of measurement end: 2004-06-30file: movement-v1.3.tar.gzaplocations: A comma-separated list of most of the APs on campus and their location.configuration: APlocations.csv: This file contains the locations of the APs. We used building blueprints and a campus map in AutoCAD format, and then painstakingly plotted most of the APs on the map. The rough correlation is approximately 1.7 coordinate units per foot. The Z coordinate is the floor. 99 means an unknown floor. -1 X/Y coordinates mean that we don't know where this AP is located. Tristan Henderson, November 2004format: AP, x coordinate (-1 = unknown), y coordinate (-1 = unknown), z coordinate (floor, 99 = unknown)description: A comma-separated list of most of the APs on campus and their location, as defined in coordinates on an AutoCAD map of the campus.last modified: 2006-11-14dataname: dartmouth/campus/movement/aplocationsversion: 20041109change: AP locations are addedrelease date: 2004-11-09file: APlocations.csv

达特茅斯学院无线网络中的Syslog、SNMP和tcpdump数据，时间跨度为5年或更长。请注意，此数据集具有多个版本。与该版本相关的数据集文件名列于以下'Traceset'标题下，可以在页面右侧的'Dataset Files'下下载。该数据集包括达特茅斯学院超过450个接入点和数千名用户的Syslog、SNMP和tcpdump数据。最后修改时间：2008年9月12日发布日期：2007年2月8日数据测量开始日期/时间：2001年4月11日数据测量结束日期/时间：2006年10月4日收集环境：达特茅斯学院校园占地面积约200英亩，有超过190座建筑。达特茅斯学院约有5500名学生和1200名教职员工，在研究期间，校园内有大约3200-3300名本科生。学生必须拥有电脑，并且大多数学生通过校园电脑商店购买电脑。无线笔记本电脑在购买中占据主导地位，2000年占总数的45%，2001年占70%，2002年占88%，2003年占97%。假设在其他地方获得电脑的学生以相同比例选择笔记本电脑，我们估计在我们研究的时候，超过75%的本科生拥有笔记本电脑。网络配置：2001年安装了476个Cisco 802.11b接入点（AP），以覆盖大部分校园。从那时起，为了增加覆盖范围和覆盖新的建筑，添加了AP，目前有566个AP。校园的紧凑结构意味着内部AP的信号范围延伸到覆盖大部分校园的户外区域。所有AP共享相同的SSID，允许无线客户端在AP之间无缝漫游。另一方面，建筑物的AP连接到建筑物现有的子网。具有无线覆盖的188座建筑物跨越115个子网，因此在不同建筑物之间漫游的客户端可能被迫获取新的IP地址。客户端使用DHCP获取IP地址（在不同时间点的跟踪中，租约时间为6或12小时）。数据收集方法：我们使用了三种技术：syslog事件、SNMP轮询和网络嗅探器（tcpdump）。我们还从syslog数据中导出了移动历史数据。数据净化：所有数据都已净化以保护我们用户的隐私。我们已重新净化数据（2004年11月8日），以确保所有跟踪中MAC地址映射的一致性和IP地址映射的一致性。换句话说，净化的IP地址111.222.333.444将对应于所有跟踪中相同的原始IP地址。同样，净化的MAC地址aa:bb:cc:dd:ee:ff将始终对应于所有跟踪中相同的原始MAC地址。请注意，这些可能不代表相同的物理设备，因为DHCP、MAC欺骗等可能导致映射。Tracesetdartmouth/campus/syslog带时间戳的、净化的达特茅斯无线网络syslog记录.files: syslog-v3.3.tar.gz, syslog-2005-2006-cisco.tar.gz, syslog-2005-2006-aruba.tar.gz, syslog-2005-2006-merged.tar.gz描述：该跟踪集是对接入点产生的syslog记录的近乎连续记录，时间从2001年4月11日到2004年6月30日，以及从2005年9月1日到2006年10月4日。每个日志记录都添加了UNIX时间戳，并对MAC地址和AP名称进行了净化。测量目的：使用特征描述，用户移动性特征描述。方法：我们配置接入点在客户端卡与接入点关联或解除关联时发送syslog消息（我们针对Cisco AP和Aruba AP进行了不同的配置。有关更多详细信息，请参阅dartmouth/campus/syslog/01_04和dartmouth/campus/syslog/05_06跟踪）。达特茅斯目前没有与网络关联的认证，因此我们不知道用户的身份，并且用户分配的IP地址在不同时间和不同建筑物中有所不同。最后修改时间：2007年2月8日数据名称：dartmouth/campus/syslog版本：20070208变更：已添加新的syslog跟踪（从2005年9月2日到2006年10月4日收集）。发布日期：2007年2月8日日期/时间测量开始：2001年4月11日日期/时间测量结束：2006年10月4日数据缺口：我们没有发布从2004年7月1日到2005年8月31日收集的syslog跟踪。dartmouth/campus/syslog Traces01_04：带时间戳的、净化的达特茅斯无线网络syslog记录.format：时间戳、AP名称、卡片的MAC地址和消息类型描述：对接入点产生的syslog记录的近乎连续记录的跟踪，时间从2001年4月11日到2004年6月30日。每个日志记录都添加了UNIX时间戳，并对MAC地址和AP名称进行了净化。最后修改时间：2007年1月31日数据名称：dartmouth/campus/syslog/01_04版本：20041218变更：syslog跟踪是新建的。发布日期：2004年12月18日日期/时间测量开始：2001年4月11日日期/时间测量结束：2004年6月30日文件：syslog-v3.3.tar.gz数据缺口：我们只在2001年秋季有这些缺口列表。我们遇到了“空间缺口”，因为许多AP没有发送syslog。[配置错误。]我们还遇到了“时间缺口”，因为我们的syslog记录服务器失败了。您可以参阅注释以获取详细信息。似乎工程学院的AP（建筑名称“cummings”）在2002年初安装了防火墙后直到我注意到问题并要求他们晚些时候在防火墙中打开一个洞之前都没有发送任何消息。我们没有发布从2004年7月1日到2005年8月31日收集的syslog跟踪。限制：由于syslog消息是以UDP消息的形式从AP发送到中继服务器（ns1），然后从中继服务器发送到我们的syslog记录服务器，因此在传输过程中可能会丢失或顺序错乱。时间戳由我们主机的syslog守护进程应用，因此时间戳是单调递增的。但是，事件可能记录顺序不当，并且可能丢失一些事件。我们认为这种影响足够小，可以忽略不计。我们有两个syslog记录服务器，并且我们没有在两个服务器上看到具有不同时间戳的相同事件。从2003年10月19日起，这种情况不再适用。净化：每个MAC地址都已净化，并且已删除客户端机器的IP地址或主机名。为了净化MAC地址，我们随机化了底部六个十六进制数字。我们从所有的syslog、SNMP和tcpdump跟踪中收集了每个MAC地址，并建立了一个巨大的表格，将真实的MAC地址映射到随机化的MAC地址，确保所有映射都是唯一的。每个接入点名称都已通过以下形式进行掩盖：AcadBldg10AP3，其中此表示第十座学术类型建筑中的第三个AP。建筑类型是Adm（行政）、Ath（运动）、Lib（图书馆）、Oth（其他 - 主要为sysadmin测试AP）、Res（住宅）和Soc（社交）。请参阅注释以获取详细信息。05_06：带时间戳的、净化的达特茅斯无线网络syslog记录。配置：[Cisco AP] 我们配置Cisco接入点在客户端卡与接入点进行身份验证、关联、重新关联、解除关联或取消认证时发送syslog消息。每条消息都包含AP名称、卡的MAC地址和消息类型。[Aruba AP] 在我们的校园中，我们部署了Aruba无线网络，使用Aruba 5000交换机作为主交换机，以集中方式控制无线网络。配置具有三级层次结构（主交换机-AP），因此多个交换机连接到主交换机，同样，多个AP连接到每个交换机。我们有三款Aruba AP型号：52、61和72。无线网络在虚拟上划分为几个区域（子网），每个区域都有一个控制器来控制一组AP。Aruba syslog消息来自主交换机（中央控制器）或每个区域控制器。由于不同的区域覆盖不同的AP集合，因此来自每个区域控制器的syslog消息是分开的。Aruba系统能够为每个AP配置多个ESSID。在收集这些syslog数据时，我们使用了四个ESSID - “Kiewit Wireless”、“Kiewit Video”、“Kiewit Voice”和“Hanover Inn”。在这些ESSID中，“Kiewit Video/Voice”进行NAT，并使用私有（RFC1918）地址。我们没有在Aruba syslog跟踪中找到L2关联/解除关联/身份验证/取消认证消息，因为Aruba交换机没有提供这些消息。我们有什么是“station up”和“station down”消息，这表明交换机看到客户端与BSSID连接。尽管我们不知道这些station up|down消息在802.11 FSM中的对应关系是什么，但对于大多数分析来说，应该可以将这些消息与Cisco syslog中的关联|解除关联消息大致相关联。格式：目录和文件此跟踪由三个tar包（目录）组成：“syslog-2005-2006-cisco”、“syslog-2005-2006-aruba”和“syslog-2005-2006-merged”。“syslog-2005-2006-cisco”和“syslog-2005-2006-aruba”目录包含来自Cisco AP和Aruba AP的syslog记录，分别。“syslog-2005-2006-merged”目录包含来自“cisco”和“aruba”syslog记录的合并记录，按时间戳排序。每个目录包含测量期间每天的syslog跟踪文件。文件名遵循以下格式：YYMMDD.HHMMSS.{syslog或aruba或merged}。用于文件名的时间是在UTC。对于Aruba syslog跟踪，我们使用位置ID表示每个接入点名称（格式为[building_id.floor_id.ap_id]，例如15.1.1）。在跟踪根目录下，我们提供了一个名为“aruba_locid_table.csv”的文件，其中包含位置ID和净化的AP名称之间的映射（例如，一对15.1.1和AcadBldg10AP3）。格式：Cisco syslog记录的格式如下：unix_timestamp timestamp1 AP_name1 timestamp2 counter AP_name2 timestamp2 syslog_message unix_timestamp：UTC中的UNIX时间戳timestamp1：syslog消息被接收的时间AP_name1：（净化的）发送syslog消息的主机名counter：内部计数器AP_name2：（净化的）AP认为的（净化的）主机名。有时AP_name1和AP_name2不匹配。timestamp2：AP的时钟。有时timestamp1和timestamp2不匹配。syslog_message：syslog消息内容以下是在Cisco IOS syslog跟踪中的一个示例行：1157014202 Aug 31 04:50:02 AcadBldg33AP1 14375: AcadBldg33AP1 Aug 31 08:50:01: %DOT11-6-ASSOC: Interface Dot11Radio0, Station 0016cbf7ca65 Associated KEY_MGMT[NONE] Aruba syslog记录的格式如下：unix_timestamp timestamp ip_address1 year [ip_address2] syslog_message unix_timestamp：UTC中的UNIX时间戳timestamp，year：syslog消息被接收的时间ip_address1：（净化的）控制器的IP地址ip_address2：（净化的）发送此消息的另一个控制器的IP地址。有时消息不是直接从控制器发送的，而是从树中更低的控制器发送的。syslog_message：syslog消息内容以下是在Aruba syslog跟踪中的一个示例行：1159954944 Oct 4 05:42:24 50.32.208.194 2006 [50.32.208.195] authmgr[510]: station down bssid 00:0b:86:d3:ab:80, essid Kiewit Voice, vlan 2242, ingress 0x1168 (tunnel 264), u_encr 1, m_encr 1, loc 15.1.1 slotport 0xfc7此消息表示连接到AP的用户已从用户表中删除。之前他连接到VLAN 2242，位置为15.1.1。断开连接的原因可能是以下之一：- 用户离开了网络- 用户从网络注销描述：从2005年9月1日到2006年10月4日产生的syslog记录的近乎连续记录的跟踪。每个日志记录都添加了UNIX时间戳，并对MAC地址和AP名称进行了净化。最后修改时间：2007年2月8日数据名称：dartmouth/campus/syslog/05_06版本：20070208变更：此2005-2006 syslog跟踪是新创建的。发布日期：2007年2月8日日期/时间测量开始：2005年9月1日日期/时间测量结束：2006年10月4日净化：每个MAC地址都已通过随机化底部六个十六进制数字进行净化，并且我们使用前缀保留的净化器映射所有IP地址。[Cisco syslog] 每个接入点名称都已通过以下形式进行掩盖：AcadBldg10AP3，其中此表示第十座学术类型建筑中的第三个AP。建筑类型是Adm（行政）、Ath（运动）、Lib（图书馆）、Oth（其他 - 主要为sysadmin测试AP）、Res（住宅）和Soc（社交）。[Aruba syslog] 每个接入点名称表示为位置ID（格式为[building_id.floor_id.ap_id]，例如15.1.1）。我们还提供了一个名为“aruba_locid_table.csv”的文件，其中包含位置ID和净化的AP名称之间的映射（例如，一对15.1.1和AcadBldg10AP3）。dartmouth/campus/snmp达特茅斯学院SNMP轮询记录.files：fall01.tar.gz，spring02.tar.gz，fall03.tar.gz描述：在秋季学期2001年、春季学期2002年、秋季学期2003年和冬季学期2004年的每个五分钟对每个AP进行轮询的跟踪集。2001年秋季的数据用于[MobiCom 2002论文]。2003/4的数据用于[MobiCom 2004论文]。我们建议仅使用2003/4的数据。请参阅有关2001/2002 SNMP数据集问题的这个重要注释。有关2001/2数据的任何问题都将进入我们的LBE（低于最佳努力）队列，即它们可能不会得到回答...请改用2003/4的数据。测量目的：使用特征描述。方法：我们使用简单网络管理协议（SNMP）每五分钟轮询每个AP一次，查询AP和客户端特定计数器。AP特定变量包括入站/出站字节、数据包和错误，以及与给定AP关联的客户端。客户端特定变量包括MAC地址、信号强度和质量。数据净化：为了净化数据，我们将MAC地址字段随机（但一致）映射到随机选择的相同供应商的MAC地址，并使用前缀保留的净化器映射所有IP地址。最后修改时间：2008年9月12日数据名称：dartmouth/campus/snmp版本：20041109变更：SNMP跟踪集已重新净化。发布日期：2004年11月9日日期/时间测量开始：2001年9月14日日期/时间测量结束：2004年2月28日限制：我们没有区分没有客户端的时期与AP关闭或不可达的时期的方法。我们也没有检测AP重启或重置的方法，这重置了这里报告的每个客户端的计数器。因此，在解释每个客户端的字节计数时必须非常小心...计数器可以在两次轮询之间重置或回滚，并且因此增量可能看起来是负数（或在无符号数学中，是一个非常大的数字）。数据缺口：数据收集过程中出现了不幸的缺口，通常由断电引起。错误：在2001/2数据中，执行SNMP查询的perl脚本出现了一些问题，即它们查询了不适用的SNMP值，或误解了其他值的含义。这些数据也用于随后的分析。相同的脚本用于收集另一个无线网络的后续研究数据。请参阅http://www.cs.dartmouth.edu/reports/abstracts/TR2003-480/。fall01：秋季学期2001年的SNMP轮询记录。配置：对所有接入点进行轮询的工作被分配给了两台机器：agentnews和klebb。每台主机都有一个目录。每个目录中都有一个子目录，每个子目录对应于一天，在每天中，都有一个子目录包含该机器在该日期轮询的每个接入点的SNMP日志文件。格式：有两种类型的文件。第一种类型的文件为每个接入点有一个文件。每个文件提供了每个轮询中每个接口的信息。大多数接口都是无关紧要的；你只关心无线接口（具有ifSpeed=11000000的接口）。以下是一个示例：V1.0ap时间戳，ap，ifIndex，ifInOctets，ifOutOctets，ifSpeed，ifInErrors，ifOutErrors请注意文件格式版本和以下行中使用的MIB变量名称的周期性重申。第二种类型的文件为每个AP和每个日期发生一次。文件名传达了掩盖的AP名称，例如AcadBldg10AP3，这表示第十座学术类型建筑中的第三个AP。建筑类型是Adm（行政）、Ath（运动）、Lib（图书馆）、Oth（其他 - 主要为sysadmin测试AP）、Res（住宅）和Soc（社交）。每个数据文件包含该日期该接入点的所有数据。以下是一个文件的示例顶部。前两行是文档；第一行指示文件格式版本（始终为V1.0）。第二行标识后续数据行中每个数据行的列标题。在时间戳（标准Unix时间）之后，其余字段是AWC MIB（Aironet Wireless Communications是我们接入点开发商的名称；Aironet后来被思科收购，然后以自己的品牌出售AP）的MIB变量。V1.0时间戳，awcTpFdbAddress，awcTpFdbClassID，awcTpFdbSrcOctetsImmed，awcTpFdbDestOctetsImmed，awcTpFdbIPv4Addr，awcTpFdbDdpProdDevID，awcTpFdbDdpRadioDevID，awcDot11TpFdbAID，awcDot11TpFdbTxShortRetries，awcDot11TpFdbLatestRxSignalQuality，awcDot11TpFdbCapabilities 1001908847，003065d1eb95，clientStation，1276264，1986728，000.000.000.000，-15，unknown，state2，73，73 1001909056，003065d1eb95，clientStation，1276264，1986728，000.000.000.000，generic80211Client，unknown，state2，73，73 1001909266，003065d1eb95，clientStation，1276264，1986728，000.000.000.000，broadcast，-16，state2，73，73 1001909476