Saturday, August 26, 2006

Deciphering 802.11

I'm reading cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 excellent 802.11 Wireless Networks: The Definitive Guide, 2nd Ed by Matcá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365w Gast. Matcá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365w knows 802.11, period. I can't wait to review this book. I wish I had read it sooner.

I've been analyzing network traffic in Wireshark while devouring cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 book. I read that figures like 3-10 (reproduced below -- please consider this free publicity, O'Reilly!) show cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 least significant bit (LSb) first -- at least within a defined field.

Also, although cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 diagrams are LSb first, cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 text uses values that are most siginifcant bit (MSb) first. For example, cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 subtype for a RTS frame is depicted as 1101 in a diagram but 1011 in cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 text and Table 3-1.

This is where I became confused when closely inspecting Wireshark output.

The top of cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 figure shows a generic 802.11 MAC frame. The bottom of cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 figure expands upon cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 Frame Control field. With cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 FC field, notice cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 bits are numbered 0 to 15, with 0 at cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 far left and 15 at cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 far right of cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 diagram.



So what does this look like on cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 wire? Here is Tshark's rendition of cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 important parts.

orr:/home/richard$ tshark -n -V -x -r sample_wireless.lpc
Frame 1 (97 bytes on wire, 97 bytes captured)
Arrival Time: Apr 5, 2006 20:27:06.651549000
Time delta from previous packet: 0.000000000 seconds
Time since reference or first frame: 0.000000000 seconds
Frame Number: 1
Packet Length: 97 bytes
Capture Length: 97 bytes
Frame is marked: False
Protocols in frame: wlan
IEEE 802.11
Type/Subtype: Probe Response (5)
Frame Control: 0x0850 (Normal)
Version: 0
Type: Management frame (0)
Subtype: 5
Flags: 0x8
DS status: Not leaving DS or network is operating in AD-HOC mode
(To DS: 0 From DS: 0) (0x00)
.... .0.. = More Fragments: This is cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 last fragment
.... 1... = Retry: Frame is being retransmitted
...0 .... = PWR MGT: STA will stay up
..0. .... = More Data: No data buffered
.0.. .... = Protected flag: Data is not protected
0... .... = Order flag: Not strictly ordered
Duration: 314
Destination address: 00:20:a6:4c:3b:87 (00:20:a6:4c:3b:87)
Source address: 00:0f:f8:58:40:cb (00:0f:f8:58:40:cb)
BSS Id: 00:0f:f8:58:40:cb (00:0f:f8:58:40:cb)
Fragment number: 0
Sequence number: 367
...edited...

0000 50 08 3a 01 00 20 a6 4c 3b 87 00 0f f8 58 40 cb P.:.. .L;....X@.
0010 00 0f f8 58 40 cb f0 16 0d ab 9f 1e 2e 00 00 00 ...X@...........
0020 64 00 01 00 00 0b 00 00 00 00 00 00 00 00 00 00 d...............
0030 00 01 04 82 84 8b 96 03 01 0b dd 06 00 40 96 01 .............@..
0040 01 00 dd 05 00 40 96 03 02 dd 16 00 40 96 04 00 .....@......@...
0050 03 06 a5 00 00 22 a5 00 00 41 54 00 00 61 43 00 ....."...AT..aC.
0060 00 .

If you don't like reading text, here is a jpg or cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 packet itself.

In any case, you'll see this represents cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 Frame Control field.

Frame Control: 0x0850 (Normal)

If you look at cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 hex output above, however you see this:

0000 50 08 3a 01 00 20 a6 4c 3b 87 00 0f f8 58 40 cb P.:.. .L;....X@.

The 0x5008 is represented as 0x0850 by Tshark/Wireshark/whatever. Why not 0x5008? Is it because Frame Control is 16 bits?

At this point it would be nice for someone to respond and say "That's because..." I'm guessing that although traffic is sent in network byte order, cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 positioning of those bytes may be interpreted differently when two bytes are needed to represent an entire field. (Frame Control is 16 bits or 2 bytes.)

Thus far cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 only relevant line I've read is on p. 78:

The most significant bits in cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 802.11 specification come at cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 end of fields.

Can anyone comment? Sorry if this is a dumb question -- I've been working with this chapter for a few hours, and even Matcá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365w warns people not to read it unless cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365y really need to understand 802.11 internals.

By cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 way, cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 following filter has been helpful to ignore Probe Requests, Probe Responses, and Beacons while inspecting wireless traffic.

!(wlan.fc.type == 0 and wlan.fc.subtype == 4) and !(wlan.fc.type == 0 and wlan.fc.subtype == 5) and !(wlan.fc.type == 0 and wlan.fc.subtype == 8)

I'm also using cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 following dumb for loop to look for traces with specific type and subtypes set, so I can see real traffic.

$ for i in `ls *.dump`; do echo $i && tshark -n -r $i -R "wlan.fc.type == 1 and wlan.fc.subtype == 10"; done

The -R feature lets you pass a Wireshark display filter as if it were a capture filter or BPF.

3 comments:

Anonymous said...

Careful not to get confused between most significant bit first and most significant byte first. Big- vs. little-endian is generally referring to byte order, racá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365r than bit order. e.g. if you have cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 integer 16909060 (1 * 2^24 + 2 * 2^16 + 3 * 2^8 + 4), big-endian MSb (SPARC) would be 0x01020304, little-endian MSb (Intel) would be 0x04030201. In both cases, cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 bit order within cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 byte is cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 same. However, in big-endian LSb it would be 0x8040c020.

In cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 case of what you're looking at, I'd guess tshark was running on an Intel box and just read cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 value as a short int and printed it (as 0x0850) before parsing it. When it parsed it, it handled cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 octets in cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 correct order - cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 0x08 was parsed as cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 high (flags) octet. In MSb, it is 00001000, and cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 flags in cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 text dump shows reset (fourth from cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 left in LSb, fourth from cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 right in MSb) as set. Interestingly, cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 subtype shows a value of 5 - which is cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 MSb value of cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 subtype (cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 four high-order bits in cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 low-order octet). So if I've understood correctly, tshark is correctly pulling out cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 correct four bits for cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 subtype, but not reversing cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365m before printing... which is definately confusing. I'd also question whecá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365r it's properly mapping cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 subtype; if probe response is actually int 5, cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365n this wouldn't be a probe response, it's int 10. However, if probe response is 'bits 4 and 6 according to cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 diagram being set', cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365n it is a probe response, and tshark should probably print out cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 value as 10. Well, most importantly, it should show what cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 standard specifies, so if cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 standard says 'a probe response is 1010', it should print 1010; if cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 standard says 'a probe response is 0xa', it should print 0xa.

Thanks Richard, now my head hurts. ;-)

Anonymous said...

It is not a mistake.

That is because, 802.11 is little-endian , while general networking - TCP/IP-802.3 etc., are all big-endian

rOadbill said...

Remote Monitoring & Networking 2006 -- SCADA, Data Acquisition, Device Networking, M2M and Security for Remote Sites and Onsite Power -- Offgrid, Standby and Back-up Power for Mission Critical Operations will be held November 9-10, 2006 Long Beach, California at cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 The Westin Long Beach.

These technology-driven and solution oriented conferences bring togecá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365r cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 innovators and users from multiple industries, including utilities, power, oil & gas, telecom, industrial, water & public utilities, agriculture and facilities management.

Remote Monitoring & Networking 2006 will focus on cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 leading advancements for cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 monitoring and management of distributed equipment and facilities, remote assets, automated process & system controls and device networks. Large-scale users and industry experts will speak on SCADA, security, control, automation, M2M, networking, telemetry and condition monitoring.

Onsite Power 2006 will cover cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 latest advancements in back-up, UPS, emergency and standby power systems, and design strategies for monitoring & controlling distributed, remote and mission-critical equipment and facilities. MORE INFO AT:

http://www.remotemagazine.com/rem_conf_index.htm