I would like to have my TCP/IP connections be maintained while picking up multiple wifi hotspots during my commute. My main concern is not to have to re-authenticate myself when I roam to another hotspot.
I saw a solution on Linux using ethertap and a proxy to transmit UDP packets from a client machine to a server.
I'd like the same thing but with a Windows XP as a client machine. (I have a Linux machine available on the internet that may run a publicly-accessible service.)
Does such a thing exist? It seems like a common enough problem and seems like a somewhat simple program to write.
You probably won't have that until 802.11r (Fast Roaming) is approved and supported by access point vendors.
formatting link
like working group approval in March 2007, maybe.
formatting link
URL?
Proxy ARP is useful for moving servers around while renumbering IP addresses. Basically, it's used to fool the client that has requested an ARP lookup, into connecting to a different IP address (and therefore a different machine). It's commonly used for "man in the middle" attacks and ARP cache poisoning.
formatting link
formatting link
use arpwatch specifically to prevent anyone from spoofing arp replies:
formatting link
Proxy ARP will almost do what you want, but only with the cooperation of all the routers and servers involved. If you collect the MAC addresses of the various routers you want to connect, and manually force a static ARP entry with (in Windoze): arp -s 192.168.1.1 00-11-22-33-44-55 you can then manually change the default route to the desired gateway on the fly with the "route" command. If the gateway addresses happen to be the same for sequential routers, then simply delete one static arp entry and replace it with another. For faster switching, it can probably(?) be automated with a Windoze VBS script.
However, there are lots of things wrong with this approach. The big one is that the connecting server on the internet still has the old previous wireless gateway internet IP address in its routing table. When you switch to a different wireless gateway, you have no way to tell the remote server that your connection has moved or changed (other than a disconnect and reconnect). There's much more to providing a seamless handoff than just juggling the ARP table. If someone were able to magically do this with ethertap and proxy ARP, I would be very interested as it is a commonly requested feature.
Proprietary fast IP roaming solutions do exist. Most of the work is being done to facilitate Wi-Fi VoIP phones. However, most solutions are not made for public access points, random hardware selections, and uncontrolled network environments. Most important, they are not intended to operate across the internet, just across a common backend network connecting the various roam-able access points.
He setup a VPN tunnel without encryption thus creating a new network interface that didn't change IP when he juggled cards (and interfaces). The tunnel is terminate on what I guess is his Linux server acting as a router.
You setup a VPN server somewhere on the interknot to terminate the VPN tunnel. It delivers an IP address to you that does not change. When you roam to a different wireless access point, you disconnect from the previous wireless access point, and reconnect to the new access point. Your IP address may change, but the IP address from the VPN tunnel does not change. You remain connected to the same VPN delivered IP. Switching will not be particularly fast or automatic but as long as the connection through the VPN tunnel doesn't time out, you remain connected.
There's no reason this cannot be done with Windoze, but there may be some challenges. I just tried changing the route to a customers VPN router by switching from my DSL connection to a neighbors wireless access point. Cisco VPN client v3.1. The VPN was dropped for some reason. When I restarted the VPN client, it connected just fine. It may be that I waited too long when switching. Dunno.
Another challenge will be to get your wireless client to disconnect from the previous wireless access point to a closer access point in a graceful manner. Most wireless clients will tenacious remain connected to a given access point and refuse to switch to a better connection unless the signal disappears, or the error rate climbs. This is for good reason as the radio path may come and go. Having it disconnect at the first sign of a signal fade or interference is not a great way to maintain a connection.
Intel Proset 10.1 has a persistence(?) setting that controls how it holds on to a connection before searching for a better one. However, it relys on the assumption that the SSID of the various access points is the same. It will not roam to a different SSID which is what you'll be facing trying to roam across random hot spots. Methinks you'll be doing manual disconnect/connect cycles.
Hope that is "as a passenger" - the world is already in bad enough shape with drivers using cell-phones, putting on makeup, shaving, drinking coffee, carrying on heavy conversations with passengers (all of which I've seen so far this year). I keep thinking about a Stan Freberg radio commercial in the
1970s (cop is investigating a traffic accident - driver says he had the TV on, and 'someone on the TV said "Watch this", and I did').
Not a problem with tunneling.
"In theory" this is supposed to be another benefit of IPv6, but that's kinda thin on the ground at the moment. In the US (as of last month), there were about 31500 IPv4 blocks (totalling 1,339,665,920 addresses), but only 216 IPv6 assignments.
Yeah - I'm not sure why UDP would be used for this. On the other hand,
2002 IP Mobility Support. C. Perkins, Ed.. October 1996. (Format: TXT=193103 bytes) (Obsoleted by RFC3220) (Updated by RFC2290) (Status: PROPOSED STANDARD)
3220 IP Mobility Support for IPv4. C. Perkins, Ed.. January 2002. (Format: TXT=238343 bytes) (Obsoletes RFC2002) (Obsoleted by RFC3344) (Status: PROPOSED STANDARD)
3344 IP Mobility Support for IPv4. C. Perkins, Ed.. August 2002. (Format: TXT=241041 bytes) (Obsoletes RFC3220) (Status: PROPOSED STANDARD)
I don't see how this would work - ARP is a local segment protocol, and you will play merry hell getting it to work across network boundries. This certainly would not work where the intervening links are not Ethernet. At the packet level, Internet routers work on the IP address to decide where to forward the packet. MAC addresses are dropped at the link level of the stack.
[compton ~]$ whatis arping ifconfig macchanger arping (8) - sends arp and/or ip pings to a given host ifconfig (8) - configure a network interface macchanger (1) - MAC Changer [compton ~]$
Before arpwatch (previously called arpsnmp), we used a shell script to dump the arp caches of the routers and several key servers, and a Perl script to compare that data to the NIS /etc/ethers and /etc/hosts files.
The editor of those RFCs (above) is from Nokia, but the Mobile IP Working Group has members of several .edu's, PARC, Sun, and the NRL among others.
As I said OpenVPN. It actively supports this situation (flip one switch on the server) to facilitate persistant connections of dialup users, so it handels this situation just fine.
California vehicle code section on "television" in the vehicle.
formatting link
that it nicely muddles the distinction between a computah and a television by calling a computer a device that displays "business applications". Also note the weird exception for electric utilities.
I don't try. It won't work through a router anyway.
formatting link
What I was thinking is that one could use proxy arp to redirect traffic as the user switches wireless access points. Thinking a bit more clearly today, that won't work at all. Never mind, dumb idea. The VPN method will work.
None of my customers used NIS. For intrusion detection, we had a list of authorized MAC addresses that were allowed on the LAN. For remote users, RADIUS authentication was sufficient. arpwatch was used to detect duplicate IP's, man in the middle, proxy arp, and manually assigned static IP's. The worst problem was caused by creative users that somehow assign their workstation the same IP as one of the servers.
"visually displaying a television broadcast or video signal that produces entertainment or business applications"
Yabbut it's OK to use it to display advertising - as long as the ads are not entertaining.
(b)(6) seems to say that it has to be not viewable by the driver, and (d) says when the vehicle is deployed - not when it's deploying. Bet the lawyers had a field day with that one.
Well, it would work as long as you remain on the same network, and the proxy-arp is being done by one of a number of routers all connected to the same network. That's not all that much different from the way ppp (RFC1661) operates. From 'man pppd'
proxyarp Add an entry to this system's ARP [Address Resolution Proto- col] table with the IP address of the peer and the Ethernet address of this system. This will have the effect of making the peer appear to other systems to be on the local ether- net.
as will the mobile-IP - I just don't know how far along that concept has come. RFC2002 has been around since 1996, and there are substantial provisions for it - searching for 'Mobile' in the old RFC1700 (Assigned Numbers - superseded by a number of IANA web pages) shows ICMP message types, port numbers, protocol numbers and that 224.0.0.11 is used for this. (All this is news to me too.)
The only reason we were using NIS was that the /etc/ethers file lived there (the NIS hosts file was also used to create DNS zonefiles, so that was also kept up to date). We had/have standing written policy that no computer attaches to our wires unless the registrar has recorded the information "in advance". Likewise, no one alters or moves the computer without reporting this to the registrar "within 30 minutes". Because of this, and managed switches, we know in seconds what is going on.
Been There, Done That, Got the blood drenched tee-shirt. Managed switches are a major blessing. Also, the fact that an abnormal situation is now _automatically_ reported to the guard stations in addition to network operations. It's almost a contest as to who reaches the malefactor first - the guards or the network admin. Neither one is likely to be smiling.
Robert and I are searching for essentially the same thing, although I am more than willing to forego the requirement of "reauthentication" for authentication's sake. IOW, I only want the connectivity. I am willing to assume that the AP's are "open".
I read some of the postings that Jeff put up. It seems to me that, to minimize delay, all devices should be operated in ad-hoc mode.
Is it true that, in ad-hoc mode, frames can be transmitted and received in a stateless fashion?
I just checked the properties of my Intel Pro/Wireless 2200BG in my notebook computer and there is a setting for the ad-hoc channel, currently set to 11. Does this means that all frames received on this channel will be process without regard to current AP association?
The latest fad in vehicular electronics is using a laptop or SBC (single bored computer) to do MP3, video, GPS, navigation, diagnostics, cell phone directories, etc. See:
formatting link
Discussions and FAQ's
formatting link
Wireless communications including 802.11:
formatting link
Ummm.... don't tell the highway patrol.
Yes, but the wireless routers at the various hot spots are NOT connected with a common backbone or are on the same network. Won't work. Bad idea. Etc.
Well, it's possible to over automate the system. The original intrusion detection system consisted of arpwatch feeding a tangle of sed, grep, ark, tr, in a pipe, that eventually sent out an SNMP write incantation that disabled the offending port on the switch (stack of Cisco 1900 switches as I vaguely recall). After some crude simulation and limited testing, the script went live on a network with about 500 workstations. It did its job just fine for about 6 months. Then, some bozo somehow assigned a broadcast address to their device. Most devices and IP stacks won't let you do that, but he apparently found a way. In a few seconds, the script detected a duplicate IP on every MAC address. The script then successfully disabled almost every port it could find, including most of the unused and management ports. I couldn't even login over the network to undo the damage. The next half hour was spent fabricating a Cisco console cable and running around the large campus with a laptop re-enabling all the ports.
When we do manage to catch the evil perpetrator, it invariably is either the president of the company, one of the top management types, a clueless consultant, or someone in IT. Unauthorized wireless access points are a common problem. These people all think they're above following the rules, making it difficult to yell at them.
Guards? Sounds like a high security installation. Have I got the intrusion detection script for you. It only has one small bug.
We're looking into a new car - the old joke about the difference between a computer sales-droid and a car salesman (the car salesman _can_ drive) is loosing some of it, with all of the bells, whistles, and doo-dads that are being added to cars today. Not even the salesman can figure out all of the new stuff.
Certainly - Murphy has many proven implementations of it ;-)
Our setup goes back to the days when the local setup was a number of /20 subnets (with a few exceptions, each confined to a single floor, and a somewhat limited area) of thicknet. As a result, there was no choice but to output the warning using 'rwall' to specified hosts.
New and Improved Bozo! More inventive than before! (My guess, he also screwed up the network mask.)
The closest we've had to that was some idiot who set his Mac 7200 to the IP address of the local port of the router... and the Mac then starts sending ICMP 3/1 packets to everyone who is trying to talk to hosts on other networks. Much hilarity.
Yeah, but look at it from the fitness standpoint - great exercise.
A week after we implemented a corporate policy about unauthorized PCs (this was connected to the development of the arp cache monitoring program), we get the message of an intruder up on Mahogany Row. Remember, we're still thicknet, so there is this thundering herd of guards and network/sys-admins running about opening doors, etc. (Think of the 'Capital One' TV commercials with the Vikings running about, waving swords and battle axes.) Yes, it was the president - in on a visit from corporate on the East coast - deciding to check his e-mail by plugging in his (corporate owned) lap-doggy into an "available" network drop. Red faces - and a local policy change that unused drops are now deactivated and have a dummy connector indicating that status. Oh, and who was it who had just signed the corporate policy bulletin? And walked past the big new signs at all entrances warning about unauthorized computers?
Written policy, spelling it out very explicitly. Employee signed copy in the employee files. Warning signs up the whazoo.
This is an R&D facility, but the policy is corporate wide. Some of the facilities also have government contracts with various restrictions.
That's why I've never been a fan of automatic reactions. It's bad enough with a human in the loop. Murphy (and our users) can be _so_ inventive.
Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.