pan profile support in freebsd

Iain Hibbert plunky at rya-online.net
Wed Feb 4 07:58:35 PST 2009


On Wed, 4 Feb 2009, Alexander Motin wrote:
[relating to -d device]
> Does actually this binding really necessary? rfcomm somehow works without it.

This binding is used (in original version) to set the tap interface
address to be the same as the bdaddr.  I did consider allowing to use it
without setting that but then ethernet packets are being transmitted with
a source address that is not the bdaddr. Now, IIRC it would seem that the
spec allows this, but my windows mobile device (for instance) fails to
route packets back to the computer.

there are a couple of ways around this I could see

1.  skip the bdaddr_any(local_bdaddr) check while validating the command
   line options, but add something to set it if it is unset. That would
   be the easiest option I guess but you need to be able to find the
   device with the best route to remote (could be first device, could be
   we already have a connection to remote device - I don't know what
   FreeBSD provides here?)

2. perform 'address rewriting' on ethernet packets. Actually this is not
   that difficult to do and I had it going during testing (when receiving
   packets, if the source address is the same as the remote bdaddr, or the
   ethernet tap address, set it to NULL. When sending, if the source is
   NULL, use the local bdaddr or ethernet tap address.)  This also allows
   a single btpand instance to straddle multiple controllers but I thought
   it might be better to keep it simple in the beginning.

the fact of it requiring the commandline argument at first I prefer -
because its always possible to relax a requirement but not to tighten one
up :)

iain


More information about the freebsd-bluetooth mailing list