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
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bluetooth
To unsubscribe, send any mail to "[email protected]"
