download the syslog-v3.3.tar.gz file

from a CRAWDAD mirror:  US UK AU
size="1.1 GB" type="tar.gz"

last modified

2007-01-31

reason for most recent change

Syslog trace is newly created.

short description

Timestamped, sanitized syslog records from Dartmouth wireless network.

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.

derived

false

release date

2004-12-18

date/time of measurement start

2001-04-11

date/time of measurement end

2004-06-30

format of trace data

timestamp, AP name, the MAC address of the card, and type of message

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.

disruptions to data collection

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.

download the syslog-2005-2006-cisco.tar.gz file

from a CRAWDAD mirror:  US UK AU
size="32.2 MB" type="tar.gz"

download the syslog-2005-2006-aruba.tar.gz file

from a CRAWDAD mirror:  US UK AU
size="439.2 MB" type="tar.gz"

download the syslog-2005-2006-merged.tar.gz file

from a CRAWDAD mirror:  US UK AU
size="488.7 MB" type="tar.gz"

last modified

2007-02-08

reason for most recent change

This 2005-2006 syslog trace is newly created.

short description

Timestamped, sanitized syslog records from Dartmouth wireless network for the period 2005 - 2006.

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.

derived

false

release date

2007-02-08

date/time of measurement start

2005-09-01

date/time of measurement end

2006-10-04

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.

sanitization

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).

format of trace data

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]: <INFO> station down <00:15:f9:9e:71:25> 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.

download the aplocations_meter.csv file

from a CRAWDAD mirror:  US UK AU
size="20KB" type="csv" md5="e3a57fc4e69f7bb8d352c156778d9280"

last modified

2009-09-09

reason for most recent change

AP locations as of the end of 2008, have been added.

short description

A list of most of the APs on campus and their locations.

description

A comma-separated list of most of the APs on campus and their locations as of the end of 2008, as defined in (x,y) coordinates in meter.

derived

true

release date

2009-09-09

format of trace data

AP name (location id), x coordinate (meter), y coordinate (meter) where
AP name is represented as location id 
(with the format [building_id.floor_id.ap_id] like 15.1.1), 
in the same way as the dartmouth/campus/syslog/05_06 trace 
represents the AP names. 

configuration

aplocations_meter.csv: This file contains the locations of Aruba APs on campus as of the end of 2008. To protect the real locations of the APs, we converted the locations into meter coodinates relative to an arbitrary location on campus. AP names are represented as location id (with the format [building_id.floor_id.ap_id] like 15.1.1), in the same way as the dartmouth/campus/syslog/05_06 trace represents the AP names. Therefore, we think that users who use the dartmouth/campus/syslog/05_06 trace can easily associate the APs in the trace with their locations. However, please note that since the AP locations are based on the information collected as of the end of 2008, some AP locations may have changed (or may have been removed or added) from the time the dartmouth/campus/syslog/05_06 trace was collected.

When writing a paper that uses CRAWDAD tracesets, we would appreciate it if you could cite both the authors of the traceset and CRAWDAD itself, and identify the exact traceset using the appropriate version number. For this traceset, this citation would look like:

David Kotz, Tristan Henderson, Ilya Abyzov, Jihwang Yeo, CRAWDAD dataset dartmouth/campus (v. 2009‑09‑09), traceset: syslog, downloaded from https://crawdad.org/dartmouth/campus/20090909/syslog, https://doi.org/10.15783/C7F59T, Sep 2009.

• Cite using BibTeX
• Cite using RIS

@misc{dartmouth-campus-20090909,
    author = {David Kotz and Tristan Henderson and Ilya Abyzov and Jihwang Yeo},
    title = {{CRAWDAD} dataset dartmouth/campus (v. 2009-09-09)},
    howpublished = {Downloaded from \url{https://crawdad.org/dartmouth/campus/20090909/syslog}},
    note = {traceset: syslog},
    doi = {10.15783/C7F59T},
    month = sep,
    year = 2009
}

TY  - DATA
TI  - CRAWDAD dataset dartmouth/campus (v. 2009-09-09)
T2  - traceset: syslog
UR  - https://crawdad.org/dartmouth/campus/20090909/syslog
PY  - 2009/09/09/
AU  - David Kotz
AU  - Tristan Henderson
AU  - Ilya Abyzov
AU  - Jihwang Yeo
DO  - 10.15783/C7F59T
ER  -

If you do not use the provided citation formats, please include a reference with the same information, as described in the CRAWDAD FAQ.