From owner-freebsd-bluetooth@FreeBSD.ORG Wed Feb 4 20:13:18 2009 Return-Path: Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 86F5F1065674 for ; Wed, 4 Feb 2009 20:13:18 +0000 (UTC) (envelope-from mav@mavhome.dp.ua) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id 00FDA8FC1B for ; Wed, 4 Feb 2009 20:13:17 +0000 (UTC) (envelope-from mav@mavhome.dp.ua) X-Spam-Flag: SKIP X-Spam-Yversion: Spamooborona-2.1.0 Received: from [212.86.226.226] (account mav@alkar.net HELO mavbook.mavhome.dp.ua) by cmail.optima.ua (CommuniGate Pro SMTP 5.2.9) with ESMTPSA id 233561111; Wed, 04 Feb 2009 22:13:16 +0200 Message-ID: <4989F6E3.9020702@mavhome.dp.ua> Date: Wed, 04 Feb 2009 22:13:23 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.19 (X11/20090118) MIME-Version: 1.0 To: Maksim Yevmenkin References: <1233365217.00068654.1233354838@10.7.7.3> <4988DCCC.80201@mavhome.dp.ua> <4988EBAC.3080202@mavhome.dp.ua> <4988F857.5080407@mavhome.dp.ua> <4989EC35.80502@mavhome.dp.ua> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-bluetooth@freebsd.org" Subject: Re: pan profile support in freebsd X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2009 20:13:18 -0000 Maksim Yevmenkin wrote: > On Wed, Feb 4, 2009 at 11:27 AM, Alexander Motin wrote: >> Maksim Yevmenkin wrote: >>>> Does actually this binding really necessary? rfcomm somehow works without >>>> it. >>> please see Iain's response :) i knew he would chime in :) thanks Iain! >>> >>> and, yes, i suspected that it would be something related to mac >>> addresses on virtual ethernet interface. i do not have a copy of spec >>> handy, but i recall something about setting mac address to be the same >>> as radio's bd_addr. dont remember if it was a requirement or more of a >>> guideline. >>> >>> in any case, i like Iain's suggestion to rewrite mac addresses on the >>> fly. i would have done it this way. also, i think, nap server should >>> just act as ethernet hub, i.e. forward everything everywhere. after >>> all, nap is supposed to be like local ethernet network :) >> Hmm. Working like an Ethernet hub also means that every single hub port (in >> our case every single point-to-point BT link) may transmit packets from >> different source MAC addresses, that can't be equal to BT adapter address. >> So or I don't understand your example, or something is wrong here. > > why do you think it is wrong? logically all the radios are on the same > virtual ethernet network. i think the only issue here is that > apparently some clients are picky about src mac address and that > complicates the case when nap server has multiple radios. You have told that NAP server works as hub. So, as I have understood, it retransmits upstream traffic back down to all/some clients. So, it transmits packets with MAC addresses of other clients via it's BT adapter. So, source MAC address will not match his BDADDR. Or server is an exception, which can violate the rule of equal addresses? -- Alexander Motin