[MLB-WIRELESS] How to get a node going quick.:- Don't do anything we did.

[Tony Smith]

Over the past couple of days I've been faced with the problem of quickly
getting a node going so that a friend who lives a little over 200 metres
away can share some of the resources of my LAN.

At various times we almost came to the conclusion that running an Ethernet
cable through the drains late at night might have been the most viable
solution to the problem. Never  the less we persevered and we now have our
very own wireless link happening.

The first step, actually done a couple of months back now was to dedicate a
machine running Linux to be an Access point. To this end we had purchased
DLink DWL-520 PCI radio LAN cards and had laid in a small stock of 486 and
early Pentium motherboards to become our "radio routers".

This was mistake No.1.

Although there was no hint on DLink's website and nothing either on the
boxes or in the documentation, the cards do not in fact work in a machine
that has a PCI bus of less than revision 2.2  When we bought the cards in
early January 2002 not many other people knew that either, but we did then
have to find compatible machines. Fortunately I found that HP Vectra VL
machines (Socket 7 200mmx) do in fact have the correct revision of PCI bus
and do work. These machines were available less hard drive and memory fairly
cheaply as a local business had a slew of them coming off lease. In view of
the non standard power supplies and motherboards we bought a few spares.

Next we loaded Windows 98 on the machines, once we had them going and tested
the cards, all went well and Linux (RedHat 7.2) was installed. We spent
several weeks floundering about trying various driver combinations etc
without much success until we discovered  three things.

This generally encompasses major mistakes numbers 2, 3 and 4. Know in
advance how you are going to use the equipment and then only buy equipment
that has stable well-proven drivers.

1/. That it doesn't matter much what card/driver combination you use, Prism2
peer-to-peer mode didn't (and apparently still doesn't) work too well under
*nix/
2/. We were going to need something called an access point, whatever that
was, we looked and the then entry level price of $500 scared us off.
3/ We discovered the wlan-ng prism drivers and the wonderful Prism host-AP
drivers.

Being relative novices in Linux we had some fun wading through the
documentation, but eventually we got there.

An access point was soon created and in order to test it I purchased a
Xircom CWE1120 PCMCIA card for my Laptop.

This was mistake No. 5.  I should have asked myself why these cards were so
much cheaper than others about, mind you due to lack of research I still
ended up paying more than twice what I would have paid for an Entrasys card
via one of Melbourne Wireless's infamous TIB offers. And in the end I had a
card of marginal performance with no external antenna jack and limited to no
support under Linux, which was a pity as my Laptop had been a Linux device
for over a year. Windows 98 was installed and the access point tested and
fine tuned as further revisions became available.

I won't dwell too much on mistakes 6 & 7 as they relate to paying for far
too much co-ax lead and having it pre-terminated with exactly the wrong
sorts of connectors which subsequently resulted in the purchase of $40 worth
of adaptors at the antenna end and $30 pigtails at the radio card end.
Research, and more explicit instructions to the cable maker, combined with
more accurate measuring of cable paths could have saved well over $150 here.

Finally we moved to the fun of  setting up the "node" station. This should
be easy we thought as we quickly built a box and installed a brand new copy
of RedHat 7.3 on it. Quickly compiled the wlan-ng prism2 drivers, used the
bridge software that comes with 7.3 and expectantly plugged in the laptop to
the bridged wired ethernet card via a cross-over Ethernet cable.

Zip, nada was the result.

Strangely the "traffic" lights on both the laptop's pcmcia card and the
realtek Ethernet card fitted to the "node" indicated that traffic was
happening, in fact out of the corner of my eye I could see them both beating
time to the traffic led on the hub, but no networking was happening.

We did the usual stuff, swapped cards etc, but it looked like the hardware
was just fine, it had to be software. The obvious suspect was the RedHat 7.3
system. So it was ripped out and 7.2 installed, bridge utils, wireless
utils, card drivers etc all compiled and installed.

Same result......

If I'd had 1/2 a brain it might have clicked what was wrong, but not me,
swapped hard drives and installed a copy of Smoothwall. Then I discovered
that Smoothwall used kernel 2.2.21 whereas we had been using kernel
2.4.something in the RedHat boxes and all the nice driver modules were not
going to load under Smoothwall.

A quick request for someone else to supply compiled modules didn't elicit
any help so I downloaded the kernel source for 2.2.21 and installed it onto
my working redHat 7.2 system (swapped hard drives again) and compiled all
the drivers and then mounted the Smooth drive under the RedHat drive and
copied everything across.

This little misadventure comprises major mistakes 8, 9 and 10.  Simple good
practice should have dictated checking and re-checking basic assumptions and
then making small incremental changes instead of blind wholesale ones.

The next drama was to reverse-engineer Smoothwall enough to accept wlan0
instead of eth0 as its incoming network device......This was fun.....

It was also mistake No. 11

Although the smartest thing I did was to bit by bit install midnight
commander onto the smoothwall box so that I could navigate around it more
effectively. (for the record the lib.gpm libraries and the entire
subdirectory of /usr/lib/mc is all that is required in addition to the
executable to make it work). Eventually I discovered how to manipulate
Smoothwall's network devices and had it all up.

Same problem as before, there was traffic happening over the bridge but not
in a form that my laptop, or another PC pressed into service actually
recognised. Cables were changed, hubs were borrowed, all to no avail.

Finally my friend Kent, who cunningly stayed right away from the software
side of things and had buried himself away making antennas (anyone got any
use for a pair of nice omnis that have been unfortunately painted a pretty
shade of black with microwave absorbent black enamel) asked me what the
difference between the version numbers on the wlan-ng site meant.

By the way, the painted antennas were mistakes 12 and 13 cause there were 2
of them.

A brief look and the exercise of more than three brain cells resulted in the
dawning realisation that the file cunningly marked
"linux-wlan-ng-0.1.14-pre7.tar.gz" was a lot younger than the file marked
"linux-wlan-ng-0.1.13.tar.gz". The grand total of two minutes work looking
at the change log for the intervening 7 revisions between the version we
were trying to use and the most recent indicated that a lot of the changes
were specifically to solve the problem that had beset us.

Kent insists that due to the enormity of this one that it constitutes
mistakes 14 through 20 all by itself. I'm too embarrassed to argue.

Once the new drivers where downloaded and compiled for the 2.2.21 kernel in
the Smoothwall box, it all functioned. Although it was very slow getting
only around 4.5k/sec on downloads that I know normally zip along at 7.2k/sec
on our ISDN connection. In retrospect the reason is probably tied up with
compiling the modules against a kernel they were never designed to function
with. In fact this further pointless dicking about with Smoothwall
undoubtedly constitutes mistake 21.

Finally, the new drivers were installed on the RH7.2 box. The project never
looked back. We get a reliable 11meg connect and whilst file transfers
between the machines on our networks over the radio link appear more than a
bit sluggish, there is more than enough bandwidth for other things.
Doubtless the bandwidth will improve with new versions of the drivers,
something I am strangely a little more aware of now.


So there it is, if you want to set up a Linux based access point and make
services available to your local community the simple step-by-step approach
is to look at what we did and don't do any of it!




Cheers

Tony Smith

Connected to the internet in Sunny Far North Queensland Australia
http://www.tonsyl.org







To unsubscribe: send mail to majordomo at wireless.org.au
with "unsubscribe melbwireless" in the body of the message