public inbox for linux-bluetooth@vger.kernel.org
 help / color / mirror / Atom feed
From: "M RISON" <mrison@hotmail.com>
To: marcel@holtmann.org, survivor@uni-paderborn.de
Cc: bluez-devel@lists.sourceforge.net
Subject: Re: [Bluez-devel] Piconet Routing
Date: Thu, 21 Oct 2004 09:51:13 +0000	[thread overview]
Message-ID: <BAY8-F70Vy134IpLcEc000010f6@hotmail.com> (raw)

> > > > Since Bluetooth uses Time Division Duplex, a slave is not allowed to
> > > > talk to another slave in the same Piconet. The logical consequence 
>must
> > > > be that the data is routed over the master. I've used l2test to 
>check if
> > > > l2cap does this kind of routing automatically. It doesn't but rather
> > > > creates a new, direct acl link to the remote slave device 
>(scatternet).
> > > > I don't know how it is with rfcomm, but I suppose it's the same. My
> > > > question: Is there any automatic Piconet Routing inside BlueZ or 
>does
> > > > one have to implement it by oneself?
> > > you must do it by yourself, because even if the master manages to put
> > > all devices into the same piconet the connections are point to point.
> > TCP connections are also point to point, but since it's built on top
> > of IP, it goes (transparently) over many routers. Before I tested it,
> > I thought the link manager would take care of this. How does the
> > communiction of many BT devices work in practice? Who manages this
> > routing, since one device can only be point-to-point-connected to 2
> > devices (an this doesn't work really smooth)?

[No, a master can be P2P-connected to up to 7 active slaves in a piconet,
and if you support scatternets then you can in theory also be P2P-connected
to several masters (although this is indeed not very smooth in BT1.2).]

> > There must be one
> > controlling instance. One cannot let the different applications handle
> > this, can one?
>this is true, but the problem is, that a slave does not know to which
>other slaves a master is connected. There is no routing stuff like in IP
>and you can't retrieve these information from the HCI layer.

A solution to the OP's problem is to use the PAN profile.  The master (GN)
will then automatically "route" (bridge, actually) BNEP (Ethernet) packets
between the slaves (PANUs).

Mark

--
CPC/IP - A TCP/IP stack for Amstrad CPCs
-- http://www.nenie.org/cpcip/
"Z88 vs CPC? Christ. How did we miss that platform war?"
-- http://www.ntk.net/index.cgi?back=archive00/now0128.txt&line=110#l

             reply	other threads:[~2004-10-21  9:51 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-10-21  9:51 M RISON [this message]
  -- strict thread matches above, loose matches on Subject: below --
2004-10-18 17:07 [Bluez-devel] Piconet Routing Stefan Mischke
2004-10-18 17:33 ` Marcel Holtmann
     [not found]   ` <4174026A.1080209@uni-paderborn.de>
2004-10-18 23:42     ` Marcel Holtmann
2004-10-19  9:11 ` GUILLON Gabriel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=BAY8-F70Vy134IpLcEc000010f6@hotmail.com \
    --to=mrison@hotmail.com \
    --cc=bluez-devel@lists.sourceforge.net \
    --cc=marcel@holtmann.org \
    --cc=survivor@uni-paderborn.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox