From owner-freebsd-bluetooth@FreeBSD.ORG Thu Feb 5 06:37:02 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 93E1F106564A for ; Thu, 5 Feb 2009 06:37:02 +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 C69958FC23 for ; Thu, 5 Feb 2009 06:37:01 +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 233592800; Thu, 05 Feb 2009 08:37:00 +0200 Message-ID: <498A8912.9050208@mavhome.dp.ua> Date: Thu, 05 Feb 2009 08:37:06 +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> <4988F857.5080407@mavhome.dp.ua> <4989EC35.80502@mavhome.dp.ua> <4989F6E3.9020702@mavhome.dp.ua> <498A0DDF.1050605@mavhome.dp.ua> <498A1966.4030600@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: Thu, 05 Feb 2009 06:37:02 -0000 Maksim Yevmenkin wrote: > [...] > >>>>> 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. >> If there is no any radio present yet, you can just choose any random MAC >> address for TAP and transfer it via BNEP later. You will loose 6 bytes per >> packet due to addresses mismatch, but it should work. By doing unconditional > > tap is already getting "randomly" selected mac address by default. > >> translation of TAP MAC address into BDADDR, you will make impossible >> bridging between Bluetooth and local network, which is interesting, as can >> be used, for example, as cheap and low power WiFi alternative. > > huh? please explain why. i think if you want to put your nap > (wireless) clients onto the same wired lan you might have on your nap > server you will have to do bridging no matter what. I just mean that bridging should be clean, you should pass LAN MAC addresses to Bluetooth directly without mapping to BDADDR and without compression. > otherwise your > wired clients will not be able to talk to your nap (wireless) clients. > and, btw, if i were to do such a setup in real world, i would > _never_ever_ use bridging unless i _absolutely_ had to. its just soooo > much easier/cleaner/etc. to put nap (wireless) clients onto a separate > subnet and use ip routing. > > as far as wifi alternative goes, its not really going to fly, imo. > range is too short, speed is too slow, and it can only do 7 clients at > the same time. does not scale at all :( maybe ok for home, but i yet > to see a laptop/desktop that has bluetooth and does not have wifi :) WiFi kills my PDA's battery in hour or even less and it's range and performance are not much different. -- Alexander Motin