aboutsummaryrefslogtreecommitdiffstats
path: root/Documentation
diff options
context:
space:
mode:
authorLinus Torvalds <torvalds@linux-foundation.org>2008-10-11 12:33:18 -0400
committerLinus Torvalds <torvalds@linux-foundation.org>2008-10-11 12:33:18 -0400
commit4dd9ec4946b4651a295d3bc8df9c15ac692a8f4e (patch)
treeafb300c752de7175bb2df4722d5c857e070c75d9 /Documentation
parent86ed5a93b8b56e4e0877b914af0e10883a196384 (diff)
parent6861ff35ec5b60fafaf8651754c9a75142bfa9a4 (diff)
Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next-2.6
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next-2.6: (1075 commits) myri10ge: update driver version number to 1.4.3-1.369 r8169: add shutdown handler r8169: preliminary 8168d support r8169: support additional 8168cp chipset r8169: change default behavior for mildly identified 8168c chipsets r8169: add a new 8168cp flavor r8169: add a new 8168c flavor (bis) r8169: add a new 8168c flavor r8169: sync existing 8168 device hardware start sequences with vendor driver r8169: 8168b Tx performance tweak r8169: make room for more specific 8168 hardware start procedure r8169: shuffle some registers handling around (8168 operation only) r8169: new phy init parameters for the 8168b r8169: update phy init parameters r8169: wake up the PHY of the 8168 af_key: fix SADB_X_SPDDELETE response ath9k: Fix return code when ath9k_hw_setpower() fails on reset ath9k: remove nasty FAIL macro from ath9k_hw_reset() gre: minor cleanups in netlink interface gre: fix copy and paste error ...
Diffstat (limited to 'Documentation')
-rw-r--r--Documentation/DocBook/mac80211.tmpl12
-rw-r--r--Documentation/feature-removal-schedule.txt21
-rw-r--r--Documentation/networking/LICENSE.qlge46
-rw-r--r--Documentation/networking/can.txt44
-rw-r--r--Documentation/networking/multiqueue.txt54
-rw-r--r--Documentation/networking/phonet.txt175
-rw-r--r--Documentation/networking/regulatory.txt194
-rw-r--r--Documentation/networking/tproxy.txt85
-rw-r--r--Documentation/rfkill.txt32
9 files changed, 646 insertions, 17 deletions
diff --git a/Documentation/DocBook/mac80211.tmpl b/Documentation/DocBook/mac80211.tmpl
index b651e0a4b1c0..77c3c202991b 100644
--- a/Documentation/DocBook/mac80211.tmpl
+++ b/Documentation/DocBook/mac80211.tmpl
@@ -145,7 +145,6 @@ usage should require reading the full document.
145 this though and the recommendation to allow only a single 145 this though and the recommendation to allow only a single
146 interface in STA mode at first! 146 interface in STA mode at first!
147 </para> 147 </para>
148!Finclude/net/mac80211.h ieee80211_if_types
149!Finclude/net/mac80211.h ieee80211_if_init_conf 148!Finclude/net/mac80211.h ieee80211_if_init_conf
150!Finclude/net/mac80211.h ieee80211_if_conf 149!Finclude/net/mac80211.h ieee80211_if_conf
151 </chapter> 150 </chapter>
@@ -177,8 +176,7 @@ usage should require reading the full document.
177 <title>functions/definitions</title> 176 <title>functions/definitions</title>
178!Finclude/net/mac80211.h ieee80211_rx_status 177!Finclude/net/mac80211.h ieee80211_rx_status
179!Finclude/net/mac80211.h mac80211_rx_flags 178!Finclude/net/mac80211.h mac80211_rx_flags
180!Finclude/net/mac80211.h ieee80211_tx_control 179!Finclude/net/mac80211.h ieee80211_tx_info
181!Finclude/net/mac80211.h ieee80211_tx_status_flags
182!Finclude/net/mac80211.h ieee80211_rx 180!Finclude/net/mac80211.h ieee80211_rx
183!Finclude/net/mac80211.h ieee80211_rx_irqsafe 181!Finclude/net/mac80211.h ieee80211_rx_irqsafe
184!Finclude/net/mac80211.h ieee80211_tx_status 182!Finclude/net/mac80211.h ieee80211_tx_status
@@ -189,12 +187,11 @@ usage should require reading the full document.
189!Finclude/net/mac80211.h ieee80211_ctstoself_duration 187!Finclude/net/mac80211.h ieee80211_ctstoself_duration
190!Finclude/net/mac80211.h ieee80211_generic_frame_duration 188!Finclude/net/mac80211.h ieee80211_generic_frame_duration
191!Finclude/net/mac80211.h ieee80211_get_hdrlen_from_skb 189!Finclude/net/mac80211.h ieee80211_get_hdrlen_from_skb
192!Finclude/net/mac80211.h ieee80211_get_hdrlen 190!Finclude/net/mac80211.h ieee80211_hdrlen
193!Finclude/net/mac80211.h ieee80211_wake_queue 191!Finclude/net/mac80211.h ieee80211_wake_queue
194!Finclude/net/mac80211.h ieee80211_stop_queue 192!Finclude/net/mac80211.h ieee80211_stop_queue
195!Finclude/net/mac80211.h ieee80211_start_queues
196!Finclude/net/mac80211.h ieee80211_stop_queues
197!Finclude/net/mac80211.h ieee80211_wake_queues 193!Finclude/net/mac80211.h ieee80211_wake_queues
194!Finclude/net/mac80211.h ieee80211_stop_queues
198 </sect1> 195 </sect1>
199 </chapter> 196 </chapter>
200 197
@@ -230,8 +227,7 @@ usage should require reading the full document.
230 <title>Multiple queues and QoS support</title> 227 <title>Multiple queues and QoS support</title>
231 <para>TBD</para> 228 <para>TBD</para>
232!Finclude/net/mac80211.h ieee80211_tx_queue_params 229!Finclude/net/mac80211.h ieee80211_tx_queue_params
233!Finclude/net/mac80211.h ieee80211_tx_queue_stats_data 230!Finclude/net/mac80211.h ieee80211_tx_queue_stats
234!Finclude/net/mac80211.h ieee80211_tx_queue
235 </chapter> 231 </chapter>
236 232
237 <chapter id="AP"> 233 <chapter id="AP">
diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt
index 83c88cae1eda..3d2d0c29f027 100644
--- a/Documentation/feature-removal-schedule.txt
+++ b/Documentation/feature-removal-schedule.txt
@@ -6,6 +6,24 @@ be removed from this file.
6 6
7--------------------------- 7---------------------------
8 8
9What: old static regulatory information and ieee80211_regdom module parameter
10When: 2.6.29
11Why: The old regulatory infrastructure has been replaced with a new one
12 which does not require statically defined regulatory domains. We do
13 not want to keep static regulatory domains in the kernel due to the
14 the dynamic nature of regulatory law and localization. We kept around
15 the old static definitions for the regulatory domains of:
16 * US
17 * JP
18 * EU
19 and used by default the US when CONFIG_WIRELESS_OLD_REGULATORY was
20 set. We also kept around the ieee80211_regdom module parameter in case
21 some applications were relying on it. Changing regulatory domains
22 can now be done instead by using nl80211, as is done with iw.
23Who: Luis R. Rodriguez <lrodriguez@atheros.com>
24
25---------------------------
26
9What: dev->power.power_state 27What: dev->power.power_state
10When: July 2007 28When: July 2007
11Why: Broken design for runtime control over driver power states, confusing 29Why: Broken design for runtime control over driver power states, confusing
@@ -232,6 +250,9 @@ What (Why):
232 - xt_mark match revision 0 250 - xt_mark match revision 0
233 (superseded by xt_mark match revision 1) 251 (superseded by xt_mark match revision 1)
234 252
253 - xt_recent: the old ipt_recent proc dir
254 (superseded by /proc/net/xt_recent)
255
235When: January 2009 or Linux 2.7.0, whichever comes first 256When: January 2009 or Linux 2.7.0, whichever comes first
236Why: Superseded by newer revisions or modules 257Why: Superseded by newer revisions or modules
237Who: Jan Engelhardt <jengelh@computergmbh.de> 258Who: Jan Engelhardt <jengelh@computergmbh.de>
diff --git a/Documentation/networking/LICENSE.qlge b/Documentation/networking/LICENSE.qlge
new file mode 100644
index 000000000000..123b6edd7f18
--- /dev/null
+++ b/Documentation/networking/LICENSE.qlge
@@ -0,0 +1,46 @@
1Copyright (c) 2003-2008 QLogic Corporation
2QLogic Linux Networking HBA Driver
3
4This program includes a device driver for Linux 2.6 that may be
5distributed with QLogic hardware specific firmware binary file.
6You may modify and redistribute the device driver code under the
7GNU General Public License as published by the Free Software
8Foundation (version 2 or a later version).
9
10You may redistribute the hardware specific firmware binary file
11under the following terms:
12
13 1. Redistribution of source code (only if applicable),
14 must retain the above copyright notice, this list of
15 conditions and the following disclaimer.
16
17 2. Redistribution in binary form must reproduce the above
18 copyright notice, this list of conditions and the
19 following disclaimer in the documentation and/or other
20 materials provided with the distribution.
21
22 3. The name of QLogic Corporation may not be used to
23 endorse or promote products derived from this software
24 without specific prior written permission
25
26REGARDLESS OF WHAT LICENSING MECHANISM IS USED OR APPLICABLE,
27THIS PROGRAM IS PROVIDED BY QLOGIC CORPORATION "AS IS'' AND ANY
28EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
29IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
30PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR
31BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
32EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED
33TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
34DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
35ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
36OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
37OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
38POSSIBILITY OF SUCH DAMAGE.
39
40USER ACKNOWLEDGES AND AGREES THAT USE OF THIS PROGRAM WILL NOT
41CREATE OR GIVE GROUNDS FOR A LICENSE BY IMPLICATION, ESTOPPEL, OR
42OTHERWISE IN ANY INTELLECTUAL PROPERTY RIGHTS (PATENT, COPYRIGHT,
43TRADE SECRET, MASK WORK, OR OTHER PROPRIETARY RIGHT) EMBODIED IN
44ANY OTHER QLOGIC HARDWARE OR SOFTWARE EITHER SOLELY OR IN
45COMBINATION WITH THIS PROGRAM.
46
diff --git a/Documentation/networking/can.txt b/Documentation/networking/can.txt
index 297ba7b1ccaf..2035bc4932f2 100644
--- a/Documentation/networking/can.txt
+++ b/Documentation/networking/can.txt
@@ -35,8 +35,9 @@ This file contains
35 6.1 general settings 35 6.1 general settings
36 6.2 local loopback of sent frames 36 6.2 local loopback of sent frames
37 6.3 CAN controller hardware filters 37 6.3 CAN controller hardware filters
38 6.4 currently supported CAN hardware 38 6.4 The virtual CAN driver (vcan)
39 6.5 todo 39 6.5 currently supported CAN hardware
40 6.6 todo
40 41
41 7 Credits 42 7 Credits
42 43
@@ -584,7 +585,42 @@ solution for a couple of reasons:
584 @133MHz with four SJA1000 CAN controllers from 2002 under heavy bus 585 @133MHz with four SJA1000 CAN controllers from 2002 under heavy bus
585 load without any problems ... 586 load without any problems ...
586 587
587 6.4 currently supported CAN hardware (September 2007) 588 6.4 The virtual CAN driver (vcan)
589
590 Similar to the network loopback devices, vcan offers a virtual local
591 CAN interface. A full qualified address on CAN consists of
592
593 - a unique CAN Identifier (CAN ID)
594 - the CAN bus this CAN ID is transmitted on (e.g. can0)
595
596 so in common use cases more than one virtual CAN interface is needed.
597
598 The virtual CAN interfaces allow the transmission and reception of CAN
599 frames without real CAN controller hardware. Virtual CAN network
600 devices are usually named 'vcanX', like vcan0 vcan1 vcan2 ...
601 When compiled as a module the virtual CAN driver module is called vcan.ko
602
603 Since Linux Kernel version 2.6.24 the vcan driver supports the Kernel
604 netlink interface to create vcan network devices. The creation and
605 removal of vcan network devices can be managed with the ip(8) tool:
606
607 - Create a virtual CAN network interface:
608 ip link add type vcan
609
610 - Create a virtual CAN network interface with a specific name 'vcan42':
611 ip link add dev vcan42 type vcan
612
613 - Remove a (virtual CAN) network interface 'vcan42':
614 ip link del vcan42
615
616 The tool 'vcan' from the SocketCAN SVN repository on BerliOS is obsolete.
617
618 Virtual CAN network device creation in older Kernels:
619 In Linux Kernel versions < 2.6.24 the vcan driver creates 4 vcan
620 netdevices at module load time by default. This value can be changed
621 with the module parameter 'numdev'. E.g. 'modprobe vcan numdev=8'
622
623 6.5 currently supported CAN hardware
588 624
589 On the project website http://developer.berlios.de/projects/socketcan 625 On the project website http://developer.berlios.de/projects/socketcan
590 there are different drivers available: 626 there are different drivers available:
@@ -603,7 +639,7 @@ solution for a couple of reasons:
603 639
604 Please check the Mailing Lists on the berlios OSS project website. 640 Please check the Mailing Lists on the berlios OSS project website.
605 641
606 6.5 todo (September 2007) 642 6.6 todo
607 643
608 The configuration interface for CAN network drivers is still an open 644 The configuration interface for CAN network drivers is still an open
609 issue that has not been finalized in the socketcan project. Also the 645 issue that has not been finalized in the socketcan project. Also the
diff --git a/Documentation/networking/multiqueue.txt b/Documentation/networking/multiqueue.txt
index d391ea631141..4caa0e314cc2 100644
--- a/Documentation/networking/multiqueue.txt
+++ b/Documentation/networking/multiqueue.txt
@@ -24,4 +24,56 @@ netif_{start|stop|wake}_subqueue() functions to manage each queue while the
24device is still operational. netdev->queue_lock is still used when the device 24device is still operational. netdev->queue_lock is still used when the device
25comes online or when it's completely shut down (unregister_netdev(), etc.). 25comes online or when it's completely shut down (unregister_netdev(), etc.).
26 26
27Author: Peter P. Waskiewicz Jr. <peter.p.waskiewicz.jr@intel.com> 27
28Section 2: Qdisc support for multiqueue devices
29
30-----------------------------------------------
31
32Currently two qdiscs are optimized for multiqueue devices. The first is the
33default pfifo_fast qdisc. This qdisc supports one qdisc per hardware queue.
34A new round-robin qdisc, sch_multiq also supports multiple hardware queues. The
35qdisc is responsible for classifying the skb's and then directing the skb's to
36bands and queues based on the value in skb->queue_mapping. Use this field in
37the base driver to determine which queue to send the skb to.
38
39sch_multiq has been added for hardware that wishes to avoid head-of-line
40blocking. It will cycle though the bands and verify that the hardware queue
41associated with the band is not stopped prior to dequeuing a packet.
42
43On qdisc load, the number of bands is based on the number of queues on the
44hardware. Once the association is made, any skb with skb->queue_mapping set,
45will be queued to the band associated with the hardware queue.
46
47
48Section 3: Brief howto using MULTIQ for multiqueue devices
49---------------------------------------------------------------
50
51The userspace command 'tc,' part of the iproute2 package, is used to configure
52qdiscs. To add the MULTIQ qdisc to your network device, assuming the device
53is called eth0, run the following command:
54
55# tc qdisc add dev eth0 root handle 1: multiq
56
57The qdisc will allocate the number of bands to equal the number of queues that
58the device reports, and bring the qdisc online. Assuming eth0 has 4 Tx
59queues, the band mapping would look like:
60
61band 0 => queue 0
62band 1 => queue 1
63band 2 => queue 2
64band 3 => queue 3
65
66Traffic will begin flowing through each queue based on either the simple_tx_hash
67function or based on netdev->select_queue() if you have it defined.
68
69The behavior of tc filters remains the same. However a new tc action,
70skbedit, has been added. Assuming you wanted to route all traffic to a
71specific host, for example 192.168.0.3, through a specific queue you could use
72this action and establish a filter such as:
73
74tc filter add dev eth0 parent 1: protocol ip prio 1 u32 \
75 match ip dst 192.168.0.3 \
76 action skbedit queue_mapping 3
77
78Author: Alexander Duyck <alexander.h.duyck@intel.com>
79Original Author: Peter P. Waskiewicz Jr. <peter.p.waskiewicz.jr@intel.com>
diff --git a/Documentation/networking/phonet.txt b/Documentation/networking/phonet.txt
new file mode 100644
index 000000000000..0e6e592f4f55
--- /dev/null
+++ b/Documentation/networking/phonet.txt
@@ -0,0 +1,175 @@
1Linux Phonet protocol family
2============================
3
4Introduction
5------------
6
7Phonet is a packet protocol used by Nokia cellular modems for both IPC
8and RPC. With the Linux Phonet socket family, Linux host processes can
9receive and send messages from/to the modem, or any other external
10device attached to the modem. The modem takes care of routing.
11
12Phonet packets can be exchanged through various hardware connections
13depending on the device, such as:
14 - USB with the CDC Phonet interface,
15 - infrared,
16 - Bluetooth,
17 - an RS232 serial port (with a dedicated "FBUS" line discipline),
18 - the SSI bus with some TI OMAP processors.
19
20
21Packets format
22--------------
23
24Phonet packets have a common header as follows:
25
26 struct phonethdr {
27 uint8_t pn_media; /* Media type (link-layer identifier) */
28 uint8_t pn_rdev; /* Receiver device ID */
29 uint8_t pn_sdev; /* Sender device ID */
30 uint8_t pn_res; /* Resource ID or function */
31 uint16_t pn_length; /* Big-endian message byte length (minus 6) */
32 uint8_t pn_robj; /* Receiver object ID */
33 uint8_t pn_sobj; /* Sender object ID */
34 };
35
36On Linux, the link-layer header includes the pn_media byte (see below).
37The next 7 bytes are part of the network-layer header.
38
39The device ID is split: the 6 higher-order bits consitute the device
40address, while the 2 lower-order bits are used for multiplexing, as are
41the 8-bit object identifiers. As such, Phonet can be considered as a
42network layer with 6 bits of address space and 10 bits for transport
43protocol (much like port numbers in IP world).
44
45The modem always has address number zero. All other device have a their
46own 6-bit address.
47
48
49Link layer
50----------
51
52Phonet links are always point-to-point links. The link layer header
53consists of a single Phonet media type byte. It uniquely identifies the
54link through which the packet is transmitted, from the modem's
55perspective. Each Phonet network device shall prepend and set the media
56type byte as appropriate. For convenience, a common phonet_header_ops
57link-layer header operations structure is provided. It sets the
58media type according to the network device hardware address.
59
60Linux Phonet network interfaces support a dedicated link layer packets
61type (ETH_P_PHONET) which is out of the Ethernet type range. They can
62only send and receive Phonet packets.
63
64The virtual TUN tunnel device driver can also be used for Phonet. This
65requires IFF_TUN mode, _without_ the IFF_NO_PI flag. In this case,
66there is no link-layer header, so there is no Phonet media type byte.
67
68Note that Phonet interfaces are not allowed to re-order packets, so
69only the (default) Linux FIFO qdisc should be used with them.
70
71
72Network layer
73-------------
74
75The Phonet socket address family maps the Phonet packet header:
76
77 struct sockaddr_pn {
78 sa_family_t spn_family; /* AF_PHONET */
79 uint8_t spn_obj; /* Object ID */
80 uint8_t spn_dev; /* Device ID */
81 uint8_t spn_resource; /* Resource or function */
82 uint8_t spn_zero[...]; /* Padding */
83 };
84
85The resource field is only used when sending and receiving;
86It is ignored by bind() and getsockname().
87
88
89Low-level datagram protocol
90---------------------------
91
92Applications can send Phonet messages using the Phonet datagram socket
93protocol from the PF_PHONET family. Each socket is bound to one of the
942^10 object IDs available, and can send and receive packets with any
95other peer.
96
97 struct sockaddr_pn addr = { .spn_family = AF_PHONET, };
98 ssize_t len;
99 socklen_t addrlen = sizeof(addr);
100 int fd;
101
102 fd = socket(PF_PHONET, SOCK_DGRAM, 0);
103 bind(fd, (struct sockaddr *)&addr, sizeof(addr));
104 /* ... */
105
106 sendto(fd, msg, msglen, 0, (struct sockaddr *)&addr, sizeof(addr));
107 len = recvfrom(fd, buf, sizeof(buf), 0,
108 (struct sockaddr *)&addr, &addrlen);
109
110This protocol follows the SOCK_DGRAM connection-less semantics.
111However, connect() and getpeername() are not supported, as they did
112not seem useful with Phonet usages (could be added easily).
113
114
115Phonet Pipe protocol
116--------------------
117
118The Phonet Pipe protocol is a simple sequenced packets protocol
119with end-to-end congestion control. It uses the passive listening
120socket paradigm. The listening socket is bound to an unique free object
121ID. Each listening socket can handle up to 255 simultaneous
122connections, one per accept()'d socket.
123
124 int lfd, cfd;
125
126 lfd = socket(PF_PHONET, SOCK_SEQPACKET, PN_PROTO_PIPE);
127 listen (lfd, INT_MAX);
128
129 /* ... */
130 cfd = accept(lfd, NULL, NULL);
131 for (;;)
132 {
133 char buf[...];
134 ssize_t len = read(cfd, buf, sizeof(buf));
135
136 /* ... */
137
138 write(cfd, msg, msglen);
139 }
140
141Connections are established between two endpoints by a "third party"
142application. This means that both endpoints are passive; so connect()
143is not possible.
144
145WARNING:
146When polling a connected pipe socket for writability, there is an
147intrinsic race condition whereby writability might be lost between the
148polling and the writing system calls. In this case, the socket will
149block until write because possible again, unless non-blocking mode
150becomes enabled.
151
152
153The pipe protocol provides two socket options at the SOL_PNPIPE level:
154
155 PNPIPE_ENCAP accepts one integer value (int) of:
156
157 PNPIPE_ENCAP_NONE: The socket operates normally (default).
158
159 PNPIPE_ENCAP_IP: The socket is used as a backend for a virtual IP
160 interface. This requires CAP_NET_ADMIN capability. GPRS data
161 support on Nokia modems can use this. Note that the socket cannot
162 be reliably poll()'d or read() from while in this mode.
163
164 PNPIPE_IFINDEX is a read-only integer value. It contains the
165 interface index of the network interface created by PNPIPE_ENCAP,
166 or zero if encapsulation is off.
167
168
169Authors
170-------
171
172Linux Phonet was initially written by Sakari Ailus.
173Other contributors include Mikä Liljeberg, Andras Domokos,
174Carlos Chinea and Rémi Denis-Courmont.
175Copyright (C) 2008 Nokia Corporation.
diff --git a/Documentation/networking/regulatory.txt b/Documentation/networking/regulatory.txt
new file mode 100644
index 000000000000..a96989a8ff35
--- /dev/null
+++ b/Documentation/networking/regulatory.txt
@@ -0,0 +1,194 @@
1Linux wireless regulatory documentation
2---------------------------------------
3
4This document gives a brief review over how the Linux wireless
5regulatory infrastructure works.
6
7More up to date information can be obtained at the project's web page:
8
9http://wireless.kernel.org/en/developers/Regulatory
10
11Keeping regulatory domains in userspace
12---------------------------------------
13
14Due to the dynamic nature of regulatory domains we keep them
15in userspace and provide a framework for userspace to upload
16to the kernel one regulatory domain to be used as the central
17core regulatory domain all wireless devices should adhere to.
18
19How to get regulatory domains to the kernel
20-------------------------------------------
21
22Userspace gets a regulatory domain in the kernel by having
23a userspace agent build it and send it via nl80211. Only
24expected regulatory domains will be respected by the kernel.
25
26A currently available userspace agent which can accomplish this
27is CRDA - central regulatory domain agent. Its documented here:
28
29http://wireless.kernel.org/en/developers/Regulatory/CRDA
30
31Essentially the kernel will send a udev event when it knows
32it needs a new regulatory domain. A udev rule can be put in place
33to trigger crda to send the respective regulatory domain for a
34specific ISO/IEC 3166 alpha2.
35
36Below is an example udev rule which can be used:
37
38# Example file, should be put in /etc/udev/rules.d/regulatory.rules
39KERNEL=="regulatory*", ACTION=="change", SUBSYSTEM=="platform", RUN+="/sbin/crda"
40
41The alpha2 is passed as an environment variable under the variable COUNTRY.
42
43Who asks for regulatory domains?
44--------------------------------
45
46* Users
47
48Users can use iw:
49
50http://wireless.kernel.org/en/users/Documentation/iw
51
52An example:
53
54 # set regulatory domain to "Costa Rica"
55 iw reg set CR
56
57This will request the kernel to set the regulatory domain to
58the specificied alpha2. The kernel in turn will then ask userspace
59to provide a regulatory domain for the alpha2 specified by the user
60by sending a uevent.
61
62* Wireless subsystems for Country Information elements
63
64The kernel will send a uevent to inform userspace a new
65regulatory domain is required. More on this to be added
66as its integration is added.
67
68* Drivers
69
70If drivers determine they need a specific regulatory domain
71set they can inform the wireless core using regulatory_hint().
72They have two options -- they either provide an alpha2 so that
73crda can provide back a regulatory domain for that country or
74they can build their own regulatory domain based on internal
75custom knowledge so the wireless core can respect it.
76
77*Most* drivers will rely on the first mechanism of providing a
78regulatory hint with an alpha2. For these drivers there is an additional
79check that can be used to ensure compliance based on custom EEPROM
80regulatory data. This additional check can be used by drivers by
81registering on its struct wiphy a reg_notifier() callback. This notifier
82is called when the core's regulatory domain has been changed. The driver
83can use this to review the changes made and also review who made them
84(driver, user, country IE) and determine what to allow based on its
85internal EEPROM data. Devices drivers wishing to be capable of world
86roaming should use this callback. More on world roaming will be
87added to this document when its support is enabled.
88
89Device drivers who provide their own built regulatory domain
90do not need a callback as the channels registered by them are
91the only ones that will be allowed and therefore *additional*
92cannels cannot be enabled.
93
94Example code - drivers hinting an alpha2:
95------------------------------------------
96
97This example comes from the zd1211rw device driver. You can start
98by having a mapping of your device's EEPROM country/regulatory
99domain value to to a specific alpha2 as follows:
100
101static struct zd_reg_alpha2_map reg_alpha2_map[] = {
102 { ZD_REGDOMAIN_FCC, "US" },
103 { ZD_REGDOMAIN_IC, "CA" },
104 { ZD_REGDOMAIN_ETSI, "DE" }, /* Generic ETSI, use most restrictive */
105 { ZD_REGDOMAIN_JAPAN, "JP" },
106 { ZD_REGDOMAIN_JAPAN_ADD, "JP" },
107 { ZD_REGDOMAIN_SPAIN, "ES" },
108 { ZD_REGDOMAIN_FRANCE, "FR" },
109
110Then you can define a routine to map your read EEPROM value to an alpha2,
111as follows:
112
113static int zd_reg2alpha2(u8 regdomain, char *alpha2)
114{
115 unsigned int i;
116 struct zd_reg_alpha2_map *reg_map;
117 for (i = 0; i < ARRAY_SIZE(reg_alpha2_map); i++) {
118 reg_map = &reg_alpha2_map[i];
119 if (regdomain == reg_map->reg) {
120 alpha2[0] = reg_map->alpha2[0];
121 alpha2[1] = reg_map->alpha2[1];
122 return 0;
123 }
124 }
125 return 1;
126}
127
128Lastly, you can then hint to the core of your discovered alpha2, if a match
129was found. You need to do this after you have registered your wiphy. You
130are expected to do this during initialization.
131
132 r = zd_reg2alpha2(mac->regdomain, alpha2);
133 if (!r)
134 regulatory_hint(hw->wiphy, alpha2, NULL);
135
136Example code - drivers providing a built in regulatory domain:
137--------------------------------------------------------------
138
139If you have regulatory information you can obtain from your
140driver and you *need* to use this we let you build a regulatory domain
141structure and pass it to the wireless core. To do this you should
142kmalloc() a structure big enough to hold your regulatory domain
143structure and you should then fill it with your data. Finally you simply
144call regulatory_hint() with the regulatory domain structure in it.
145
146Bellow is a simple example, with a regulatory domain cached using the stack.
147Your implementation may vary (read EEPROM cache instead, for example).
148
149Example cache of some regulatory domain
150
151struct ieee80211_regdomain mydriver_jp_regdom = {
152 .n_reg_rules = 3,
153 .alpha2 = "JP",
154 //.alpha2 = "99", /* If I have no alpha2 to map it to */
155 .reg_rules = {
156 /* IEEE 802.11b/g, channels 1..14 */
157 REG_RULE(2412-20, 2484+20, 40, 6, 20, 0),
158 /* IEEE 802.11a, channels 34..48 */
159 REG_RULE(5170-20, 5240+20, 40, 6, 20,
160 NL80211_RRF_PASSIVE_SCAN),
161 /* IEEE 802.11a, channels 52..64 */
162 REG_RULE(5260-20, 5320+20, 40, 6, 20,
163 NL80211_RRF_NO_IBSS |
164 NL80211_RRF_DFS),
165 }
166};
167
168Then in some part of your code after your wiphy has been registered:
169
170 int r;
171 struct ieee80211_regdomain *rd;
172 int size_of_regd;
173 int num_rules = mydriver_jp_regdom.n_reg_rules;
174 unsigned int i;
175
176 size_of_regd = sizeof(struct ieee80211_regdomain) +
177 (num_rules * sizeof(struct ieee80211_reg_rule));
178
179 rd = kzalloc(size_of_regd, GFP_KERNEL);
180 if (!rd)
181 return -ENOMEM;
182
183 memcpy(rd, &mydriver_jp_regdom, sizeof(struct ieee80211_regdomain));
184
185 for (i=0; i < num_rules; i++) {
186 memcpy(&rd->reg_rules[i], &mydriver_jp_regdom.reg_rules[i],
187 sizeof(struct ieee80211_reg_rule));
188 }
189 r = regulatory_hint(hw->wiphy, NULL, rd);
190 if (r) {
191 kfree(rd);
192 return r;
193 }
194
diff --git a/Documentation/networking/tproxy.txt b/Documentation/networking/tproxy.txt
new file mode 100644
index 000000000000..7b5996d9357e
--- /dev/null
+++ b/Documentation/networking/tproxy.txt
@@ -0,0 +1,85 @@
1Transparent proxy support
2=========================
3
4This feature adds Linux 2.2-like transparent proxy support to current kernels.
5To use it, enable NETFILTER_TPROXY, the socket match and the TPROXY target in
6your kernel config. You will need policy routing too, so be sure to enable that
7as well.
8
9
101. Making non-local sockets work
11================================
12
13The idea is that you identify packets with destination address matching a local
14socket on your box, set the packet mark to a certain value, and then match on that
15value using policy routing to have those packets delivered locally:
16
17# iptables -t mangle -N DIVERT
18# iptables -t mangle -A PREROUTING -p tcp -m socket -j DIVERT
19# iptables -t mangle -A DIVERT -j MARK --set-mark 1
20# iptables -t mangle -A DIVERT -j ACCEPT
21
22# ip rule add fwmark 1 lookup 100
23# ip route add local 0.0.0.0/0 dev lo table 100
24
25Because of certain restrictions in the IPv4 routing output code you'll have to
26modify your application to allow it to send datagrams _from_ non-local IP
27addresses. All you have to do is enable the (SOL_IP, IP_TRANSPARENT) socket
28option before calling bind:
29
30fd = socket(AF_INET, SOCK_STREAM, 0);
31/* - 8< -*/
32int value = 1;
33setsockopt(fd, SOL_IP, IP_TRANSPARENT, &value, sizeof(value));
34/* - 8< -*/
35name.sin_family = AF_INET;
36name.sin_port = htons(0xCAFE);
37name.sin_addr.s_addr = htonl(0xDEADBEEF);
38bind(fd, &name, sizeof(name));
39
40A trivial patch for netcat is available here:
41http://people.netfilter.org/hidden/tproxy/netcat-ip_transparent-support.patch
42
43
442. Redirecting traffic
45======================
46
47Transparent proxying often involves "intercepting" traffic on a router. This is
48usually done with the iptables REDIRECT target; however, there are serious
49limitations of that method. One of the major issues is that it actually
50modifies the packets to change the destination address -- which might not be
51acceptable in certain situations. (Think of proxying UDP for example: you won't
52be able to find out the original destination address. Even in case of TCP
53getting the original destination address is racy.)
54
55The 'TPROXY' target provides similar functionality without relying on NAT. Simply
56add rules like this to the iptables ruleset above:
57
58# iptables -t mangle -A PREROUTING -p tcp --dport 80 -j TPROXY \
59 --tproxy-mark 0x1/0x1 --on-port 50080
60
61Note that for this to work you'll have to modify the proxy to enable (SOL_IP,
62IP_TRANSPARENT) for the listening socket.
63
64
653. Iptables extensions
66======================
67
68To use tproxy you'll need to have the 'socket' and 'TPROXY' modules
69compiled for iptables. A patched version of iptables is available
70here: http://git.balabit.hu/?p=bazsi/iptables-tproxy.git
71
72
734. Application support
74======================
75
764.1. Squid
77----------
78
79Squid 3.HEAD has support built-in. To use it, pass
80'--enable-linux-netfilter' to configure and set the 'tproxy' option on
81the HTTP listener you redirect traffic to with the TPROXY iptables
82target.
83
84For more information please consult the following page on the Squid
85wiki: http://wiki.squid-cache.org/Features/Tproxy4
diff --git a/Documentation/rfkill.txt b/Documentation/rfkill.txt
index 6fcb3060dec5..b65f0799df48 100644
--- a/Documentation/rfkill.txt
+++ b/Documentation/rfkill.txt
@@ -341,6 +341,8 @@ key that does nothing by itself, as well as any hot key that is type-specific
3413.1 Guidelines for wireless device drivers 3413.1 Guidelines for wireless device drivers
342------------------------------------------ 342------------------------------------------
343 343
344(in this text, rfkill->foo means the foo field of struct rfkill).
345
3441. Each independent transmitter in a wireless device (usually there is only one 3461. Each independent transmitter in a wireless device (usually there is only one
345transmitter per device) should have a SINGLE rfkill class attached to it. 347transmitter per device) should have a SINGLE rfkill class attached to it.
346 348
@@ -363,10 +365,32 @@ This rule exists because users of the rfkill subsystem expect to get (and set,
363when possible) the overall transmitter rfkill state, not of a particular rfkill 365when possible) the overall transmitter rfkill state, not of a particular rfkill
364line. 366line.
365 367
3665. During suspend, the rfkill class will attempt to soft-block the radio 3685. The wireless device driver MUST NOT leave the transmitter enabled during
367through a call to rfkill->toggle_radio, and will try to restore its previous 369suspend and hibernation unless:
368state during resume. After a rfkill class is suspended, it will *not* call 370
369rfkill->toggle_radio until it is resumed. 371 5.1. The transmitter has to be enabled for some sort of functionality
372 like wake-on-wireless-packet or autonomous packed forwarding in a mesh
373 network, and that functionality is enabled for this suspend/hibernation
374 cycle.
375
376AND
377
378 5.2. The device was not on a user-requested BLOCKED state before
379 the suspend (i.e. the driver must NOT unblock a device, not even
380 to support wake-on-wireless-packet or remain in the mesh).
381
382In other words, there is absolutely no allowed scenario where a driver can
383automatically take action to unblock a rfkill controller (obviously, this deals
384with scenarios where soft-blocking or both soft and hard blocking is happening.
385Scenarios where hardware rfkill lines are the only ones blocking the
386transmitter are outside of this rule, since the wireless device driver does not
387control its input hardware rfkill lines in the first place).
388
3896. During resume, rfkill will try to restore its previous state.
390
3917. After a rfkill class is suspended, it will *not* call rfkill->toggle_radio
392until it is resumed.
393
370 394
371Example of a WLAN wireless driver connected to the rfkill subsystem: 395Example of a WLAN wireless driver connected to the rfkill subsystem:
372-------------------------------------------------------------------- 396--------------------------------------------------------------------