Bluetooth Personal Area Networking

[Iain Hibbert]

Hi,

I'm looking at a Bluetooth PAN daemon written for FreeBSD (see
http://btpand.beenic.net/) - I can make it build on NetBSD but its
not complete and in my specific case does not do what I need, which
is to connect my computer to the internet via my GPRS enabled phone.
Rather, he provides the opposite method where the phone could connect
to the network provided by my computer..

It seems to me that it is feasibly possible to make this tool
fully functional in both directions, and I'm working in that
direction but actually, I'm a bit of a networking novice (I've
only really used PPP, SLIP and fidonet :)

terminology they use

NAP - Network Access Point
a network server with an external network connection

GN - Group ad-hoc Network
a network server without external network connection

PANU - Personal Area Networking User
a network client

I'm a little unclear on the best way to handle something. In the
Bluetooth PAN specification it mentions that a NAP (or GN) device
should forward packets between connected PANUs as necessary, and
the author of btpand has implemented this directly by using a single
network interface (via tap(4)) and copying packets to remote
destinations as required (he refers to this as being 'like a
minimalistic layer 2 switch')

What I'm uncertain about is, in my hazy vision of a btpand, I would
have done that by cloning a new tap(4) for each session and let the
system handle routing of packets. I think it would make btpand
somewhat simpler, but does it work that way?

Also, if that is the way to go, the Bluetooth Network Encapsulation
Protocol (BNEP) which the PAN profiles use allows filtering on protocol
types and/or according to multicast addresses. Can either one of these
be passed off to the kernel?

regards,
iain
(please Cc me on replies, I'm not connected to tech-net)


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Martin Husemann]

Post by Iain Hibbert
What I'm uncertain about is, in my hazy vision of a btpand, I would
have done that by cloning a new tap(4) for each session and let the
system handle routing of packets.

Why? The tap(4) is not point2point (I guess), so I don't see what cloning other
instances buys you.

Martin

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Greg Troxel]

I am not familiar with bluetooth networking, so I may be off in
understanding what you are trying to do.

The question of tap(4) vs tun(4), and how many devices is really about
how the bluetooth protocol works. I suspect that none of these are
entirely appropriate. So I have a bunch of questions, and from the
answers we can probably figure out something sensible.

Does the Bluetooth PAN spec allow forwarding of multiple kinds of
packets (IP, IPv6, arp, etc?)? Is this done by having a next-protocol
field somehow, like ethernet's 16-bit type field, similar fields in ppp,
or an AF word in tunnel drives?

What is the service model for NAP/GN/PANU users? Do they see a
point-to-point link (logically), or a network with multiple hosts?
Specifically, is PANU A supposed to perceive PANU B as an attached peer?
Or is this all vague and PANU A is supposed to just default-route all
packets to the NAP/GN node?

How are addresses handled? Are the semantics of bluetooth addresses
sufficiently close that it's possible for the tap interface to work with
bluetooth addresses with nothing bad happening?

Does the bluetooth spec involve using ARP to resolve IP addresses into bluetooth addresses?

When a PANU client sents a broadcast packet, is the same
ff:ff:ff:ff:ff:ff address used as in ethernet, and does this packet get
related to all other PANU clients on the same NAP/GN? In other words,
is this like 802.11?

With tap, packets that arrive from the host will show up on the file
descriptor. The daemon will then need to send this packet to the single
peer (PANU case) or all connected peers (NAP/GN) case.

When a packet arrives from the peer, sending it to tap will cause it to
be received or forwarded by the local stack. That's an IP-level or
bridging-level action, and may or may not be what you want. A packet
arriving at a NAP/GN should be sent to the correct peer, which could be
a single PANU, or all of them in the multicast/broadcast case. If the
destination address is ours, or mc/bc, then it should be written to the
tap.

What I'm uncertain about is, in my hazy vision of a btpand, I would
have done that by cloning a new tap(4) for each session and let the
system handle routing of packets. I think it would make btpand
somewhat simpler, but does it work that way?

I'm not sure what you mean by session, but if you mean connection to a
peer, then it seems this isn't the right thing to do.

Also, if that is the way to go, the Bluetooth Network Encapsulation
Protocol (BNEP) which the PAN profiles use allows filtering on protocol
types and/or according to multicast addresses. Can either one of these
be passed off to the kernel?

I'm not sure, but first you need to define what you are trying to do
precisely. Perhaps you know, but it seems the set of people who
understand bluetooth and those that understand the traditional stack are
disjoint.


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Iain Hibbert]

Post by Greg Troxel
I am not familiar with bluetooth networking, so I may be off in
understanding what you are trying to do.

Ok thanks.. some more information (sorry if its obvious, sometimes I have to
make it clear to myself :)

BNEP protocol is, so far as I understand, encapsulated ethernet
packets passing through a bluetooth tunnel.

The PAN profile is a way to enable bluetooth devices to advertise,
provide, locate and consume services using the BNEP protocol.

NAP, GN and PANU are roles within the PAN profile.

From what I can see, there is no difference between NAP and GN role except
that a GN does not have an opening to a wider network.

Post by Greg Troxel
Does the Bluetooth PAN spec allow forwarding of multiple kinds of
packets (IP, IPv6, arp, etc?)? Is this done by having a next-protocol
field somehow, like ethernet's 16-bit type field, similar fields in ppp,
or an AF word in tunnel drives?

It does allow forwarding any kinds of ethernet packets so long as they
were advertised in the service record. My phone (is windows mobile)
claims that it supports 0x0800 (IPv4), 0x0806 (ARP) and 0x86dd (IPv6)
types.

When the ethernet packet is passed to the BNEP handler, the ethernet
header is removed and replaced with a BNEP header which contains src
and dest addresses and the 16 bit type field. Then at the other end,
an ethernet header is reconstructed.

(there is some blurb about 802.1Q tag headers being supported also)

Post by Greg Troxel
What is the service model for NAP/GN/PANU users? Do they see a
point-to-point link (logically), or a network with multiple hosts?
Specifically, is PANU A supposed to perceive PANU B as an attached peer?
Or is this all vague and PANU A is supposed to just default-route all
packets to the NAP/GN node?

Well at heart it is a point-to-point link with one end anchored in
each bluetooth device. The intention is that it just appears as another
ethernet interface.

I think for the PANU then yes, there would normally be a default route
but that is not mandated.

Post by Greg Troxel
How are addresses handled? Are the semantics of bluetooth addresses
sufficiently close that it's possible for the tap interface to work with
bluetooth addresses with nothing bad happening?

Bluetooth addresses are six octets and IIRC belong to the same namespace
as any other MAC address, so I think there may be no reason why a tapN
interface cannot be given the address of the device at the other end
of the link.

Post by Greg Troxel
Does the bluetooth spec involve using ARP to resolve IP addresses
into bluetooth addresses?

No, the bluetooth addresses are irrelevant to anything above the ethernet
stack. Setting up the BNEP tunnel is handled by the PAN profile in the
bluetooth domain.

Post by Greg Troxel
When a PANU client sents a broadcast packet, is the same
ff:ff:ff:ff:ff:ff address used as in ethernet, and does this packet get
related to all other PANU clients on the same NAP/GN? In other words,
is this like 802.11?

Hm. If I understand you, not directly. The broadcast packet would need
to be retransmitted by the NAP individually to each PANU, its not in
the aether for all to see.

Post by Greg Troxel
With tap, packets that arrive from the host will show up on the file
descriptor. The daemon will then need to send this packet to the single
peer (PANU case) or all connected peers (NAP/GN) case.

Yes, the btpand daemon currently does this.

Post by Greg Troxel
When a packet arrives from the peer, sending it to tap will cause it to
be received or forwarded by the local stack. That's an IP-level or
bridging-level action, and may or may not be what you want. A packet
arriving at a NAP/GN should be sent to the correct peer, which could be
a single PANU, or all of them in the multicast/broadcast case. If the
destination address is ours, or mc/bc, then it should be written to the
tap.

Yes, this also

My hazy thought was though, if there was a cloned interface for each
bluetooth link, both of these just happen automatically? When a packet
comes in on interface XXXX and is destined for an address which we know
is behind interface YYYY then it will be sent on..

do broadcast and multicast packets get rewritten to other interfaces?

you need 'options GATEWAY' to be able to run a NAP or GN, but then you
would need it for a NAP anyway I think.

It also enables one to run packet filtering on the traffic, which is
otherwise hidden behind a daemon that does not follow the rules (this
concerns me)

Perhaps I should be looking at tun(4) instead of tap(4) ??

regards,
iain


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Greg Troxel]

Post by Iain Hibbert
BNEP protocol is, so far as I understand, encapsulated ethernet
packets passing through a bluetooth tunnel.

OK, that's very sensible. I didn't want to presume too much, given that
we're talking bluetooth :-)

Post by Iain Hibbert

Post by Greg Troxel
Does the Bluetooth PAN spec allow forwarding of multiple kinds of
packets (IP, IPv6, arp, etc?)? Is this done by having a next-protocol
field somehow, like ethernet's 16-bit type field, similar fields in ppp,
or an AF word in tunnel drives?

It does allow forwarding any kinds of ethernet packets so long as they
were advertised in the service record. My phone (is windows mobile)
claims that it supports 0x0800 (IPv4), 0x0806 (ARP) and 0x86dd (IPv6)
types.
When the ethernet packet is passed to the BNEP handler, the ethernet
header is removed and replaced with a BNEP header which contains src
and dest addresses and the 16 bit type field. Then at the other end,
an ethernet header is reconstructed.

So really this is a virtual Ethernet.

Post by Iain Hibbert
(there is some blurb about 802.1Q tag headers being supported also)

Let's not worry about that yet. Probably no one's
phone/headset/etc. does that.

Post by Iain Hibbert

Post by Greg Troxel
What is the service model for NAP/GN/PANU users? Do they see a
point-to-point link (logically), or a network with multiple hosts?
Specifically, is PANU A supposed to perceive PANU B as an attached peer?
Or is this all vague and PANU A is supposed to just default-route all
packets to the NAP/GN node?

Well at heart it is a point-to-point link with one end anchored in
each bluetooth device. The intention is that it just appears as another
ethernet interface.

Bluetooth is point to point, but one can construct a virtual Ethernet
from several point-to-point links. So the critical question is the
service model for end users.

Post by Iain Hibbert
I think for the PANU then yes, there would normally be a default route
but that is not mandated.

Since this is virtual Ethernet, that's an upper-layer issue.

Post by Iain Hibbert

Post by Greg Troxel
How are addresses handled? Are the semantics of bluetooth addresses
sufficiently close that it's possible for the tap interface to work with
bluetooth addresses with nothing bad happening?

Bluetooth addresses are six octets and IIRC belong to the same namespace
as any other MAC address, so I think there may be no reason why a tapN
interface cannot be given the address of the device at the other end
of the link.

I don't follow this; a tap interface has it's own Ethernet address, and
doesn't know the address of peers. So you can create a tapN, and either
set the MAC addr to the bluetooth MAC addr, or use the constructed MAC
addr within BNEP.

Post by Iain Hibbert

Post by Greg Troxel
Does the bluetooth spec involve using ARP to resolve IP addresses
into bluetooth addresses?

No, the bluetooth addresses are irrelevant to anything above the ethernet
stack. Setting up the BNEP tunnel is handled by the PAN profile in the
bluetooth domain.

True, but given that BNEP provides Ethernet, one would use ARP, and that
all makes sense.

Post by Iain Hibbert

Post by Greg Troxel
When a PANU client sents a broadcast packet, is the same
ff:ff:ff:ff:ff:ff address used as in ethernet, and does this packet get
related to all other PANU clients on the same NAP/GN? In other words,
is this like 802.11?

Hm. If I understand you, not directly. The broadcast packet would need
to be retransmitted by the NAP individually to each PANU, its not in
the aether for all to see.

Right - but does a NAP do this as a matter of following the protocol?
Put another way, if a NAP were to receive such a packet and not send it
to other PANU clients, would it be broken? I would think it would have
to do this to make one PANU client be able to talk to another PANU
client, and with GN that seems to be the point.

Post by Iain Hibbert

Post by Greg Troxel
With tap, packets that arrive from the host will show up on the file
descriptor. The daemon will then need to send this packet to the single
peer (PANU case) or all connected peers (NAP/GN) case.

Yes, the btpand daemon currently does this.

Thinking more, in the NAP/GN case, the daemon should match the MAC
address with the negotiated MAC address of all PANU peers, and send the
packet to the right one. If multicast/broadcast, it should go to all.

Post by Iain Hibbert

Post by Greg Troxel
When a packet arrives from the peer, sending it to tap will cause it to
be received or forwarded by the local stack. That's an IP-level or
bridging-level action, and may or may not be what you want. A packet
arriving at a NAP/GN should be sent to the correct peer, which could be
a single PANU, or all of them in the multicast/broadcast case. If the
destination address is ours, or mc/bc, then it should be written to the
tap.

Yes, this also

So that all sounds correct.

Post by Iain Hibbert
My hazy thought was though, if there was a cloned interface for each
bluetooth link, both of these just happen automatically? When a packet
comes in on interface XXXX and is destined for an address which we know
is behind interface YYYY then it will be sent on..

I don't think so. The basic service we are providing is virtual
Ethernet, not IP. So this has to be done without invoking IP routing at
all.

And, the multiple clients at a GN are all accessible within the daemon,
so asking the kernel to do anything won't help, unless it's filtering.

I suppose you could create a tap for each client, and write packets
received from each client blindly to it, and then bridge all the taps
together, so the kernel will do the mac address filtering. Then you
will need a tap with no reader/writer for the local host. But, this
will result in promiscuous delivery before the bridge learns, and allow
address stealing by malicious nodes, when control should be according to
the mac addresses from setup.

Post by Iain Hibbert
do broadcast and multicast packets get rewritten to other interfaces?

These are Ethernet packets, so no (assuming no bridging).

Post by Iain Hibbert
you need 'options GATEWAY' to be able to run a NAP or GN, but then you
would need it for a NAP anyway I think.

Really you need "sysctl -w net.inet.ip.forwarding=1", but GATEWAY
defaults to that. I don't think you really do (or should), in order to
be a GN - this is all about bridging Ethernet frames. I agree that
forwarding IP packets in those frames is the point of a NAP, but that
all happens after the frame is injected into the tap as a to-this-host
frame, and then the frame ends when the upper-layer packet is extracted
and e.g. put on the IP input queue.

Post by Iain Hibbert
It also enables one to run packet filtering on the traffic, which is
otherwise hidden behind a daemon that does not follow the rules (this
concerns me)

I would look at the hostap implementation in net80211. That is the
closest thinhg to GN/NAP. The packets between STAs (PANUs) aren't being
processed by upper layer stacks, and I am pretty sure are not subject to
ipfilter.

Post by Iain Hibbert
Perhaps I should be looking at tun(4) instead of tap(4) ??

tun doesn't implement Ethernet, so I don't think so.

From what you've described, the daemon is doing things correctly. I can
see the one tap per peer with a bridge configured scheme working.


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Paulo Matias]

Post by Iain Hibbert
I'm looking at a Bluetooth PAN daemon written for FreeBSD (see
http://btpand.beenic.net/) - I can make it build on NetBSD but its
not complete and in my specific case does not do what I need, which
is to connect my computer to the internet via my GPRS enabled phone.
Rather, he provides the opposite method where the phone could connect
to the network provided by my computer..

What you actually do need is simpler. Read "Serial Connections" and
DUN stuff at http://www.netbsd.org/docs/guide/en/chap-bluetooth.html.

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Iain Hibbert]

Post by Paulo Matias
What you actually do need is simpler. Read "Serial Connections"
and DUN stuff at http://www.netbsd.org/docs/guide/en/chap-bluetooth.html.

Heh (I wrote that.. :)

But in this case I need PAN because this phone does not do DUN.

iain



--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Iain Hibbert]

Post by Greg Troxel
So really this is a virtual Ethernet.

I think so

Post by Greg Troxel

Post by Iain Hibbert
Well at heart it is a point-to-point link with one end anchored in
each bluetooth device. The intention is that it just appears as another
ethernet interface.

Bluetooth is point to point, but one can construct a virtual Ethernet
from several point-to-point links. So the critical question is the
service model for end users.

In the Bluetooth 'Generic Access Profile' they mention that, for the
end-user (eg dweeb with mobile phone), implementations should be simple
and obvious to use and while I'm trying to follow that principle in the
bluetooth tools for NetBSD by ensuring consistency and clarity, I think
that at heart these are all low level tools and that 'applications' should
be layered on top so I'm mostly concerned about the service model for the
netbsd-admin (maybe thats what you mean by end-user :) at this stage..

Post by Greg Troxel

Post by Iain Hibbert
Hm. If I understand you, not directly. The broadcast packet would need
to be retransmitted by the NAP individually to each PANU, its not in
the aether for all to see.

Right - but does a NAP do this as a matter of following the protocol?

yes, it SHALL do that.

Post by Greg Troxel
Put another way, if a NAP were to receive such a packet and not send it
to other PANU clients, would it be broken?

it would

Post by Greg Troxel
I would think it would have to do this to make one PANU client be able
to talk to another PANU client, and with GN that seems to be the point.

right

However, my thought was that the spec refers to a NAP device, not a
NAP application, and that in the context of a NetBSD system, the NAP
device is not just an instance of a daemon but the whole machine.

The spec specifically does not go into more complex situations where
more than one GN interacts, or when a GN connects to a NAP, but I was
trying not to rule that sort of thing out by starting on the wrong
foot.

Post by Greg Troxel
Thinking more, in the NAP/GN case, the daemon should match the MAC
address with the negotiated MAC address of all PANU peers, and send the
packet to the right one. If multicast/broadcast, it should go to all.

I think so. I'm not sure about 'negotiated' MAC address, I think it must
be that the Bluetooth device address is used though I can't see anywhere
that is specifically stated. It is known in order to make the bluetooth
connection but for BNEP the originator just says 'Setup. me <role1>, you
<role2>' and the responder indicates success or failure as it will.

Post by Greg Troxel

Post by Iain Hibbert
My hazy thought was though, if there was a cloned interface for each
bluetooth link, both of these just happen automatically? When a packet
comes in on interface XXXX and is destined for an address which we know
is behind interface YYYY then it will be sent on..

I don't think so. The basic service we are providing is virtual
Ethernet, not IP. So this has to be done without invoking IP routing at
all.

Ah ok.. this is probably where my lack of networking kicks me, I've never
got down to ethernet and probably my wrong concepts are leading me down
the garden path when its ok to wander over the lawn.

Post by Greg Troxel
From what you've described, the daemon is doing things correctly.
I can see the one tap per peer with a bridge configured scheme working.

Right ok. I think thats what I've been aiming for and I see that its not
as simple as I thought but could be possible. I'll look at it in more
depth, but it might be less complex to just keep the bridge functionality
inside the PAN daemon, since if more than one daemon needs to be run then
the admin can do some fiddling and enable what they want.

thanks,
iain



--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Greg Troxel]

Post by Iain Hibbert

Post by Greg Troxel
Bluetooth is point to point, but one can construct a virtual Ethernet
from several point-to-point links. So the critical question is the
service model for end users.

In the Bluetooth 'Generic Access Profile' they mention that, for the
end-user (eg dweeb with mobile phone), implementations should be simple
and obvious to use and while I'm trying to follow that principle in the
bluetooth tools for NetBSD by ensuring consistency and clarity, I think
that at heart these are all low level tools and that 'applications' should
be layered on top so I'm mostly concerned about the service model for the
netbsd-admin (maybe thats what you mean by end-user :) at this stage..

Sorry, I meant 'user of the PAN service', not humans. So I don't even
mean netbsd-admin, I mean some upper layer protocol that sends ethernet
frames.

Post by Iain Hibbert
However, my thought was that the spec refers to a NAP device, not a
NAP application, and that in the context of a NetBSD system, the NAP
device is not just an instance of a daemon but the whole machine.

NAP is a logical service within a computer, I would think. You are
proposing to implement that by the daemon and then being able to pass
frames to the regular stack, and that sounds very sensible.

Post by Iain Hibbert
The spec specifically does not go into more complex situations where
more than one GN interacts, or when a GN connects to a NAP, but I was
trying not to rule that sort of thing out by starting on the wrong
foot.

OK. I think you'll find it just doesn't work; this is explicitly a
hub/spoke topology, and a distributed system is more complicated.

Post by Iain Hibbert

Post by Greg Troxel
Thinking more, in the NAP/GN case, the daemon should match the MAC
address with the negotiated MAC address of all PANU peers, and send the
packet to the right one. If multicast/broadcast, it should go to all.

I think so. I'm not sure about 'negotiated' MAC address, I think it must
be that the Bluetooth device address is used though I can't see anywhere
that is specifically stated. It is known in order to make the bluetooth
connection but for BNEP the originator just says 'Setup. me <role1>, you
<role2>' and the responder indicates success or failure as it will.

So in this case the 'negotiated address' is the bluetooth address; that
seems implicit.

Post by Iain Hibbert
Right ok. I think thats what I've been aiming for and I see that its not
as simple as I thought but could be possible. I'll look at it in more
depth, but it might be less complex to just keep the bridge functionality
inside the PAN daemon, since if more than one daemon needs to be run then
the admin can do some fiddling and enable what they want.

If you want to run two PANs on a single computer (this could be a way to
build a larger network), then either approach could support multiple
daemons - I don't see the daemon choosing to use multiple taps and
bridging making any difference. The hard part will likely be that
incoming bluetooth packets will be routed to the first daemon, although
it might be possible to run one NAP/GN instance, and then other PANU
instances if they only get replies.

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de