From owner-freebsd-bluetooth@FreeBSD.ORG Wed Feb 4 22:27:54 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 BF30D1065697 for ; Wed, 4 Feb 2009 22:27:54 +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 72CC08FC23 for ; Wed, 4 Feb 2009 22:27:54 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by yx-out-2324.google.com with SMTP id 8so1133562yxb.13 for ; Wed, 04 Feb 2009 14:27:53 -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=k2lKWM0+ImPAQoUUvwkW//6N5zGc33f5nBWwB1Heb60=; b=Qn8mKf4ofIdQg6SRKuo7nZxoQl1hNURAL/0hECZjI/ZERmdzQ4AMD7zaB4uRgLpu4z JRK4oG8t5t2AlEs5TeIYI/jaGQr5arPl471qtWmbA2oxo6nor4JjZXnyUxu3ZpJw8tw/ 8KmUAnsye5/K1wyRGF3fy4kaVWTRdLAWH53VQ= 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=f7Hyn/mpstKqjksqv7FxLK+X0xE+mfcCnAObnsejw4YNgVxALJb8T+G9BvsVvte9tj qwEEFCGolM8hE7EUF+xDdqs7R/Um81kHZt48D36+zz4IsgJ2Eh/sPll5QubSbV9MfJdc YhF1O67aPDmI/gr1+xwWDZhqH105DtoTmeL2w= MIME-Version: 1.0 Received: by 10.150.98.18 with SMTP id v18mr3535853ybb.231.1233786473766; Wed, 04 Feb 2009 14:27:53 -0800 (PST) In-Reply-To: <498A0DDF.1050605@mavhome.dp.ua> References: <1233365217.00068654.1233354838@10.7.7.3> <4988EBAC.3080202@mavhome.dp.ua> <4988F857.5080407@mavhome.dp.ua> <4989EC35.80502@mavhome.dp.ua> <4989F6E3.9020702@mavhome.dp.ua> <498A0DDF.1050605@mavhome.dp.ua> Date: Wed, 4 Feb 2009 14:27:53 -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 22:27:55 -0000 On Wed, Feb 4, 2009 at 1:51 PM, Alexander Motin wrote: [...] >>>>> 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) > > Thanks for the explanation, I have got it. Looking into specification I see > there is even four header formats: no addresses, source, dest and > source+dest. oh yes, i forgot about "no src, no dst" packet :) its been a while since i looked at bnep specification :) so, yes, "no src, no dst" is used when both packet originator and receiver's radios are directly connected via rf link. > As I understand it's just a form of header compression. As soon as each side > knows address of the peer it can compress MAC address if it matches to > respective BDADDR. And that's all. exactly. i must admit that saving up to 14 bytes on relatively slow bluetooth link does not exactly strike me as a huge win :) but what do i know anyway :) >> 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. > > I still think we should not do such hacks. As I understand there is OK to > bridge completely unrelated Ethernet traffic via BNEP link. As soon as MAC > addresses does not match to BDADDRs, packets should just be transmitter with > full uncompressed Ethernet header. We should keep TAP MAC address equal to > BDADDR just as much as possible to maximally benefit from header > compression. But if we have single TAP interface on server, which handles > several links via different adapters, I understand it should be fine to just > choose one of BDADDRs as MAC address to be completely honest to everybody. > If there is only one adapter, then all headers will be compressed, if there > is several - only part of them. > > Am I right? well, yes and no. somehow you need to map multiple local bd_addr to either one bd_addr or completely different mac address on tap interface. somehow i think that having completely different mac address on tap interface and map all the local bd_addr's to it makes it cleaner. even if we have to transfer 6 extra bytes in bnep header. i like the ability to bind to wildcard address, it allows us to run bluetooth servers even if there are no bluetooth radios connected to the system. for example, i run sdpd, hcsecd etc. on my laptop always. when i need, i simply plug my usb bluetooth dongle it - presto - it all works. magic! :) if you bind to a particular radio, then you tied to it. cant do anything before radio is present and cant do anything after radio is gone. thanks, max