Iain Hibbert <plunky@rya-online.net> writes:

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

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

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

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

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

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

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

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

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

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

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

> do broadcast and multicast packets get rewritten to other interfaces?

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

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

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

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