Date: Tue, 8 Jun 2010 11:15:30 -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: <AANLkTilW_u-_PzVbU7RMDGe14meZcThlwjSUOQUuYi4t@mail.gmail.com> In-Reply-To: <4C0E717B.4030009@aldan.algebra.com> References: <4C081B71.30801@aldan.algebra.com> <AANLkTil-tEwwrv8IlNAUA4GBnmDX2xvBPDBbPXBWjn9Y@mail.gmail.com> <4C0957FE.1030206@aldan.algebra.com> <AANLkTilk9EJ2sbCnVZvO7cscs2-hkMRaFwPjPjFgHeWY@mail.gmail.com> <4C0E717B.4030009@aldan.algebra.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Jun 8, 2010 at 9:36 AM, Mikhail T. <mi+thun@aldan.algebra.com> wrot= e: > 07.06.2010 20:49, Maksim Yevmenkin =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0= =D0=B2(=D0=BB=D0=B0): > >>> 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, t= he > 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 th= e > device pretending to be a "modem" and the computer "dialing" a certain, > provider-specified "number" (such as *99***1#) to establish a PPP-link. T= hat > "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 be= st > 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. thanks, max
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTilW_u-_PzVbU7RMDGe14meZcThlwjSUOQUuYi4t>