Lost your wire? Wireless Networking with OS/2 and eCS. Part 2

By Jonas Buys

4. Drivers for setting up a wireless device.
What are the system requirements? Warp3 or higher, eCS, or WSoD and the appropriate device drivers.

First of all, you need a PCMCIA slot, mostly PC CARD type II. This can be either a regular PC Card slot in a notebook, or it can also be a PCI-to-PCMCIA adapter using the PLX driver (included in Generic PRISM device driver).

Please do NOT bombard me with e-mails asking for these drivers; I won't give them. I got them for testing purposes only, and I promised both IBM and the developer that I wouldn't distribute them. Please wait until they become available via SoftWare Choice (which should be really soon now), or get an IBM business contract. Also, please don't bother IBM with questions regarding the drivers in development that are not available to the public yet.

4.1. Orinoco compatibles
The Orinoco (also referred to as WaveLAN) by Lucent/Agere is kind of a debugged and enhanced PRISM chipset. It offers data transfer rates up to 11Mbps. Orinoco-equipped WLAN cards are considerably more expensive then PRISM ones. Compared to the original PRISM2 chipset, Orinoco performs better (though not better than PRISM3) because of ameliorated firmware.

4.1.1. Artem, BinTec, Jakarta
The Artem ComCards are - at present - the only wireless cards that come with OS/2 support out-of the box. BinTec and Jakarta Blue cards are OEM variants of the Artem card. They all work with the same driver, the ComCard NDIS 2.01 Treiber (latest version is 1.5), which can be downloaded from the our WiFi drivers download page. This driver is also included in eComStation 1.1 (although not the latest version). Note that the driver available for download from the Artem web site is not the latest version. The driver comes in a static ZIP-file, which you need to unzip the files of to x:\IBMCOM\MACS, where x: is the drive on which OS/2 is installed. Artem regularly provides updates and bug fixes. There is a also very good article available about how to install these drivers on eCS and OS/2. Mensys distributes all of these cards actively in Europe, and Artem sells directly to individuals in the Americas. OS/2 CHL hardware testing team has tested some of these devices, and they offer very reasonable performance for reasonable pricing. BinTek also hosts a driver for their cards, but that is just the same driver as that of Artem. All Artem cards support 64-bit and 128-bit encryption. Artem driver revisions 1.5 and higher are designed to work with the nice IBM WiFiState utility.

Artem is currently assessing the market to investigate if OS/2 users would be interested in IEEE 802.11g. Thus, it is likely that the company will release drivers for these products too, sooner or later. More about this later...

4.1.2. IBM High Rate Wireless PC Card 128
Some other very professional device is the IBM High Rate Wireless PC Card 128. Just as CISCO, IBM can go along the ride with superior performance, combined with extremely high pricing. The driver is specifically for this card, and cannot be used with other Orinoco cards. The driver was in internal IBM beta testing for some months, but now it has finally been made general availability via IBM Device Driver Pak Online (need valid and active SoftWare Choice or PassPort Advantage subscription). It is also available via eComStation download site, if you have a login to access the downloads section. The self-extracting file ibmwifi2.exe contains a DDP file, a good readme, and all things that can be desirable. Surely, just as is the case with the CISCO driver, this driver was meant to be for business needs. It is also equipped with the WiFiStat.exe utility, discussed in a later section. On the global IBM web site, OS/2 support is stated: "IBM is offering OS/2 device drivers and support for these OS/2 drivers for the IBM PCMCIA Wireless LAN cards on a fee basis. For more information please contact emeawarp@de.ibm.com." This means, the driver is also available via IBM business contracts in case you wouldn't dispose of a SWC or PPA subscription.

The IBM High Rate driver performs better than every average WiFi card, but compared to the CISCO 340 Series physical performance, it gets the worst of it.

4.1.3. Others
There's also a modified version of the Artem driver, which does truly allow other devices to work with this driver by specifying the manufacturer and device IDs. In fact, it is one of the older versions of the Artem driver. Current Artem drivers don't have this feature and thus are for Artem, BinTec and Jakarta Blue devices only. As already said, these IDs are used by the device driver to search for and locate the wireless device(s). In fact, this driver is unattainable for the public, but somewhere on the World Wide Web, it is traveling, and offering extreme good support for a great deal of Orinoco-branded cards.

As of the Release Candidate 1 release of the IBM Generic PRISM device driver, support for Orinoco chipsets was added to this driver. Please refer to the section about the Generic PRISM device driver for more information.

4.2. PRISM2/2.5/3 compatibles
Just like the Orinoco chipset, PRISM2, PRISM2.5 and PRISM3 chipsets offer a maximum data transfer rate of 11Mbps. The older PRISM1 chipset only supports a maximum of 2Mbps. PRISM3 has the best performance, and can be compared to Orinoco chipset performance. Most WLAN devices are using a PRISM solution, and PRISM chipsets are normally rather cheap WLAN cards.

4.2.1. IBM miniPCI
This driver has been finished, and also internal IBM beta testing is completed. The driver has become available via SWC download. IBM miniPCI cards are used in many newer ThinkPads, like the IBM T30, and some other T2x models. The self-extracting driver ibmprism.exe has served as a basis for the NetGear, LinkSys, PLX9052, and Generic PRISMx driver. Some PCI-devices of other brands can also work with this driver. E.g. CompuShack SWN-103 PCI Wireless LAN Adapter, a PCI card with an external antenna, and equipped with a PRISM2.5 chipset. Just as the IBM High Rate PC Card 128, this driver is available via SoftWare Choice and PassPort Advantage subscriptions, and can be downloaded from IBM Device Driver Pak Online. Also available via eComStation download site. Please note that IBM ONLY supports this device with this particular driver! Other devices (in particular miniPCI solutions) WILL NOT WORK.

4.2.2. NetGear MA-401
The NetGear company's strategy is something like offering good average-performing devices for a reasonable price. I really like the way their support services handle non-Windows questions. They carefully say that they don't support the operating system referred to, but they try to help you as much as possible. Those guys really know the technical details of their products, like the manufacturer and device IDs! Very good, since the documentation that comes with the card is rather limited.

The card uses a PRISM2.5 chip, and has two variants: the MA401NA, which is available in North-America; and the MA401RA, for Asia and Europe. Due to the PRISM2.5 chip, the driver is identical to that for IBM miniPCI, but since the manufacturer and device IDs from NetGear and IBM are different, a specific driver for this WLAN NIC has been written. You can also get this device going using the Generic PRISMx driver.

The MA-401 card performs well for short distances. Even very thick walls don't really diminish its performance. Unfortunately, for large distances, the signals aren't strong enough; I only got the card's waves to one of my neighbors, and not to the next street. But, if you want a good card for wireless home networking, go for this one! The driver is not available to the public yet.

This card is also supported by the newer RC1 release of the official IBM Generic PRISM device driver.

4.2.3. LinkSys Instant Wireless WPC-11 v3
LinkSys has always been a very reliable brand for network products (that's part of the reasons why CISCO recently bought LinkSys). With its Instant Wireless WPC-11 card, LinkSys offers a great product for a reasonable price (€ 80.00 incl. VAT). Just as a lot of manufacturers, this card comes in several versions. The third version, equipped with a Prism3 chipset, has a special driver, which is just a modification of the Prism2/2.5/3 driver (and again, it also works with the Generic PRISMx driver). Version 2.5 comes with a Prism 2.5 chipset, but I didn't test this card (though I really don't forsee any problems when you use the PRISM2/2.5/3 driver, using the correct IDs). Taken a look at the card's performance, I was astonished by the good results: the cards actually supports a distance of 450 meters outside @ a data transfer rate of 1.2 Mbps. Even CISCO couldn't give these results.

Unfortunately, LinkSys's support services are awful. I had asked them for device and manufacturer ID, and also the chipset they used in the product, and they simply refused to give "this kind of information"! Documentation is awfully limited, thus, if you're new to WiFi, don't go for this card!

Also, this driver is not available to the public yet. This card is also supported by the newer RC1 release of the official IBM Generic PRISM device driver.

4.2.4. Others
Another modification of the IBM miniPCI driver is a Generic PRISMx driver. Theoretically, the driver was written for PRISM2.5; but because of some backwards compatibility aspect of the chipset's design, it should also work with other PRISM chipsets, if they are Intersil-branded, thus using Intersil firmware.

PC Cards using the PRISM2, PRISM2.5 and PRISM3 chipsets should be supported. The Generic PRISM driver is currently in Release Candidate phase, and is intended to appear on DDP OnLine via valid and active SWC or PPA subscription.

4.3. CISCO 340 and 350 Series
CISCO 340 and 350 products use an AiroNet chipset, which is actually again a greatly enhanced PRISM chipset.

Cisco has always been a leading networking company because of its high quality products. Unfortunately, this also reflects in the company's price strategy :( Now, both the CISCO 340 and 350 PC Cards perform excellent. Without a doubt, I dare say that these cards are the best of all the ones I tested. The 340 Series are End Of Life (EOL), but the 350 Series are available now as a replacement, offering the very same functionality.

Installation of the drivers is a breeze. The driver comes in a ZIP-file, that is not self-extracting. An excellent FAQ is included in the readme. It's noticeable that IBM is targeting this product for use under business contracts only, since everything is so smooth... Just copy the drivers in your x:\IBMCOM\MACS directory (where x: is the driver letter from the drive on which OS/2 has been installed), open MPTS, and add the card. In my case, I didn't even have to change settings to get the card running! Mark Dodel has written an excellent report about this card for eCS. There seems to be some misunderstanding in the OS/2 community about this driver. This driver ONLY supports PCMCIA cards, thus PCI and ISA variants of the same series won't work under OS/2. Perhaps you can get them to work by the PLX 9052 driver, although the PLX driver offers only support for PRISM.

Just as is the case with the other cards, there are different variants available of this card. Of each version, there are European and American edition available, since, as was already mentioned earlier, power consumption differs on both continents. For the CISCO 340 PCMCIA card, three variants have been released: first, there is the AIR-PCM340, which doesn't support WEP. The AIR-PCM341 supports 40 bit WEP encryption, while the latest version, AIR-PCM342 supports up to 128 bit encryption. Setting up WEP protection is really straightforward with this driver; more details about this will be given in the next section. Perhaps you would expect support for LEAP, CISCO's proprietary standard for security. Unfortunately, this is not supported, nor are the other security technologies from CISCO for WLAN networking.

Though I managed to get the AIR-PCM350 running with the 340 driver, IBM does not officially support this. IBM has just started the development of another business-only device driver especially for the CISCO 350 PC Card, which will also officially support the CISCO 340 PCMCIA series and that will incorporate LEAP support in the driver package. Development of this driver should be straightforward, since the 350 is a very close follow-on to the 340, since you can even flash a 340 to make it a 350 card. The new 350 driver should also support the miniPCI version of the 350 Series, including bus mastering.

The old IBM driver is unfortunately not stable, testing made it trap after a few seconds of full traffic load. The support for encryption is only for 40 bits (WEP-64), only one key. With the new 350 Beta driver, there is better throughput than any PRISM-based card. This comes due to a different buffer allocation scheme in the driver.

4.4. PLX PCI boards
The only weak spot in hardware support for OS/2 is PCMCIA or PC Card Socket Services (However, with APSoft's OS/2 Socket Services, that problem can be solved quickly). Some very handy solution are PCI-to-PCMCIA adapter devices. These cards enable you to use virtually any WiFi PC Card on regular computer. In their specifications, most manufacturers claim that only one or two specific cards work with the board, but that's just commercial nonsense. Fact is that most of the time, these slots will only work with a particular chipset. Currently supported chipset is the PLX PCI9052 chip, that can co-operate with PRISM2.5 compatibles. In general, if you use a WLAN card with the very same chipset and same voltage, you should be able to use any similar device in the brackets.

For similar devices using a PLX 9052 chipset, a driver is available. It was written especially for the AmbiCOM WL1100b-PCI card, and has been enhanced and merged into the official IBM Generic PRISM device driver. Also, the NetGear MA-301 PCI-slot-Adapter was found to be compatible with this driver, using almost any PRISM2.5 card. Also Belkin WL11000P and LinkSys Instant Wireless Adapter WDT11 PC are supported. The driver is still in very early development phase, and device IDs are still being added to it.

This driver should also work with wireless PCI cards, that also use the required chipsets (like 3COM 3CRWE777A PCI WLAN card).

One VERY IMPORTANT note: do not remove the WiFi card out of the slot before you've turned off the power, either by powering your computer off, either by using the drivers. Ignoring this warning will cause damage to your PLX board and WiFi PC Card. The older beta device driver is still available via login and password on this web site, but we recommend the use of the newer updated IBM Generic PRISM device driver (RC1 version or above). Huge difference is that using the Generic PRISM RC driver, you will be able to use Orinoco and AiroNet PCMCIA cards in conjunction with a PLX card too!

4.5. Wireless Access Points
Wireless devices, such as laptops or PDAs, connect to a wired LAN via a Wireless Access Point, which is a hardware device or computer software which acts as a communications hub (server). Access Points provide heightened wireless security and extend the physical range of a wireless LAN.

Using a Wireless Access Point, you can establish several WiFi connections with one single device. Mostly, such devices come with an Ethernet port, which you simply connect to the server. Devices like the Linksys WAP11 Version 2.2, 3COM AP2000, CISCO AIR-AP1120b, HP WL-520, TrendNet TEW-310APB, ZyXEL ZyAir B-1000, Artem access points, etc. work with a flexible web-browser based setup and configuration utility. These devices are compatible with OS/2 Warp (for e-Business) and eCS, and have been tested by the OS/2 CHL. Other come only with software, and thus aren't suitable for use with OS/2, nor Linux. Also, there are Eicon DSL-routers that also allow this kind of configuration. Normally, these devices should act as a DHCP server. Just plug them into your Ethernet port, configure the port to be a DHCP client, and reboot.

One tip I'd like to give: if you want to use these devices, make sure your computer has a very recent build of Mozilla installed, and also Java 1.3.1 or higher. Since M$ Internet Exploder is considered to be standard, older builds won't be able to display everything.

Some other good alternative, and then especially for businesses is to use a Wireless Access Point for IEEE 802.11g on the server. OS/2 nodes could use the b-standard, and other Windows nodes could use the g-standard.

4.6. Intel Centrino Mobile Technology
With the recent introduction of Intel's Centrino specifications for the latest notebooks, comes a special miniPCI wireless adapter as feature of that specific technology. This miniPCI device is the Intel PRO/Wireless 2100 v 3b device. Unfortunately, as of writing, this device is not supported by any of the OS/2 device drivers already available for OS/2. There is a beta device driver available for selected Linux distributions, but it is still very buggy and only works on selected distributions.

More information about the Intel Centrino technology and OS/2 is to be found in the NoteBook/2 part of this website.

5.1.1. Ad hoc versus infrastructure modes
Most WLANs deployed by organizations operate in a mode called "infrastructure". In this mode, all wireless clients connect through an access point (such as LinkSys WAP11 v2.2) for all communications. You can, however, deploy WLAN technology in an easier way that forms an independent peer-to-peer network, which is more commonly called an ad hoc WLAN. In an ad hoc WLAN, laptop or desktop computers that are equipped with compatible WLAN adapters and are within range of one another can share files DIRECTLY, without the use of an access point (compare this to the similar technology USB On-The-GO, which uses a similar approach). Thus deploying this strategy, you can use a direct connection between your clients. The range varies, depending on the type of WLAN system. Laptop and desktop computers equipped with 802.11b or 802.11g WLAN cards can create ad hoc networks if they are within at least 500 feet of one another. Computers in a specific ad hoc wireless LAN must be configured to the same radio channel to communicate with one another. More than one ad hoc networks can exist in the same space if it is configured to operate on a different channel. There are a varying number of channels depending on the part of the world you are operating in. Europe has 13 channels, the US 11 and Japan 14.

The security impact of ad hoc WLANs is significant. Many wireless cards, including some shipped as a default item by PC manufacturers, support ad hoc mode. When adapters use ad hoc mode, any hacker with an adapter configured for ad hoc mode and using the same settings as the other adapters may gain unauthorized access to clients.

Ad hoc is a rather cheap solution, because each client needs a wireless NIC that is already available for less than &euro; 80.00 incl. VAT, which sometimes comes built-in with new notebooks. For a regular workstation, a PCI-carrier (with the PLX PCI9052 chipset) can be used. This PCI-to-PCMCIA slot is very handy, the cards can be taken out of the slot at any time you need a WiFi card for your notebook. A pure P2P solution is - of course - only suited for a limited number of nodes/clients.

Deploying the infrastructure mode, an AP takes care of all wireless network traffic. The client in your network can communicate to one another via this AP (see it as the server in a client-server network environment). Of course, you can also connect an AP "wired" to your existing wired network. The exact location of your AP can have an implicit impact on the strength of signals, and thus also the bandwidth and range of your WLAN, but using the WiFi Status monitoring utility, you will soon find out the details. Practice has already proven a high-placed AP with the antennas directed to the wireless receivers to deliver the highest signal strength. It's also better to keep the AP as far away as possible from large (metal) obstacles or electrical sources that can cause interference. Also, the same conditions for regular PCMCIA cards are appropriate here. Important remark, however! The AP's range is very limited in performance. The signal weakens visibly once distances between AP and receiver is larger than approximately 30 meters. So far, no solution yet but to use several APs simultaneously to bridge over these limitations. Nevertheless, using a WAP, the range of wireless connectivity can be greatly expanded. This is because the WAP serves as a central point for routing of all wireless network traffic between the wireless nodes in the network.

Each AP spreads its own zone, but just as is the case with mobile phone antennas, these zones can overlap each other without any problem. This way, you can walk from one zone into another, without cutting off the connection (this is called roaming). The APs themselves can preferably be interconnected using classic wires and, of course, you should configure WLAN properly. The WAP can be configured to use encryption or grant access to computers with a specific MAC address. Wireless equipped computers networked together in infrastructure mode form a group called Basic Service Set (BSS). The BSS term is comprised of a WAP and all the LAN PCs that are associated with it. Up to 64 individual computers can exist at a single time in a BBS. This is due to the ability of the WAP to handle no more than 64 clients. The diagram below illustrates how the access point will effectively double the distance between wireless equipped computers in a BBS.

Something else you should remember is that the total available WLAN bandwidth is divided between the devices that are connected in the network. P.e., suppose you have a server running with a PLX card, and you've got three other computers connected. You've got no WAP, and all three computers request data at the same time from the server. The server will probably use the entire throughput of 11Mbps, but it will divide the data to serve all clients on an equal basis. Thus, the clients each have less than 11 / 3Mbps throughput. This very same restriction applies also to WAPs.

A term that also applies in the BSS (Infrastructure) operating mode is ESS (Extended Service Set). This is a technology in which more BSS'es can form a single subnetwork. Therefore, ESS is especially interesting for roaming. These services can only be deployed if the Wireless Access Point is configured correctly for that.

5.1.2. EMI - ElectroMagnetic Interference
There is often a great concern about electromagnetic radiation. Europe, in particular, is extremely conscious of the unknown health consequences of electromagnetic &quot;smog&quot;. In the US, we hear periodic claims of handsets causing brain cancer. Whatever the evidence, the topology of multi-hop networks needs less power, as the signals go only a short distance. One can assume that lower power means lower health risk. Microwave ovens and many cordless phones operate in the 2.4 GHz spectrum, the same radio spectrum used by 802.11b Wi-Fi wireless networks. That means they can cause interference (can disturb each other's signals, waves), but in most instances this will just slow down the Wi-Fi connection; it won't stop transmission or break the connection. To reduce interference, you can move a 2.4 GHz cordless phone away from your Wi-Fi equipped computer or base station. Interference usually only happens with older microwave ovens. You can also try changing the channel on which your Wi-Fi network operates. In addition, some manufacturers have developed and implemented special technologies that can minimize interference from cordless phones and ovens.

Which brings up the next thing to mention: channels. A channel is a frequency range within the IEEE 802.11 spectrum over which transmission may occur.

How can we understand channels of IEEE 802.11b? They are part of the spread spectrum technology, and each channel is a range of frequencies 22MHz wide, and different channels always overlap a bit. This is how [UnixWiz.net] explains it: "When picking a channel, first see what your 'neighbors' are using, thus you pick up a channel that overlaps the least with them."

We already said that a particular wireless network needs to share one same channel. But what exactly are these channels? Channels specify the band at which WiFi works more specifically, thus it is more accurate than 2.4GHz. A channel is a decimal number between one and 11 (13 in Europe) and designates the frequency on which the network will operate. Channel 1 equals a frequency of 2.412GHz, channel 2 2.417 and so on with steps of five until 2.462GHz for channel 11. Not all WiFi cards support the 12th and 13th channels, but if your devices does; the frequency of those channels are analogous.

Should you have troubles from EMI, the solution is to specify another channel. Conclusion: electromagnetic interference: no big issue.

5.2. WiFi Status monitoring utility
This article only introduces this powerful IBM utility briefly, but this page gives more details and examples.

5.2.1. Introduction
The WiFiStat.exe monitoring utility really is a great utility provided by IBM. It works with all the WLAN WiFi drivers described above except the CISCO 340 driver, and it allows you to change NIC setting on the fly (you do need version 1.5 or higher of Artem's driver). Remember, all settings can be changed using the NIF file via MPTS, but then you are obliged to reboot. WiFiStat removes this obligation. In fact, the only thing you need to do in MPTS is add the driver and attach a protocol to it. Also, very nice feature, you can specify up to four different Profiles, so that you can select the appropriate profile in a particular situation.

The main window is very easy and straightforward; its title bar states its name and also the currently activated profile.

The are two fields that always appear; the Status: field, which will tell you whether you are still searching a WLAN or whether you're already connected to one. And then, there's the SSID: field. SSID is the abbreviation of Service Set Identifier. It's a name (a sequence of characters) for the wireless network and it's sometimes simply called Network Name. In infrastructure mode, the SSID should be set to the same value as the WAP; in ad hoc mode, the SSID on ALL notebook (or for PC using PLX board) network cards in the network must be set to the same value. In the example above, my ad hoc network was called Wireless. As you can see, you can hide this field by right-clicking anywhere in the main window, and selecting Hide SSID. Analogous, you can re-enable SSID by selecting Show SSID.

Very handy is the green indicator showing you the quality of your connection. The rectangle will be 100% filled when your connection is the full 11Mbps, the maximum. If the speeds are lower, then you will see this in this rectangle. If you haven't got connection yet, but are searching for the presence of a WLAN (and notice a WLAN announces his presence, which causes security issues!), the Status: field will state Connected to IBSS, and sometimes it is changed by Searching for WLAN. The rectangle at the right is not green, you can hardly see a small white vertical line.

The options Radio On and Radio Off in the main windows' pop-up menu respectively will enable and disable your WiFi card's working. This is a handy feature, since you needn't even remove the card when entering an airplane or a hospital (where the WLAN waves could interfere with the infrastructure).

As already pointed to above, you can specify several profiles. This means you can specify for example two profiles, one for a connection in a WLAN with a WAP, and another for an ad hoc connection. Instead of having to change this using MPTS an then rebooting, in order to activate that kind of WLAN connection, just right-click the main window, select Select Profile from the pop-up, and in the submenu, choose the profile you wish. I have called my profile Profile1, but of course, you can assign it any name you want (for the scenario just described, you could name the ad hoc connection AdHoc and the infrastructure mode connection InfrWAP, and that name will appear in the Select Profile's submenu. By selecting a profile, this profile will immediately become active, but first your current connection (if it exists) will be broken. Then, using the new setting, OS/2 will try to establish a new WLAN connection.

Also interesting is that this utility (though copyright from IBM) also works with the Artem WLAN cards, if you have driver revision 1.5 or above. The WiFiStat utility is only provided with miniPCI and High Rate 128 solutions.

5.2.2. How to specify profiles...


As already said, you can specify up to four profiles for a WLAN device. In this section we'll discuss how you can specify them. To specify a new profile(, or to change: then simple change the values already listed), proceed as follows: right-click the main windows, select Add/Edit Profile from the pop-up menu, which will cause this window at the left to appear. If you change your mind, you can leave this window at any time by clicking the Cancel button. Select the profile you want to edit or a new one from scratch by selecting a radio button. By selecting a radio button next to an empty field, you will create a new profile. Before clicking the Profile Settings button, click in the empty field, and type the name of the profile. This name will later appear the the pop-up menu of the main window. After you have specified or changed the name, click the Profile Settings button. A new window will now appear, with name Settings for 'PROFILEX', with PROFILEX the name you just assigned to the profile. You will note immediately that not all the setting available via MPTS are available, but only the most frequent settings are there. In the drop-down box at the right of Operating Mode of the Card you can specify whether you are going to connect to an ad hoc WLAN network or BBS (Base Service Set, thus a WLAN using infrastructure mode) WLAN. Below, you are going to specify the network name that shall be used by the devices to identify the network in which the nodes belong. Just click in the field at the right and type the name you wish. Note the remarks about SSID in section 5.2.1! Below, there's a check-box Create a Network if none found. I have experienced it's best only to enable this with one NIC in an ad hoc network, and not to select it when using a WAP. Next, there's a drop-down box for Encryption. For &quot;secure&quot; data transmissions most WLAN NICs are capable of encryption, scrambling the information that is sent over the air between computers. The WAP uses a form of encryption called WEP (Wired Equivalent Privacy). There are two levels (the latest WiFi cards make three of that by adding 256bit) of WEP encryption, 64-bit and 128-bit. As the numbers imply, 128-bit encryption is more secure than 64-bit encryption. However, using 128-bit encryption uses keys to scramble and unscramble the data that is being sent between the wireless equipped computers. The wireless network must use the same key to be able to communicate using encryption. Note that WEP is an effective security alternative, but if your card supports it, you should use it. To enable security, select one of the options (WEP64, WEP128) from the drop-down box. Be sure your card does support encryption! In the last four text boxes, you can specify the WEP keys that will serve as a kind of password for data to pass from one node to another, since both the nodes (and in general ALL nodes in the same network) need to have the same WEP keys. You can enter 32 characters per text box. Though you can specify four encryption keys, only one can be active at a time. To make OS/2 use a particular key, specify the number of the key in the TX Key No field. If you do this, be sure that key is specified! To finish the creation of your profile, in the Settings for Profile 'PROFILEX', click the OK button. To dismiss the changes, press the Cancel button. Then you'll return to the Select a Profile dialog box. Click OK. Now you can immediately start using your profile by right-clicking in the main window, selecting Select Profile from the pup-op, and then choosing the profile you just created. IMPORTANT! Always, always, always try to get your wireless network going without encryption first.

5.3. xWireless LAN xCenter Widget
Many eComStation users have replaced the IBM WarpCenter by the eCenter, a slightly modified xCenter, part of XWorkPlace. The xCenter of XWorkPlace is a complete replacement of the old (sometimes buggy) WarpCenter. The image below shows a possible xCenter. Click the image to magnify it.

The xCenter provides several advantages over the WarpCenter, of which some are listed here:
 * Offers the same functionality of the WarpCenter, like CPU usage, shut down, search, lockup, task killer, desktop navigation menu, clock,... ;
 * Offers extra functionality like the system of the Windows Start Bar: open programs are displayed in the bar. Clicking them, makes the programs visible;
 * Network Throughput monitor;
 * APM battery indicator.

The extra functionality is achieved by embedding widgets at the places where you want it in the xCenter. This also implies more customizability than was previously the case with the WarpCenter (also called eComCenter*). The remaining part of this paragraph will deal about the Wireless Widget (wxWireless widget). For more information about the xCenter, its configuration and available widgets, we refer to one of the links in the Related Links area of the left navigation bar. To install the wxWireless widget, download the wxWireless ZIP file from the os2warp.be Wireless Device Drivers downloads page, and unzip it in the \plugins\xcenter directory, located in the installation directory of XWorkPlace (for the eCenter included with eComStation 1.1, this folder is c:\ecs\system\ecenter\plugins\ecenter). Then, just right-click any free space of the xCenter, click Create new widget, and then select XWireless LAN Monitor. The Wireless Widget is added, and you're ready to configure it and use as a tool to facilitate your daily wireless networking. The widget displays the strength of the signal, in a similar way as WiFiState, described in section Line Speeds. By pointing to the widget, you can see from the picture above, that the other information available from WiFiState is displayed.


 * Please note that eComCenter is not the same as eCenter. eComCenter equals the WarpCenter, eCenter equals xCenter.

For more information about the xWireless LAN Widget, please visit.

6. Security restrictions? What about encryption?
With the increased reliance on wireless local area networks, businesses are increasingly more concerned about network security. Network managers need to provide end-users with freedom and mobility without offering intruders access to the WLAN or the information sent and received on the wireless network. With a WLAN, transmitted data is broadcast over the air using radio waves. This means that any WLAN client within an access point (AP) service area can receive data transmitted to or from the access point, since it is just a matter of &quot;picking up&quot; the waves at a certain frequency (2.4GHz, 5GHz) and &quot;deciphering&quot; them. Because radio waves travel through ceilings, floors, and walls, transmitted data may reach unintended recipients on different floors or even outside the building that houses the AP. With a WLAN, the boundary for the network has moved. Without stringent security measures in place, installing a WLAN can be the equivalent of putting Ethernet ports everywhere, including the parking lot.

Because of these security concerns, many network managers have been reluctant or unwilling to deploy WLANs, especially in light of the vulnerability of the Wired Equivalent Privacy (WEP) keys that are used to encrypt and decrypt transmitted data (even for this limited form a security, there are ways to break it). Several research papers and articles have highlighted the potential vulnerabilities of static WEP keys. In addition, hackers have ready access to tools for cracking WEP keys, such as AirSnort, which enables an attacker to passively monitor and analyze packets of data and then use this information to break the WEP key that encrypts the packets. Network managers need reassurance that WLANs can provide the same level of security, manageability, and scalability offered by wired LANs. WEP currently is available in all OS/2 WLAN drivers.

6.1. Traditional WLAN Security
For this section, I made use of CISCO's White Sheet about Security Issues related to WLANs. As with other networks, security for WLANs focuses on access control and privacy. Robust WLAN access control prevents unauthorized users from communicating through APs, the WLAN endpoints on the Ethernet network that link WLAN clients to the network. Strong WLAN access control ensures that legitimate clients associate with trusted, rather than &quot;rogue&quot; APs. WLAN privacy ensures that only the intended audience understands the transmitted data. The privacy of transmitted WLAN data is protected only when that data is encrypted with a KEY that can be used only by the intended recipient of the data.

Traditional WLAN security includes the use of Service Set Identifiers (SSIDs), open or shared-key authentication, static WEP keys and optional Media Access Control (MAC) authentication. This combination offers a rudimentary level of access control and privacy, but each element can be compromised. Yes, indeed, all technical term, which will be discussed in the paragraphs below:

SSID is a common network name for the devices in a WLAN subsystem; it serves to logically segment that subsystem. An SSID prevents access by any client device that does not have the SSID. By default, however, an AP broadcasts its SSID in its beacon (a beacon frame are the frames that the AP sends every 20 milliseconds whenever it doesn't receive frames anymore). Even if broadcasting of the SSID is turned off, an intruder or hacker can detect the SSID through sniffing (sniffing means, &quot;catching waves&quot; and trying to decode them).

The 802.11 standard, a group of specifications for WLANs created by the Institute of Electrical and Electronics Engineers Incorporated (IEEE), supports two means of client authentication: open and shared-key authentication. Open authentication involves little more than supplying the correct SSID. With shared-key authentication, the AP sends the client device a challenge text packet that the client must then encrypt with the correct WEP key and return to the access point. If the client has the wrong key or no key, authentication will fail and the client will not be allowed to associate with the access point. Shared-key authentication is not considered secure, because a hacker who detects both the clear-text challenge and the same challenge encrypted with a WEP key can decipher the WEP key. Also, encryption is performed via the RC4 encoding algorithm, which is already well-known to expert-hackers.

With open authentication, even if a client can complete authentication and associate with an AP, the use of WEP prevents the client from sending data to and receiving data from the AP, unless the client has the correct WEP key.

Another type of key that is often used, but is not considered secure, is a "static" WEP key. A static WEP key is a key composed of either 40 or 128 bits that is statically defined by the network administrator on the AP and all clients that communicate with the AP. When static WEP keys are used, a network administrator must perform the time-consuming task of entering the same keys on every device in the WLAN.

If a device that uses static WEP keys is lost or stolen, the possessor of the stolen device can access the WLAN. An administrator won't be able to detect that an unauthorized user has infiltrated the WLAN, until and unless the theft is reported. The administrator must then change the WEP key on every device that uses the same static WEP key used by the missing device. In a large enterprise WLAN with hundreds or even thousands of users, this can be a daunting task. Worse still, if a static WEP key is deciphered through a tool like AirSnort, the administrator has no way of knowing that the key has been compromised by a hacker. So you can immediately see now why I've already discommended WLANs for business endings.

Some WLAN vendors support authentication based on the physical address, or MAC address, of the client Network Interface Card (NIC). An access point will allow association by a client only if that client's MAC address matches an address in an authentication table used by the access point. But MAC authentication is an inadequate security measure, because MAC addresses can be forged, or a NIC can be lost or stolen.

While traditional WLAN security that relies on SSIDs, open or shared-keys, static WEP keys or MAC authentication is better than no security at all, it is not sufficient for the enterprise organization. Only very small businesses, or those that do not entrust mission-critical data to their WLAN networks, can rely on these WLAN security types. All other enterprises and organizations must invest in a robust, enterprise-class WLAN security solution.

Although traditional WLAN security that relies on open or shared keys and static WEP keys is better than no security at all, it is not sufficient for the enterprise organization. Only very small businesses, or those that do not entrust mission-critical data to their WLAN networks, can rely on these WLAN security types. All other enterprises and organizations must invest in a robust, enterprise-class WLAN security solution.

Nowadays, more modern security measures are available. Newer technologies like IPSec, EAP/802.1x, EAP/TLS, PEAP et cetera. Surely, they will be better then WEP, but they are more software-based security solutions, thus mostly Windows-only, and thus not available on the OS/2 Warp platform.

6.2. Why WEP Is Insecure...
This section was taught at the WarpWeekend 2003 event in Roermond, the Netherlands. This section is only for people who want the theoretical background of why the WEP (Wired Equivalent Privacy) is awfully insecure. If you are currently still having problems with the previous sections, then please skip this section and get back to it at a later time when you have a complete knowledge. One note you should remember during the study of this section is that WEP is defined in the 802.11 standard, not the individual standards for 802.11b, 802.11a, and 802.11g task groups. As a consequence, WEP vulnerabilities have the potential to affect all flavors of 802.11 networks (except newer 802.11 standards that replace WEP like 802.11i).

Before we go on, you should be aware of what a XOR port is. A XOR port is in fact an OR port with only one (indicated in red) input combination different from the OR. At this moment, we are speaking about Boolean Algebra (algebra with only 2 values: a zero (false) and a one (true)). Both ports we have referred to are in fact functions that we offer two inputs, and a function has only one output. Now consider the two truth tables below: The columns in0 and in1 are in fact the two inputs, two wires connected to the gate, and there's only one wire that leaves the gate, called out.

Now, WEP employs an integrity check field in each data packet to ensure that data is not modified during transmission. For this purpose, a 32-bit CRC checksum is used. But deploying WEP, we need one (select one out of four keys) secret key, consider it a password to encrypt/decrypt data, generally referred to as the "WEP key". WEP also uses the RSA RC4 encryption algorithm. RC4 is a stream cipher designed by Ron Rivest for RSA Security. A stream cipher expands a fixed-length key into an infinite pseudo-random key stream for the purpose of encrypting data. In WEP, plain-text data is bitwise XOR'ed with the key stream to produce the cipher text. This results in the presentation below. Now let us continue step by step:  ++-+ ++-+ +--+ +--+ +-+--+ +-+--+  What is bitwise XOR'ing? Consider first our data. It is being sent as a plaintext message. That means that in fact, the data is being transferred as text, thus as a sequence of ASCII characters, which we express in binary (strings of 1s and 0s because our computer can only understand those two binary digits). Suppose we are going to bitwise XOR the characters of our plain text string, which are all ASCII characters. Suppose that we are going to XOR the characters n and b. They have ASCII values 110 and 98 respectively, which are decimal numbers. However, we must express these two characters in binary so that the computer can understand what we mean. If we convert, then we have respective binary values of 01101110 and 01100010. Now, just as we have the units, tens, hundreds, thousands in our decimal number system, in binary (radix two), we have such things too. In fact, these things assign a particular weight to a specific digit. Anyway, consider the bit string of n: 01101110. The rightmost 0 is on the units place, the 1 at the left of it is at the 2^1s place, the bit at the left at the 2^2s place and so on... Now what we're going to do is just XOR the respective bits of the bit strings of n and b.
 * Plaintext Message (= DATA!!)|  CRC   |
 * Keystream = RC4(V,K)                |
 * V |             Ciphertext               |

We're starting from right to left, but note that we can reverse this process without any problem. At the place of the units (2^0) we have respective bits 0 and 0. XOR(0,0) = 0. Now we move one place left (thus we're now at the place 2^1). XOR(1,1) = 0; again one place to the left: XOR(1,0) = 1, and we continue in this way till we reach the left side of the bit strings. This is what bitwise XOR'ing is. 01101110 The letter  n, in binary 01100010 The letter b, in binary 00001100 The XOR'ed value As we already explained, WEP requires that each wireless network connection share a secret key for encryption purposes. WEP doesn't define key management techniques such as the number of different keys used within a network or the frequency to change keys. In practice, networks use one key among access points and change keys infrequently, as most vendor implementations of WEP require that keys be changed manually. The key stream produced by WEP's RC4 algorithm depends upon BOTH the secret key and the Initialization Vector. The Initialization Vector is used to ensure that subsequent data packets are encrypted with different key streams, despite using the same secret key. The Initialization Vector is a 24 bit field that is unencrypted within the header of the data packet, as shown above.

Now consider the diagram above that explains how we encrypt our data. As already said, we send our data as plain text, a series of ASCII characters. We target a mathematical function, assume it is called CRC32 on this plaintext. CRC32(Plaintext Message) = a certain number. This certain number is what we're going to convert to base two, and will then fit in 32 bits. We now create a new array of 0s and 1s: the first bar of the diagram. Then we are going to produce a Keystream. Again, we use a mathematical function: this time the RSA RC4 algorithm, that is actually the real encoding part of the system. RC4(V,K) equals a key string, which we can easily convert to binary (1s and 0s). This is the second bar in the diagram. Now, we are going to bitwise XOR these two bars, and we get what is called the Ciphertext. We're now just pasting the Initialization Vector (24 bit) in front of that, and we have our packet of encrypted data via WEP.

Now, in optimal conditions, we have this:
 * 11Mbps + ((1500 bytes per packet) * (8 bits per byte)) = 916.67 packets that are transmitted each second.
 * 16777216 Initialization Vectors + (916.67 packets per second is) = 18302.41745 seconds to use all Initialization Vectors.
 * (18302.41745 seconds) *( 60 seconds per minute) * (60 minutes per hour) = 5.0840048 hours to generate all Initialization Vectors.

We can conclude out of these calculations that an Initialization Vector would be repeated (referred to as an Initialization Vector Collision) about every five hours in a network running @ 11Mbps and transmitting packets of size 1500 bytes.Once an Initialization Vector Collision occurs, and an attacker has two different plain-text messages encrypted with the same key stream, it is possible to obtain the XOR of the two plain-text messages by XORing the two cipher text messages. The XOR that results can then be used to decrypt the traffic. Let's clarify this now with Boolean Algebra:  C1 = Ciphertext 1 C2 = Ciphertext 2 P1 = Plaintext 2 P2 = Plaintext 2 V = Initialization Vector K = Secret Key C1 = XOR [ P1, RC4(V,K) ] and C2 =XOR [ P2, RC4(V,K) ], thus: XOR (C1, C2) = 	XOR { XOR [ P1, RC4(V,K) ]; XOR [ P2, RC4(V,K) ] }  We now apply the associative law: XOR [ P1, RC4(V,K), P2, RC4(V,K) ] We now apply the commutative law: XOR [ P1, P2, RC4(V,K), RC4(V,K) ] RC4(V,K) and RC4(V,K) are two bit strings that are the same. XOR(0,0) = 0 and XOR(1,1) = 0 ==> RC4(V,K) + RC4(V,K) = 000...0 = 0, and thus we can leave this away XOR ( P1, P2 ) Example (slightly modified from example from iDEFENSE Inc.):

Therefore, when using the same secret key (just trying, it's only 128 bits long), the XOR'ed value of the plaintext messages (&quot;a&quot; and &quot;b&quot;) is equivalent to the XOR'ed value of the encrypted messages. Thus, if an attacker has knowledge of the contents of one plain-text message when an IV collision occurs, the attacker could then decipher the contents of the other plain-text message without any knowledge of the key stream used for encryption.

6.3. Modern Security Technologies
Since Wireless Equivalent Privacy (WEP) is very insecure, both the IEEE and individual manufacturers try to develop newer and more secure technologies for encrypting data. Here are a few of the new ones:

6.4. Where does this leave us with OS/2?
For now, WEP is available using all current OS/2 device drivers. As said, the LEAP security protocol is not officially supported by IBM's business device drivers. But documentation to get LEAP running with the CISCO 340 driver is available if you've got IBM business contract for the driver.

7. And what about Linux?
All devices that currently work under OS/2 will most likely also work on the Linux platform and vice versa. For the Orinoco chip, two drivers are in wide use. The older wlan_cs driver, and the newer driver orinoco_cs. For the CISCO products, there is also an Open Source driver available for the AiroNet product series (although you need to specify the WEP keys every bloody time you boot). About PRISM, Linux has fewer drivers than OS/2 for the moment. The only driver that is really usable is a driver for Intersil PRISM2 (there are also other drivers, but they are either unstable, or written for specific devices). [] will provide you with all possible answers to your questions. OS/2 CHL is currently putting intense effort in an article identical to this, but which applies to the GNU Linux platform. This article will be included in the OS/2 Hardware Infosheet as is referred to in the links below.

8. Conclusion.
If you have already hated these wires for so long, I'd definitely go for it. IEEE 802.11b cards that work with OS/2 are not that expensive; also, they are an alternative for wired NICs, for which manufacturers tend to develop less and less NDIS 2.01 drivers, the drivers we need for the OS/2 Community. For business ends, I would say: Go for something else. IEEE 802.11b is not as fast as regular 10/100Mbps network adapters, and certainly is inferior to the speeds offered by Gigabit Networks. WEP is not a really good answer to security issues, and it doesn't seem that effective security solutions will be available in the future. With an eye on the very near future, you'll also be able to use your existing WiFi card for hot spots, a bright new, and interesting technology that could mean TRUE mobility.

OS/2 has now drivers for the most popular chipsets in use today for IEEE 802.11b devices, and development continues (maybe there will be an Atmel driver soon).

All in all, I would target WiFi cards not for business networked connectivity, but for DSL or cable connections and perhaps for small home networking.

10. Acknowledgements.
Please note: IBM (International Business Machine Corp.) is a very large world-wide company. Due to its largeness, a very diverse set of announcements are officially made, but unfortunately, from time to time, a lot of rumors are also passing in the world. I tried my very best to be as accurate and precise as possible, though mistakes can never be overcome. If, despite of all efforts that have been done with the help of IBM Germany, incorrect statements about IBM should occur, then I do apologize for these inconveniences, and I'll try to correct mistakes as much as possible. It is my intention to provide correct information.

I'd really like to thank some people for their continuous efforts for OS/2 Warp, and for helping me either with my OS/2 CHL project, or in assistance of writing hardware articles for the OS/2 Warp product family:
 * Especially Jens Glathe, for his continues effort to support WiFi under OS/2, and        for device driver in-depth details;
 * Oliver Mark, IBM Germany, for his continuous effort to support OS/2 and the OS/2 Compatible Hardware List;
 * All members of the OS/2 Warp User Group Belgium, for helping me testing all of those        WiFi cards, and for their continuous efforts to support OS/2 and eCS;
 * Perry Werneck, Kevin P. Walter, Johan Driesmans, Roderick Klein, Stuart Grey for beta testing;
 * All OS/2 CHL hardware testing team member for their continues effort and drivenness to pursuade with os2warp.be.