Basically, wireless networks can be classified as managed networks and ad-hoc networks. Managed networks have a managing element: the access point. In this mode (also referred to as infrastructure mode), all connections of the WLAN stations in the network run over the access point, which may also serve as a connection to an ethernet. Ad-hoc networks do not have an access point. The stations communicate directly with each other. The transmission range and number of participating stations are greatly limited in ad-hoc networks. Therefore, an access point is usually more efficient. It is even possible to use a WLAN card as an access point. Most cards support this functionality.

Because a wireless network is much easier to intercept and compromise than a wired network, the various standards include authentication and encryption methods. In the original version of the IEEE 802.11 standard, these are described under the term WEP. However, because WEP has proven to be insecure (see Section 29.1.5.2, “Security”), the WLAN industry (joined under the name Wi-Fi Alliance) has defined a new extension called WPA, which is supposed to eliminate the weaknesses of WEP. The later IEEE 802.11i standard (also referred to as WPA2, because WPA is based on a draft version 802.11i) includes WPA and some other authentication and encryption methods.

To make sure that only authorized stations can connect, various authentication mechanisms are used in managed networks:

There are various encryption methods to ensure that no unauthorized person can read the data packets that are exchanged in a wireless network or gain access to the network:

The performance and reliability of a wireless network mainly depend on whether the participating stations receive a clean signal from the other stations. Obstructions like walls greatly weaken the signal. The more the signal strength sinks, the more the transmission slows down. During operation, check the signal strength with the iwconfig utility on the command line (Link Quality field) or with NetworkManager or KNetworkManager. If you have problems with the signal quality, try to set up the devices somewhere else or adjust the position of the antennas of your access points. Auxiliary antennas that substantially improve the reception are available for a number of PCMCIA WLAN cards. The rate specified by the manufacturer, such as 54 Mbit/s, is a nominal value that represents the theoretical maximum. In practice, the maximum data throughput is no more than half this value.

If you want to set up a wireless network, remember that anybody within the transmission range can easily access it if no security measures are implemented. Therefore, be sure to activate an encryption method. All WLAN cards and access points support WEP encryption. Although this is not entirely safe, it does present an obstacle for a potential attacker. WEP is usually adequate for private use. WPA-PSK would be even better, but it is not implemented in older access points or routers with WLAN functionality. On some devices, WPA can be implemented by means of a firmware update. Furthermore, Linux does not support WPA on all hardware components. When this documentation was prepared, WPA only worked with cards using Atheros, Intel PRO/Wireless, or Prism2/2.5/3 chips. On Prism2/2.5/3, WPA only works if the hostap driver is used (see Section 29.1.6.2, “Problems with Prism2 Cards”). If WPA is not available, WEP is better than no encryption. In enterprises with advanced security requirements, wireless networks should only be operated with WPA.

Modern laptops usually have a network card and a WLAN card. If you configured both devices with DHCP (automatic address assignment), you may encounter problems with the name resolution and the default gateway. This is evident from the fact that you can ping the router but cannot surf the Internet. The Support Database features an article on this subject at http://old-en.opensuse.org/SDB:Name_Resolution_Does_Not_Work_with_Several_Concurrent_DHCP_Clients.

Several drivers are available for devices with Prism2 chips. The various cards work more or less smoothly with the various drivers. With these cards, WPA is only possible with the hostap driver. If such a card does not work properly or not at all or you want to use WPA, read /usr/share/doc/packages/wireless-tools/README.prism2.

WPA support is quite new in SUSE Linux Enterprise and still under development. Thus, YaST does not support the configuration of all WPA authentication methods. Not all wireless LAN cards and drivers support WPA. Some cards need a firmware update to enable WPA. If you want to use WPA, read /usr/share/doc/packages/wireless-tools/README.wpa.

To be able to use Bluetooth, you need a Bluetooth adapter (either a built-in adapter or an external device), drivers, and a Bluetooth protocol stack. The Linux kernel already contains the basic drivers for using Bluetooth. The Bluez system is used as protocol stack. To make sure that the applications work with Bluetooth, the base packages bluez-libs and bluez-utils must be installed. These packages provide a number of needed services and utilities. Additionally, some adapters, such as Broadcom or AVM BlueFritz!, require the bluez-firmware package to be installed. The bluez-cups package enables printing over Bluetooth connections. If you need to debug problems with Bluetooth connections, install the package bluez-hcidump.

A Bluetooth system consists of four interlocked layers that provide the desired functionality:

When inserting a Bluetooth adapter, its driver is loaded by the hotplug system. After the driver is loaded, the system checks the configuration files to see if Bluetooth should be started. If this is the case, it determines the services to start. Based on this information, the respective daemons are started. Bluetooth adapters are probed upon installation. If one or more are found, Bluetooth is enabled. Otherwise the Bluetooth system is deactivated. Any Bluetooth device added later must be enabled manually.

In Bluetooth, services are defined by means of profiles, such as the file transfer profile, the basic printing profile, and the personal area network profile. To enable a device to use the services of another device, both must understand the same profile—a piece of information that is often missing in the device package and manual. Unfortunately, some manufacturers do not comply strictly with the definitions of the individual profiles. Despite this, communication between the devices usually works smoothly.

In the following text, local devices are those physically connected to the computer. All other devices that can only be accessed over wireless connections are referred to as remote devices.

Use the YaST Bluetooth module, shown in Figure 29.2, “YaST Bluetooth Configuration”, to configure Bluetooth support on your system. As soon as hotplug detects a Bluetooth adapter on your system (for example, during booting or when you plug in an adapter), Bluetooth is automatically started with the settings configured in this module.

Figure 29.2. YaST Bluetooth Configuration¶

In the first step of the configuration, determine whether Bluetooth services should be started on your system. If you have enabled the Bluetooth services, two things can be configured. First, the Device Name. This is the name other devices display when your computer has been discovered. There are two placeholders available—%h stands for the hostname of the system (useful, for example, if it is assigned dynamically by DHCP) and %d inserts the interface number (only useful if you have more than one Bluetooth adapter in your computer). For example, if you enter Laptop %h in the field and DHCP assigns the name unit123 to your computer, other remote devices would know your computer as Laptop unit123.

The Security Manager parameter is related to the behavior of the local system when a remote device tries to connect. The difference is in the handling of the PIN number. Either allow any device to connect without a PIN or determine how the correct PIN is chosen if one is needed. You can enter a PIN (stored in a configuration file) in the appropriate input field. If a device tries to connect, it first uses this PIN. If it fails, it falls back to using no PIN. For maximum security, it is best to choose Always Ask User for PIN. This option allows you to use different PINs for different (remote) devices.

Click Advanced Daemon Configuration to enter the dialog for selecting and configuring the available services (called profiles in Bluetooth). All available services are displayed in a list and can be enabled or disabled by clicking Activate or Deactivate. Click Edit to open a dialog in which to specify additional arguments for the selected service (daemon). Do not change anything unless you are familiar with the service. After completing the configuration of the daemons, exit this dialog by clicking OK.

Back in the main dialog, click Security Options to enter the security dialog and specify encryption, authentication, and scan settings. Then exit the security dialog to return to the main dialog. After you close the main dialog with Finish, your Bluetooth system is ready for use.

From the main dialog, you can reach the Device and Service Classes dialog, too. Bluetooth devices are grouped into various device classes. In this dialog, choose the correct one for your computer, such as Desktop or Laptop. The device class is not very important, unlike the service class, also set here. Sometimes remote Bluetooth devices, like cell phones, only allow certain functions if they can detect the correct service class set on your system. This is often the case for cell phones that expect a class called Object Transfer before they allow the transfer of files from or to the computer. You can choose multiple classes. It is not useful to select all classes “just in case.” The default selection should be appropriate in most cases.

To use Bluetooth to set up a network, activate PAND in the Advanced Daemon Configuration dialog and set the mode of the daemon with Edit. For a functional Bluetooth network connection, one pand must operate in the Listen mode and the peer in the Search mode. By default, the Listen mode is preset. Adapt the behavior of your local pand. Additionally, configure the bnepX interface (X stands for the device number in the system) in the YaST Network Card module.

The configuration files for the individual components of the Bluez system are located in the directory /etc/bluetooth. The only exception is the file /etc/sysconfig/bluetooth for starting the components, which is modified by the YaST module.

The configuration files described below can only be modified by the user root. Currently, there is no graphical user interface to change all settings. The most important ones can be set using the YaST Bluetooth module, described in Section 29.2.2.1, “Configuring Bluetooth with YaST”. All other settings are only of interest for experienced users with special cases. Usually, the default settings should be adequate.

A PIN number provides basic protection against unwanted connections. Mobile phones usually query the PIN when establishing the first contact (or when setting up a device contact on the phone). For two devices to be able to communicate, both must identify themselves with the same PIN. On the computer, the PIN is located in the file /etc/bluetooth/pin.

	Security of Bluetooth Connections
Despite the PINs, the transmission between two devices may not be fully secure. By default, the authentication and encryption of Bluetooth connections is deactivated. Activating authentication and encryption may result in communication problems with some Bluetooth devices.

Various settings, such as the device names and the security mode, can be changed in the configuration file /etc/bluetooth/hcid.conf. Usually, the default settings should be adequate. The file contains comments describing the options for the various settings.

Two sections in the included file are designated as options and device. The first contains general information that hcid uses for starting. The latter contains settings for the individual local Bluetooth devices.

One of the most important settings of the options section is security auto;. If set to auto, hcid tries to use the local PIN for incoming connections. If it fails, it switches to none and establishes the connection anyway. For increased security, this default setting should be set to user to make sure that the user is requested to enter a PIN every time a connection is established.

Set the name under which the computer is displayed on the other side in the device section. The device class, such as Desktop, Laptop, or Server, is defined in this section. Authentication and encryption are also enabled or disabled here.

Use hcitool to determine whether local and remote devices are detected. The command hcitool dev lists the local devices. The output generates a line in the form interface_name device_address for every detected local device.

Search for remote devices with the command hcitool inq. Three values are returned for every detected device: the device address, the clock offset, and the device class. The device address is important, because other commands use it for identifying the target device. The clock offset mainly serves a technical purpose. The class specifies the device type and the service type as a hexadecimal value.

Use hcitool name device-address to determine the device name of a remote device. In the case of a remote computer, the class and the device name correspond to the information in its /etc/bluetooth/hcid.conf. Local device addresses generate an error output.

The command /usr/sbin/hciconfig delivers further information about the local device. If hciconfig is executed without any arguments, the output shows device information, such as the device name (hciX), the physical device address (a 12-digit number in the form 00:12:34:56:78), and information about the amount of transmitted data.

hciconfig hci0 name displays the name that is returned by your computer when it receives requests from remote devices. As well as querying the settings of the local device, hciconfig can modify these settings. For example, hciconfig hci0 name TEST sets the name to TEST.

Use sdptool to check which services are made available by a specific device. The command sdptool browse device_address returns all services of a device. Use sdptool search service_code to search for a specific service. This command scans all accessible devices for the requested service. If one of the devices offers the service, the program prints the full service name returned by the device together with a brief description. View a list of all possible service codes by entering sdptool without any parameters.

In the first example, a network connection is established between the hosts H1 and H2. These two hosts have the Bluetooth device addresses baddr1 and baddr2 (determined on both hosts with the command hcitool dev as described above). The hosts should be identified with the IP addresses 192.168.1.3 (H1) and 192.168.1.4 (H2).

The Bluetooth connection is established with the help of pand (personal area networking daemon). The following commands must be executed by the user root. The description focuses on the Bluetooth-specific actions and does not provide a detailed explanation of the network command ip.

Enter pand -s to start pand on the host H1. Subsequently, establish a connection on the host H2 with pand -c baddr1. If you enter ip link show on one of the hosts to list the available network interfaces, the output should contain an entry like the following:

 bnep0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop qlen 1000 
 link/ether 00:12:34:56:89:90 brd ff:ff:ff:ff:ff:ff

Instead of 00:12:34:56:89:90, the output should contain the local device address baddr1 or baddr2. Now this interface must be assigned an IP address and activated. On H1, do this with the following two commands:

ip addr add 192.168.1.3/24 dev bnep0
ip link set bnep0 up

On H2, use the following commands:

ip addr add 192.168.1.4/24 dev bnep0
ip link set bnep0 up

Now H1 can be accessed from H2 at the IP 192.168.1.3. Use the command ssh 192.168.1.4 to access H2 from H1, assuming H2 runs an sshd, which is activated by default in SUSE Linux Enterprise®. The command ssh 192.168.1.4 can also be run as a normal user.

The second example shows how to transfer a photograph created with a mobile phone with a built-in digital camera to a computer (without incurring additional costs for the transmission of a multimedia message). Although the menu structure may differ on various mobile phones, the procedure is usually quite similar. Refer to the manual of your phone, if necessary. This example describes the transfer of a photograph from a Sony Ericsson mobile phone to a laptop. The service Obex-Push must be available on the computer and the computer must grant the mobile phone access. In the first step, the service is made available on the laptop. You need a special service daemon running on the laptop to get the data from the phone. If the package kbluetooth is installed, you do not need to start a special daemon. If kbluetooth is not installed, use the opd daemon from the bluez-utils package. Start the daemon with the following command:

opd --mode OBEX --channel 10 --daemonize --path /tmp --sdp 

Two important parameters are used: --sdp registers the service with sdpd and --path /tmp instructs the program where to save the received data—in this case to /tmp. You can also specify any other directory to which you have write access.

If you use kbluetooth, you are prompted for a directory when the photograph is received on the laptop.

Now the mobile phone must get to know the computer. To do this, open the Connect menu on the phone and select Bluetooth. If necessary, click Turn On before selecting My devices. Select New device and let your phone search for the laptop. If a device is detected, its name appears in the display. Select the device associated with the laptop. If you encounter a PIN query, enter the PIN specified in /etc/bluetooth/pin. Now your phone recognizes the laptop and is able to exchange data with the laptop. Exit the current menu and go to the image menu. Select the image to transfer and press More. In the next menu, press Send to select a transmission mode. Select Via Bluetooth. The laptop should be listed as a target device. Select the laptop to start the transmission. The image is then saved to the directory specified with the opd command. Audio tracks can be transferred to the laptop in the same way.