persistent connections through IP address changes - TCP-IP

This is a discussion on persistent connections through IP address changes - TCP-IP ; 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 ...

+ Reply to Thread
Results 1 to 8 of 8

Thread: persistent connections through IP address changes

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


  2. Re: persistent connections through IP address changes

    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.


  3. Re: persistent connections through IP address changes

    lknjxbe02@sneakemail.com (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 jeffl@comix.santa-cruz.ca.us
    150 Felker St #D http://www.LearnByDestroying.com
    Santa Cruz CA 95060 http://802.11junk.com
    Skype: JeffLiebermann AE6KS 831-336-2558

  4. Re: persistent connections through IP address changes

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


  5. Re: persistent connections through IP address changes

    lknjxbe02@sneakemail.com (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 jeffl@comix.santa-cruz.ca.us
    150 Felker St #D http://www.LearnByDestroying.com
    Santa Cruz CA 95060 http://802.11junk.com
    Skype: JeffLiebermann AE6KS 831-336-2558

  6. Re: persistent connections through IP address changes

    On Sat, 13 May 2006, in the Usenet newsgroup alt.internet.wireless, in article
    , Jeff Liebermann wrote:

    >lknjxbe02@sneakemail.com (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

  7. Re: persistent connections through IP address changes

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

    > lknjxbe02@sneakemail.com (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.


  8. Re: persistent connections through IP address changes

    Jeff Liebermann wrote:
    > lknjxbe02@sneakemail.com (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-


+ Reply to Thread