Date: Wed, 4 Feb 2009 14:57:43 +0000 (GMT) From: Iain Hibbert <plunky@rya-online.net> To: Alexander Motin <mav@mavhome.dp.ua> Cc: "freebsd-bluetooth@freebsd.org" <freebsd-bluetooth@freebsd.org> Subject: Re: pan profile support in freebsd Message-ID: <1233759463.493208.401.nullmailer@galant.ukfsn.org> In-Reply-To: <4988F857.5080407@mavhome.dp.ua> References: <1233365217.00068654.1233354838@10.7.7.3> <4988DCCC.80201@mavhome.dp.ua> <bb4a86c70902031622hdc5231g1c9ce33f17842a1e@mail.gmail.com> <4988EBAC.3080202@mavhome.dp.ua> <bb4a86c70902031731q83bf261s49e5812a3c208f81@mail.gmail.com> <4988F857.5080407@mavhome.dp.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1233759463.493208.401.nullmailer>