Thursday, April 14, 2005

Wireless Traffic Snippets

In my USENIX talk I show how to collect wireless traffic using Tcpdump. In my slides I use a verbose method that only shows a few packets. In the following I'd like to show a variety of traffic available using Tcpdump.

First I tell my wireless card to go into monitor mode and watch channel 1. Then I ask Tcpdump to show me the media types it understands.

orr:/root# ifconfig wi0 mediaopt monitor channel 1 up
orr:/root# tcpdump -i wi0 -L
Data link types (use option -y to set):
EN10MB (Ethernet)
IEEE802_11 (802.11)
IEEE802_11_RADIO (802.11 plus BSD radio information header)

Now that I see the media types, I select the second option and begin capturing traffic.

orr:/root# tcpdump -n -i wi0 -y IEEE802_11
tcpdump: data link type IEEE802_11
tcpdump: WARNING: wi0: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on wi0, link-type IEEE802_11 (802.11), capture size 96 bytes

First we see a beacon with the conference wireless access point SSID. Next is one of many clear-to-send packets.

00:21:19.586724 Beacon (usenix) [1.0* 2.0 5.5 6.0 9.0 11.0 12.0 18.0 Mbit] ESS CH: 1
00:21:19.587160 Clear-To-Send RA:00:0f:34:42:b7:20
...truncated...

Here's more CTSs and a NetBIOS port 137 UDP query.

00:21:19.915245 Clear-To-Send RA:00:0d:54:9c:5c:0b
00:21:19.926293 IP 131.106.56.95.137 > 172.30.0.255.137: NBT UDP PACKET(137):
QUERY; REQUEST; BROADCAST
00:21:19.938333 Clear-To-Send RA:00:0f:34:42:b7:20
...truncated...

We see our first 802.11 acknowledgement.

00:21:20.273184 Clear-To-Send RA:00:0f:34:42:b7:20
00:21:20.277588 Acknowledgment RA:00:90:4b:ae:8e:43
00:21:20.279822 Clear-To-Send RA:00:0f:34:42:b7:20
...truncated...

Here's our first request to send.

00:21:20.710353 Clear-To-Send RA:00:0d:54:9c:5c:0b
00:21:20.711677 Request-To-Send TA:00:0d:54:9c:5c:0b
00:21:20.712081 Clear-To-Send RA:00:0d:54:9c:5c:0b
...truncated...

I don't know what the LLC packet means, but it's quickly followed by a probe request and response.

00:21:20.858267 Clear-To-Send RA:00:0f:34:42:b7:20
00:21:20.859258 [|llc](LLC 000d)
00:21:20.859604 Acknowledgment RA:00:0d:54:9c:5c:0b
00:21:20.860719 Probe Request () [1.0 2.0 5.5 11.0 Mbit]
00:21:20.862199 Probe Response (usenix) [1.0* 2.0 5.5 6.0 9.0 11.0 12.0 18.0 Mbit] CH: 1
00:21:20.862469 Acknowledgment RA:00:0f:34:42:b7:20
00:21:20.863118 Clear-To-Send RA:00:0f:34:42:b7:20
...truncated...

We don't only see broadcast traffic. Here's a couple TCP packets:

00:21:26.612946 Clear-To-Send RA:00:0d:93:ec:5f:ba
00:21:26.619326 IP 216.239.57.105.80 > 131.106.58.64.1614:
F 126736513:126736513(0) ack 2074693501 win 8190
00:21:26.620840 IP 216.239.57.105.80 > 131.106.58.64.1614:
F 0:0(0) ack 1 win 8190
...truncated...

Here's an ARP request.

00:21:30.564116 Clear-To-Send RA:00:0f:34:42:b7:20
00:21:30.566783 arp who-has 131.106.56.11 tell 131.106.56.32
00:21:30.567184 Clear-To-Send RA:00:0f:34:42:b7:20
...truncated...

Last, here's a DHCP request.

00:21:32.238510 Clear-To-Send RA:00:90:96:a6:6a:70
00:21:32.252827 IP 131.106.56.64.68 > 255.255.255.255.67:
BOOTP/DHCP, Request from 00:90:96:ab:c6:10, length: 300
00:21:32.254038 Acknowledgment RA:00:90:4b:ae:8e:43
00:21:32.275796 Clear-To-Send RA:00:0f:34:42:b7:20

That was the IEEE802_11 media option. Unfortunately, the IEEE802_11_RADIO option does not seem to produce anything useful.

orr:/root# tcpdump -n -i wi0 -y IEEE802_11_RADIO
tcpdump: data link type IEEE802_11_RADIO
tcpdump: WARNING: wi0: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on wi0, link-type IEEE802_11_RADIO
(802.11 plus BSD radio information header), capture size 96 bytes
00:26:12.788071 [|802.11]
00:26:12.788915 [|802.11]
00:26:12.789331 [|802.11]
...truncated...

This is nothing special, but it does show what you can capture using Tcpdump while not being associated with a wireless network.

3 comments:

Andrew Lockhart said...

I'm not sure if this will help under *BSD, but you might be able to get some more info out of the tcpdump output when using IEEE802_11_RADIO by setting the snaplen to 0.

Here's an example from Linux with an Atheros card with Prism headers:

/usr/sbin/tcpdump -n -i ath0
tcpdump: WARNING: ath0: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ath0, link-type PRISM_HEADER (802.11 plus Prism header), capture size 96 bytes
23:21:24.843499 [|802.11]
23:21:24.852295 [|802.11]
23:21:24.872980 [|802.11]

Now with snaplen set to 0:

/usr/sbin/tcpdump -n -i ath0 -s 0
tcpdump: WARNING: ath0: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ath0, link-type PRISM_HEADER (802.11 plus Prism header), capture size 65535 bytes
23:25:06.252051 Beacon (linksys) [1.0* 2.0* 5.5* 11.0* 18.0 24.0 36.0 54.0 Mbit] ESS CH: 6
23:25:06.254008 Beacon (linksys) [1.0* 2.0* 5.5* 11.0* Mbit] ESS CH: 6, PRIVACY
23:25:06.265268 Beacon (linksys) [1.0* 2.0* 5.5* 11.0* 18.0 24.0 36.0 54.0 Mbit] ESS CH: 6

--Andrew

Richard Bejtlich said...

Hi Andrew, thanks for the tip. Unfortunately no luck here:

tcpdump -n -i wi0 -s 0 -y IEEE802_11_RADIO -vv
tcpdump: data link type IEEE802_11_RADIO
tcpdump: WARNING: wi0: no IPv4 address assigned
tcpdump: listening on wi0, link-type IEEE802_11_RADIO (802.11 plus BSD radio information header), capture size 65535 bytes
11:50:55.091449 [|802.11]
11:50:55.115335 [|802.11]
11:50:59.089959 [|802.11]
11:50:59.365834 [|802.11]
^C
4 packets captured
4 packets received by filter
0 packets dropped by kernel

Bezahaf Mehdi said...

thanks Andrew for me it works using

tcpdump -n -i ath0 -s 0