Notes on how to sniff device: ipw2200 To enable monitor mode: iwconfig eth1 mode Monitor to return to normal: iwconfig eth1 mode Managed To set the channel: iwconfig eth1 channel 3 iwconfig eth1 channel auto To see all packets: tcpdump -i eth1 -s 0 -e -vv -XX -e: print link-level headers -vv: verbose description of them -XX: body in hex/ascii to save to a file: tcpdump -i eth1 -s 0 -w file.dump dlink: set to channel 6 BSSID : 00:1B:11:4E:AA:C7 linksys200: BSSID : 00:16:B6:F2:19:2C, ESSID: cobhill1 linksys54: BSSID: 00:21:29:D1:24:40 (bluebird) laptop5: 00:16:CF:3E:B7:14 (wireless) 00:15:C5:6B:42:88 (ethernet) gram: 00:0D:87:4F:D1:B4 (ethernet) ================================================ To filter out the beacons: tcpdump -i eth1 -s 0 -vv -XX link[0] != 0x80 DOES NOT WORK for live captures! (though it does work for tcpdump replays) But this works: tcpdump -i eth1 -s 0 -e -vv -XX link[25] != 0x80 To get just the data packets: link[0] = 0x08 (tcpdump replay only) to sniff to a file: tcpdump -i eth1 -s 0 -w dump.out; iwconfig eth1 mode ... tcpdump -i eth1 -L: Data link types (use option -y to set): IEEE802_11_RADIO (802.11 plus BSD radio information header) Alas! I have no way of disabling the radio information header! Sample packet, as sniffed: 20:06:12.538532 00:00:00:00:00:00 (oui Ethernet) > 00:00:19:00:6f:08 (oui Unknown), 802.3, length 113: LLC, dsap Null (0x00) Individual, ssap Null (0x00) Command, ctrl 0x0200: Information, send seq 0, rcv seq 1, Flags [Command], length 99 0x0000: 0000 1900 6f08 0000 0000 0000 0000 0000 ....o........... 0x0010: 0002 6c09 a000 e000 0180 0000 00ff ffff ff ffff.. is DA, 4 bytes in! ^^ 0x0020: ffff ff00 16b6 f219 2c00 16b6 f219 2cf0 00 16b6... is SA: AP addr 0x0030: cda1 d996 9e58 0100 0064 0001 0400 0863 .....X...d.....c<-38 bytes in ^^ 0x0040: 6f62 6869 6c6c 3101 0482 848b 9603 0101 obhill1......... 0x0050: 0504 0001 0000 2a01 0032 088c 1298 24b0 ......*..2....$. 0x0060: 4860 6cdd 0c00 0af5 0a02 02c0 0003 0103 H`l............. 0x0070: 05 . From this we see that it's really byte 25 (link[25] that is "80", the beacon mark MAC header starts with the 80 above and ends with the cd in line 30 Beacon frame body: Timestamp: 8 bytes Beacon interval: 2 bytes Capability: 2 bytes SSID is "cobhill1" here, but is prefixed by a 0 byte and a length (0x08) byte. So the SSID offset is 12 bytes into the packet body, not 14. ================================================ Packet header format: IEE 7.1.2, AbsPg 49 Data frames: 2 bytes frame control (below) 2 bytes duration/id 6 bytes address 1 6 bytes address 2 6 bytes address 3 2 bytes sequence control 6 bytes address 4 0-2312 data 4 bytes FCS Control frames (RTS, CTS, ACK, PS-Poll, 2 bytes frame control 2 bytes duration 6 bytes Receiver (Dest) Addr 6 bytes Transmitter Addr 4 bytes FCS Management frames (beacon, assoc req/resp, disassoc, reassoc req/resp, probe req/resp, auth 2 bytes frame control (below) 2 bytes duration/id 6 bytes Receiver (Dest) Addr 6 bytes Transmitter (Source) Addr 6 bytes BSSID, = transmitter addr for AP 2 bytes sequence control 0-2312 data 4 bytes FCS ================================================ Frame-Control field analysis: IEEE, 7.1.3 bits (note IEEE lists them in "reverse" order!!!) 0 proto version: = 00 1 " cntl data mgmt 2 type: control=01/data=10/mgmt=00/reserved=11 1 0 0 3 " b3,b2 0 1 0 4 subtype: 4 bits beacon=1000 (8), AssocReq=0000 (0), AssocResp=0001(1) 5 " ReassocReq=0010(2), ReassocResp=0011(3) 6 " ProbeReq=0100(4), resp=0101(5) 7 " Disassoc=1010(A), Auth=1011(B), DeAuth=1100(C) bit order is backwards: b7 b6 b5 b4 8 To DS 9 From DS 10 More Frag 11 Retry 12 Pwr Mgt 13 More Data 14 WEP 15 Order Beacon: 1st byte is 80, 1000 0000 7654 3210 from bit 7 to bit 0; 2nd byte is bit 15 to bit 8 beacon: bits 7-4 are 1000, in that order ================== 1st byte = 08: 0000 1000 7654 3210 this is subtype=0000, type=data! 2nd byte: 02 0000 0010 5432 1098 FromDS bit is set: frame exits the DS in this case, that means it's from the LAN [?] 3rd addr is 00:0d:87:4f:d1:b4, a winbox [sigh] on my net ==================== bluebird_conn.text: look at connecting to bluebird access point, under windoze This is my first tcpdump file. I've manually removed most, but not all, of the beacons. Note that there are both bluebird (a linksys router that happens to be blue) and dlink beacons. 40 00 line 59 in bluebird_conn.text: 0100 0000 bit 6 is set. mgmt frame, subtype=0100: ProbeReq 7654 3210 bcast/laptop5/bcast line 65: 50 00 line 65 mgmt frame, nybble 5 == ProbeResp, laptop5/ap/ap line 73: 40 00 line 73: dup probe request line 79: 50 00 probeResp line 87: ditto line 95: 50 08 ProbeResp, RETRY, laptop5/ap/ap line 103: ditto ditto: 111, 119, 127, 135, 143: beacon 151: probe response from dlink. ???? dlink is on channel 6 and we're on channel 11 (note radio header info) Note source addr 00 1b11 4eaa c7 168: bcast ProbeReq 199: 08 02! Arp who-has; a data packet bcast/ap/gram/aa:aa:03:00:00:00 followed by 08 06: ARP code 301,309,317, ... ProbeResponses sent very close together 431: b0 00 Authentication! ap/laptop5/ap 10110000 76543210 437: Authentication laptop/ap/ap 442: 0000: Assoc request, ap/laptop/ap 450: 10 00 Assoc response: Success 457: gram windoze noise 482: laptop5 591: gram (00 0d87 4fd1 b4) 640: bluebird beacon, dlink beacon (longer!), bluebird beacon 757: Arp answer laptop5/ap/00:60:08:b0:e5:f3/aa:aa:03:00:00:01 ^^^^^^^^^^^^^^^^^asgard (arp server) 793: duplicate, ~ 600 µs later ===================================================== file bluebird2.text: goal is to illustrate connections However, we start with a couple odd frame controls: 1 48 01 0100 1000 7654 3210 The 8 means data, but for mgmt frames the 4 means "probe request" but for data it means "null function (no data)" 6 48 09 11 08 01 TCP syn 19 d4 00 IEEE ACK 1101 0100 4 means "cntl", 1101 means ACK (IEEE AbsPage 51) 7654 3210 ===================================================== thursday.text: random scan from my office. Line 1157 1923 2025 2132 4036 sing_Services 329166 Peter =====================================================