diff options
author | Linus Torvalds <torvalds@linux-foundation.org> | 2008-10-11 12:33:18 -0400 |
---|---|---|
committer | Linus Torvalds <torvalds@linux-foundation.org> | 2008-10-11 12:33:18 -0400 |
commit | 4dd9ec4946b4651a295d3bc8df9c15ac692a8f4e (patch) | |
tree | afb300c752de7175bb2df4722d5c857e070c75d9 /Documentation | |
parent | 86ed5a93b8b56e4e0877b914af0e10883a196384 (diff) | |
parent | 6861ff35ec5b60fafaf8651754c9a75142bfa9a4 (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.tmpl | 12 | ||||
-rw-r--r-- | Documentation/feature-removal-schedule.txt | 21 | ||||
-rw-r--r-- | Documentation/networking/LICENSE.qlge | 46 | ||||
-rw-r--r-- | Documentation/networking/can.txt | 44 | ||||
-rw-r--r-- | Documentation/networking/multiqueue.txt | 54 | ||||
-rw-r--r-- | Documentation/networking/phonet.txt | 175 | ||||
-rw-r--r-- | Documentation/networking/regulatory.txt | 194 | ||||
-rw-r--r-- | Documentation/networking/tproxy.txt | 85 | ||||
-rw-r--r-- | Documentation/rfkill.txt | 32 |
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 | ||
9 | What: old static regulatory information and ieee80211_regdom module parameter | ||
10 | When: 2.6.29 | ||
11 | Why: 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. | ||
23 | Who: Luis R. Rodriguez <lrodriguez@atheros.com> | ||
24 | |||
25 | --------------------------- | ||
26 | |||
9 | What: dev->power.power_state | 27 | What: dev->power.power_state |
10 | When: July 2007 | 28 | When: July 2007 |
11 | Why: Broken design for runtime control over driver power states, confusing | 29 | Why: 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 | |||
235 | When: January 2009 or Linux 2.7.0, whichever comes first | 256 | When: January 2009 or Linux 2.7.0, whichever comes first |
236 | Why: Superseded by newer revisions or modules | 257 | Why: Superseded by newer revisions or modules |
237 | Who: Jan Engelhardt <jengelh@computergmbh.de> | 258 | Who: 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 @@ | |||
1 | Copyright (c) 2003-2008 QLogic Corporation | ||
2 | QLogic Linux Networking HBA Driver | ||
3 | |||
4 | This program includes a device driver for Linux 2.6 that may be | ||
5 | distributed with QLogic hardware specific firmware binary file. | ||
6 | You may modify and redistribute the device driver code under the | ||
7 | GNU General Public License as published by the Free Software | ||
8 | Foundation (version 2 or a later version). | ||
9 | |||
10 | You may redistribute the hardware specific firmware binary file | ||
11 | under 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 | |||
26 | REGARDLESS OF WHAT LICENSING MECHANISM IS USED OR APPLICABLE, | ||
27 | THIS PROGRAM IS PROVIDED BY QLOGIC CORPORATION "AS IS'' AND ANY | ||
28 | EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE | ||
29 | IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A | ||
30 | PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR | ||
31 | BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, | ||
32 | EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED | ||
33 | TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, | ||
34 | DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON | ||
35 | ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, | ||
36 | OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY | ||
37 | OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE | ||
38 | POSSIBILITY OF SUCH DAMAGE. | ||
39 | |||
40 | USER ACKNOWLEDGES AND AGREES THAT USE OF THIS PROGRAM WILL NOT | ||
41 | CREATE OR GIVE GROUNDS FOR A LICENSE BY IMPLICATION, ESTOPPEL, OR | ||
42 | OTHERWISE IN ANY INTELLECTUAL PROPERTY RIGHTS (PATENT, COPYRIGHT, | ||
43 | TRADE SECRET, MASK WORK, OR OTHER PROPRIETARY RIGHT) EMBODIED IN | ||
44 | ANY OTHER QLOGIC HARDWARE OR SOFTWARE EITHER SOLELY OR IN | ||
45 | COMBINATION 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 | |||
24 | device is still operational. netdev->queue_lock is still used when the device | 24 | device is still operational. netdev->queue_lock is still used when the device |
25 | comes online or when it's completely shut down (unregister_netdev(), etc.). | 25 | comes online or when it's completely shut down (unregister_netdev(), etc.). |
26 | 26 | ||
27 | Author: Peter P. Waskiewicz Jr. <peter.p.waskiewicz.jr@intel.com> | 27 | |
28 | Section 2: Qdisc support for multiqueue devices | ||
29 | |||
30 | ----------------------------------------------- | ||
31 | |||
32 | Currently two qdiscs are optimized for multiqueue devices. The first is the | ||
33 | default pfifo_fast qdisc. This qdisc supports one qdisc per hardware queue. | ||
34 | A new round-robin qdisc, sch_multiq also supports multiple hardware queues. The | ||
35 | qdisc is responsible for classifying the skb's and then directing the skb's to | ||
36 | bands and queues based on the value in skb->queue_mapping. Use this field in | ||
37 | the base driver to determine which queue to send the skb to. | ||
38 | |||
39 | sch_multiq has been added for hardware that wishes to avoid head-of-line | ||
40 | blocking. It will cycle though the bands and verify that the hardware queue | ||
41 | associated with the band is not stopped prior to dequeuing a packet. | ||
42 | |||
43 | On qdisc load, the number of bands is based on the number of queues on the | ||
44 | hardware. Once the association is made, any skb with skb->queue_mapping set, | ||
45 | will be queued to the band associated with the hardware queue. | ||
46 | |||
47 | |||
48 | Section 3: Brief howto using MULTIQ for multiqueue devices | ||
49 | --------------------------------------------------------------- | ||
50 | |||
51 | The userspace command 'tc,' part of the iproute2 package, is used to configure | ||
52 | qdiscs. To add the MULTIQ qdisc to your network device, assuming the device | ||
53 | is called eth0, run the following command: | ||
54 | |||
55 | # tc qdisc add dev eth0 root handle 1: multiq | ||
56 | |||
57 | The qdisc will allocate the number of bands to equal the number of queues that | ||
58 | the device reports, and bring the qdisc online. Assuming eth0 has 4 Tx | ||
59 | queues, the band mapping would look like: | ||
60 | |||
61 | band 0 => queue 0 | ||
62 | band 1 => queue 1 | ||
63 | band 2 => queue 2 | ||
64 | band 3 => queue 3 | ||
65 | |||
66 | Traffic will begin flowing through each queue based on either the simple_tx_hash | ||
67 | function or based on netdev->select_queue() if you have it defined. | ||
68 | |||
69 | The behavior of tc filters remains the same. However a new tc action, | ||
70 | skbedit, has been added. Assuming you wanted to route all traffic to a | ||
71 | specific host, for example 192.168.0.3, through a specific queue you could use | ||
72 | this action and establish a filter such as: | ||
73 | |||
74 | tc 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 | |||
78 | Author: Alexander Duyck <alexander.h.duyck@intel.com> | ||
79 | Original 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 @@ | |||
1 | Linux Phonet protocol family | ||
2 | ============================ | ||
3 | |||
4 | Introduction | ||
5 | ------------ | ||
6 | |||
7 | Phonet is a packet protocol used by Nokia cellular modems for both IPC | ||
8 | and RPC. With the Linux Phonet socket family, Linux host processes can | ||
9 | receive and send messages from/to the modem, or any other external | ||
10 | device attached to the modem. The modem takes care of routing. | ||
11 | |||
12 | Phonet packets can be exchanged through various hardware connections | ||
13 | depending 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 | |||
21 | Packets format | ||
22 | -------------- | ||
23 | |||
24 | Phonet 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 | |||
36 | On Linux, the link-layer header includes the pn_media byte (see below). | ||
37 | The next 7 bytes are part of the network-layer header. | ||
38 | |||
39 | The device ID is split: the 6 higher-order bits consitute the device | ||
40 | address, while the 2 lower-order bits are used for multiplexing, as are | ||
41 | the 8-bit object identifiers. As such, Phonet can be considered as a | ||
42 | network layer with 6 bits of address space and 10 bits for transport | ||
43 | protocol (much like port numbers in IP world). | ||
44 | |||
45 | The modem always has address number zero. All other device have a their | ||
46 | own 6-bit address. | ||
47 | |||
48 | |||
49 | Link layer | ||
50 | ---------- | ||
51 | |||
52 | Phonet links are always point-to-point links. The link layer header | ||
53 | consists of a single Phonet media type byte. It uniquely identifies the | ||
54 | link through which the packet is transmitted, from the modem's | ||
55 | perspective. Each Phonet network device shall prepend and set the media | ||
56 | type byte as appropriate. For convenience, a common phonet_header_ops | ||
57 | link-layer header operations structure is provided. It sets the | ||
58 | media type according to the network device hardware address. | ||
59 | |||
60 | Linux Phonet network interfaces support a dedicated link layer packets | ||
61 | type (ETH_P_PHONET) which is out of the Ethernet type range. They can | ||
62 | only send and receive Phonet packets. | ||
63 | |||
64 | The virtual TUN tunnel device driver can also be used for Phonet. This | ||
65 | requires IFF_TUN mode, _without_ the IFF_NO_PI flag. In this case, | ||
66 | there is no link-layer header, so there is no Phonet media type byte. | ||
67 | |||
68 | Note that Phonet interfaces are not allowed to re-order packets, so | ||
69 | only the (default) Linux FIFO qdisc should be used with them. | ||
70 | |||
71 | |||
72 | Network layer | ||
73 | ------------- | ||
74 | |||
75 | The 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 | |||
85 | The resource field is only used when sending and receiving; | ||
86 | It is ignored by bind() and getsockname(). | ||
87 | |||
88 | |||
89 | Low-level datagram protocol | ||
90 | --------------------------- | ||
91 | |||
92 | Applications can send Phonet messages using the Phonet datagram socket | ||
93 | protocol from the PF_PHONET family. Each socket is bound to one of the | ||
94 | 2^10 object IDs available, and can send and receive packets with any | ||
95 | other 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 | |||
110 | This protocol follows the SOCK_DGRAM connection-less semantics. | ||
111 | However, connect() and getpeername() are not supported, as they did | ||
112 | not seem useful with Phonet usages (could be added easily). | ||
113 | |||
114 | |||
115 | Phonet Pipe protocol | ||
116 | -------------------- | ||
117 | |||
118 | The Phonet Pipe protocol is a simple sequenced packets protocol | ||
119 | with end-to-end congestion control. It uses the passive listening | ||
120 | socket paradigm. The listening socket is bound to an unique free object | ||
121 | ID. Each listening socket can handle up to 255 simultaneous | ||
122 | connections, 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 | |||
141 | Connections are established between two endpoints by a "third party" | ||
142 | application. This means that both endpoints are passive; so connect() | ||
143 | is not possible. | ||
144 | |||
145 | WARNING: | ||
146 | When polling a connected pipe socket for writability, there is an | ||
147 | intrinsic race condition whereby writability might be lost between the | ||
148 | polling and the writing system calls. In this case, the socket will | ||
149 | block until write because possible again, unless non-blocking mode | ||
150 | becomes enabled. | ||
151 | |||
152 | |||
153 | The 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 | |||
169 | Authors | ||
170 | ------- | ||
171 | |||
172 | Linux Phonet was initially written by Sakari Ailus. | ||
173 | Other contributors include Mikä Liljeberg, Andras Domokos, | ||
174 | Carlos Chinea and Rémi Denis-Courmont. | ||
175 | Copyright (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 @@ | |||
1 | Linux wireless regulatory documentation | ||
2 | --------------------------------------- | ||
3 | |||
4 | This document gives a brief review over how the Linux wireless | ||
5 | regulatory infrastructure works. | ||
6 | |||
7 | More up to date information can be obtained at the project's web page: | ||
8 | |||
9 | http://wireless.kernel.org/en/developers/Regulatory | ||
10 | |||
11 | Keeping regulatory domains in userspace | ||
12 | --------------------------------------- | ||
13 | |||
14 | Due to the dynamic nature of regulatory domains we keep them | ||
15 | in userspace and provide a framework for userspace to upload | ||
16 | to the kernel one regulatory domain to be used as the central | ||
17 | core regulatory domain all wireless devices should adhere to. | ||
18 | |||
19 | How to get regulatory domains to the kernel | ||
20 | ------------------------------------------- | ||
21 | |||
22 | Userspace gets a regulatory domain in the kernel by having | ||
23 | a userspace agent build it and send it via nl80211. Only | ||
24 | expected regulatory domains will be respected by the kernel. | ||
25 | |||
26 | A currently available userspace agent which can accomplish this | ||
27 | is CRDA - central regulatory domain agent. Its documented here: | ||
28 | |||
29 | http://wireless.kernel.org/en/developers/Regulatory/CRDA | ||
30 | |||
31 | Essentially the kernel will send a udev event when it knows | ||
32 | it needs a new regulatory domain. A udev rule can be put in place | ||
33 | to trigger crda to send the respective regulatory domain for a | ||
34 | specific ISO/IEC 3166 alpha2. | ||
35 | |||
36 | Below is an example udev rule which can be used: | ||
37 | |||
38 | # Example file, should be put in /etc/udev/rules.d/regulatory.rules | ||
39 | KERNEL=="regulatory*", ACTION=="change", SUBSYSTEM=="platform", RUN+="/sbin/crda" | ||
40 | |||
41 | The alpha2 is passed as an environment variable under the variable COUNTRY. | ||
42 | |||
43 | Who asks for regulatory domains? | ||
44 | -------------------------------- | ||
45 | |||
46 | * Users | ||
47 | |||
48 | Users can use iw: | ||
49 | |||
50 | http://wireless.kernel.org/en/users/Documentation/iw | ||
51 | |||
52 | An example: | ||
53 | |||
54 | # set regulatory domain to "Costa Rica" | ||
55 | iw reg set CR | ||
56 | |||
57 | This will request the kernel to set the regulatory domain to | ||
58 | the specificied alpha2. The kernel in turn will then ask userspace | ||
59 | to provide a regulatory domain for the alpha2 specified by the user | ||
60 | by sending a uevent. | ||
61 | |||
62 | * Wireless subsystems for Country Information elements | ||
63 | |||
64 | The kernel will send a uevent to inform userspace a new | ||
65 | regulatory domain is required. More on this to be added | ||
66 | as its integration is added. | ||
67 | |||
68 | * Drivers | ||
69 | |||
70 | If drivers determine they need a specific regulatory domain | ||
71 | set they can inform the wireless core using regulatory_hint(). | ||
72 | They have two options -- they either provide an alpha2 so that | ||
73 | crda can provide back a regulatory domain for that country or | ||
74 | they can build their own regulatory domain based on internal | ||
75 | custom knowledge so the wireless core can respect it. | ||
76 | |||
77 | *Most* drivers will rely on the first mechanism of providing a | ||
78 | regulatory hint with an alpha2. For these drivers there is an additional | ||
79 | check that can be used to ensure compliance based on custom EEPROM | ||
80 | regulatory data. This additional check can be used by drivers by | ||
81 | registering on its struct wiphy a reg_notifier() callback. This notifier | ||
82 | is called when the core's regulatory domain has been changed. The driver | ||
83 | can 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 | ||
85 | internal EEPROM data. Devices drivers wishing to be capable of world | ||
86 | roaming should use this callback. More on world roaming will be | ||
87 | added to this document when its support is enabled. | ||
88 | |||
89 | Device drivers who provide their own built regulatory domain | ||
90 | do not need a callback as the channels registered by them are | ||
91 | the only ones that will be allowed and therefore *additional* | ||
92 | cannels cannot be enabled. | ||
93 | |||
94 | Example code - drivers hinting an alpha2: | ||
95 | ------------------------------------------ | ||
96 | |||
97 | This example comes from the zd1211rw device driver. You can start | ||
98 | by having a mapping of your device's EEPROM country/regulatory | ||
99 | domain value to to a specific alpha2 as follows: | ||
100 | |||
101 | static 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 | |||
110 | Then you can define a routine to map your read EEPROM value to an alpha2, | ||
111 | as follows: | ||
112 | |||
113 | static 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 = ®_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 | |||
128 | Lastly, you can then hint to the core of your discovered alpha2, if a match | ||
129 | was found. You need to do this after you have registered your wiphy. You | ||
130 | are 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 | |||
136 | Example code - drivers providing a built in regulatory domain: | ||
137 | -------------------------------------------------------------- | ||
138 | |||
139 | If you have regulatory information you can obtain from your | ||
140 | driver and you *need* to use this we let you build a regulatory domain | ||
141 | structure and pass it to the wireless core. To do this you should | ||
142 | kmalloc() a structure big enough to hold your regulatory domain | ||
143 | structure and you should then fill it with your data. Finally you simply | ||
144 | call regulatory_hint() with the regulatory domain structure in it. | ||
145 | |||
146 | Bellow is a simple example, with a regulatory domain cached using the stack. | ||
147 | Your implementation may vary (read EEPROM cache instead, for example). | ||
148 | |||
149 | Example cache of some regulatory domain | ||
150 | |||
151 | struct 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 | |||
168 | Then 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 @@ | |||
1 | Transparent proxy support | ||
2 | ========================= | ||
3 | |||
4 | This feature adds Linux 2.2-like transparent proxy support to current kernels. | ||
5 | To use it, enable NETFILTER_TPROXY, the socket match and the TPROXY target in | ||
6 | your kernel config. You will need policy routing too, so be sure to enable that | ||
7 | as well. | ||
8 | |||
9 | |||
10 | 1. Making non-local sockets work | ||
11 | ================================ | ||
12 | |||
13 | The idea is that you identify packets with destination address matching a local | ||
14 | socket on your box, set the packet mark to a certain value, and then match on that | ||
15 | value 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 | |||
25 | Because of certain restrictions in the IPv4 routing output code you'll have to | ||
26 | modify your application to allow it to send datagrams _from_ non-local IP | ||
27 | addresses. All you have to do is enable the (SOL_IP, IP_TRANSPARENT) socket | ||
28 | option before calling bind: | ||
29 | |||
30 | fd = socket(AF_INET, SOCK_STREAM, 0); | ||
31 | /* - 8< -*/ | ||
32 | int value = 1; | ||
33 | setsockopt(fd, SOL_IP, IP_TRANSPARENT, &value, sizeof(value)); | ||
34 | /* - 8< -*/ | ||
35 | name.sin_family = AF_INET; | ||
36 | name.sin_port = htons(0xCAFE); | ||
37 | name.sin_addr.s_addr = htonl(0xDEADBEEF); | ||
38 | bind(fd, &name, sizeof(name)); | ||
39 | |||
40 | A trivial patch for netcat is available here: | ||
41 | http://people.netfilter.org/hidden/tproxy/netcat-ip_transparent-support.patch | ||
42 | |||
43 | |||
44 | 2. Redirecting traffic | ||
45 | ====================== | ||
46 | |||
47 | Transparent proxying often involves "intercepting" traffic on a router. This is | ||
48 | usually done with the iptables REDIRECT target; however, there are serious | ||
49 | limitations of that method. One of the major issues is that it actually | ||
50 | modifies the packets to change the destination address -- which might not be | ||
51 | acceptable in certain situations. (Think of proxying UDP for example: you won't | ||
52 | be able to find out the original destination address. Even in case of TCP | ||
53 | getting the original destination address is racy.) | ||
54 | |||
55 | The 'TPROXY' target provides similar functionality without relying on NAT. Simply | ||
56 | add 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 | |||
61 | Note that for this to work you'll have to modify the proxy to enable (SOL_IP, | ||
62 | IP_TRANSPARENT) for the listening socket. | ||
63 | |||
64 | |||
65 | 3. Iptables extensions | ||
66 | ====================== | ||
67 | |||
68 | To use tproxy you'll need to have the 'socket' and 'TPROXY' modules | ||
69 | compiled for iptables. A patched version of iptables is available | ||
70 | here: http://git.balabit.hu/?p=bazsi/iptables-tproxy.git | ||
71 | |||
72 | |||
73 | 4. Application support | ||
74 | ====================== | ||
75 | |||
76 | 4.1. Squid | ||
77 | ---------- | ||
78 | |||
79 | Squid 3.HEAD has support built-in. To use it, pass | ||
80 | '--enable-linux-netfilter' to configure and set the 'tproxy' option on | ||
81 | the HTTP listener you redirect traffic to with the TPROXY iptables | ||
82 | target. | ||
83 | |||
84 | For more information please consult the following page on the Squid | ||
85 | wiki: 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 | |||
341 | 3.1 Guidelines for wireless device drivers | 341 | 3.1 Guidelines for wireless device drivers |
342 | ------------------------------------------ | 342 | ------------------------------------------ |
343 | 343 | ||
344 | (in this text, rfkill->foo means the foo field of struct rfkill). | ||
345 | |||
344 | 1. Each independent transmitter in a wireless device (usually there is only one | 346 | 1. Each independent transmitter in a wireless device (usually there is only one |
345 | transmitter per device) should have a SINGLE rfkill class attached to it. | 347 | transmitter 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, | |||
363 | when possible) the overall transmitter rfkill state, not of a particular rfkill | 365 | when possible) the overall transmitter rfkill state, not of a particular rfkill |
364 | line. | 366 | line. |
365 | 367 | ||
366 | 5. During suspend, the rfkill class will attempt to soft-block the radio | 368 | 5. The wireless device driver MUST NOT leave the transmitter enabled during |
367 | through a call to rfkill->toggle_radio, and will try to restore its previous | 369 | suspend and hibernation unless: |
368 | state during resume. After a rfkill class is suspended, it will *not* call | 370 | |
369 | rfkill->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 | |||
376 | AND | ||
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 | |||
382 | In other words, there is absolutely no allowed scenario where a driver can | ||
383 | automatically take action to unblock a rfkill controller (obviously, this deals | ||
384 | with scenarios where soft-blocking or both soft and hard blocking is happening. | ||
385 | Scenarios where hardware rfkill lines are the only ones blocking the | ||
386 | transmitter are outside of this rule, since the wireless device driver does not | ||
387 | control its input hardware rfkill lines in the first place). | ||
388 | |||
389 | 6. During resume, rfkill will try to restore its previous state. | ||
390 | |||
391 | 7. After a rfkill class is suspended, it will *not* call rfkill->toggle_radio | ||
392 | until it is resumed. | ||
393 | |||
370 | 394 | ||
371 | Example of a WLAN wireless driver connected to the rfkill subsystem: | 395 | Example of a WLAN wireless driver connected to the rfkill subsystem: |
372 | -------------------------------------------------------------------- | 396 | -------------------------------------------------------------------- |