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
next 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