Wireless LTSP clients

Using a wireless ethernet bridge

Introduction

If you already operate a wireless LAN, using laptops as wireless LTSP clients is an attractive option. However, booting over the network is not as straighforward with a wireless NIC as with a wired one as few if any wireless NICs can boot off the network. If you want to boot from the network (as opposed to floppy/CD/USB disk/CF disk etc) using a PCMCIA wireless card is not an option because these will only work once the kernel has been loaded and without the wireless card, the machine won't be able to load the kernel.

The approach I successfully adopted was to connect a physically small wireless ethernet bridge to my laptop's built-in ethernet card (which does support network booting using PXE) and to fool the laptop into thinking it was on a wired LAN.

I use one of these http://www.asus.com/products.aspx?l1=12&l2=41&l3=0&model=59&modelmenu=1 which works fine and can be powered from a USB port. I have also tried a normal access point which was not as small but worked just the same once it was set to operate in client mode (rather than access point mode).

Configuration

The pre-requisites for this approach are:

• an ethernet card that supports booting over a network (required for all LTSP clients)

• a wireless bridge or access point that can operate as a bridge (a router won't work) to connect to the client's ethernet port

• a wireless bridge or access point that can operate as a bridge (a router won't work here either) to connect to the main switch or hub on your network which must be on the same subnet as your LTSP server. If you already operate a wireless network, you probably have one of these already.

Most wireless APs would be suitable to connect to the client, but the cheapest suitable devices are often marketed as "wireless ethernet bridges" and are usually advertised for connecting devices such as games consoles to a wireless network.

Most people considering this option will already have the AP connected to their wired LAN in place.

The reason you cannot use routers for either of these APs is that routers do not forward broadcast traffic (which is what DHCP requests are) to another LAN segment. The LTSP server will therefore never see DHCP requests and so the client will not boot.

First of all, you will save difficulties later on if you check that the client machine will boot as an LTSP client on a wired network. If this doesn't work nothing else will, so get this set up first.

Secondly you need to set up your wireless AP. For all the wireless APs I have used this is done using a web interface from a machine directly connected to the AP. Ensure that you have correctly configured WEP/WPA/WPA2 as appropriate and that the AP is configured to operate in client mode (this may be called "ethernet adapter mode" depending on the particular device).

If your LTSP is configured to recognise the MAC of each client's NIC, you should also configure your AP to clone the MAC of the NIC to which it is connected. If you don't do this you will need to add another entry to your dhcpd.conf file on the LTSP server with the MAC of your AP (my AP can clone the MAC so I haven't tested this but it should work).

If the client machine has an operating system installed that works on the wired network, you should test the configuration of your AP. If you plug the AP into your client machine, and then boot up, it should see the network (whether your wired ethernet port has a static or dynamic IP address). You should not need to make any configuration changes at all to the existing OS setup and this should work regardless of the OS you are using.

Testing

Once you have these two elements working, you are ready to test LTSP.

Turn the AP connected to the client machine on and wait for a minute or so (to allow the AP to associate with the AP connected to your wired network). Now turn on the client machine and if you have correctly configured everything else, your machine should boot up almost exactly as if it were connected to the wired network. The only visible difference should be the lower speed of a wireless network compared to a wired network.

My setup works very well except for displaying video. Videos will play but the speed is unacceptably low. The problem appears to be related to the latency on a wireless network (which on my setup is a factor of ten higher than my wired network) rather than the bandwidth, but I am trying to find out if there is a solution. If I find one, I shall update this page.

Have fun.

Related product links

http://macsense.com/product/broadband/wua800.html - Macsense http://www.dlink.com/products/?pid=346 http://www.argontechnology.com/product.aspx/cid1/22 - PXE ON DISK http://www.argontechnology.com/product.aspx/cid1/103 - PXE NETWORK ADAPTERS http://www.argontechnology.com/products.aspx?id=103&pid=304 - 10/100 Cardbus Fast Ethernet Notebook Card with PXE

Alternate approach: Linux-based etherboot

This setup requires no additional hardware, at the cost of some scripting. Kernel image with initrd containing wifi drivers, wpa_supplicant, wireless-tools and configuration files (essid, PSK etc) is booted locally (from HD, flash, whatever). After the wireless setup has been completed, DHCP is requested on iver wireless, real kernel and initrd is downloaded, loaded and kexec'ed. Yes, the new system (LTSP, for example, though we used thinstation) has to do the same network setup again. But in this way, only if network config changes, one has to change the local boot image, too. Real systems can be upgraded without maintenance on the thinclient.

It works very well, though we do not yet use it in production environment. http://www.arcig.cz/~eudoxos/eb-linux/ has some details.

(BTW: Is WPA going to be supported officially in LTSP?)

-- EudoxOs - 26 Nov 2005

Some background information on wireless pxe booting

The only real problem with a pxe wireless is that none of the card makers have considered this a desired option. Nothing real fancy is need other than a way to set the acces point for initial connection. you can lock down the pxe to only specific MACs if you need to limit who could pull the inital image. Any encryption can start once the main kernel is booted and takes over. The LinuxBios^? project could likely support something like this by configuring the wifi card in the boot rom.

Actually, it's more subtle than that. For example, there is support in Etherboot (which has PXE support) for prism-based PCI cards to boot wirelessly. I have demonstrated it at LinuxWorld^? in the past, and it's slow but it works. We also don't have easy ways to specify SSIDs and various other parameters that would be desirable, but it is possible, using specific PCI cards to boot wirelessly.

The problem is that most wireless cards are really PCMCIA cards, and whether you have a laptop or desktop, there is an extra interface called a PCI to PCMCIA bridge that must be initialized before the computer can talk to the wireless card.

The PXE driver in general has no idea which PCI to PCMCIA bridge is in the computer it happens to be in. Have you ever noticed how late in booting Linux that PCMCIA support is enabled? In order for wireless booting, the BIOS must get involved and cooperate with the PCMCIA card. It must initialize the PCMCIA to PCI bridge, and the driver has to know where to probe. The PXE loader could do this, but it's not trivial to do, since you'd have to put PCMCIA support in the driver and probe.