Differences
This shows you the differences between two versions of the page.
Next revision | Previous revision | ||
soc:2009:oremanj:notes:protocol [2009/05/17 17:57] rwcr created |
soc:2009:oremanj:notes:protocol [2009/05/27 17:05] (current) rwcr PS-Poll clarification |
||
---|---|---|---|
Line 111: | Line 111: | ||
The specific types are detailed below, but the generall association | The specific types are detailed below, but the generall association | ||
process is as such: | process is as such: | ||
- | * At frequent periodic intervals, every AP not configured in "hidden | + | * At frequent periodic intervals, every AP not configured in "hidden SSID" mode (which is against the standard) sends out //beacon// frames with information about its network: its MAC address, ESSID (network name), regulatory information (how much power are we allowed to transmit?), etc. The AP can choose how much information to include in the beacon frame. |
- | SSID" mode (which is against the standard) sends out //beacon// | + | * If we're not satisfied with the information in the beacon we get, we're trying to associate with a hidden network, or we just don't want to wait for a beacon, we can send a //probe// frame requesting specific information in a beacon-like response from a particular network. The network is referenced by name, not AP MAC address, so large networks with multiple APs work fine. |
- | frames with information about its network: its MAC address, ESSID | + | * Once we have enough information to connect, we send an //authentication// frame. In most cases there's no actual authentication involved; anyone requesting authentication is granted it. The one exception is a WEP network configured in "Shared Key" mode, in which one must encrypt a challenge with the WEP key to authenticate. This is even more insecure than ordinary "Open System" WEP, and in practice no one uses it. |
- | (network name), regulatory information (how much power are we | + | * Once we're authenticated, we send an //association// frame requesting to be added to the AP's list of clients. |
- | allowed to transmit?), etc. The AP can choose how much information | + | * Once we're associated, there may be additional security steps if we're connecting to a WPA network. There's a four-way handshake involved, the details of which I'm still researching. |
- | to include in the beacon frame. | + | |
- | * If we're not satisfied with the information in the beacon we get, | + | |
- | we're trying to associate with a hidden network, or we just don't | + | |
- | want to wait for a beacon, we can send a //probe// frame requesting | + | |
- | specific information in a beacon-like response from a particular | + | |
- | network. The network is referenced by name, not AP MAC address, so | + | |
- | large networks with multiple APs work fine. | + | |
- | * Once we have enough information to connect, we send an | + | |
- | //authentication// frame. In most cases there's no actual | + | |
- | authentication involved; anyone requesting authentication is granted | + | |
- | it. The one exception is a WEP network configured in "Shared Key" | + | |
- | mode, in which one must encrypt a challenge with the WEP key to | + | |
- | authenticate. This is even more insecure than ordinary "Open System" | + | |
- | WEP, and in practice no one uses it. | + | |
- | * Once we're authenticated, we send an //association// frame | + | |
- | requesting to be added to the AP's list of clients. | + | |
- | * Once we're associated, there may be additional security steps if | + | |
- | we're connecting to a WPA network. There's a four-way handshake | + | |
- | involved, the details of which I'm still researching. | + | |
=== LLC layer === | === LLC layer === | ||
Line 151: | Line 132: | ||
Overall frame structure: | Overall frame structure: | ||
- | * Frame control (2 bytes). | + | * Frame control (2 bytes). |
- | * Duration/ID (2 bytes). | + | * Duration/ID (2 bytes). |
- | * Address 1 (6 bytes, MAC address). Specific meaning depends on the | + | * Address 1 (6 bytes, MAC address). Specific meaning depends on the frame, but we only accept frames where this is our address or multicast/broadcast. |
- | frame, but we only accept frames where this is our address or | + | * Address 2 (6 bytes, MAC address). Specific meaning depends on the frame, but this is the address we ACK to if we have to ACK. |
- | multicast/broadcast. | + | * Address 3 (6 bytes, MAC address). Specifies another address; e.g. if we're sending through the AP (Address 1) from ourselves (Address 2), the final destination goes in Address 3. |
- | * Address 2 (6 bytes, MAC address). Specific meaning depends on the | + | * Sequence control (2 bytes). Contains sequence number and fragment number information. |
- | frame, but this is the address we ACK to if we have to ACK. | + | * Data (up to 2304 bytes plus encryption overhead). |
- | * Address 3 (6 bytes, MAC address). Specifies another address; e.g. if | + | * Frame check sequence (4 bytes). CRC-32 over the rest of the frame *after* everything is packaged up/encrypted, just before it's sent over the wire. |
- | we're sending through the AP (Address 1) from ourselves (Address 2), | + | |
- | the final destination goes in Address 3. | + | |
- | * Sequence control (2 bytes). Contains sequence number and fragment | + | |
- | number information. | + | |
- | * Data (up to 2304 bytes plus encryption overhead). | + | |
- | * Frame check sequence (4 bytes). CRC-32 over the rest of the frame | + | |
- | *after* everything is packaged up/encrypted, just before it's sent | + | |
- | over the wire. | + | |
Apparently "network byte order" isn't standard enough: multi-byte | Apparently "network byte order" isn't standard enough: multi-byte | ||
Line 178: | Line 151: | ||
The first byte in the Frame Control field defines the type of frame: | The first byte in the Frame Control field defines the type of frame: | ||
- | * Bits 0-1: 2-bit Protocol Version field. Always 0; if nonzero we must | + | * Bits 0-1: 2-bit Protocol Version field. Always 0; if nonzero we must drop the packet. |
- | drop the packet. | + | * Bits 2-3: 2-bit Type field. |
- | * Bits 2-3: 2-bit Type field. | + | * 0: Management frame (association, breacon, authentication, etc). |
- | ** 0: Management frame (association, breacon, authentication, etc). | + | * 1: Control frame (ACK, RTS, CTS). |
- | ** 1: Control frame (ACK, RTS, CTS). | + | * 2: Data. |
- | ** 2: Data. | + | * Bits 4-7: 4-bit Subtype field. |
- | * Bits 4-7: 4-bit Subtype field. | + | * For frames of type 0 (Management): |
- | ** For frames of type 0 (Management): | + | * 0: Association request; 1: Association response. |
- | *** 0: Association request; 1: Association response. | + | * 2: Reassociation request; 3: Reassociation response. |
- | *** 2: Reassociation request; 3: Reassociation response. | + | * 4: Probe request; 5: Probe response. |
- | *** 4: Probe request; 5: Probe response. | + | * 8: Beacon. |
- | *** 8: Beacon. | + | * 9: ATIM. |
- | *** 9: ATIM. | + | * 10: Disassociation. |
- | *** 10: Disassociation. | + | * 11: Authentication; 12: Deauthentication. |
- | *** 11: Authentication; 12: Deauthentication. | + | * 13: Action. |
- | *** 13: Action. | + | * For frames of type 1 (Control): [we hope the card handles these] |
- | ** For frames of type 1 (Control): [we hope the card handles these] | + | * 11: RTS [request to send]. |
- | *** 11: RTS [request to send]. | + | * 12: CTS [clear to send]. |
- | *** 12: CTS [clear to send]. | + | * 13: ACK [acknowledgement]. |
- | *** 13: ACK [acknowledgement]. | + | * For frames of type 2 (Data): |
- | ** For frames of type 2 (Data): | + | * 0: Data. |
- | *** 0: Data. | + | * 4: Null (no data). |
- | *** 4: Null (no data). | + | |
The second byte in the Frame Control field is a set of flags: | The second byte in the Frame Control field is a set of flags: | ||
- | * Bit 8: To DS; bit 9: From DS. The "DS" is IEEE-speak for the access | + | * Bit 8: To DS; bit 9: From DS. The "DS" is IEEE-speak for the access point, on the theory that one might have a mesh network (Data System) of them. If both bits are 0, the packet is being transferred between two nodes in ad-hoc mode; if To DS is 1, it's from a node to the AP, and if From DS is 1, it's from an AP to the node. If both bits are 1 the packet is inter-AP communication and we should drop it. |
- | point, on the theory that one might have a mesh network (Data | + | * Bit 10: More Frag. Set on all fragments except the last; fragment details are included in the Sequence Control field (described below). The spec requires that we handle fragments of three different packets all mixed up before we start dropping. Maximum packet size is 64k. |
- | System) of them. If both bits are 0, the packet is being transferred | + | * Bit 11: Retry. Set if this is a retransmission, clear if not. |
- | between two nodes in ad-hoc mode; if To DS is 1, it's from a node | + | * Bit 12: Pwr Mgmt. Set iff the sending node is a low-power device that wants to go to sleep. We can probably ignore this; APs aren't allowed to be low-power devices. |
- | to the AP, and if From DS is 1, it's from an AP to the node. If both | + | * Bit 13: More Data. Set on packets transmitted from an AP if more packets than this one are buffered for transmit, as an indictation to low-power devices that they shouldn't go to sleep yet. |
- | bits are 1 the packet is inter-AP communication and we should drop | + | * Bit 14: Protected. Set if this frame is encrypted by any method. |
- | it. | + | * Bit 15: Order. Set if this frame is transmitted in strict order (with respect to its fragments, I assume). Probably can be ignored; I've never seen it used in the wild. |
- | * Bit 10: More Frag. Set on all fragments except the last; fragment | + | |
- | details are included in the Sequence Control field (described | + | |
- | below). The spec requires that we handle fragments of three | + | |
- | different packets all mixed up before we start dropping. Maximum | + | |
- | packet size is 64k. | + | |
- | * Bit 11: Retry. Set if this is a retransmission, clear if not. | + | |
- | * Bit 12: Pwr Mgmt. Set iff the sending node is a low-power device | + | |
- | that wants to go to sleep. We can probably ignore this; APs aren't | + | |
- | allowed to be low-power devices. | + | |
- | * Bit 13: More Data. Set on packets transmitted from an AP if more | + | |
- | packets than this one are buffered for transmit, as an indictation | + | |
- | to low-power devices that they shouldn't go to sleep yet. | + | |
- | * Bit 14: Protected. Set if this frame is encrypted by any method. | + | |
- | * Bit 15: Order. Set if this frame is transmitted in strict order (with | + | |
- | respect to its fragments, I assume). Probably can be ignored; I've | + | |
- | never seen it used in the wild. | + | |
There are other frame types defined to support QoS, but we don't have | There are other frame types defined to support QoS, but we don't have | ||
Line 277: | Line 233: | ||
=== RTS frame === | === RTS frame === | ||
Used to indicate a Request To Send a management or data frame. | Used to indicate a Request To Send a management or data frame. | ||
- | * Address 1 is the intended immediate recipient of the frame we want | + | * Address 1 is the intended immediate recipient of the frame we want to send. (Probably the AP's MAC.) |
- | to send. (Probably the AP's MAC.) | + | * Address 2 is our MAC address. |
- | * Address 2 is our MAC address. | + | * Address 3 and the Sequence Control field are not included. There is no data; the frame is 20 bytes long including FCS. |
- | * Address 3 and the Sequence Control field are not included. There is no | + | * Duration is the number of microseconds we expect to be required for one CTS frame, one ACK frame, the data or management frame we're asking to send, and three short interframe spaces. |
- | data; the frame is 20 bytes long including FCS. | + | |
- | * Duration is the number of microseconds we expect to be required for | + | |
- | one CTS frame, one ACK frame, the data or management frame we're | + | |
- | asking to send, and three short interframe spaces. | + | |
=== CTS frame === | === CTS frame === | ||
Used to tell the sender of an RTS frame that it is Clear To Send the | Used to tell the sender of an RTS frame that it is Clear To Send the | ||
management or data frame it wants to send. | management or data frame it wants to send. | ||
- | * Address 1 is copied from Address 2 of the preceding RTS frame: it's | + | * Address 1 is copied from Address 2 of the preceding RTS frame: it's the MAC of the node we're allowing to send. |
- | the MAC of the node we're allowing to send. | + | * Addresses 2 and 3 and the Sequence Control field are not included. There is no data; the frame is 14 bytes long including FCS. |
- | * Addresses 2 and 3 and the Sequence Control field are not included. | + | * Duration is the duration value from the RTS frame minus the time required to transmit the CTS frame and its preceding interframe space. |
- | There is no data; the frame is 14 bytes long including FCS. | + | |
- | * Duration is the duration value from the RTS frame minus the time | + | |
- | required to transmit the CTS frame and its preceding interframe | + | |
- | space. | + | |
=== ACK frame === | === ACK frame === | ||
- | Used to acknowledge receipt of a data, management, PS-Poll, or block | + | Used to acknowledge receipt of a data, management, PS-Poll, or //block// |
- | ACK frame. [Yes, ACKs get ACKed.] | + | ACK frame (an optimization we don't have to support). |
- | * Address 1 is copied from Address 2 of the frame we're ACKing. | + | * Address 1 is copied from Address 2 of the frame we're ACKing. |
- | * Duration is 0 if the frame we're ACKing had no more fragments; | + | * Duration is 0 if the frame we're ACKing had no more fragments; otherwise, it's the duration value from the frame we're ACKing minus the time to transmit the ACK frame and its preceding interframe space. |
- | otherwise, it's the duration value from the frame we're ACKing minus | + | |
- | the time to transmit the ACK frame and its preceding interframe | + | |
- | space. | + | |
=== PS-Poll frame === | === PS-Poll frame === | ||
- | Sent by nodes to an AP; purpose currently a mystery. | + | Sent by nodes to an AP; used for managing low-power devices, which we won't be using. |
- | * Address 1 is the MAC address of the AP we're polling. | + | * Address 1 is the MAC address of the AP we're polling. |
- | * Address 2 is our MAC address. | + | * Address 2 is our MAC address. |
- | * Address 3 and the Sequence Control field are not included. There is | + | * Address 3 and the Sequence Control field are not included. There is no data; the frame is 20 bytes long including FCS. |
- | no data; the frame is 20 bytes long including FCS. | + | * As explained above, Duration is here used as an association ID field. |
- | * As explained above, Duration is here used as an association ID | + | |
- | field. | + | |
=== Other types === | === Other types === | ||
Line 374: | Line 317: | ||
to potential clients. They are unencrypted and contain some or all of | to potential clients. They are unencrypted and contain some or all of | ||
the following, in the listed order. | the following, in the listed order. | ||
- | * Timestamp (field, 64bit): value of the timing sync function of the AP. | + | * Timestamp (field, 64bit): value of the timing sync function of the AP. |
- | * Beacon interval (field, 16bit): number of 1024-us intervals between beacons. | + | * Beacon interval (field, 16bit): number of 1024-us intervals between beacons. |
- | * Capability (field, 16bit): see below. | + | * Capability (field, 16bit): see below. |
- | * SSID (element #0, 2-34byte). | + | * SSID (element #0, 2-34byte). |
- | * Supported rates (element #1, 3-10byte). | + | * Supported rates (element #1, 3-10byte). |
- | * Frequency-hopping parameter set (element #2, 7byte). | + | * Frequency-hopping parameter set (element #2, 7byte). |
- | * DS parameter set (element #3, 3byte). | + | * DS parameter set (element #3, 3byte). |
- | * CF parameter set (element #4, 8byte). | + | * CF parameter set (element #4, 8byte). |
- | * IBSS parameter set (element #6, 4byte). | + | * IBSS parameter set (element #6, 4byte). |
- | * Traffic indication map (element #5, 6-256byte). | + | * Traffic indication map (element #5, 6-256byte). |
- | * Country information (element #7, 8-256byte). | + | * Country information (element #7, 8-256byte). |
- | * Frequency-hopping parameters (element #8, 4byte) -OR- FH pattern table (element #9, 6-256byte). | + | * Frequency-hopping parameters (element #8, 4byte) -OR- FH pattern table (element #9, 6-256byte). |
- | * Power constraint (element #32, 3byte). | + | * Power constraint (element #32, 3byte). |
- | * Channel switch announcement (element #37, 5byte). | + | * Channel switch announcement (element #37, 5byte). |
- | * Quiet (element #40, 8byte). | + | * Quiet (element #40, 8byte). |
- | * IBSS DFS (element #41, 10-255byte). | + | * IBSS DFS (element #41, 10-255byte). |
- | * TPC report (element #35, 4byte). | + | * TPC report (element #35, 4byte). |
- | * ERP [extended rate protocol] information (element #42, 3byte). | + | * ERP [extended rate protocol] information (element #42, 3byte). |
- | * Extended supported rates (beyond 8) (element #50, 3-257byte). | + | * Extended supported rates (beyond 8) (element #50, 3-257byte). |
- | * RSN (information on better-than-WEP security) (element #48, 36-256byte). | + | * RSN (information on better-than-WEP security) (element #48, 36-256byte). |
- | * BSS load (element #11, 7byte). | + | * BSS load (element #11, 7byte). |
- | * EDCA parameter (element #12, 20byte) -OR- QoS capability (element #46, 3byte). | + | * EDCA parameter (element #12, 20byte) -OR- QoS capability (element #46, 3byte). |
=== ATIM frame === | === ATIM frame === | ||
Line 415: | Line 358: | ||
Informs an AP that we want to join its network. The body of the frame | Informs an AP that we want to join its network. The body of the frame | ||
contains some or all of the following fields, in the listed order. | contains some or all of the following fields, in the listed order. | ||
- | * Capability (field, 16bit): see below. | + | * Capability (field, 16bit): see below. |
- | * Listen interval (field, 16bit): multiple of the beacon interval | + | * Listen interval (field, 16bit): multiple of the beacon interval indicating how often a low-power device wakes up to listen for beacon frames. We can set this to 1. |
- | indicating how often a low-power device wakes up to listen for beacon | + | * SSID (element #0, 2-34byte). |
- | frames. We can set this to 1. | + | * Supported rates (element #1, 3-10byte). |
- | * SSID (element #0, 2-34byte). | + | * Extended supported rates (beyond 8) (element #50, 3-257byte). |
- | * Supported rates (element #1, 3-10byte). | + | * Power capability (element #33, 4byte). |
- | * Extended supported rates (beyond 8) (element #50, 3-257byte). | + | * Supported channels (element #36, 4-256byte). |
- | * Power capability (element #33, 4byte). | + | * RSN information (element #48, 36-256byte). |
- | * Supported channels (element #36, 4-256byte). | + | |
- | * RSN information (element #48, 36-256byte). | + | |
=== Association response frame === | === Association response frame === | ||
Line 430: | Line 371: | ||
frame contains some or all of the following fields, in the listed | frame contains some or all of the following fields, in the listed | ||
order. | order. | ||
- | * Capability (field, 16bit): see below. | + | * Capability (field, 16bit): see below. |
- | * Status code (field, 16bit): see below. | + | * Status code (field, 16bit): see below. |
- | * Association ID (field, 16bit): tells the associating node what its | + | * Association ID (field, 16bit): tells the associating node what its ID in this iteration of the network is. The top 2 bits are set to 1, for quick matching against the AID field in PS-Poll control frames. |
- | ID in this iteration of the network is. The top 2 bits are set to 1, | + | * Supported rates (element #1, 3-10byte). |
- | for quick matching against the AID field in PS-Poll control frames. | + | * Extended supported rates (beyond 8) (element #50, 3-257byte). |
- | * Supported rates (element #1, 3-10byte). | + | * EDCA parameter set (element #12, 20byte). |
- | * Extended supported rates (beyond 8) (element #50, 3-257byte). | + | |
- | * EDCA parameter set (element #12, 20byte). | + | |
=== Reassociation request frame === | === Reassociation request frame === | ||
Line 452: | Line 391: | ||
Sent to ask for additional information about an AP, beyond what it | Sent to ask for additional information about an AP, beyond what it | ||
advertises in its beacon, before joining. Contains: | advertises in its beacon, before joining. Contains: | ||
- | * SSID (element #0, 2-34byte). | + | * SSID (element #0, 2-34byte). |
- | * Supported rates (element #1, 3-10byte). | + | * Supported rates (element #1, 3-10byte). |
- | * Request information (element #10, 2-256byte). | + | * Request information (element #10, 2-256byte). |
- | * Extended supported rates (beyond 8) (element #50, 3-257byte). | + | * Extended supported rates (beyond 8) (element #50, 3-257byte). |
=== Probe response frame === | === Probe response frame === | ||
Line 477: | Line 416: | ||
The frame contains: | The frame contains: | ||
- | * Authentication algorithm number (field, 16bit): 0 for open system or | + | * Authentication algorithm number (field, 16bit): 0 for open system or 1 for shared key. |
- | 1 for shared key. | + | * Authentication transaction sequence number (field, 16bit): starts at 1, increases with each frame; frames sent by node wanting to be authenticated are odd, replies are even. |
- | * Authentication transaction sequence number (field, 16bit): starts at | + | * Status code (field, 16bit): see below. Used only for even sequence numbers (AP replies). |
- | 1, increases with each frame; frames sent by node wanting to be | + | * Challenge text (element #16, 3-255byte) (if Shared Key type and sequence number 2 or 3). |
- | authenticated are odd, replies are even. | + | |
- | * Status code (field, 16bit): see below. Used only for even sequence | + | |
- | numbers (AP replies). | + | |
- | * Challenge text (element #16, 3-255byte) (if Shared Key type and | + | |
- | sequence number 2 or 3). | + | |
=== Deauthentication frame === | === Deauthentication frame === | ||
Line 507: | Line 441: | ||
The capability field is 16 bits wide and contains information about | The capability field is 16 bits wide and contains information about | ||
requested or advertised optional capabilities. The bits are | requested or advertised optional capabilities. The bits are | ||
- | * Bit 0: ESS; bit 1: IBSS. Ad-hoc networks are IBSS, AP-managed are | + | * Bit 0: ESS; bit 1: IBSS. Ad-hoc networks are IBSS, AP-managed are ESS. Exactly one of these bits should be set. |
- | ESS. Exactly one of these bits should be set. | + | * Bit 2: CF-Pollable. Used for high-performance "contention-free" connections, which gPXE will not support. Bit 3 (CF-Poll Request) should in such cases also be 0. |
- | * Bit 2: CF-Pollable. Used for high-performance "contention-free" | + | * Bit 4: Privacy. Set by the AP if all data on its network is encrypted. Cleared in association request frames we send (it is ignored). |
- | connections, which gPXE will not support. Bit 3 (CF-Poll Request) | + | * Bit 5: Short Preamble. (PHY-level) |
- | should in such cases also be 0. | + | * Bit 6: PBCC. (PHY-level) |
- | * Bit 4: Privacy. Set by the AP if all data on its network is | + | * Bit 7: Channel agility. (PHY-level) |
- | encrypted. Cleared in association request frames we send (it is | + | * Bit 8: Spectrum management. (PHY-level) |
- | ignored). | + | * Bit 9: QoS. Indicates support for (duh) QoS. |
- | * Bit 5: Short Preamble. (PHY-level) | + | * Bit 10: Short slot time. (PHY-level) |
- | * Bit 6: PBCC. (PHY-level) | + | * Bit 11: APSD. No idea. |
- | * Bit 7: Channel agility. (PHY-level) | + | * Bit 13: DSSS-OFDM. (PHY-level) |
- | * Bit 8: Spectrum management. (PHY-level) | + | * Bit 14: Delayted block ACK. Set by nodes that implement delayed block ACK. |
- | * Bit 9: QoS. Indicates support for (duh) QoS. | + | * Bit 15: Immediate block ACK. Set by nodes that implement immediate block ACK. |
- | * Bit 10: Short slot time. (PHY-level) | + | |
- | * Bit 11: APSD. No idea. | + | |
- | * Bit 13: DSSS-OFDM. (PHY-level) | + | |
- | * Bit 14: Delayted block ACK. Set by nodes that implement delayed | + | |
- | block ACK. | + | |
- | * Bit 15: Immediate block ACK. Set by nodes that implement immediate | + | |
- | block ACK. | + | |
=== Status code field === | === Status code field === | ||
Line 536: | Line 463: | ||
The following information elements bear data that can be | The following information elements bear data that can be | ||
interpreted as a simple string: | interpreted as a simple string: | ||
- | * SSID (element #0) | + | * SSID (element #0) |
- | * Challenge text (element #16) | + | * Challenge text (element #16) |
=== Supported Rates element === | === Supported Rates element === |