diff options
author | David S. Miller <davem@sunset.davemloft.net> | 2007-07-14 21:58:49 -0400 |
---|---|---|
committer | David S. Miller <davem@sunset.davemloft.net> | 2007-07-14 21:58:49 -0400 |
commit | cf3842ec5015c862f4869e3641a8549393bb958e (patch) | |
tree | 6c2f0158504f3463fcca1359de90b699cb636e97 /Documentation | |
parent | b3b0b681b12478a7afa7d1f3d58be96830e16c7d (diff) | |
parent | 63fc33ceb0ccc08b3f62d7bfe56a33eb33ca9427 (diff) |
Merge branch 'upstream-davem' of master.kernel.org:/pub/scm/linux/kernel/git/linville/wireless-2.6
Diffstat (limited to 'Documentation')
-rw-r--r-- | Documentation/networking/mac80211-injection.txt | 59 | ||||
-rw-r--r-- | Documentation/networking/radiotap-headers.txt | 152 |
2 files changed, 211 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..953331c7984f --- /dev/null +++ b/Documentation/networking/radiotap-headers.txt | |||
@@ -0,0 +1,152 @@ | |||
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 | Using the Radiotap Parser | ||
88 | ------------------------- | ||
89 | |||
90 | If you are having to parse a radiotap struct, you can radically simplify the | ||
91 | job by using the radiotap parser that lives in net/wireless/radiotap.c and has | ||
92 | its prototypes available in include/net/cfg80211.h. You use it like this: | ||
93 | |||
94 | #include <net/cfg80211.h> | ||
95 | |||
96 | /* buf points to the start of the radiotap header part */ | ||
97 | |||
98 | int MyFunction(u8 * buf, int buflen) | ||
99 | { | ||
100 | int pkt_rate_100kHz = 0, antenna = 0, pwr = 0; | ||
101 | struct ieee80211_radiotap_iterator iterator; | ||
102 | int ret = ieee80211_radiotap_iterator_init(&iterator, buf, buflen); | ||
103 | |||
104 | while (!ret) { | ||
105 | |||
106 | ret = ieee80211_radiotap_iterator_next(&iterator); | ||
107 | |||
108 | if (ret) | ||
109 | continue; | ||
110 | |||
111 | /* see if this argument is something we can use */ | ||
112 | |||
113 | switch (iterator.this_arg_index) { | ||
114 | /* | ||
115 | * You must take care when dereferencing iterator.this_arg | ||
116 | * for multibyte types... the pointer is not aligned. Use | ||
117 | * get_unaligned((type *)iterator.this_arg) to dereference | ||
118 | * iterator.this_arg for type "type" safely on all arches. | ||
119 | */ | ||
120 | case IEEE80211_RADIOTAP_RATE: | ||
121 | /* radiotap "rate" u8 is in | ||
122 | * 500kbps units, eg, 0x02=1Mbps | ||
123 | */ | ||
124 | pkt_rate_100kHz = (*iterator.this_arg) * 5; | ||
125 | break; | ||
126 | |||
127 | case IEEE80211_RADIOTAP_ANTENNA: | ||
128 | /* radiotap uses 0 for 1st ant */ | ||
129 | antenna = *iterator.this_arg); | ||
130 | break; | ||
131 | |||
132 | case IEEE80211_RADIOTAP_DBM_TX_POWER: | ||
133 | pwr = *iterator.this_arg; | ||
134 | break; | ||
135 | |||
136 | default: | ||
137 | break; | ||
138 | } | ||
139 | } /* while more rt headers */ | ||
140 | |||
141 | if (ret != -ENOENT) | ||
142 | return TXRX_DROP; | ||
143 | |||
144 | /* discard the radiotap header part */ | ||
145 | buf += iterator.max_length; | ||
146 | buflen -= iterator.max_length; | ||
147 | |||
148 | ... | ||
149 | |||
150 | } | ||
151 | |||
152 | Andy Green <andy@warmcat.com> | ||