I thought it might be useful to post a few notes on the process of getting connected to the CafeNET WLAN here in Wellington. It will help me in absorbing everything that I have read about and might prove useful to someone else one day. Be warned, this is a fairly technical post!

Hardware and OS:

• Slackware Linux 9
• Sony Vaio PCG-C1F Notebook Computer
• ZoomAir 4100 Wireless PC Card

Software Requirements:

• PCMCIA Card Services (series a, pcmcia-cs-3.2.4)
• Wireless Tools (series n, wireless-tools-25)
• dhcp client daemon (series n, dhcpcd-1.3.22pl4)

The package references in parentheses above are Slackware specific. I can’t imagine that there is a major distribution that does not supply any of these packages, but the links will take you to the source if you need it. There are alternatives to dhcpcd you might use, and there is an alternative solution (in part) to the one I am going to describe using a different driver and toolkit.

The ZoomAir 4100 uses the PRISM II architecture with a MANFID of 0x0156, 0x0002. This architecture is listed in the know cards database (/etc/pcmcia/config) and bound to the orinoco_cs device driver, so upon card insertion the cardmgr daemon loads the relevant drivers and logs this in /var/log/messages.

Once cardmgr has identified a card and loaded the device driver(s), it performs some further configuration using the scripts in /etc/pcmcia. The scripts called depend on the device class of the card (see the PCMCIA-HOWTO for more information). In this case cardmgr calls the network script which in turn calls the wireless script. Specific configuration options can be added to the scripts by editing corresponding *.opts files in the same directory.

I had not altered any of these scripts when I began experimenting with the ZoomAir card, and it turned out that the scripts as distributed with Slackware don’t do anything untoward – but neither do they do anything particularly useful, so the final steps needed to be performed manually.

The CafeNET website gives their SSID as ‘cafenet’ and tells us that they do not use WEP (encryption). Armed with this information, we can manually configure the interface using iwconfig. It turns out that the default setup has encryption turned off and sets reasonable values for everything else, so all we need to do is set the SSID:

# iwconfig eth0 essid cafenet

Then you can fire up the dhcp client daemon and hopefully get connected:

# dhcpcd eth0

(I’m going to use eth0 as the interface throughout these examples, but this might not always be the correct option for everyone. If your interface is eth0, you don’t actually need to specify it to dhcpcd as it will use that by default. I’m specifying it for clarity.)

This was enough to get connected to the network. To ‘hang-up’, firstly cleanly kill dhcpcd:

# dhcpcd -k

Then you can eject the card:

# cardctl eject

So – very little needs doing to get connected. But there are some tweaks I’ve made to automate the whole process – even geeks get bored of typing in the same old commands all the time, and what are computers good for if not automation, anyway?

As implied above, Card Services comes with a ready-made system to help automate managing cards. By adding some code to the scripts in /etc/pcmcia we can automate the entire process of connecting to and disconnecting from CafeNET.

I created a scheme for connecting to CafeNET by customising network.opts and wireless.opts. There is no card-specific configuration that I’ve found necessary, so this scheme may be of use to you whatever your card type. Before customising these scripts it is worth reading through the comments as there will probably be sections you will want to remove or comment out.

Here is the case to add to wireless.opts:

cafenet,*,*,*)
    INFO="Scheme for connecting to Wellingon's CafeNET"
    ESSID="cafenet"
    MODE="managed"
    # Turn off encryption as suggested:
    KEY="off"
    ;;

And here is the one for network.opts:

cafenet,*,*,*)
     # Leave it all up to dhcpcd:
     DHCP="y"
     ;;

You can now connect to CafeNET by inserting your card and changing the scheme to cafenet:

# cardctl scheme cafenet

Schemes are described in the Card Services documentation. They’re are a handy way of packaging configuration options for different circumstances which can then be called with a single command on the fly.

It is worth noting that Schemes persist across boots. This is useful for me at the moment as I can leave the scheme set to ‘cafenet’ and get connected simply by inserting the card which will automatically try to connect – I don’t have to type anything at all. But this might not be the behaviour you want. You should be able to set a variable ($SCHEME, funnily enough) in your init scripts to set the scheme at boot time, under Slackware you can set this in /etc/rc.d/rc.pcmcia. There are various ways of controlling this, check out the docs.

To disconnect you should just be able to eject the card using cardctl. Unfortunately there is a slight problem with the network script supplied with Slackware 9 – it sends dhcpcd a SIGTERM when it needs a SIGHUP to exit cleanly (see the man page for more). This is easily fixed. In the network script in the section of the ‘stop’ case dealing with killing dhcpcd replace the line:

kill -TERM $PID

with:

kill -s HUP $PID

This is line 182 in my original network script.

This small change will make sure that everything is left nice and tidy. You could, of course, kill dhcpcd by hand and then eject the card, but why type two commands when one will do?!?

So, there we are – it all works quite well and working it out has taught me quite a bit about the Card Services tools and about both wireless networks and networking in general, all areas I didn’t know a great deal about before. Perhaps this stuff will be useful to someone else.

One final point: while researching all this stuff, it became apparent that there is at least one other option for this particular card in terms of drivers. The orinoco_cs driver is a generic solution – it supports several types of card, and is distributed with the Card Services package as a standard module. According to the orinoco page at Jean Tourrilhe’s site (a great resource for Wireless and Linux stuff generally), the support for Prism II cards is ‘not yet fully functional’, and for Prism 2.5/3 cards the alternative linux-wlan-ng system should definitely be used.

The linux-wlan drivers and subsystem provide an alternative to the orinoco/wireless extensions system described above – not only is the driver different, but the wireless extension tools (e.g. iwconfig) are not used either. Right now, I’m still using orinoco_cs (it works), but I might take a look at the linux-wlan package if I’ve got the time as it is specifically designed for the Prism-type cards of which the ZoomAir 4100 is an example.