Date: Thu, 05 Feb 2009 08:37:06 +0200 From: Alexander Motin <mav@mavhome.dp.ua> To: Maksim Yevmenkin <maksim.yevmenkin@gmail.com> Cc: "freebsd-bluetooth@freebsd.org" <freebsd-bluetooth@freebsd.org> Subject: Re: pan profile support in freebsd Message-ID: <498A8912.9050208@mavhome.dp.ua> In-Reply-To: <bb4a86c70902041500x18b6137exdbf3c74cc263d63c@mail.gmail.com> References: <1233365217.00068654.1233354838@10.7.7.3> <4988F857.5080407@mavhome.dp.ua> <bb4a86c70902040947q13da3b4ag6b972da4c1a16a30@mail.gmail.com> <4989EC35.80502@mavhome.dp.ua> <bb4a86c70902041202s36b6f8ct5017bd6ac97c9284@mail.gmail.com> <4989F6E3.9020702@mavhome.dp.ua> <bb4a86c70902041317t8f44a21h2cc75a4854122250@mail.gmail.com> <498A0DDF.1050605@mavhome.dp.ua> <bb4a86c70902041427q37a7dbb4s967b4454f88c7d6f@mail.gmail.com> <498A1966.4030600@mavhome.dp.ua> <bb4a86c70902041500x18b6137exdbf3c74cc263d63c@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?498A8912.9050208>