Multihomed WLANs from Intel
accessdeniednsp writes: "El Reg gives us some insight on Intel Labs' new software to let your wireless LAN card hop between various networks (802.3, 802.11, and 'fixed Ethernet' they call it). Perfect for us snoopers to walk by college frat houses and hopping on the 'net with our linux ipaq's :)" First company to come out with a "universal connectivity" PCMCIA card wins all the marbles.
I am not in a frat, but I do have a wireless LAN in my apartment. Playing MP3s to the stereo from a laptop (and using it to surf from the couch) is far easier and safer (for drunken idiots) than running ethernet to the living room from the hub in my room.
;(
I do phone support and I hear a lot of people getting into wireless routers b/c of the ease of having it run to all the computers in the house. Why not do it for frats?
And unfortunatly I do have a WLAN but no kegerator
You need to get your information straight. This article is talking about completely different architectures being supported with no additional hardware.
Besides, any NT based (at least from 4.0 up to 2000 and XP) can change settings on the fly. As a matter of fact, XP can even retain settings for more than one network and automatically switch between the two, one w/ DHCP and another with static settings. Or you could use NetSwitcher to do it...
The basic idea is to set up a gateway on both the wired and wireless networks, and proxies ARPs on both networks, so that hosts on the different network see each other as if they were on the same LAN. This is a little like bridging--except that only a tiny bit of traffic (the ARP's) needs to "bridge" the two networks. The rest is taken care of by normal routing.
The trick is switching a host from wired to wireless without changing its IP addresses (so it doesn't drop any connections). Note this implies that the gateway's routing table has a host route (specifying the interface) to every address that is allowed to switch networks: you can't tell from the address which side its on, so the usual subnet mask routing won't work.
Pulling off the switch requires that the gateway be able to detect the switch, and then do two things: One, change its routing table, so that traffic for the address goes out on the right interface. Two, send "gratuitous ARPs" to other hosts, forcing them to update their ARP tables (since, if the host moved to the other network, traffic to it now needs to be routed through the gateway).
I think the most straightforward way to detect the switch is to have the gateway run a DHCP server, and have the mobile hosts renegotiate a lease when they switch networks. Then, add a hook to the DHCP server to do the magic whenever it notices a host renegotiate on a different network. For the mobile hosts to be identifyable across networks, they need to send the same client-identifier on both networks. Since the default client-identifier is usually the MAC address, this requires configuration on the clients (I edit /etc/dhclient.conf and pick one MAC address to use as
the client-identifier). Of course, the DHCP server needs to be configured
to give out the same address range on both interfaces.
Unfortunately, on the network I care about, my gateway is not the DHCP server. Instead, I run a DHCP relay. This mostly works--except the ISC DHCP relay doesn't have any hooks, and I haven't hacked it to add them. But it should be easy.
Another way to solve this might be for the gateway simply to monitor ARPs and do something when it notices a host switch networks. I haven't found a clean way to do this, and I think it might be less than perfect, because the host wouldn't get switched until it initiated an ARP transaction.
The last problem is that different systems seem to respond differently to gratuitous ARPs. For example, Linux systems don't seem to require them at all, because they (apparently) issue a new ARP pretty quickly after the old MAC address stops answering. But I can't get Solaris systems to listen to gratuitious ARPs at all, and they don't time out for minutes.
Also, gratuitiously ARPing the whole network is ugly. Ideally, we would would only send an ARP when we notice another host using a MAC that we know has moved to the other network. I have no idea how to do this.
Despite all the glitches, it's quite fun to switch to the wireless for mobility and back to the ethernet for speed, without losing my ssh connections. Improvements on this setup would be welcome!
The evaluation of an action as 'practical' . . . depends on what it is that one wishes to practice.
Companies are working on 802.11b/a and a/g solutions, but you will not see $199 cards for this until 2003 (from what I hear). The biggest issue concerning the ability to support the newer standards via a 'firmware upgrade' is the fact that the 11a/g handle the air interface differently from 11b. This requires different/upgraded transcievers in the card itself, not to mention new access points.
To get specific, 802.11a uses a different spectrum (5.5GHz) and 802.11g uses OFDM for modulation at 2.4GHz, and both of these are vastly different (hardware level) from 802.11b. Secondarily, the other 802.11x standards mostly effect the MAC layer (QoS et al) and this is typically not handled by a general purpose processor, so just upgrading the firmware won't necessarily help here either.
Just my 2 cents
Shoot, why not just get a Mac running OSX? I have been doing just this sort of thing for almost a year now with a Powerbook and now an iBook running OSX. The iBooks are really impressive small laptops that can be had for as little as $1100 and they give you a hell of a nice GUI and the option to X-windows or CLI in UNIX to your hearts content.
Visit Jonesblog and say hello.
Here's a news item at InfoSync about the new Nokia GSM, GPRS, HSCSD, and WiFi PCMCIA card.
Pretty freakin' cool. I want one.
-Russ
Me