Networking parameters (the NetID is set automatically by the card):
| Old CouchNet (home) | ||
| ESSID | CouchNet | |
| Mode | Ad-Hoc | |
| Channel | 01 (2.412 GHz) | |
| WEP | Yes | |
| New CouchNet (home) | ||
| ESSID | CouchNet | |
| Mode | Managed | |
| Channel | 11 (2.462 GHz) | |
| WEP | Yes | |
| UCLA Bruin Online Wireless Net | ||
| ESSID | UCLAWLAN | |
| Mode | Managed | |
| Channel | Default (per AP) | |
| WEP | No | |
Installation and Struggle
This history illustrates the learning process that I went through to set up my wireless network. I hope this documentation will help other users to avoid so many pitfalls.
I installed the Netgear hardware, booted both machines into Windows, and installed the respective drivers and utilities. Installation was uneventful, following vendors' instruction manuals.
However, the cards did not associate (using the default settings for each). They also did not associate when I configured them with the CouchNet ESSID, channel and WEP key (and ad hoc organization). They also did not associate with a manually set different channel (11) and ESSID, and WEP disabled.
I then installed the Netgear MA401 Windows driver on the laptop (this is the server's card) and went off to the UCLA library, where an 802.11b network is installed. However, I was not signed up for it and I didn't have the WEP key (didn't know at that time that there was no WEP key). Neither card was able to locate the network on any channel.
I then thrashed around nonproductively trying to get the cards to work under Linux (kernel 2.4.5) using the wvlan_cs driver. After that, I upgraded my kernel so I could use the orinoco_cs driver, version 0.07.
The wireless tools (iwconfig) consistently got segmentation faults, and its documentation indicates that the cause is a mismatch between structure formats (header files) used in the kernel and in the tool. Recompiling the wireless tools took care of the seg faults, brought more coherent information reports, and enabled the cards to be configured so as to function (but not associate). The version used was v22; download from here or relevant mirror sites. Progress is rapid; as this is written (2002-12-10) the latest version is 25.
Official command line for configuring the cards:
Some cards require the ESSID to be last, the Agere and Netgear cards don't care, but the Linksys card needs it to be before the mode setting.iwconfig eth2 nick FAFNIR essid CFT mode Ad-hoc channel 3 key aaaa-9999-88 iwconfig eth1 nick XENA essid CFT mode Ad-hoc channel 3 key aaaa-9999-88
I obtained the Bruin Online wireless infrastructure test ESSID and the VPN client that you have to use. (There's a version for Linux also, q.v.) Again, neither radio noticed the access points (in WinXP). This was not an issue of not having the SSID or WEP key; the cards are just deaf. (It turned out that only one card was defective, but the access points were inoperative when I did one of the tests, and I was in locations alleged to be covered but which had the worst signal strength, for the other.)
More Linux hackery. When you start and stop the internal Ethernet and wireless cards and/or insert a PCMCIA card in random order, they end up getting eth0, eth1 or eth2 randomly. In theory, the PCMCIA services scripts handle this issue automatically. Also, the provided /etc/init.d/dhclient script (which executes dhcpcd) will not start dhcpcd on card B if there is already an instance running on card A, even though dhcpcd is able to handle this situation. I hacked the script to treat clients on different interfaces as different instances. (SuSE 8.1 has an equivalent hack already.) A sufficient solution would have been to set the wired Ethernet card to not be started, and to configure it manually in the rare cases when I need to use it.
The Network Begins to Function
Back to Bruin Online. Using a known good access point, the internal wireless in Xena under WinXP associates with it and is fully operational; you can connect to their VPN using the provided software. A co-worker's Linksys WPC11 card also works. But the Netgear MA401 is deaf as a post. Send it back!
I received and installed a Linksys WPC11 Network PC Card version 2.5, and WDT11 PCI Adapter. The adapter uses a PLX PCI9052 PCMCIA bridge chip. Idiots! Version 2.5 is for Windows CE (and XP if you put on a firmware upgrade). They sent a driver disc with the PCMCIA card and no users manual, and the directories on the disc did not match the "quick start" instructions, and had no Win98 drivers. With the WDT11 there was a users manual (that covered both products) but no disc. So I'll have to initially try this out under Linux. (I never did get the Linksys card working under Windows 98.)
The driver for the WDT11 PCI adapter, and several others that use the PLX
PCI9052, is orinoco_plx. Its PCI ID is 0x16ab:0x1102, which you can discover
by using lspci -v -n
. You need to recompile orinoco_plx.c v0.07 with this
PCI ID so the card will be recognized. Beware, the kernel configuration help
says, Support for these adaptors is so far still incomplete and buggy. You
have been warned.
v0.09b includes the Linksys PCI ID, and has at least one
major bug fix in the PLX PCI9052 support.
I set the thing up on the server with Linux, using the Orinoco drivers, omitting WEP. Works right off! The Dell TrueMobile 1150 (laptop) running XP associated with the Linksys WPC11 running Linux (kernel 2.4.16) with the orinoco_plx driver. Signal strength is reasonable and it can do 11 Mbps. (I should have left well enough alone. I "upgraded" the Linksys firmware and the problems started with missing ACKs, described above.)
The Dell TrueMobile 1150 card was initially not recognized by PCMCIA card
services, so I used cardctl ident
to determine its manfid (or I could have
used lspci -v -n
to find its PCI ID), and I made a stanza for it in a
separate file called /etc/pcmcia/agere.conf, which is read automatically after
config. It would appear that the card is listed properly in
/etc/pcmcia/orinoco_cs.conf (called hermes.conf in later versions), but for
some reason it was not recognized until I made my own file. Possibly this was
coincidental with some other change in the configuration procedure.
After making my own stanza, I got orinoco_cs working on the laptop (Linux), recognized by PCMCIA card services, and associating with the server. I didn't have to recompile the card services utility programs. Timing data for `scp local.file fafnir:/tmp/junk`:
| File Size | How Long |
|---|---|
| 2600 bytes | 0.63 secs |
| 623 Kbytes | 1.63 secs |
Inferred data rate for the large file: 4.4 to 5.0e6 bits/sec, which is what people report as the typical useable data rate for 802.11b at full speed. It is generally true that 802.x type networks cannot be used effectively at their full rated speed. While 802.3 will go up to around 9 MHz, there is a lot more overhead in 802.11 and its variants, and half the rated speed is more typical.
Orinoco Driver v0.09b
On Fafnir (the server, with the Linksys card) in v0.07,
orinoco.c::dldwd_xmit sometimes gets this error over and over: eth2: Error
-110 writing packet header to BAP
. The link is extremely sluggish when this
mode is happening, and once it starts, only rebooting will make it stop. It is
impossible to unload the drivers due to some kind of bug in orinoco_plx (you
have been warned, they said). Error 110 is ETIMEDOUT. I scanned the
changelogs for later Linux kernels and discovered that v0.09b has a fix for
this. I obtained and compiled that version; the fix was effective. With the
new driver the Linksys card gives the impression of working optimally.
However, other problems surfaced on the Agere card. First, most outgoing
packets (could be all) get the error message eth1: Tx error, status 1
(FID=03ED)
from __orinoco_ev_txexc. Status 1 is excessive retries
. The
packets get through, but the speed of a file copy is 2.02e5 bit/sec (slooooow).
On a large file the other end got one each of "Unknown Rx error (0x3). Frame
dropped." and "Undecryptable frame on Rx. Frame dropped." A similar file copy
on which the Agere card was receiving went at 1.56e6 bit/sec, reasonable for a
2 Mb/sec setting (see below), although status 1 reports were logged from the
Agere card, presumably for acks. My solution was selective denial: hack the
code to omit the error message on status 1.
On the Linksys card in the PCI adapter, there were a lot (but less than one
per packet) of Null event in orinoco_interrupt!
The card posts an interrupt
for reporting some event which should be something like transmit finished or
incoming packet received, but when the event record is retrieved, nothing is
there. A comment in the code says, does this really happen?
Yes, it does
really happen. Again, selective denial: I commented out the error message.
On the Agere card, hermes_read_ltv rid does not match type
was seen
often. My solution: Flush twice, it's a long way to the kitchen. I made
hermes_read_ltv repeat the seek and read operations (only once) on seeing
that error, and it solved the problem.
At least on the Linksys card, the CURRENTCHANNEL is zero until you do
ifconfig up
, and most other current
values are in an arbitrary state,
causing a bizarre frequency report and other output from iwconfig. Later
driver versions initialize the current
values to innocuous but
meaningless values before the card has been brought up.
40-bit WEP works between the Agere and Linksys cards. Set key fedc-ba98-76 or a 5-byte string. With the Orinoco driver set v0.09b, but not with v0.07, 104-bit WEP also works. Set a 13-byte key, extending the format used for the 40-bit key. (In 0.07 it was just assumed that Intersil firmware could not do 104-bit WEP, and the key was not set; in 0.09b the program sets the key whether or not the card can handle it.)
In an ad-hoc network, when you change the key on the second card to match the first one, it takes less than 5 seconds for the cards to associate (i.e. you can start pinging). There is an order dependency in iwconfig with WEP on Intersil firmware. The command lines given above are sufficient to satisfy the dependency.
Using orinoco_cs on an ad-hoc network, /proc/net/wireless reports all 0 for
the status and link quality. To activate the quality measures you need to
specify one or more spy addresses
, the MAC address or hostname(s) of
partner machines, on whose incoming packets the measures will be recorded.
You can use either of these command lines:
In the latter case the name would be translated to an IP address and that would be looked up in the arp cache.iwspy eth2 00:02:2D:35:33:27 iwspy eth2 xena
Signal Strength and Range
Using Orinoco drivers v0.09b, I made a site survey around my house. The effective exterior range was about 20 meters. However, several factors limited the range. First, the server's antenna sticks out the back of the metal case which faces an exterior wall made of stucco backed by metal mesh, the typical residential construction in Los Angeles. The antenna is low to the floor (in slot 6 of a tower case). There is a metal fence between us and the neighbor, and a metal filing cabinet between the computer and the back of the house. Thus the antenna is situated in the worst possible location. If I could have, I would have gotten a USB network adapter with a long USB cable, and set the NIC on top of the filing cabinet, or in the window for the distance tests. When I eventually got the Agere AP-200 access point, I located it on my highest bookshelf above the filing cabinet, and signal strength is now excellent throughout the house.
In any case, here is the signal to noise ratio (in dB) around my house. Due
to either firmware or driver problems, communication was at 2 Mb/s. At a SNR
of 5, most packets are lost. At 9 to 11, almost all get through. At 6, about
70% of the packets make it.
SIGNUKE, a microwave oven is operating next to your laptop. Cannot be caught
or ignored. The SNR was seemingly lower, but not a lot, and the difference
does not seem to be statistically significant. This was only tested on
channel 3; perhaps the result would have been different on a channel
that included the oven's operating frequency, whatever that is.
Security is quite a complicated topic, with multiple issues and dimensions.
First, attacks can be random, or can be targeted specifically at you because
the hacker knows you have something of value. Second, attacks can involve
controlling your machine or executing the hacker's code on it, or can be purely
passive eavesdropping. The special vulnerability of wireless networking is
that an eavesdropper can pick your packet stream out of the air, undetectably.
On an unswitched wired network the same thing can happen if the hacker has
access to a computer on your net, but on a modern switched net each machine
sees only its own packets (and broadcast packets). When the packet stream
is handled by your ISP, personnel can extract your packets, either pursuant
to a search warrant or illegally.
From the packet stream the hacker can obtain passwords, and any other
sensitive information that may be sent over the net, such as database
queries.
To combat eavesdropping people use encryption at the second, third and
fourth protocol layers. Specifically, modern wireless cards include If you have serious security concerns you should use better protection at
the third or fourth layer. While UCLA is not exactly a hotbed of espionage, I
do system administration from home, and now on the wireless net, and I encrypt
all my connections using ssh. This channel is believed to be invulnerable, in
the sense that several billion dollars of computing equipment would have to
work together for a year to crack a single session. ssh provides end-to-end
protection from your machine to the one you connect to, at the fourth protocol
layer. Web commerce and database products generally use ssl, again at the
fourth layer, to protect data end-to-end, and all modern web browsers can
handle ssl. It uses similar algorithms to ssh and is also believed to be
invulnerable.
(When the channel is invulnerable, the hackers will steal the information
from the endpoints, which may or may not have exploitable security holes.
An acquaintance was the target of industrial espionage: the thieves broke
into his office and physically removed just his hard disc.)
For the wireless test, UCLA provides the Cisco
VPN5000 virtual private network (VPN) product (q.v.), which encrypts all
traffic packetwise at the third layer, making it appear to originate from
the VPN server machine. A problem with VPNs is that traffic
from the VPN server to the ultimate destination is not protected. Also,
incoming traffic provided by hackers has to be blocked by a firewall on your
own machine, same as if you were connected directly to the internet where
the VPN server is located. During a test described with VPN5000, I received
three hack attempts unencrypted from the access point, and one via the VPN on
the encrypted channel.
This is another vulnerability of wireless nets: hackers can inject packets
untraceably, whereas on a wired net they would either have to have physical
access to a computer on the net, or must send packets from afar, which may or
may not be blocked by a firewall router. It's unfortunately true that you
cannot secure the operating system version expected to be used most often on
the UCLA wireless net, but users should do the best job they can, same as on a
wired net or particularly with DSL. A Linux system can be configured to
essentially not see hacker sendings, yet still be useable. Most Linux
distributions have a firewall component, which should be used. Windows XP
includes a simple firewall, and third-party add-ons are available for all
Windows versions. See here about using a
firewall with the Cisco VPN5000 client, and what kinds of attacks to expect in
a real wireless session.
The major security threats seen recently have been imprudent execution
of e-mail attachments, and buffer overflow exploits. The vast majority
of attacks are performed by viruses, which (lacking laptop computers) are not
able to use to advantage the vulnerability of wireless nets, that packets
can be sent without visibility and without external firewall filtering.
In my opinion the security of the wireless net is not significantly less
than the wired one. And the security of the wired net is overestimated.
Security Issues
Wired
Equivalent Privacy
(WEP), which is encryption of each packet at the second
layer. An exploit to crack the encryption is known, but a less vulnerable
algorithm has been developed and firmware upgrades in the near future should
include it. The WEP key has to be given to the user (it is not passed out by
Diffie-Hellman key exchange), and for a serious targeted attack, an agent
should be able to steal the WEP key easily. Also, a 40-bit key (64 bits
including the MAC address) is well within range of a brute-force exploit.
104-bit WEP is probably beyond the reach of brute force, but the
exploit works on it too. Thus WEP is enough to resist the usual teenage
snoopers, but should not be taken seriously in an environment of national
security or corporate espionage.
| Next: Kernel | Previous: X Setup | Contents |