NAT over bluetooth for mobile devices
maksim.yevmenkin at gmail.com
Tue Jun 8 00:49:54 UTC 2010
On Fri, Jun 4, 2010 at 12:46 PM, Mikhail T. <mi+thun at aldan.algebra.com> wrote:
> 04.06.2010 13:43, Maksim Yevmenkin написав(ла):
>> 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.
> Do those profiles (almost) always exist on otherwise suitable devices? Even
> if available from the manufacturer, they may be disabled by the service
any particular device may or may not implement any particular profile.
of course, as you have pointed out, service provider (i.e. network
operator) may request device manufacturer to disable certain features.
> It may be simpler if the communication was over some other, widely
> available, profile. A customized daemon (perhaps even a patched-up ppp)
well, that's the point. standard bluetooth profiles that provide local
network connectivity are pretty much dun, lan and panu/nap/gn. those
are likely to be disabled.
> would then run on the computer behind the tun-interface, relaying
> network-requests over the bluetooth (or cable) link for a piece of software
> on the device to turn into network packets, which would appear to the rest
> of the world as originating from the device itself.
like i said, i don't think it matters. data connection is always
originated from the device. i don't think service provider can
actually tell whether or not device is used as 'modem' or as a
'gateway'. hence the request to completely disable certain bluetooth
>> the trick is the second part, i.e. "natd" part that runs on the mobile
> Absolutely... I don't have the slightest idea, where to even begin such a
mobile device sdk :) blackberry actually has java me at the lowest
level. it supposedly confirms to midp and cldc. how bad can it be
really? :) the other problem is that such application would probably
never be allowed by service providers and/or device manufacturer :)
More information about the freebsd-bluetooth