Comp [34]49 Week 7, Oct 9, LT 412 BCH codes Midterm: Oct 23!! ===================================================================================== Comment on BCH-code requirement that all S(E) are distinct (S(E) = E mod P) Fact: A given P can *correct* all r-bit errors iff it can *detec* all 2r-bit errors S is the result of E mod P Let S1 = S(E1), S2 = S(E2). If S1==S2, then E1 xor E2 mod P = 0 Suppose we want a code to detect all r-bit errors, so E1, E2 have <= r 1-bits. Then E1 xor E2 has <= 2r 1-bits. As long as P is chosen so that as a CRC it detects all 2r-bit errors, it will provide r-bit error correction. Similarly, if P provides r-bit error correction, then any E with 2r errors is not divisible by P, because E can be written as E1 xor E2, where E1 and E2 have <= r 1-bits, and so P detects all 2r-bit errors. Also, note that adding a single parity bit detects ALL 1-bit errors, no matter what the length of the message. However, if we want to detect 2-bit (or more) errors, then the length of the message must be capped. Consider a possible m-bit code, which supposedly can detect all 2-bit errors. Choose k>2^m, and consider all possible Ei, i n output bits, BUT the n output bits depend on the last K blocks of k bits each. Figure 8.9: example with (n,k,K) = (2,1,3) Explain encoder and state diagram how encoding works how decoding works how history (K blocks) works What to do if k>1 Trellis diagram: fig 8.10 input v output path a-b-c-b-d-c-a-a Trellis fig 8.11. Example: data = 1011010 (or 0101101, as it goes into the encoder right to left). 1. Start in state 0, and put in the leading 1 into slot 1: 1000000 => 11 (that is, upper output bit is 1 and lower output bit is 1; upper bit is xor of positions 1,3,4,5,7; lower is xor of 1,2,3,4,5,6) from state 0 on input 11: state 32 2. put in the 0: 0100000 => 01; 32 --01--> 16 3. put in the 1: 1010000 => 00; 16 --00--> 40 4. put in the 1: 1101000 => 01; 40 --01--> 52 5. put in the 0: 0110100 => 01; 52 --01--> 26 6. put in the 1: 1011010 => 10; 26 --10--> 45 7. put in the 0: 0101101 => 11; 45 --11--> 22 So far this is just about encoding: 11-01-00-01-01-10-11 states: 0-32-16-40-52-26-45-22. Now use solid/dashed edge coloring to decode: 1 0 1 1 0 1 0 w00T! Viterbi decoding: pick a "window size" b. Take all paths of length b, and for each state list the valid path (or paths) that is CLOSEST to the received input. Example 8.10, based on Stallings Fig 8.12: Input 10-01-01-00-10-11-00 Note that no valid input can begin 10! Step 1: valid paths are 00 and 11; both have distance 1 from 10. Step 2: valid paths are 00 and 11 from state a, and 10 and 01 from state b. No ambiguities; note that the path ending in state d is closest to valid. Step 3: Fig 8.12 shows THREE paths out of state c. The one down to state d is wrong. Note that we now have multiple paths ending at the same state (eg state a); we throw away all but the shortest one(s). For example, to state a we have paths from a and from c; their respective distances are 3 and 4. Step 7: all ACTIVE (bold) paths start out with 11, so we correct to that, and go on. Note that if b=5, then we'd stop at state 5, and we'd still be ambiguous. =============== Next week we'll look at three forms of encoding used by 802.11: FHSS DSSS OFDM All provide a reason to believe that noise bursts will only affect a limited number of the bits in a packet, and so FEC can save the day. ==================================================================================== ==================================================================================== Frame format & Frame types 4 addresses: source & dest : actual MAC addresses transmitter address, receiver address (= SSID) Table 14.4 of Stallings: from IEEE802.11.pdf absolute page 51 = table of packet types IEEE, p 38: There are four address fields in the MAC frame format. These fields are used to indicate the BSSID [AP], source address, destination address, transmitting station address, and receiving station address. The usage of the four address fields in each frame type is indicated by the abbreviations BSSID, DA, SA, RA, and TA, indicating basic service set identifier (BSSID), Destination Address, Source Address, Receiver Address, and Transmitter Address, respectively. Certain frames may not contain some of the address fields. BSSID: usually MAC address of AP DestAddr (DA): ultimate destination SourceAddr (SA) station that initiated the transmission ReceiverAddr (RA) station that is the next receiver in the chain, often = DestAddr TransmitterAddr (TA) Station doing the immmediate sending mesh view: Recv/Trans addrs NOT the same as Dest/Src RTS/CTS/ACK frames: absolute page 57 Latter are 14 bytes = 112 bits. At 11mbit, this is ~10µsec, which is well under one 20µsec slot! Data frames: AbsPage 59 Table 4 shows interpretation of address fields Table from Tutorial (prob also in IEEE standard) showing values of the ToDS, FromDS bits and how Addr1-Addr4 are interpreted ToDS FromDS Address 1 Address 2 Address 3 Address 4 0 0 DA SA BSSID N/A 0 1 DA BSSID SA N/A 1 0 BSSID SA DA N/A 1 1 RA TA DA SA In the first line, the traffic is wireless-to-wireless, and DA and SA are the MAC addresses of the stations. In a base-station configuration, one of these is likely to be the AP, and the BSSID will be the AP (IEEE has a standard pending for station-to-station transmission bypassing the AP, but I've not yet seen it in the field). In an infrastructure network, all three fields can be used. The second case represents a packet from a host on the "wired" part of the LAN, sending to a host on the wireless side. Consider a typical wireless home router: you can plug things in (the wireful side), or connect wirelessly. Broadcast packets from the wireful side will have this form. DA = Mac address of destination station (or b'cast addr) BSSID = Mac address of AP SA = Ethernet address of actual sender out in wireworld. The third case represents a wireless station (SA) sending to a wireful node (with Ethernet address DA); the BSSID is the AP. The fourth case never occurs. Well, it was intended to represent "wireless distribution service", but again I have never seen this in the field. The DS is really your "backbone"; if you make that wireless, then you're really counting on wireless to work, and you're really vulnerable to a DOS attack. ================================================ 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 ====================================================================================== Wireless dumps Do a live dump, first, with and without beacons Mystery of 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.