user_pref("network.protocol-handler.app.mailto","/usr/bin/thunderbird");

Just remember to change /usr/bin/thunderbird to the appropriate path for your installation.

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.

Thing is, I’ve put a nice new Slackware 9 install on it. Sounds good – but I’ve got to do all the configuration myself. If I didn’t know any better I’d assume that Gavin thought I needed a project to keep my mind busy. Still, I suppose it gives me something else to post about, too.

Linux can be a little bit of a pain to install on laptops sometimes – there’s a lot of scope for non-standard hardware and the like for which no-one has got around to hacking out device drivers for yet. Still, at first glance, installing a recent distro on the little Vaio seems like a fairly straigtforward task. Touch wood.

The basic install goes well. The machine boots, and the kernel recognises the cards that came with the machine – the ethernet card Just Works. The modem and wireless cards are recognised, and just need some configuration – I can easily whip up a chatscript for the modem, but I’m a bit less certain about what to do with the wireless card, having never used this technology before. Still, one thing at a time, and the first thing I want to do is to get XFree86 running satisfactorily.

The standard XF86Config file installed alongside with Slackware is actually enough to start X despite the fact that it thinks the screen is 1024×768 whereas it is actually 1024×480. A bit of manpage reading and a quick surf later, and I have a nice little example of an XF86Config file as hacked together by Jochen Topf for his Sony Vaio. (This page has a lot of other stuff on it, too. I plan to read it a bit more thoroughly, and it might be useful to you if you’ve arrived at this page because you’re researching getting linux running on a Vaio.) This doesn’t quite work – he uses the svga driver which I don’t seem to have, and one or two other little minor errors crop up – but a quick glance in /usr/X11R6/lib/modules/drivers turns up a rather promising little file called neomagic_drv.o. The Vaio uses the NeoMagic MagicMedia 256AV, so this looks good.

And sure enough, between this, Topf’s mode line for 1024×480 and a bit of a ripoff from the stock config file, I’ve pulled together an XF86Config file that allows me to startx quite happily and launch the XFce Desktop Environment, which for some reason Gavin and I selected as the default window manager when we were doing the original install without knowing much about at the time.

Despite prioritising getting the X server running, I find that I’m spending very little time using it anyway. Oh well. Next thing I did was to get my digital camera working, a Nikon Coolpix 3100, which proved very simple. This simple: plug in the USB cable, and type

# mkdir /mnt/flash
# mount -t vfat /dev/sda1 /mnt/flash

And off we go. Straight out of the box, as they say.

Next up: the modem and wireless cards. Not to mention a bit of trimming in /etc/rc.d/ to cut down on a raft of unnecessary services.

I did a total reinstall for 8.1 as I wanted to completely redesign my partition layout to allow space for Slackware and LFS, and as such was expecting a fairly painless install onto a nice freshly formatted piece of disk. ‘Twas not to be … nothing really Bad, but just a series of irritating things to fix once the system was running. And although I had no trouble sorting it all out I suspect that a total newb might have had to spend quite a while reading to fix things.

Now I don’t necessarily think that this is a bad thing for a newbie to have to do, but SuSE are regarded as a fairly safe bet for beginners and some of the problems – such as the modules for controlling DVD and CDRW drives – hadn’t occurred in 7.3, so why suddenly an issue in 8.1? Most newbies probably want to spend a bit of time learning about commands like ls and cd before they get onto modprobe and gcc.

Maybe I’ll post a bit more about getting 8.1 to the same stage as 7.3 got itself another day. There’s certainly been a fair bit of traffic in alt.os.linux.suse about some of these problems, so it might be helpful to some people.

Anyway, I’ve got to go and configure an X server and compile some winmodem drivers, so I’ll be signing off now. Bye!