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

> Greg Troxel writes:
>> 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.

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

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

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

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