Greg Troxel writes:
>Iain Hibbert <plunky@rya-online.net> writes:
>So really this is a virtual Ethernet.

I think so

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

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

> 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

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

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

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

> 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