From owner-freebsd-bluetooth@FreeBSD.ORG Tue Jun 8 00:49:54 2010 Return-Path: Delivered-To: bluetooth@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7FD681065670 for ; Tue, 8 Jun 2010 00:49:54 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id 52E588FC19 for ; Tue, 8 Jun 2010 00:49:54 +0000 (UTC) Received: by pxi7 with SMTP id 7so1752567pxi.13 for ; Mon, 07 Jun 2010 17:49:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=SOUeHoqPlJKfcOhskYj6alQ9zBAbdcc/2QXSCLjPatI=; b=rFdFgcFRfYjqRId/CaZpRtRYbhhwNcD3Uex1N2hazv60IZdj4Dv4CMuyDWrJ3slm4/ 3hamgoWt7lXUSu5VxPgbFc4Iso8+PvTlZLl0XFZ1SXrRrd5CXOHVvteGcgUC8VPmc8by amYtOaRiloHKz0+82nddaYO0Sj+DZ0iRXLkRg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=e4Vgl0J0bjRRVg262WGXQoXTZS8Cayar22t9jJDpvGbC6DUqPgdjSfZT8NvFUvXxdU Glw+kH0MR9uE5gFP67LdQybdHNaRAwu7zRZw3JN08e5d8aNF8pUSTEUt4tg8yuohpLlF muq4+YOm6G5GmgEcwahOyALRzQW5XBpJAeWMA= MIME-Version: 1.0 Received: by 10.141.139.11 with SMTP id r11mr8352618rvn.61.1275958193529; Mon, 07 Jun 2010 17:49:53 -0700 (PDT) Received: by 10.140.142.13 with HTTP; Mon, 7 Jun 2010 17:49:53 -0700 (PDT) In-Reply-To: <4C0957FE.1030206@aldan.algebra.com> References: <4C081B71.30801@aldan.algebra.com> <4C0957FE.1030206@aldan.algebra.com> Date: Mon, 7 Jun 2010 17:49:53 -0700 Message-ID: From: Maksim Yevmenkin To: "Mikhail T." Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: bluetooth@freebsd.org Subject: Re: NAT over bluetooth for mobile devices X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2010 00:49:54 -0000 On Fri, Jun 4, 2010 at 12:46 PM, Mikhail T. wro= te: > 04.06.2010 13:43, Maksim Yevmenkin =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0= =D0=B2(=D0=BB=D0=B0): > >> 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? Ev= en > if available from the manufacturer, they may be disabled by the service > provider... 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 softwa= re > on the device to turn into network packets, which would appear to the res= t > 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 services. >> the trick is the second part, i.e. "natd" part that runs on the mobile >> device. > > Absolutely... I don't have the slightest idea, where to even begin such a > thing... 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 :) thanks, max From owner-freebsd-bluetooth@FreeBSD.ORG Tue Jun 8 16:36:12 2010 Return-Path: Delivered-To: bluetooth@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9BD0D1065680 for ; Tue, 8 Jun 2010 16:36:12 +0000 (UTC) (envelope-from mi+thun@aldan.algebra.com) Received: from mail2.timeinc.net (mail2.timeinc.net [64.236.74.30]) by mx1.freebsd.org (Postfix) with ESMTP id 5C14B8FC16 for ; Tue, 8 Jun 2010 16:36:12 +0000 (UTC) Received: from mail.timeinc.net (mail.timeinc.net [64.12.55.166]) by mail2.timeinc.net (8.13.8/8.13.8) with ESMTP id o58GaBhb025092 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 Jun 2010 12:36:11 -0400 Received: from ws-mteterin.dev.pathfinder.com (ws-mteterin.dev.pathfinder.com [209.251.223.173]) by mail.timeinc.net (8.13.8/8.13.8) with SMTP id o58GaBpN026251; Tue, 8 Jun 2010 12:36:11 -0400 Message-ID: <4C0E717B.4030009@aldan.algebra.com> Date: Tue, 08 Jun 2010 12:36:11 -0400 From: "Mikhail T." Organization: Virtual Estates, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; uk; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: Maksim Yevmenkin References: <4C081B71.30801@aldan.algebra.com> <4C0957FE.1030206@aldan.algebra.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: bluetooth@freebsd.org Subject: Re: NAT over bluetooth for mobile devices X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2010 16:36:12 -0000 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". > 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... 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... > 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. 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... -mi From owner-freebsd-bluetooth@FreeBSD.ORG Tue Jun 8 18:15:31 2010 Return-Path: Delivered-To: bluetooth@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2B965106567D for ; Tue, 8 Jun 2010 18:15:31 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from mail-pz0-f183.google.com (mail-pz0-f183.google.com [209.85.222.183]) by mx1.freebsd.org (Postfix) with ESMTP id F14ED8FC26 for ; Tue, 8 Jun 2010 18:15:30 +0000 (UTC) Received: by pzk13 with SMTP id 13so631048pzk.13 for ; Tue, 08 Jun 2010 11:15:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=jhRhliP0F1fGZEUJutusFiFbGTkZwDzQkQm/cQ8L0Xs=; b=Gxhq5d8L/2GL2Ort92nVwTxEGNARBH9khRlWZq0rD+8Boj90PgfG8ay+Ss7almtQMf 7Kw9iIusI7xCa/unq9mPj/eIQlWng+Z0HbmtHT1ow8nBwdeH1ZBkaMXinWsBgLth9Hgd RI9EYtxWfRwjYnsXCvoGAQIdocEmyxy2+7+uI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=YGhSX21KZkPFMQF7UlDvzlBjcXFINzivUUFC2obwrY9K2vB2vFppIzw4yfJoJoVfXa g85xD8Np8vQfupxfBws/gcYC9GuRmUDnyVa8bifjKY/Oxk/MUk1QegT6On4WeUwRF/x+ 9xECeuc2gT0T2zplWbMrsy1wvHcISAimqRSFc= MIME-Version: 1.0 Received: by 10.141.88.12 with SMTP id q12mr13638709rvl.188.1276020930171; Tue, 08 Jun 2010 11:15:30 -0700 (PDT) Received: by 10.140.142.13 with HTTP; Tue, 8 Jun 2010 11:15:30 -0700 (PDT) In-Reply-To: <4C0E717B.4030009@aldan.algebra.com> References: <4C081B71.30801@aldan.algebra.com> <4C0957FE.1030206@aldan.algebra.com> <4C0E717B.4030009@aldan.algebra.com> Date: Tue, 8 Jun 2010 11:15:30 -0700 Message-ID: From: Maksim Yevmenkin To: "Mikhail T." Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: bluetooth@freebsd.org Subject: Re: NAT over bluetooth for mobile devices X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2010 18:15:31 -0000 On Tue, Jun 8, 2010 at 9:36 AM, Mikhail T. 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