A major design feature of my car computer has been wireless (wifi) networking. The only way to get music into the car, and to do maintenance on it, is via the network, since there is clearly no "console" display nor keyboard. (The few times I did this during debugging were most unpleasant; the trunk of a car is not exactly an ergonomic workstation.)
There are two methods to talk to the car computer: copper ethernet and wifi. The copper is almost (but not quite) a no-brainer. It's configured with a static address (192.168.1.254), plugging a long ethernet cable into the switch in my lab is reliable and simple. (The "not quite no-brainer" part is that you must be careful when you have two network interfaces in the same assigned network; a two-address netmask practically solves it.)
But copper ethernet is just a backup and failsafe; wifi is must more useful, but a lot more complicated. Luckily linux has available the Wireless Tools, with which I implemented a "war driving" wifi scanner. The code is called wifilinkup, is run in the background at boot time, and brings up networking as agressively as it can.
wifilinkup runs only when the ignition is off (car off, not playing music) because wifi scanning causes "gapping" in the audio playback (which might be a bug manifestation in the wifi driver; see below).
When the ignition is on, eg. you're in the seat driving, wifi network link maintenance is suspended; if the link is up it stays up, but no attempt is made to bring it up if it's not up, or if it goes down.
When the ignition turns off, clearly music is not playing any more; system maintenance begins. wifilinkup scans for visible, non-WEP-locked access points, and tries to associate with each until it gets a functional connection to the net. If the car is turned on, link maintenance is suspended within one second, and it returns to the idle mode.
Out of necessity, wifilinkup is fairly smart. It keeps a persistent database of accesspoints it has ever seen. When wifilinkup makes a list of visible networks, each is assigned a score that is derived from a weighted combination of past history and signal strength; it learns which APs are a waste of time to try, and which are reliable. (I intend to add heuristics such as remembering last-used IP address and gateway; IP/gateway guessing and derivation for open APs without DHCP; and possibly offline WEP key cracking.)
I now use it on my laptop, which makes it easy to test before installation in the car.
I've had terrible problems with wifi networking, all are related to the wifi network adapter I'm using -- the Linksys WUSB54G USB wifi adapter.
Previous versions of the rt2570 driver hung the kernel -- hard. I spent far too many hours tryin to coerce good behavior from it. I then abandoned it for most of a year. I revisited it when I upgraded to SuSE 10.1. Kernel hangs no longer happen, but it causes audio gapping (interrupts? interrupt blocking? too slow CPU? ...?) and mysterious hangs during AP scanning. Once associated, it seems fine. I'm still working on this.
wifilinkup works perfectly (well, pending my own bugs) on my Sony laptop, which uses some Intel 801.11 ABG adapter. Certainly no hangs/crashes.
My real problem is that in my particular hardware configuration (EPIA 5000, VoomPC chassis, etc) my only choice for network hardware is USB. As far as I can tell my only choice is the Linksys WUSB54G, which uses the RT2570 USB 802.11 chip, which has linux support. This was a strategic mistake on my part. I need to get a case that accepts a PCI card (then deal with RF signal loss in the then-needed cable). I really like the idea of a USB wifi adapter, though, since it lets me run USB cable up to the car's rear deck so that there is zero coax cable length.