Linux wireless networking

A look at WLAN, Bluetooth, GPRS, GSM, and Infrared Data on Linux

These days you cannot talk about computers and networks without thinking of Linux and wireless networking. In this article, Sreekrishnan Venkateswaran explains wireless networking with WLAN, Bluetooth, GPRS, GSM, and IrDA from a Linux perspective. He uses various wireless devices and the corresponding kernel layers and user space tools to demonstrate how they work with Linux.

Share:

Sreekrishnan Venkateswaran (s_krishna@in.ibm.com), Staff Software Engineer, IBM India

Sreekrishnan Venkateswaran holds a master's degree in Computer Science from the Indian Institute of Technology, Kanpur, India. He's been working with IBM India since February 1996. His interests include designing device drivers and network protocols. You can contact Sreekrishnan at s_krishna@in.ibm.com.



02 March 2004

Wireless technologies like WLAN (Wireless Local Area Network), Bluetooth, GPRS (General Packet Radio Service), GSM (Global System for Mobile communications), and IrDa (Infrared Data) serve different niches. While WLAN supports higher speeds and longer range than Bluetooth, it also has higher costs and higher power consumption. GPRS is slower than Bluetooth and WLAN, but can be used on the move. Despite their diversity, or rather because of it, devices with multiple wireless capabilities can use them in tandem. For example, a device can switch transparently from GPRS on the road to a cheaper WLAN in an Internet cafe for network connectivity, depending on location input from a GPS module. A cell phone can communicate through Bluetooth to a heart rate monitor and send an alert over GSM to a doctor if the patient's heart rate crosses a certain threshold.

These wireless technologies are widely available today in the form of PCMCIA or Compact Flash (CF) cards, or as USB devices. Most computer systems, including embedded devices, have PCMCIA, CF, or USB interfaces, thus instantly enabling them to take advantage of wireless technologies even if they do not have built-in support for them. This article examines examples of such wireless devices and explores the respective Linux implementations of the device drivers, bus technologies, and protocols.

You'll first see how WLAN devices work on Linux by tracing the code flow for an example WLAN card. Then you'll see how several Bluetooth devices interface with the Linux Bluetooth stack and other kernel layers. Next, you'll learn how to get GPRS and GSM devices to work with Linux. The article ends with the examination of Linux IrDa support and a brief look at performance issues faced by wireless networking devices.

Note: The kernel data structures and file names referred to in this article are those used in current Linux versions. The file names are relative to the root of the Linux kernel source tree.

Linux 802.11 WLAN

A WLAN communication system acts as an alternative to wired LAN and is generally used within a building. WLAN uses the ISM (Industrial, Scientific, Medical) radio-band frequency for communication. WLAN's 802.11a standard uses the 5 GHz band and supports a maximum speed of 54 Mbps, while the 802.11b and the 802.11g standards use the 2.4 GHz band and support maximum speeds of 11 Mbps and 54 Mbps, respectively.

WLAN resembles wired Ethernet in that both are assigned MAC (Media Access Control) addresses from the same address pool and both appear to the operating system network-device layer as Ethernet devices. For instance, ARP (Address Resolution Protocol) tables are populated with WLAN MAC addresses alongside Ethernet MAC addresses.

WLAN and wired Ethernet, however, differ significantly at the link layer. The 802.11 standard, for example, uses collision avoidance (CSMA/CA) instead of collision detection (CSMA/CD) used by wired Ethernet. Moreover, WLAN frames, unlike Ethernet frames, are acknowledged.

Because of fuzzy boundaries between WLAN stations, the WLAN link layer has a protocol to clear out an area before transmission. For security, WLAN's Wired Equivalent Privacy (WEP) encryption mechanism provides a level of security equivalent to wired networks. WEP combines a 40-bit or a 104-bit key with a random 24-bit initialization vector to encrypt/decrypt data. WLAN supports two modes of communication: Ad Hoc mode for communication between a small group of stations for a short period of time without using an access point, and Infrastructure mode where all communication passes through an access point. Access points periodically broadcast a Service Set Identifier (SSID) that identifies one WLAN network from another.

Most available WLAN cards are either based on the Intersil Prism chipset or the Lucent Hermes chipset. Compaq, Nokia, Linksys, and D-Link cards use the Prism chipset, while the Lucent Orinoco card and the Apple Airport use the Hermes chipset.

Linux WLAN support

Linux support for WLAN broadly consists of a WLAN API implementation and WLAN device drivers. I'll look at them in turn.

Two Linux projects define a generic WLAN API and provide tools to let user-space applications configure parameters and access information from WLAN device drivers. The Wireless Extensions project provides a common Linux user space interface for different wireless cards. The project's tools include iwconfig to configure parameters like WEP keys and SSIDs in the WLAN driver. The linux-wlan project, for its part, also supports a set of tools that talk to WLAN device drivers from user space. These utilities, unlike the ones based on Wireless Extensions, use an SNMP (Simple Network Management Protocol) MIB (Management Information Base)-like syntax that mirrors the IEEE 802.11 specification. (See Resources for more on the projects.)

Moving on to device drivers, the Linux device drivers that support popular WLAN cards include:

  • The Orinoco WLAN driver: Part of the Linux kernel sources, supports both Hermes-based cards and Intersil Prism-based cards. The orinoco_cs module provides PCMCIA card services support needed for PCMCIA and CF cards.
  • The linux-wlan project's linux-wlan-ng driver: Supports a variety of cards based on the Prism chipset. The driver supports the linux-wlan API and partially supports Wireless Extensions.
  • The Host AP device driver: Supports the Host AP mode of Prism chipsets that lets a WLAN host act as an access point.
  • The Linux Symbol Spectrum device driver: Supports Symbol PCMCIA cards. The Symbol CF card, unlike the PCMCIA card, lacks firmware on the card and depends on the device driver to download the firmware. A separate version of the driver works for the CF card. Intel repackages the Symbol PCMCIA card as the Intel PRO/Wireless card, while Socket communications repackages the Symbol CF card.
  • The Atmel USB WLAN driver: Supports many USB WLAN devices using Atmel chipsets.

See Resources for information on drivers for these devices.

The Intersil Prism2 WLAN CF card

I'll review the Intersil Prism2 802.11b WLAN CF card to show you how it works with the Linux PCMCIA, network devices, and protocol layers.

The Linux PCMCIA/CF layer consists of device drivers for PCMCIA host controllers, client drivers for different cards, user mode programs, daemons that aid hot plugging, and a kernel card-services core that interacts and provides services to all of the above (see Resources). The PCMCIA controller bridges the card to the system bus. It maps card memory to host I/O and memory windows and routes interrupts generated by the card to a free processor interrupt line. CF cards are smaller, but compatible with PCMCIA, and are frequently used in handheld devices. PCMCIA/CF cards have two memory spaces: attribute memory and common memory. Attribute memory holds configuration registers and descriptor information like the Card Information Structure (CIS). The Linux card services core interacts with the host controller device driver, the card device drivers, and the user mode cardmgr daemon. It invokes the card driver's event handler routine during events like card insertion, card removal, and low battery. Whereas card services passes information up to cardmgr from the card's CIS, cardmgr passes down to card services the resource allocation policy defined in user space (/etc/pcmcia/config.opts) for allocating memory windows and interrupt levels. Look at drivers/pcmcia/ds.c to see the kernel code that interacts with cardmgr and refer to /etc/pcmcia/config.opts to see the user space resource allocation policies.

When the Intersil WLAN CF card is inserted, card services invokes the orinoco_cs module's PCMCIA event handler. Card services parses the CIS tuples in the card attribute memory and passes the information up to cardmgr, which loads the appropriate device drivers from the /etc/pcmcia/config file (see Listing 1). Because the manfid tuple in the card's CIS matches the entry in /etc/pcmcia/config, cardmgr binds the card with the orinoco_cs driver. The device entry in Listing 1 states that the orinoco_cs driver consists of three kernel modules: orinoco, orinoco_cs, and hermes. Also, because the device is of class wireless, cardmgr executes the script /etc/pcmcia/wireless while starting and stopping the device. The script uses WLAN tools and utilities to configure device driver parameters like WEP keys and SSIDs. It can also start networking protocols like DHCP (Dynamic Host Configuration Protocol) over the WLAN. The example in Listing 1 uses Wireless Extensions tools to perform device configuration.

Note: The exact location of the PCMCIA configuration files depends on the Linux distribution used.

Listing 1. PCMCIA device entries for the Intersil WLAN CF card
card "Intersil PRISM2 11 Mbps Wireless Adapter"
manfid 0x0156, 0x0002
bind "orinoco_cs"

device "orinoco_cs" class "wireless" module "orinoco","orinoco_cs","hermes"

Parameters like WEP keys and SSIDs are configured using the /etc/pcmcia/wireless and the /etc/pcmcia/wireless.opts scripts.

Listing 2. Configuring WLAN specific parameters
iwconfig ethX essid <wlan_name> 
key AAAA-AAAA-AA [1] key BBBB-BBBB-BB [2] key CCCC-CCCC-CC [3] key DDDD-DDDD-DD [4]
                   : Set 64-bit WEP Keys and ESSID in the driver
iwconfig ethX      : Display WLAN parameters
iwpriv             : Get nongeneric, driver-specific parameters
iwlist             : List Information and statistics from an interface
iwspy              : Read quality of link for a set of addresses
/proc/net/wireless : Wireless Statistics from the device driver

During card insertion, orinoco_cs, like legacy network device drivers, invokes register_netdev to get an ethX network interface name assigned to the WLAN interface. It also registers an interrupt service routine's address to service interrupts generated when wireless data is sent or received. The interrupt handler is part of the orinoco module and interacts with the Linux networking stack. The key data structure used by the Linux networking stack is the sk_buff structure (defined in include/linux/skbuff.h, (see Resources), which contains control information about a block of memory attached to it. sk_buffs provide efficient buffer handling and flow control mechanisms for all networking layers. Network device drivers do an dev_alloc_skb and an skb_put to populate an sk_buff with IP data, and then pass it on to the TCP/IP stack by invoking netif_rx. The orinoco interrupt service routine populates sk_buffs with data received from the WLAN and passes it on to the IP stack via netif_rx.

Linux TCP/IP applications can run unchanged over the network interface provided by the kernel modules mentioned earlier for the Intersil WLAN CF card.


Linux Bluetooth

Bluetooth, a short-range wireless technology designed to replace cables, supports speeds of 723 kbps (asymmetric) and 432 kbps (symmetric) and can transfer both data and voice. Bluetooth devices have a range of about 10 meters (30 feet). (See Resources for the Bluetooth specification.)

BlueZ, the official Linux Bluetooth stack, consists of the Host Control Interface (HCI) layer, the Bluetooth protocol core, the Logical Link Control and Adaptation Protocol (L2CAP), the SCO audio layer, other Bluetooth services, user space daemons, and configuration tools (see Resources).

The Bluetooth specification supports UART (Universal Asynchronous Receiver/Transmitter) and USB transport mechanisms for Bluetooth HCI packets. The BlueZ stack supports both of those transport mechanisms (drivers/Bluetooth/). BlueZ BNEP (Bluetooth Network Encapsulation Protocol) implements Ethernet emulation over Bluetooth, which lets TCP/IP run directly over Bluetooth. The BNEP module(net/bluetooth/bnep/) and the user mode pand daemon implement Bluetooth Personal Area Networking (PAN). BNEP registers itself with the Linux networking layer as an Ethernet device using register_netdev, and populates and passes sk_buffs to the protocol stack using netif_rx as described for WLAN drivers above. BlueZ RFCOMM (net/bluetooth/rfcomm/) provides serial emulation over Bluetooth that lets serial port applications like minicom and protocols like Point-to-Point Protocol (PPP) run unchanged over Bluetooth. The RFCOMM module and the user mode dund daemon implement Bluetooth dialup networking. The list below shows the BlueZ modules, utilities, daemons, and configuration files necessary to configure various protocol services over Bluetooth.

Next, consider the examples of a Bluetooth CF card, a Bluetooth USB adapter, a device with a built-in CSR Bluetooth chipset, and a Sony Bluetooth Headset to see how they work with Linux.

Sharp Bluetooth CF card

The Sharp Bluetooth CF card uses a UART transport to transfer HCI packets. The interaction of the Linux PCMCIA/CF layer with the rest of the OS for the Sharp card resembles the one explained for the Intersil WLAN CF card, except for the fact that serial_cs is the card services driver that interacts with the Linux PCMCIA core. The serial_cs driver (explained further in "Linux GPRS and Data over GSM" below) emulates a serial port over the Sharp CF card. The BlueZ hci_uart link driver talks with Bluetooth UART channels and connects the emulated serial port to the BlueZ stack.

The list below shows the modules that must be loaded when the card is inserted. Other Bluetooth CF cards, like the Pretec CompactBT card and the Socket Bluetooth card, have UART interfaces, but have their own card services drivers (drivers/bluetooth/bt950_cs.c and drivers/bluetooth/dtl1_cs.c, respectively). You'll find more information about Bluetooth UART transport later in the article.

An entry in /etc/pcmcia/config for the Sharp Bluetooth CF card:

card "SHARP Bluetooth Card"
version "SHARP", "Bluetooth Card"
bind "serial_cs"

The necessary kernel modules to be loaded:

  • insmod serial_cs
  • insmod bluez
  • insmod l2cap
  • insmod hci_uart
  • insmod bnep (for pand)
  • insmod rfcomm (for dund)

BlueZ user space daemons, utilities, and configuration files:

  • hciattach ttySx any [baud_rate] [flow]
  • hciconfig -a : Examine the HCI interface
  • hcitool -a hci0 scan 'flush: Discover other devices
  • hcidump: HCI Sniffer
  • hcid: HCI Daemon
  • /etc/bluetooth/hcid.conf: HCI daemon configuration file used by hcid that specifies link mode (master or slave), link policy, inquiry and scan mode, and so on
  • /etc/bluetooth/pinDB: BlueZ PIN Database
  • sdpd: Service Discovery Protocol Daemon
  • pand: To run TCP/IP over Bluetooth (--listen for the server, --connect <bluetooth_address> for the client)
  • /etc/bluetooth/pan/dev-up: pand invokes this script while bringing up TCP/IP. This script can contain a command like ifconfig bnep0 <ip_address> up to configure an IP address for the Bluetooth interface
  • dund: To run PPP over Bluetooth RFCOMM (--listen for the server, --connect <bluetooth_address> for the client)

The Belkin Bluetooth USB Adapter

The Belkin Bluetooth USB adapter has a Bluetooth CSR chipset and uses USB transport for transferring HCI packets. Therefore, the Linux USB layer, the BlueZ USB transport driver, and the BlueZ protocol stack are the main kernel layers that get the device working. Now, you'll see how the three layers interact to get Linux networking applications running over this device.

The Linux USB subsystem (see Resources) resembles the PCMCIA subsystem in that both have host controller device drivers that talk to removable devices and both include a core layer that offers services to device drivers for the host controller and the individual devices. USB host controllers follow one of two standards: UHCI (Universal Host Controller Interface) or OHCI (Open Host Controller Interface). As with PCMCIA, the Linux device drivers for the individual USB devices do not depend on the host controller. Data transfers to and from a USB device fall into one of four categories (or pipes):

  • Control
  • Interrupt
  • Bulk
  • Isochronous

The first two are usually used for small messages while the latter two are used for larger messages.

When a USB device is plugged in, it is enumerated by the host controller driver using control pipes and assigned a device address (1 to 127). The device descriptor read by the host controller driver contains information about the device, such as class, subclass, and protocol. Linux's usbcore kernel module supports USB host controllers and USB devices. It contains functions and data structures that USB device drivers can use. USB drivers register two entry points, probe and disconnect, with usbcore, along with their class/subclass/protocol information (see struct usb_driver in include/linux/usb.h). When the corresponding USB device is attached, usbcore matches the registered class information with the one read from the device configuration descriptor during enumeration and binds the device with the corresponding driver. The core uses a data structure called USB Request Block, or URB (defined in include/linux/usb.h), to asynchronously manage data transfers between the host and the device. Device drivers use these routines to request various types of data transfers (control, interrupt, bulk, or isochronous). The core notifies the driver using previously registered callback functions after the transfer request is completed.

For Bluetooth USB devices, HCI commands are transported using Control pipes, HCI events using Interrupt pipes, Asynchronous (ACL) data using Bulk pipes, and Synchronous (SCO) audio data using Isochronous pipes. The Bluetooth specification defines a class/subclass/protocol code of 0xE/0x01/0x01 for Bluetooth USB devices. The BlueZ USB transport driver (drivers/bluetooth/hci_usb.c) registers this class/subclass/protocol information with the Linux USB core. When the Belkin USB adapter is plugged in, the host controller device driver enumerates it. Because the device descriptor read from the adapter during enumeration matches the information registered by the hci_usb driver with the USB core, this driver gets attached to the Belkin USB device. The HCI, ACL, and SCO data read by the hci_usb driver from the various endpoints described above are transparently passed on to the BlueZ protocol stack. Once this is done, Linux TCP/IP applications can run over BlueZ BNEP, and serial applications can run over BlueZ RFCOMM using the BlueZ services and tools described above.

A board with a built-in CSR Bluetooth chipset

Now, take a look at Bluetooth network data flow on a device with a built-in Bluetooth chipset. Consider a handheld with a built-in CSR Bluetooth chipset interfaced to the system using a UART interface. For UART interfaces, the available protocols to transport HCI packets between the Bluetooth device and the system are BlueCore Serial Protocol (BCSP), H4/UART, and H3/RS232. While H4 serves as the standard method to transmit Bluetooth data over UART as defined in the specifications, the proprietary BCSP protocol from CSR supports error checking and retransmission. BCSP is used on non-USB devices based on CSR BlueCore chips including PCMCIA and CF cards. BlueZ supports BCSP and H4.

The legacy serial driver that drives this board's UART channels can send and receive data from the BlueZ UART transport driver. If the CSR chip is programmed to encapsulate HCI packets using the BSCP protocol, you must inform the BlueZ link driver using hciattach (hciattach ttySx bcsp), where x is the UART channel number connected to the CSR chipset. hci_uart now talks to the CSR chip and passes on Bluetooth data to and from the BlueZ stack.

Sony HBH-30 Bluetooth Headset

The previous Bluetooth device examples showed network data flow. Now, consider the transfer of Bluetooth audio (SCO) data by looking at a Sony Ericsson Bluetooth headset. Before the headset can start communicating with a Linux device, it must be discovered by the Bluetooth link layer on the Linux device. Therefore, you must put the headset in a discover mode (by pressing a button on the headset). Additionally, you need to configure the headset's PIN with BlueZ on the Linux device. An application on the Linux Bluetooth device that uses BlueZ SCO APIs can now send audio data to the headset. The audio data should be in a format understood by the headset (for example, A-law PCM [Pulse Code Modulation] format for the Sony headset). There are public domain utilities for converting audio (and even text files) into various PCM formats.

Bluetooth chipsets have PCM interface pins in addition to the HCI transport interface. If a device supports, for instance, both GSM and Bluetooth, the PCM lines from the GSM chipset might be directly wired to the Bluetooth chip's PCM audio lines. You might then have to configure the Bluetooth chipset on the Linux device to receive and send SCO audio packets over the HCI transport interface rather than the PCM interface.


Linux GPRS and Data over GSM

GPRS is a packet service for carrying data over GSM, the prominent digital cellular standard. While data over GSM is circuit-switched and occupies a channel irrespective of usage, data over GPRS is an always-on, packet-switched data stream where users pay according to usage. GSM speeds are typically 9.6 kbps, while GPRS can run at speeds of 56 kbps to 170 kbps.

GPRS and GSM chips usually have a UART interface to the system. For a board with built-in GSM/GPRS support (for example, a board with a Siemen's MC-45 module wired to a UART channel), the legacy serial driver can drive the link. For a PCMCIA/CF form factor (an Options GPRS card, for example), serial_cs, the generic card service driver to access PCMCIA serial devices, allows the rest of the operating system see the card as a serial device. The first unused serial device (/dev/ttySx) gets allotted to the card, which can then be accessed as if it where a serial device. serial_cs can also emulate serial ports over Global Positioning System (GPS) PCMCIA and CF cards. For USB GPRS modems, a USB-to-serial converter typically converts the USB port into a virtual serial port so the rest of the system sees it as a serial device.

The GPRS network connects to an external network (like the Internet) using a GGSN (Gateway GPRS Support Node). A GPRS device, which resembles a modem with an extended AT command set, must define a context using an AT command before it enters data mode. The context string looks like the example shown in Listing 3.

Listing 3. Context string
 'AT+CGDCONT=1,"IP","internet.voicestream.com","0.0.0.0",0,0'

In this example, 1 stands for a context number, IP is the packet type, internet.voicestream.com is an Access Point Name (APN) string, 0.0.0.0 means that the service provider chooses the IP address, and the rest of the parameters relate to data and header compression. The APN string depends on the service provider. A user name and password are usually not needed.

PPP allows networking protocols such as TCP/IP run over a serial link. In the context of wireless networks, PPP can get TCP/IP running over GPRS, data over GSM, Bluetooth RFCOMM, and IrDa IrCOMM. Listing 4 shows a common syntax for invoking the PPP daemon, pppd.

Listing 4. Common syntax for invoking the PPP daemon, pppd
pppd ttySx call connection-script

In this example, ttySx is the physical or virtual serial device over which PPP runs, and connection-script is a file in the /etc/ppp/peers/ directory that contains the AT command sequences exchanged between pppd and the service provider to establish a link. After establishing a link connection and completing authentication, PPP starts a Network Control Protocol (NCP). IPCP (Internet Protocol Control Protocol) is the NCP for running IP. Once IPCP successfully negotiates IP addresses, PPP starts talking with the TCP/IP stack.

Listing 5 shows an example PPP connection script for connecting to a GPRS service provider, while Listing 6 shows a connection script for data connection to a GSM service provider.

Listing 5. A sample pppd connection script for GPRS (/etc/ppp/peer/gprs-script)
115200
connect "/usr/sbin/chat -s -v "" AT+CGDCONT=1,"IP",
"internet2.voicestream.com","0.0.0.0",0,0 OK AT+CGDATA="PPP",1"
crtscts
noipdefault
modem
usepeerdns
defaultroute
connect-delay 5000

From an operating system's perspective, data over GSM resembles sending and receiving data over a dial-up modem connection. The Internet Service Provider's (ISP) phone number is dialed using GSM and a dial-up connection is established. Authentication occurs with a user name and password.

Once PPP establishes an IP connection to the service provider, TCP applications such as Web browsers can run unchanged over the GSM/GPRS device.

The gsmlib project provides utilities for voice and SMS (Short Messaging Service) messaging over GSM (see Resources for more on gsmlib). It contains utilities to access the phone book in the Subscriber Identity Module (SIM) card, send and receive SMS messages, and so on.

Listing 6. A sample pppd connection script for data over GSM (/etc/ppp/peer/gsm-script)
115200
connect '/usr/sbin/chat -s -v ABORT "NO CARRIER" ABORT "NO DIALTONE" ABORT "BUSY" "" AT OK 
ATDT<phone_number> CONNECT'
crtscts
noipdefault
modem
user "linux"
usepeerdns
defaultroute
connect-delay 5000

Linux Infrared Data

Infrared Data (IrDa) is a specification to wirelessly transfer data using infrared radiation. It is primarily used for linking laptops or for connecting equipment like video or photo cameras to computer systems.

IrDa speeds range from 115 kbps for Serial Infrared (SIR) to 16 Mbps for Very Fast Infrared (VFIR). Most IrDa chips in the SIR mode are UART 16650-compatible (16650 is a common PC UART), so the legacy Linux serial port drivers can serve as link-level drivers. The IrDa line discipline implementation, IrTTY (drivers/net/irda/irtty.c), lets the serial driver drive SIR. The IrPORT driver (drivers/net/irda/irport.c) replaces IrTTY and the serial driver, and offers better device control. IrDa chips incompatible with the serial driver have their own device drivers. The NSC PC87108 chipset, for example, uses its own driver (nsc-ircc.c). Similar to the hci-usb driver used for USB Bluetooth devices discussed above, USB IrDa FIR dongles are supported by the irda-usb.c device driver.

IrLAP is the link accesses protocol layer responsible for IrDa device discovery, retransmission, and flow control. Above IrLAP resides the IrLMP link management layer and the Tiny Transport protocol layer (TinyTP). Above these are the IrCOMM and IrLAN layers. IrCOMM (implemented in net/irda/ircomm/) provides serial emulation that lets applications that run over serial ports, like terminal emulators, run unchanged over the IrDa stack. IrLAN (implemented in net/irda/irlan/) provides a virtual network interface that lets TCP/IP run directly over the IrDa stack. The IrLAN code uses register_netdev to register an Ethernet device with the Linux networking layer and netif_rx to send data to the Linux IP stack (as explained for WLAN drivers and for Bluetooth BNEP). IrCOMM is analogous to Bluetooth RFCOMM, while IrLAN is analogous to Bluetooth BNEP.

IrOBEX is a simple protocol built on top of TinyTP that allows transfer of binary data. Extensions to IrOBEX define transfer of different kinds of data objects.

To use the IrDa protocols with Linux, you must install IrDa utilities (like irattach) developed as part of the Linux IrDa project.


Performance issues

Network performance depends on the characteristics of the particular bearer network. GPRS bandwidth, for example, depends on the coding schema used, while Bluetooth performance is affected by segmentation at the L2CAP layer. For communication between a WLAN station and an access point, frame acknowledgments decrease the bandwidth, as do the number of other stations using the same access point.

Characteristics of wireless networks like low and fluctuating bandwidth and high latencies skew TCP's measurement and transmission strategies. Even though most losses in wireless networks stem from factors like signal fading, interference, and link blackouts, TCP assumes the losses to be related to congestion, so it kicks in algorithms that slow down network traffic. There are various projects that tune TCP and Web browser behavior to suit wireless networks.


Conclusion

In this article you've toured the Linux device driver and network protocol layers for popular wireless technologies including WLAN, Bluetooth, GPRS, GSM, and IrDA. You've also learned how different wireless devices work with Linux by tracing corresponding code paths and discussing relevant user space tools.

Armed with a general understanding of the core support provided on Linux for various wireless, networking, and bus technologies, you can now tinker with various wireless devices having different form factors, and develop Linux kernel code required to enable unsupported devices.

Resources

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into Linux on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Linux
ArticleID=11381
ArticleTitle=Linux wireless networking
publish-date=03022004