diff options
-rw-r--r-- | Documentation/networking/mac80211-injection.txt | 59 | ||||
-rw-r--r-- | Documentation/networking/radiotap-headers.txt | 87 |
2 files changed, 146 insertions, 0 deletions
diff --git a/Documentation/networking/mac80211-injection.txt b/Documentation/networking/mac80211-injection.txt new file mode 100644 index 000000000000..53ef7a06f49c --- /dev/null +++ b/Documentation/networking/mac80211-injection.txt | |||
@@ -0,0 +1,59 @@ | |||
1 | How to use packet injection with mac80211 | ||
2 | ========================================= | ||
3 | |||
4 | mac80211 now allows arbitrary packets to be injected down any Monitor Mode | ||
5 | interface from userland. The packet you inject needs to be composed in the | ||
6 | following format: | ||
7 | |||
8 | [ radiotap header ] | ||
9 | [ ieee80211 header ] | ||
10 | [ payload ] | ||
11 | |||
12 | The radiotap format is discussed in | ||
13 | ./Documentation/networking/radiotap-headers.txt. | ||
14 | |||
15 | Despite 13 radiotap argument types are currently defined, most only make sense | ||
16 | to appear on received packets. Currently three kinds of argument are used by | ||
17 | the injection code, although it knows to skip any other arguments that are | ||
18 | present (facilitating replay of captured radiotap headers directly): | ||
19 | |||
20 | - IEEE80211_RADIOTAP_RATE - u8 arg in 500kbps units (0x02 --> 1Mbps) | ||
21 | |||
22 | - IEEE80211_RADIOTAP_ANTENNA - u8 arg, 0x00 = ant1, 0x01 = ant2 | ||
23 | |||
24 | - IEEE80211_RADIOTAP_DBM_TX_POWER - u8 arg, dBm | ||
25 | |||
26 | Here is an example valid radiotap header defining these three parameters | ||
27 | |||
28 | 0x00, 0x00, // <-- radiotap version | ||
29 | 0x0b, 0x00, // <- radiotap header length | ||
30 | 0x04, 0x0c, 0x00, 0x00, // <-- bitmap | ||
31 | 0x6c, // <-- rate | ||
32 | 0x0c, //<-- tx power | ||
33 | 0x01 //<-- antenna | ||
34 | |||
35 | The ieee80211 header follows immediately afterwards, looking for example like | ||
36 | this: | ||
37 | |||
38 | 0x08, 0x01, 0x00, 0x00, | ||
39 | 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, | ||
40 | 0x13, 0x22, 0x33, 0x44, 0x55, 0x66, | ||
41 | 0x13, 0x22, 0x33, 0x44, 0x55, 0x66, | ||
42 | 0x10, 0x86 | ||
43 | |||
44 | Then lastly there is the payload. | ||
45 | |||
46 | After composing the packet contents, it is sent by send()-ing it to a logical | ||
47 | mac80211 interface that is in Monitor mode. Libpcap can also be used, | ||
48 | (which is easier than doing the work to bind the socket to the right | ||
49 | interface), along the following lines: | ||
50 | |||
51 | ppcap = pcap_open_live(szInterfaceName, 800, 1, 20, szErrbuf); | ||
52 | ... | ||
53 | r = pcap_inject(ppcap, u8aSendBuffer, nLength); | ||
54 | |||
55 | You can also find sources for a complete inject test applet here: | ||
56 | |||
57 | http://penumbra.warmcat.com/_twk/tiki-index.php?page=packetspammer | ||
58 | |||
59 | Andy Green <andy@warmcat.com> | ||
diff --git a/Documentation/networking/radiotap-headers.txt b/Documentation/networking/radiotap-headers.txt new file mode 100644 index 000000000000..e29e027d9be3 --- /dev/null +++ b/Documentation/networking/radiotap-headers.txt | |||
@@ -0,0 +1,87 @@ | |||
1 | How to use radiotap headers | ||
2 | =========================== | ||
3 | |||
4 | Pointer to the radiotap include file | ||
5 | ------------------------------------ | ||
6 | |||
7 | Radiotap headers are variable-length and extensible, you can get most of the | ||
8 | information you need to know on them from: | ||
9 | |||
10 | ./include/net/ieee80211_radiotap.h | ||
11 | |||
12 | This document gives an overview and warns on some corner cases. | ||
13 | |||
14 | |||
15 | Structure of the header | ||
16 | ----------------------- | ||
17 | |||
18 | There is a fixed portion at the start which contains a u32 bitmap that defines | ||
19 | if the possible argument associated with that bit is present or not. So if b0 | ||
20 | of the it_present member of ieee80211_radiotap_header is set, it means that | ||
21 | the header for argument index 0 (IEEE80211_RADIOTAP_TSFT) is present in the | ||
22 | argument area. | ||
23 | |||
24 | < 8-byte ieee80211_radiotap_header > | ||
25 | [ <possible argument bitmap extensions ... > ] | ||
26 | [ <argument> ... ] | ||
27 | |||
28 | At the moment there are only 13 possible argument indexes defined, but in case | ||
29 | we run out of space in the u32 it_present member, it is defined that b31 set | ||
30 | indicates that there is another u32 bitmap following (shown as "possible | ||
31 | argument bitmap extensions..." above), and the start of the arguments is moved | ||
32 | forward 4 bytes each time. | ||
33 | |||
34 | Note also that the it_len member __le16 is set to the total number of bytes | ||
35 | covered by the ieee80211_radiotap_header and any arguments following. | ||
36 | |||
37 | |||
38 | Requirements for arguments | ||
39 | -------------------------- | ||
40 | |||
41 | After the fixed part of the header, the arguments follow for each argument | ||
42 | index whose matching bit is set in the it_present member of | ||
43 | ieee80211_radiotap_header. | ||
44 | |||
45 | - the arguments are all stored little-endian! | ||
46 | |||
47 | - the argument payload for a given argument index has a fixed size. So | ||
48 | IEEE80211_RADIOTAP_TSFT being present always indicates an 8-byte argument is | ||
49 | present. See the comments in ./include/net/ieee80211_radiotap.h for a nice | ||
50 | breakdown of all the argument sizes | ||
51 | |||
52 | - the arguments must be aligned to a boundary of the argument size using | ||
53 | padding. So a u16 argument must start on the next u16 boundary if it isn't | ||
54 | already on one, a u32 must start on the next u32 boundary and so on. | ||
55 | |||
56 | - "alignment" is relative to the start of the ieee80211_radiotap_header, ie, | ||
57 | the first byte of the radiotap header. The absolute alignment of that first | ||
58 | byte isn't defined. So even if the whole radiotap header is starting at, eg, | ||
59 | address 0x00000003, still the first byte of the radiotap header is treated as | ||
60 | 0 for alignment purposes. | ||
61 | |||
62 | - the above point that there may be no absolute alignment for multibyte | ||
63 | entities in the fixed radiotap header or the argument region means that you | ||
64 | have to take special evasive action when trying to access these multibyte | ||
65 | entities. Some arches like Blackfin cannot deal with an attempt to | ||
66 | dereference, eg, a u16 pointer that is pointing to an odd address. Instead | ||
67 | you have to use a kernel API get_unaligned() to dereference the pointer, | ||
68 | which will do it bytewise on the arches that require that. | ||
69 | |||
70 | - The arguments for a given argument index can be a compound of multiple types | ||
71 | together. For example IEEE80211_RADIOTAP_CHANNEL has an argument payload | ||
72 | consisting of two u16s of total length 4. When this happens, the padding | ||
73 | rule is applied dealing with a u16, NOT dealing with a 4-byte single entity. | ||
74 | |||
75 | |||
76 | Example valid radiotap header | ||
77 | ----------------------------- | ||
78 | |||
79 | 0x00, 0x00, // <-- radiotap version + pad byte | ||
80 | 0x0b, 0x00, // <- radiotap header length | ||
81 | 0x04, 0x0c, 0x00, 0x00, // <-- bitmap | ||
82 | 0x6c, // <-- rate (in 500kHz units) | ||
83 | 0x0c, //<-- tx power | ||
84 | 0x01 //<-- antenna | ||
85 | |||
86 | |||
87 | Andy Green <andy@warmcat.com> | ||