persistent connections through IP address changes

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.

On Sat, 13 May 2006 16:44:22 +0000, Robert wrote:

> 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.

OpenVPN. Optionally with null encryption.

M4
--
Redundancy is a great way to introduce more single points of failure.

(E-Mail Removed) (Robert) hath wroth:

>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.

You probably won't have that until 802.11r (Fast Roaming) is approved
and supported by access point vendors.
http://en.wikipedia.org/wiki/IEEE_802.11r
Looks like working group approval in March 2007, maybe.
http://grouper.ieee.org/groups/802/1..._Timelines.htm

>I saw a solution on Linux using ethertap and a proxy to transmit UDP
>packets from a client machine to a server.

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.
http://www.webopedia.com/TERM/A/ARP_spoofing.html
http://www.l0t3k.org/security/docs/arp/
I use arpwatch specifically to prevent anyone from spoofing arp
replies:
http://linuxcommand.org/man_pages/arpwatch8.html

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.

>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.

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.

Light reading:
| http://www.radio-ip.com/radioroam.php
| http://www.drizzle.com/~aboba/IEEE/1...techniques.ppt
| http://www-cse.ucsd.edu/Dienst/UI/2....se/CS2004-0787
| http://www.veriwave.com/products/roamingtest.asp

Also see the 802.11r section at:
| http://www.drizzle.com/~aboba/IEEE/
or additional references and articles.



--
Jeff Liebermann (E-Mail Removed)
150 Felker St #D http://www.LearnByDestroying.com
Santa Cruz CA 95060 http://802.11junk.com
Skype: JeffLiebermann AE6KS 831-336-2558

> >I saw a solution on Linux using ethertap and a proxy to transmit UDP
> >packets from a client machine to a server.
>
> URL?

http://www.ishiboo.com/~nirva/Projects/mobileip/

(E-Mail Removed) (Robert) hath wroth:

> > >I saw a solution on Linux using ethertap and a proxy to transmit UDP
> > >packets from a client machine to a server.
> >
> > URL?

>http://www.ishiboo.com/~nirva/Projects/mobileip/

A VPN will work.

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.


--
Jeff Liebermann (E-Mail Removed)
150 Felker St #D http://www.LearnByDestroying.com
Santa Cruz CA 95060 http://802.11junk.com
Skype: JeffLiebermann AE6KS 831-336-2558

On Sat, 13 May 2006, in the Usenet newsgroup alt.internet.wireless, in article
<(E-Mail Removed)>, Jeff Liebermann wrote:

>(E-Mail Removed) (Robert) hath wroth:
>
>> I would like to have my TCP/IP connections be maintained while picking up
>> multiple wifi hotspots during my commute.

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').

>> My main concern is not to have to re-authenticate myself when I roam to
>> another hotspot.

Not a problem with tunneling.

>You probably won't have that until 802.11r (Fast Roaming) is approved
>and supported by access point vendors.

"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.

>> I saw a solution on Linux using ethertap and a proxy to transmit UDP
>> packets from a client machine to a server.
>
>URL?

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)

>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.

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.

>I use arpwatch specifically to prevent anyone from spoofing arp replies:

[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.

>Proprietary fast IP roaming solutions do exist. Most of the work is
>being done to facilitate Wi-Fi VoIP phones.

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.

Old guy

On Sun, 14 May 2006 09:25:21 -0700, Jeff Liebermann wrote:

> (E-Mail Removed) (Robert) hath wroth:
>
>> > >I saw a solution on Linux using ethertap and a proxy to transmit UDP
>> > >packets from a client machine to a server.
>> >
>> > URL?
>
>>http://www.ishiboo.com/~nirva/Projects/mobileip/
>
> A VPN will work.

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.

M4
--
Redundancy is a great way to introduce more single points of failure.

(E-Mail Removed) (Moe Trin) hath wroth:

>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).

California vehicle code section on "television" in the vehicle.
http://www.dmv.ca.gov/pubs/vctop/d12/vc27602.htm
Note 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 see how this would work - ARP is a local segment protocol, and you
>will play merry hell getting it to work across network boundries.

I don't try. It won't work through a router anyway.
http://www.cisco.com/warp/public/105/5.html

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.

>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.

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.


--
Jeff Liebermann (E-Mail Removed)
150 Felker St #D http://www.LearnByDestroying.com
Santa Cruz CA 95060 http://802.11junk.com
Skype: JeffLiebermann AE6KS 831-336-2558

On Sun, 14 May 2006, in the Usenet newsgroup alt.internet.wireless, in article
<(E-Mail Removed)>, Jeff Liebermann wrote:

>Note that it nicely muddles the distinction between a computah and a
>television by calling a computer a device that displays "business
>applications".

"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.

>Also note the weird exception for electric utilities.

(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.

>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.

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.

>Never mind, dumb idea. The VPN method will work.

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.)

>> compare that data to the NIS /etc/ethers and /etc/hosts files.
>
>None of my customers used NIS. For intrusion detection, we had a list
>of authorized MAC addresses that were allowed on the LAN.

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.

>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.

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.

Old guy

Jeff Liebermann wrote:
> (E-Mail Removed) (Robert) hath wroth:
>
> >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.
>
> You probably won't have that until 802.11r (Fast Roaming) is approved
> and supported by access point vendors.
> http://en.wikipedia.org/wiki/IEEE_802.11r

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?

-Le Chaud Lapin-