Date: Fri, 4 Jun 2010 10:43:37 -0700 From: Maksim Yevmenkin <maksim.yevmenkin@gmail.com> To: "Mikhail T." <mi+thun@aldan.algebra.com> Cc: bluetooth@freebsd.org Subject: Re: NAT over bluetooth for mobile devices Message-ID: <AANLkTil-tEwwrv8IlNAUA4GBnmDX2xvBPDBbPXBWjn9Y@mail.gmail.com> In-Reply-To: <4C081B71.30801@aldan.algebra.com> References: <4C081B71.30801@aldan.algebra.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Mikhail, > I have the following idea, which should allow any mobile device with its = own > IP-networking -- such as a Blackberry or a (hacked) iPhone -- to offer > connectivity to a compatible computer, regardless of the service-provider= 's > wishes. a worthy idea, indeed :) > The device needs to run some equivalent of natd... This way, all network > connections will appear to the outside world as originating from the devi= ce > itself. The device will connect to the general purpose computer via > Bluetooth (although wired connections may also be possible, Bluetooth see= ms > most standardized). > > The "natd", running on the device, will intercept and properly proxy the > connections on behalf of the computer. The computer will, probably, use t= he > specially-created tun-interface: > > =A0 tun <-> bluetooth <-> network address translation on the device <-> I= P i don't really think its has to be that complicated. all we really want to do here is to turn mobile device (i.e. phone) into a "gateway". that is mobile device needs to be multihomed (local network, and, cellular data network). local network can be bluetooth, wifi or even plain usb/serial cable. for bluetooth we can use lan or pan profiles. wifi, obviously, "just works" most of the time. the trick is the second part, i.e. "natd" part that runs on the mobile devi= ce. > Note, that this would be different from using the device as a "modem" -- > doing so, typically, makes the device unusable for anything else for the > duration of the call, and requires the service-provider's cooperation (an= d > thus higher fees). My way, if you can browse the 'net with the device's > browser, you'll also be able to do so from a laptop sitting next to the > device... well, yes and no. cellular data networks are somewhat different. for example with gsm (att, tmobile, etc) you can multiplex voice and data, i.e. it is possible to talk and surf (using 3g connection) at the same time. with cdma (verizon, sprint, etc.) it is not - its data or voice, but not both. it also depends on how network operator has provisioned data connection. some could be just wap only (i'm not sure if anyone still doing it these days, but you never know). also network operator is free to put all sorts of port blocks in place and/or transparent proxy, etc. etc. imo, operator does not care if you are using your mobile device as a "modem" or as a "gateway/router". the actual data connection is always originated from the mobile device. i'm not 100% sure, but, i'm guessing, after data connection is established mobile device talks ppp to actually get the ip address, etc. what i'm trying to say is that the only difference between "modem" and "gateway/router" scenario is that in "modem" scenario mobile device will not be able to access cellular data network itself (also i already mentioned issue with multiplexing data and voice on cellular cdma networks). > If anyone wants to try it, I'd be willing to donate a Blackberry and/or s= ome > money to the cause. Please, respond off-line, if you are interested. Seri= ous > inquiries only. Continuation of the technical discussion should, certainl= y, > stay on the mailing list (please, CC me as I'm not a subscriber). i actually want to have this (got me an iphone recently). obviously, iphone adds another layer of complexity, i.e. jailbreak. for now, i'd settle for tethering, i.e. using my iphone as 3g modem, however, i think we should shoot for the stars :) full blown gateway would be very nice to have. thanks, max
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTil-tEwwrv8IlNAUA4GBnmDX2xvBPDBbPXBWjn9Y>