Date: Thu, 05 Feb 2009 21:31:53 +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: <498B3EA9.1030403@mavhome.dp.ua> In-Reply-To: <bb4a86c70902050951k43136b09v4dcfb23549a697fe@mail.gmail.com> References: <1233365217.00068654.1233354838@10.7.7.3> <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> <498A8912.9050208@mavhome.dp.ua> <bb4a86c70902050951k43136b09v4dcfb23549a697fe@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Maksim Yevmenkin wrote: > On Wed, Feb 4, 2009 at 10:37 PM, Alexander Motin <mav@mavhome.dp.ua> wrote: >> 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. > > i'm very confused now :) of course wired lan addresses will be passed > to wireless clients as is, and, without any header compression. i'm > talking about mapping local (to nap server) radio(s) bd_addr to local > (to nap server) tap interface mac address. the nap server should never > give any reason, to any directly attached wireless client, to use > radio's bd_addr instead of tap interface mac address. in other words, > the nap server should never use "no src" nor "no src, no dst" bnep > headers. all locally (on the nap server) generated packets should > always have src address set in bnep header and this src address should > be the mac address set on the tap interface. on receiving side, the > nap server should check "dst" address against the tap interface mac > address and if they match, put packet into the tap device. also, > assuming things are working correctly, the nap server should never get > packets without "dst" set in bnep header. > > so, other than wasting 6 bytes, i do not see any downside to this > approach. did i miss anything here? Sorry, looks like I have misunderstood your: "map multiple local bd_addr to either one bd_addr". I have read it as you are going to interpret fake TAP address as equal to BDADDR and silently compress it. I was against that. I would like to say about that we can: 1) or, as you have just said, set completely fake TAP address and never compress it, as it is never equal, 2) or, as I have told recently, get real BDADDR of any adapter present in system (preferably related) and use it's address for TAP, then for traffic passing via that adapter compression could be used, saving 6 bytes. For usual systems with one adapter it will make that all locally originated/terminated traffic will have compressed src/dst address. -- Alexander Motin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?498B3EA9.1030403>