pan profile support in freebsd

[Alexander Motin]

Iain Hibbert wrote:
> 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?)

Have no idea how routing expected to work in case of several BT 
adapters, this it is interesting, but I think quite rare case. I think 
it could be good to be implemented alike to usual inet connectivity, 
when unbinded accepting connection sets remotely requested IP as it's 
local, and outgoing connecting socket choose local IP using routing 
table. I am not sure if terms or routing applicable here, but at least 
we have some mesh of peered devices and if there is several peered, we 
could choose one of using some algorithm, depending on load or order, or 
just round-robin.

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

I don't very like idea of rewriting. It looks like a hack and may 
confuse somebody. Also if it works as plain Ethernet, then you will 
probably have to rewrite ARP for IPv4 and it's equivalent for IPv6, and 
something other for other protocols. It could become a permanent pain.

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

-- 
Alexander Motin