From owner-freebsd-bluetooth@FreeBSD.ORG Wed Feb 4 21:17:07 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 6DEE51065675 for ; Wed, 4 Feb 2009 21:17:07 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.29]) by mx1.freebsd.org (Postfix) with ESMTP id 2066F8FC0A for ; Wed, 4 Feb 2009 21:17:07 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by yx-out-2324.google.com with SMTP id 8so1116896yxb.13 for ; Wed, 04 Feb 2009 13:17:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=l5sIF+ovnBdi76XOCBNyQ2XCgQavW/CBtLs9vntWHJc=; b=ERCNrh4NMsNE5P+kzrR7CivWL8W+1pCqL71q9+fEXOclpLXM9K9ZlpRK8xHAJqe8eU j6VGdq6tlJcCoQHKmljyXIUnbs4QIl0zObIKH5J8jUW58+ENbCh8409k3XDI5BzC7lru gi/6Grh/3SoJylapXXpzc6cn58B3jWeUCac4c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Kz1R8UwxPhNIC7MplGBu/SfXOSjYudY6t12agY8LEmVG5nZPLRQqVlju5Kz9recE7a 6DWDEOoj+6dTN/cvUBrwqZysuT1F9AvOb8/0eSa5dPF/W+GXoICYYYIHS7C10I/IAEZO LCDlHGmndf89HejbWsEGQ32QOPltgdoNtPQT8= MIME-Version: 1.0 Received: by 10.231.20.5 with SMTP id d5mr961568ibb.25.1233782226028; Wed, 04 Feb 2009 13:17:06 -0800 (PST) In-Reply-To: <4989F6E3.9020702@mavhome.dp.ua> 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> <4989F6E3.9020702@mavhome.dp.ua> Date: Wed, 4 Feb 2009 13:17:05 -0800 Message-ID: From: Maksim Yevmenkin To: Alexander Motin Content-Type: text/plain; charset=ISO-8859-1 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 21:17:07 -0000 On Wed, Feb 4, 2009 at 12:13 PM, Alexander Motin wrote: > 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? well, i think we have a disconnect here ;) you see, bnep strips ethernet header completely and replaces it with one of the bnep ethernet headers. your options basically are 1) bnep ethernet header that has both src and dst "mac addresses" (that is both src and dst radio bd_addr's) 2) bnep ethernet header that has only src "mac address" (that is src radio bd_addr only) 3) bnep ethernet header that has only dst "mac address" (that is dst radio bd_addr only) (2) and (3) are basically short forms of (1) and used when it is possible to figure out missing dst or src "mac address" (that is bd_addr really) because there is a directly "attached" rf link. in other words, if i know that you are the final recipient of the packet and i have a direct rf link to you, i'm not going to bother to set dst "mac address" in bnep packet, because you obviously know your "mac address" (bd_addr). or if i generate a packet and i have a direct rf link to you, i'm not going to set src "mac address" (that is bd_addr really) because you know that this packet can only come from me and you already know my "mac address" (bd_addr) so, imo, there is nothing really prevents us from using multiple local radios. also mac address on tap interface is really does not matter, because its get stripped anyway. that is unless tap interface checks dst mac address and make sure it matches (like freebsd does) before passing packet up the stack. if any case, setting promisc. flag on interface will fix it. the only mess here is that arp responses for local tap interface will contain mac address of tap interface and not bd_addr of (one of the) local radio(s). i say, who cares, as long as its properly encapsulated into bnep, imo, it should work. so even if both endpoints have a direct rf link, it will look like they are not. thanks, max