At 11:12 AM 5/16/2005 -0500, Adam Maloney wrote:
>On Mon, 16 May 2005, Rob Wentworth wrote:
>> you will see that the method described involves handing off the roaming 
>> connection by having the NEW access point tunnel to the OLD access 
>> point, which proxies the existing connection(s) in progress, thereby 
>> maintaining existing connections without changing the IP address. The
>Very cool.
>> end-user also maintains a consistent local IP address. The software is 
>> available at sourceforge and they are asking people to use it. One 
>> caveat is that it appears that Win32 and WinCE users are not able to
>As clients?  If the tunneling is done entirely at the AP level, it should 
>be transparent, no?

My understanding of SOWN's TransparentMobility system is that it will work
with any IP client.  Their goal was to design something that did NOT
require special IP stacks on the clients or the installing of custom
software.  Per their website:
"Transparent MobileIP (TMip) is a technology developed in house to SOWN,
and aims to solve the key problem of migration between access points. As
described on the Routing WIKI page, each 'cell' serves its mobile users
within a unique (to consume & SOWN) subnet, such as for
OakhurstNode. Assuming that a client has been issued an IP address within
this subnet via DHCP, if they now migrate to say the SUSUNode (which uses, they will lose connectivity.

There are various solutions to this problem, but many require extra
software on the client (such as protocol stack implementations). At SOWN we
didn't want this, as we wanted every IPv4 host to be mobile, even small
PDAs. Therefore, we developed a software package called TMip to solve this

At a snip, TMip provides the ability for hosts to migrate between physical
subnets, without having to change IP, hence never losing connectivity or
previously established sessions.

This application is now live over SOWN, after we upgraded the SUSUNode to
Pebble recently. However, the software is still under test/development, so
we could do with as many nodes running it as possible to check that it all
behaves as it should!"

Here's some documentation for the project:

>I still maintain that my other points (support, billing, TOS, quality of 
>service) still preclude using individual's broadband for net access.

Two classes of APs: primary APs setup and run by the Mpls wifi project, and
participant APs run by enthusiasts.  Support for the primary APs would go
thru the Mpls wifi project.  No support for participant APs, other than
diagnostics checks to see if the participant APs appear to be working
properly (basically pinging/tracerouting).  The operators of participant
APs should provide a current, frequently checked email address that
complaints can be directed to.

There is no separate billing.  Just an authentication check for subscribers
and participants via a publicly accessible webserver.  Nonsubscribers could
use a bandwidth limited connection, say 128kbps.

While Comcast subscribers may have a TOS problem, anyone using would be okay in regards to the TOS:
They do offer DSL service in the area:    $40/month for 768/128

Another possibility is participant installation of APs that are wirelessly
uplinked to the Mpls wifi system via high-gain directional antennas to
serve areas outside of the regular service area.  There need not be TOS
issues in this case as Mpls wifi itself would be the uplink.

Quality of service issues:
The participant would be required to keep his AP powered and connected to
the broadband connection.  The captive portal page for a participant AP
could have a clearly visible notice/banner that says "This is a participant
AP, not a primary AP, and thus may not be as reliable as a primary AP."
Bandwidth QOS can be handled inside of the AP, if it is an Linksys WRT54G
or other Linux based AP such as a Soekris box.
I see the participant APs as being a neat way to extend service to areas
not covered by the regular service and as a way to contribute/participate.