NOTE: this page is for archival only, see the note at the end of the page.

Linux Wireless Subsystem

By Rami Rosen

Rami Rosen website

This wiki page is based on a my practical experience with Linux kernel networking and a series of lectures I gave in the Technion:

See:

Rami Rosen lectures

It gives description of Linux Wireless Subsystem (802.11) including some implementation details.

Please feel free to send any feedback or question to Rami Rosen by sending email to: ramirose@gmail.com

I will try hard to answer each and every question (though sometimes it takes time)

Linux Wireless Subsystem (802.11).

Each MAC frame consists of a MAC header, a frame body of variable length and an FCS (Frame Check Sequence) of 32 bit CRC. Next figure shows the 802.11 header.

The 802.11 header is represented in mac80211 by a structure called ieee80211_hdr

(include/linux/ieee80211.h).

As opposed to an Ethernet header (struct ethhdr), which contains only three fields (source MAC address, destination MAC address, and type), the 802.11 header contains four addresses and not two, and some other fields.

frame control:

  • The first field in the 802.11 header is called the frame control: it is a an important

field and in many cases, its contents determine the meaning of other fields of the 802.11 header (especially addresses). The frame control length is 16 bits; following here is a discussion of its fields.

Protocol version:

The version of the MAC 802.11 we use. Currently there is only one version of MAC, so this field is always 0.

Type:

There are three types of packets in 802.11:management, control and data.

● Management packets (IEEE80211_FTYPE_MGMT) are for management actions like association, authentication, scanning and more. We will deal more with management packets in the following sections.

● Control packets (IEEE80211_FTYPE_CTL) usually have some relevance to data packets; for example, a PS Poll packet is for retrieving packets from an Access Point buffer. Another example: a station that wants to transmit first sends a control packet called RTS (request to send); if the medium is free, the destination station will send a control packet called CTS (clear to send).

● Data packets (IEEE80211_FTYPE_DATA) are the raw data packets. Null packets are a special case of raw packets.

There is also IEEE80211_FTYPE_EXT type - we will not discuss it.

These types are defined in /include/linux/ieee80211.h

Subtype: For all the aforementioned three types of packets (management, control and data), there is a subtype field which identify the character of the packet we use. For example, a value of 0100 for the subtype field in a management frame denotes that the packet is a Probe Request (IEEE80211_STYPE_PROBE_REQ) management packet, which is used in a scan operation. Notice that the action management frame (IEEE80211_STYPE_ACTION) was introduced with 802.11h amendment, which dealt with spectrum and transmit power management; however, since there is a lack of space for management packets subtypes, action management frames are used also in 802.11n management packets. A value of 1011 for the subtype field in a control packet denotes that this is a request to send (IEEE80211_STYPE_RTS) control packet. A value of 0100 for the subtype field of a data packet denotes that this a a null data (IEEE80211_STYPE_NULLFUNC) packet, which is used for power management control. A value of 1000 (IEEE80211_STYPE_QOS_DATA) for a subtype of a data packet means that this is a QoS data packet; this subtype was added by the IEEE802.11e amendment, which dealt with QoS enhancements.

ToDS: When this bit is set, this means that the packet is for the distribution system.

FromDS: When this bit is set, this means that the packet is from the distribution system.

More Frag: When we use fragmentation, this bit is set to 1.

Retry: When a packet is retransmitted, this packet is set to 1. A common case of retransmission is when a packet that was sent did not receive an acknowledgment in time. The acknowledgements are sent by the firmware of the wireless driver.

Pwr Mgmt: When the power management bit is set, this means that the station will enter power save mode.

More Data: When an Access Points sends packets that it buffered for a sleeping station, it sets the more data bit to 1 when the buffer is not empty. Thus the station knows that there are more packets it should retrieve. When the buffer has been emptied, this bit is set to 0.

Protected Frame: This bit is set to 1 when the frame body in encrypted; only data frames and authentication frames can be encrypted.

Order: There is a MAC service called “strict ordering”. With this service, the order of frames is important. When this service is in use, the order bit is set to 1. It is rarely used.

Duration/ID: The duration holds values for the Network Allocation Vector (NAV) in microseconds, and it consists of 15 bits of the duration field. The sixteenth field is 0. When working in power save mode it is the AID (Association ID) of a station. The Network Allocation Vector (NAV) is a virtual carrier sensing mechanism.

Sequence control: This is a 2 byte field specifying the sequence control. In 802.11, it is possible that a packet will be received more than once. The most common cause for such a case is when an acknowledgement is not received for some reason. The sequence control field consists of a fragment number (4 bits) and a sequence number (12 bits). The sequence number is generated by the transmitting station, in ieee80211_tx_h_sequence(). In case of a duplicate frame in a retransmission, it is dropped, and a counter of the dropped duplicate frames (dot11FrameDuplicateCount) is incremented by 1; this is done in ieee80211_rx_h_check(). Sequence Control field is not present in control packets.

Address Fields:

There are four addresses, but we don't always use all of them. Address 1 is the Receive Address (RA), and is used in all packets. Address 2 is the Transmit Address (TA), and it exists in all packets except ACK and CTS packets. Address 3 is used only for management and data packets. Address 4 is used when ToDS and FromDS bits of the frame control are set; this happens when operating in a Wireless Distribution System (WDS).

OoS Control: The QoS Control field was added by 802.11e amendment and it is only present in QoS data packets. Since it is not part of the original 802.11 spec, it is not part of the original mac80211 implementation, so it is not a member of the ieee80211_hdr struct. In fact, it was added at the end of 802.11 header and it can be accessed by ieee80211_get_qos_ctl() method. The QoS Control field includes the tid (Traffic Identification), the Ack Policy, and a field called A-MSDU present, which tells whether an A-MSDU is present.

HT Control Field:

HT Control Field was added by 802.11n amendment. HT stands for High Throughput. One of the most important features of 802.11n amendment is increasing the rate to up to 600 Mbps.

All stations must authenticate and associate and with the Access Point prior to communicating.

Stations usually perform scanning prior to authentication and association in order to get details about the Access Point (like mac address, essid, and more).

Scanning is done thus:

ifconfig wlan0 up iwlist wlan0 scan

Scanning is triggered by issuing SIOCSIWSCAN ioctl (include/linux/wireless.h)

iwlist (and iwconfig) is from wireless-tools package.

Please note: wireless-tools is regarded deprecated. We should use "iw", which is more

modern and which is based on nl80211.

You can download iw from http://linuxwireless.org/download/iw/.

iw git repositories are at: http://git.sipsolutions.net/iw.git

Eventually, scanning starts by calling ieee80211_start_scan()

(net/mac80211/scan.c)

  • Active Scanning is performed by sending Probe

Requests on all the channels which are supported by the station

Open-system authentication (WLAN_AUTH_OPEN) is the only mandatory authentication method required by 802.11.

(WLAN_AUTH_OPEN is defined in include/linux/ieee80211.h)

● At a given moment, a station may be associated with no more than one AP. ● A Station (“STA”) can select a BSS and authenticate and associate to it.

● In Ad-Hoc : authentication is not defined.

● An Acess Point will not receive any data frames from a station before it it is associated with the AP.

● An Access Point which receive an association request will check whether the mobile station parameters match the Access point parameters.

– These parameters are SSID, Supported Rates and capability information.

● When a station associates to an Access Point, it gets an ASSOCIATION ID (AID) in the range 1-2007.

● Trying unsuccessfully to associate more than 3 times results with this message in the kernel log:

"association with AP apMacAddress timed out"

(IEEE80211_ASSOC_MAX_TRIES is the number of max tries to associate, see

net/mac80211/mlme.c)

Hostapd

hostapd is a user space daemon implementing access point functionality (and authentication servers). It supports Linux and FreeBSD.

http://hostap.epitest.fi/hostapd/

● Developed by Jouni Malinen

● hostapd.conf is the configuration file.

● Certain devices, which support Master Mode, can be operated as Access Points by running the hostapd daemon. ● Hostapd implements part of the MLME AP code which is not in the kernel ● and probably will not be in the near future. ● For example: handling association requests which are received from wireless clients.

Hostapd manages: ● Association/Disassociation requests. ● Authentication/deauthentication requests.

  • wpa_supplicant is part of hostapd project

You can clone hostap by:

git clone git://w1.fi/srv/git/hostap.git

Power save mode

  • Hardware can handle power save by itself; when this is done, it should set the IEEE80211_HW_SUPPORTS_PS flag.

There are three types of IEEE80211 packets: Management, control and data.

(These correspond to IEEE80211_FTYPE_MGMT,

IEEE80211_FTYPE_CTL and IEEE80211_FTYPE_DATA In the mac80211 stack).

● Control packets include RTS (Request to Send), CTS (Clear to Send) and ACK packets.

● Management packets are used for Authentication and Assoication.

● Mobile devices are usually battery powered most of the time. ● A station may be in one of two different modes:

  • – Awake (fully powered) – Asleep (also termed “dozed” in the specs)

● Access points never enters power save mode and does not transmit Null packets. ● In power save mode, the station is not able to transmit or receive and consumes very low power.

  • In order to sniff wireless traffic in Linux with wireshark, you can do this:

iwconfig wlan0 mode monitor ifconfig wlan0 up

And then start wireshark and select the wlan0 interface.

You can know the channel number while sniffing by looking at the radiotap header in the sniffer output; channel frequency translates to a channel number (1 to 1 correspondence.) Moreover, the channel number appears in square brackets. Like: – channel frequency 2437 [BG 6]

The radiotap header is added in certain cases under monitor mode.

It precedes the 802.11 header.

It is done in ieee80211_add_rx_radiotap_header() in net/mac80211/rx.c

ieee80211_add_rx_radiotap_header() is invoked from:

ieee80211_rx_monitor(). ieee80211_rx_cooked_monitor().

You can know the mac address of your wireless nic by:

cat /sys/class/ieee80211/phy*/macaddress

● A station send a null packet by calling ieee80211_send_nullfunc()

(net/mac80211/mlme.c)

  • The PM bit in the frame control of this packet is set. (IEEE80211_FCTL_PM bit)

● Each access point has an array of skbs for buffering unicast packets from the stations which enter power save mode.

● It is called ps_tx_buf (in struct sta_info; see net/mac80211/sta_info.h)

ps_tx_buf can buffer up to 64 skbs. (STA_MAX_TX_BUFFER=64, in net/mac80211/sta_info.h)

In case the buffer is filled, old skbs will be dropped.

● When a station enters PS mode it turns off its RF. From time to time it turns the RF on, but only for receiving beacons.

● An Access Point sends beacon frames periodically.

● Each beacon has a TIM (Traffic Indication Map) field.

AD Hoc

Implelementation of 802.11 AD Hoc is mainly in: net/mac80211/ibss.c

ieee80211_if_ibss structure represents an AD hoc station.

  • 80211.n

80211.n started with the High Throughput Study Group in about 2002.

In 802.11, each packet should be acknowledged. In 802.11nm we grouping packets in a block and acknowledging this block instead acknowledging each packet separately. This improves performance. Grouping packets in a block in this way is called "packet aggregation" in 802.11n terminology.

  • There are two forms of aggregation:

● AMPDU (The more common form)

A-MPDU aggregation requires the use of block acknowledgement or BlockAck, which was introduced in 802.11e and has been optimized in 802.11n.

802.11e is the quality-of-service extensions amendment.

The 802.11e amendment deals with QoS; it introduced four queues for different types of traffic: voice traffic, video traffic, best-effort traffic and background traffic. The Linux implementation of 802.11e uses multiqueues. Traffic in higher priority queue is transmitted before traffic in a lower priority queue.

MPDU stand for: MAC protocol data units

● AMSDU

With AMSDU, you make one big packet out of some packets.

This big packet should be acked.

Disadvantage: more risk of corruption of the big packet.

Less in usage, fading out.

MSDU stands for: MAC service data units.

Packet aggregation

● There are two sides to a block ack session: originator and recipient. Each block session has a different TID (traffic identifier).

● The originator starts the block acknowledge session by calling ieee80211_start_tx_ba_session() (net/mac80211/agg-tx.c)

ieee80211_tx_ba_session_handle_start() is a callback of ieee80211_start_tx_ba_session(). In this callback we send an ADDBA (add Block Acknowledgment) request packet, by invoking ieee80211_send_addba_request() method (Also in net/mac80211/agg-tx.c)

ieee80211_send_addba_request() method builds a management action packet

(The sub type is action, IEEE80211_STYPE_ACTION).

The response to the ADDBA request should be received within 1 HZ, which is one millisecond in x86_64 machines (ADDBA_RESP_INTERVAL, defined in net-next/net/mac80211/sta_info.h)

In case we do not get a response in time, the sta_addba_resp_timer_expired() will stop the BA session by calling ieee80211_stop_tx_ba_session().

When the other side (the recipient) receives the ADDBA request, it first sends an ACK. Then it processes the ADDBA request by calling ieee80211_process_addba_request(); (net/mac80211/agg-rx.c)

if everything is ok, it sets the aggregation state of this machine to operational (HT_AGG_STATE_OPERATIONAL), and sends an ADDBA Response by calling ieee80211_send_addba_resp().

After a session was started, a data block, containing multiple MPDU packets is sent. Consequently, the originator sends a Block Ack Request (BAR) packet by calling ieee80211_send_bar(). (net/mac80211/agg-tx.c)

The BAR is a control packet with Block Ack Request subtype (IEEE80211_STYPE_BACK_REQ).

The bar packet includes the SSN (start sequence number), which is the sequence number of the oldest MSDU in the block which should be acknowledged.

The BAR (HT Block Ack Request) is defined in include/linux/ieee80211.h.

Its start_seq_num member is initialized to the proper SSN.

There are two types of Block Ack: Immediate Block Ack and Delayed Block Ack.

Mac80211 debugfs support:

In order to have mac80211 debugfs support, kernel should be built with CONFIG_MAC80211_DEBUGFS (and CONFIG_DEBUG_FS)

Then after:

mount -t debugfs debugfs /sys/kernel/debug

You can see debugfs entries under:

/sys/kernel/debug/ieee80211/phy*

Open Firmware

The Atheros 802.11n USB chipset (AR9170) has open firmware;

see http://www.linuxwireless.org/en/users/Drivers/ar9170.fw

802.11 AC

The next generation of 802.11 is AC.

Support for 802.11AC was added in mac80211 stack. For example,

ieee80211_ie_build_vht_cap() in net/mac80211/util.c.

struct ieee80211_vht_capabilities and struct ieee80211_vht_operation

in include/linux/ieee80211.h.

VHT stands for: Very Hight Throughput

Development:

Sending patches should be done agains the wireless-testing tree

git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-testing.git

The maintainer of compat wireless is Luis R. Rodriguez.

Mesh networking (802.11s)

802.11s started as a Study Group of IEEE in September 2003, and became a Task Group named TGs in 2004.

In 2006, two proposals, out of 15, (the "SEEMesh" and "Wi-Mesh" proposals) were merged into one. This is draft D0.01.

There are two topologies for mesh networks.

The first is full mesh; with full mesh, each node is connected to all the other nodes. The second mesh topology is partial mesh. With partial mesh, nodes are connected to only some of the other nodes, not all. This topology is much more common in wireless mesh networks. In 2.6.26, the network stack added support for the draft of wireless mesh networking (802.11s), thanks to the open80211s project. The open80211s project goal was to create the first openimplementation of 802.11s. The project got some sponsorship from the OLPC project. Luis Carlos Cobo and Javier Cardona and other developers from Cozybit developed the Linux mac80211 mesh code. This code was merged into the Linux Kernel from 2.6.26 release (July 2008). There are some drivers in the linux kernel with support to mesh networking (ath5k, b43, libertas_tf, p54, zd1211rw).

HWMP protocol. 802.11s defines a default routing protocol called HWMP (Hybrid Wireless Mesh Protocol). The HWMP protocol works with layer 2 (Mac addresses) as opposed to IPV4 routing protocol, for example, which works with layer 3 (IP addresses). HWMP routing is based on two types of routing (hence it is called hybrid). The first is on demand routing and the second is proactive, dynamic routing. Currently only on demand routing is implemented in the Linux Kernel. We have three types of messages with on demand routing. The first is PREQ (Path Request). This type of messages is sent as a broadcast when we look for some destination, which we still do not have a route to. This PREQ message is propagated in the mesh until it gets to its destination. On each station until the final destination is reached, a lookup is performed (by mesh_path_lookup(), net/mac80211/mesh_pathtbl.c).

In case the lookup fails, the PREQ is forwarded (as a broadcast).

The PREQ message is sent in a management packet; its subtype is a

Then a PREP (Path Reply) unicast packet is sent. This packet is sent in the reverse path. The PREP message is also sent in a management packet; its subtype is also action. (IEEE80211_STYPE_ACTION). It is handled by hwmp_prep_frame_process(). Both PREQ and PREP are sent in the mesh_path_sel_frame_tx() function. If there is some failure on the way, a PERR is sent.(Path Error). A PERR message is handled by mesh_path_error_tx(). The route take into consideration a radio-aware metric (airtime metric). The airtime metric is calculated in the airtime_link_metric_get() method , net/mac80211/mesh_hwmp.c(based on rate and other hardware parameters). Mesh Points continuously monitor their links and update metric values with neighbours.

The station which sent the PREQ may try to send packets to the final destination while still not knowing the route to that destination; these packets are kept in a buffer called frame_queue, which is a member of mesh_path struct; net/mac80211/mesh.h) in such a case, when a PREP finally arrives, the pending packets of this buffer are sent to the final destination (by calling mesh_path_tx_pending()). The maximum number of frames buffered per destination for unresolved destinations is 10 (MESH_FRAME_QUEUE_LEN, defined in net/mac80211/mesh.h).

The advantages of mesh networking are: ● Rapid deployment. ● Minimal configuration; inexpensive. ● Easy to deploy in hard-to-wire environments. ● Connectivity while nodes are in motion.

The disadvantages: ● Many broadcasts limit network performance ● Not all wireless drivers support mesh mode at the moment.

Tip for hacking mac80211 with openwrt:


The WRTG54L LinkSys wireless router comes out of factory with Linux.

In case you want to hack mac80211 with OpenWrt, you can do it with backfire or

with kamikaze, which are versions of OpenWrt. In case of kamikaze, you will soon find out that with recent kamikaze releases (8.09.1 and 8.09.2), the wireless driver does not exist (kmod-b43).

For this reason "opkg install kmod-b43" fails on kamikaze 8.09.1 and kamikaze 8.09.2.

You can use also kamikaze 9.0.2 and build the broadcom wireless driver as a kernel module. A simple way of achieving this is thus: "make kernel_menuconfig" Then: select driver/network/wireless/B43 by

(Broadcom 43xx wireless support (mac80211 stack))

  • CONFIG_B43 should be "m". Make sure that you create also mac80211.ko and cfg80211.ko

/work/src/backfire_svn/build_dir/linux-brcm47xx/compat-wireless-2011-12-

The source files for b43 drivers selected in this way are under

build_dir/linux-brcm47xx/compat-wireless-2011-12-01/drivers/net/wireless/b43

Tip:

When working with b43 kernel module (b43.ko) it is enough to run

make target/linux/compile

in order to create b43.ko (under build_dir/linux-brcm47xx/linux-2.6.32.27/drivers/net/wireless/b43/) and copy it.

The hostapd sources are under:

  • build_dir/target-mipsel_uClibc-0.9.30.1/hostapd-full
    • Copy cfg80211.ko, mac80211.ko and b43.ko to the linksys device. Insert them by this order: insmod cfg80211.ko insmod mac80211.ko insmod b43.ko iwconfig should show "wlan0". When trying "ifconfig wlan0 up", in case you get an error about firmware, like this error message about missing firmware file, "b43-phy0 ERROR: Firmware file "b43/ucode5.fw" not found or load failed."
      • do as described in:

      http://linuxwireless.org/en/users/Drivers/b43#devicefirmware

In case you will try to scan, you will get: ifconfig wlan0 up iwlist wlan0 scan wlan0 Interface doesn't support scanning : Operation not supported

It **is** inlcuded in kamikaze 8.09.

(so when booting with kamikaze 8.09 you do see wireless interface when running iwconfig).

See this thread: https://forum.openwrt.org/viewtopic.php?id=22103 "Why is b43 driver missing in recent releases?"

See also under: http://downloads.openwrt.org/kamikaze/

Another tip:

In order to use , in /etc/hostapd.conf,

driver=nl80211,

you should have in hostapd .config, before running "make",

CONFIG_DRIVER_NL80211=y

Not that in some distribuitons CONFIG_DRIVER_NL80211 is not set in hostapd package.

- In case there are any problems with burning an image and you cannot access

the WRT54GL linksys device, you can burn an image via tftp,

in this way:

tftp 192.168.1.1

bin

trace

timeout 60

rexmt 1

put nameOfFirmareFile

- When using this way, you should download the firmware from linksys site:

http://homesupport.cisco.com/en-us/support/routers/WRT54GL

- In case you will try to burn an openwrt image, most likely you will get errors;

like:

....

...

tftp> put openwrt-brcm47xx-squashfs.trx

received ACK <block=0> sent DATA <block=1, 512 bytes> received ACK <block=0> received ERROR <code=4, msg=code pattern incorrect> Error code 4: code pattern incorrect

...

...

OpenFWWF website:

http://www.ing.unibs.it/~openfwwf/

  • - also for wrt54GL.

building a firmware for b43 is simple:

you download b43-tools and b43 firmware.

From b43-tools/assembler you run "make && make install".

(you only need assembler for building the b43 firmware)

In case you get the following error:

b43-tools/assembler># make CC b43-asm.bin /usr/bin/ld: cannot find -lfl

make sure that flex-static and flex are installed. (yum install flex-static flex)

Then simply go to the folder where you extracted the firmware, and run "make".

A file name "ucode5.fw" will be generated.

With b43 on the WRT54GL, we use SSB_BUSTYPE_SSB

This means that in b43_wireless_core_start() (drivers/net/wireless/b43/main.c),

dev->dev->bus->bustype is SSB_BUSTYPE_SSB and we call

request_threaded_irq() and not b43_sdio_request_irq().

(The other possibilites are SSB_BUSTYPE_PCI, SSB_BUSTYPE_PCMCIA or

SSB_BUSTYPE_SDIO).

b43/b43legacy Linux driver discussions:

http://lists.infradead.org/mailman/listinfo/b43-dev

  • - Patches which are sent to this mailing list are also sent to Linux kernel wireless mailing list.

TBD:

The followoing downloads 8.09.2 and not 8.09; how you get 8.09 and not 8.09.2?

You can download kamikaze 8.09 by:

svn co svn://svn.openwrt.org/openwrt/branches/8.09

OpenWrt repositories are in the following link:

rfkill is a simple tool for accessing the Linux rfkill device interface, which is used to enable and disable wireless networking devices, typically WLAN, Bluetooth and mobile broadband.

rfkill list will list the status of rfkill.

rfkill block to set a soft lock

rfkill unblock to clear a soft lock

see:

http://www.linuxwireless.org/en/users/Documentation/rfkill

WiMAX

LTE will undoubtedly be thw 4G technology. There is WimMAX solution in

Linux kernel though.

WiMAX (Worldwide interoperability for Microwave access) is based on IEEE802.16 standard. It is a wireless solution for broadband WAN (Wide Area Network). about 200 WiMAX projects around the world. WiMAX products can accommodate fixed and mobile usage models. There is a WiMAX Linux git tree, maintained by Inaky Perez-Gonzalez from Intel.

In the past, Inaky was involved in developing the Linux USB stack and the Linux UWB (Ultra Wideband) stack. The WiMAX stack and driver have been accepted in mainline for 2.6.29 in January 2009. The WiMAX support in Linux consists of a Kernel module (net/wimax/wimax.ko), device-specific drivers under it, and a user space management stack, WiMAX Network Service. There was in the past an initiative from Nokia for a WiMAX stack for Linux, but it is not integrated currently. Also work was done on D-Bus interface to the WiMAX stack, which will help user space tools manage the WiMAX stack. There is currently one WiMAX driver in the Linux tree, the Intel WiMAX Connection 2400 over USB driver (which supports any of the Intel Wireless WiMAX/WiFi Link 5x50 series). The WiMAX stack uses generic netlink protocol mechanism to send and receive netlink messages to and from userspace. Free form messages can be sent back and forth between driver/device and user space

batman-adv

"B.A.T.M.A.N. Advanced Meshing Protocol is a routing protocol for multi-hop ad-hoc mesh networks. The networks may be wired or wireless.

Inplementation is in net/batman-adv

See http://www.open-mesh.org/

Will deal with 802.11, 802.15.4 stack (6lowpan), Bluetooth, NFC, and more.

IEEE 802.15.4

IEEE standard 802.15.4 is for wireless personal area network (WPAN).

Implementation in the Linux kernel tree: net/ieee802154/

The maintainers of IEEE 802.15.4 SUBSYSTEM are Alexander Smirnov and Dmitry Eremin-Solenikov.

Web site: http://sourceforge.net/apps/trac/linux-zigbee

Git tree: git://git.kernel.org/pub/scm/linux/kernel/git/lowpan/lowpan.git

6LoWPAN stands for: "IPv6 over Low power Wireless Personal Area Networks"

compat-wireless

compat-wireless is a backport of the wireless stack from newer kernels to older ones.

Wi-Fi Direct, previously known as Wi-Fi P2P, is a standard that allows Wi-Fi devices to connect to each other without the need for an Access Point.

CRDA stands for "Central Regulatory Domain Agent". It is based on nl80211 and udev.

You can download the source code by:

git clone git://github.com/mcgrof/crda.git

Mostly written by Luis R. Rodriguez (mcgrof@qca.qualcomm.com).

see:

http://www.linuxwireless.org/en/developers/Regulatory/CRDA

Links: "Linux wireless networking", article from 2004 http://www.ibm.com/developerworks/library/wi-enable/index.html

Books:

802.11 Wireless Networks: The Definitive Guide, 2nd Edition By Matthew Gast Publisher: O'Reilly Media, 2005

802.11n: A Survival Guide By Matthew Gast Publisher: O'Reilly Media, 2012

  • TBD:

ACS (Automatic Channel Selection)


This is a static dump of the wiki, taken after locking it in January 2015. The new wiki is at https://wireless.wiki.kernel.org/.
versions of this page: last, v4, v3, v2, v1