NAT over bluetooth for mobile devices

Maksim Yevmenkin maksim.yevmenkin at
Tue Jun 8 18:15:31 UTC 2010

On Tue, Jun 8, 2010 at 9:36 AM, Mikhail T. <mi+thun at> wrote:
> 07.06.2010 20:49, Maksim Yevmenkin написав(ла):
>>> 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.
> I thought, the computer can talk with a cooperating piece of software on the
> device over ANY protocol. As long as the two can parley over a
> digital-quality (lossless) medium, we are fine... If that's true, the
> communication can be over the file-exchange "profile", for example. Or, the
> computer can even pretend to be "speakers", on which the natd running on the
> device will be "playing".

well, yes. when you have complete access to everything (like, for
example, bluetooth sockets) you can invent arbitrary custom protocol
that runs over bluetooth l2cap protocol, or, event, over raw acl (or
even sco) link. embedded platforms usually are not like that. usually
there are 'shortcuts', i.e. pre-built libraries, api's etc. that would
only allow you to access certain bluetooth profile and stay within
functionality of this particular profile. when device goes thought
bluetooth certification, its validated against only those profiles
devices claims to support.

>> 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
>> services.
> The only ways to connect via a mobile device, that I've seen, involved the
> device pretending to be a "modem" and the computer "dialing" a certain,
> provider-specified "number" (such as *99***1#) to establish a PPP-link. That
> "number" can be disabled by the provider...

yes, i think you know that pretty much all gms/gprs devices are
modems. in other words there is a piece of a silicon on a motherboard
that completely implements gsm/gprs etc. functionality. and guess
what, the main interface to that piece of silicon is at-command set
sent over serial connection. so, i do not think provider 'disables'
*99 number, because mobile device itself *has* to use the same/similar
number to initiate data connection. i think what happens is that
software that 'tunnels' remote at-commands simply filters out
'unwanted' ones.

> But they can't completely disable communication with the user's computer, so
> if there is a cooperating piece of software running on the device, it can do
> anything...

i think we are saying the same thing :) mobile device can participate
in local network via whatever is available, i.e. wifi, serial cable or
bluetooth. the same mobile device can open cellular data connection.
logically those have to be separate 'network interfaces' or whatever
abstraction mobile platform happens to use. couple of things needed
here: ip forwarding/routing and nat.

>> 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 :)
> Blackberries allow owners to install their own software, so that's the best
> bet. There are even some ssh-clients for Blackberries -- including a free
> one, so low-level TCP/IP is certainly available to "home-grown"
> applications.

agree, and, i never said it doesn't :)

> Droid-based phones run Linux, so it may be possible to modify the Linux'
> natd (whatever it is) to do it. iPhones may be even easier, but it has to
> involve jail-breaking...

android is actually java too. in theory, its possible to write native
code, but then one would have to 1) get a complete tool
chain/libraries/etc for a certain device (i.e. cpu specific) and 2)
hack firmware to get it running.

i'm 100% sure iphone can do it. its just att will never let it fly.

what i'm saying is that i would be interested in looking at this on
'crackberry' -- reading their sdk docs.


More information about the freebsd-bluetooth mailing list