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 10.13.0.0/29 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 10.13.2.0/29), 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 problem. 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: http://www.slyware.com/projects_tmip.shtml >I still maintain that my other points (support, billing, TOS, quality of >service) still preclude using individual's broadband for net access. Support: 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. Billing: 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. TOS: While Comcast subscribers may have a TOS problem, anyone using Speakeasy.net would be okay in regards to the TOS: http://www.speakeasy.net/netshare/terms/#wifipolicy https://www.speakeasy.net/tos/ They do offer DSL service in the area: https://www.speakeasy.net/home/compare/ $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.