> 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 t=
o
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.

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

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

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

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

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

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

> 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