Date: Wed, 4 Feb 2009 14:27:53 -0800 From: Maksim Yevmenkin <maksim.yevmenkin@gmail.com> To: Alexander Motin <mav@mavhome.dp.ua> Cc: "freebsd-bluetooth@freebsd.org" <freebsd-bluetooth@freebsd.org> Subject: Re: pan profile support in freebsd Message-ID: <bb4a86c70902041427q37a7dbb4s967b4454f88c7d6f@mail.gmail.com> In-Reply-To: <498A0DDF.1050605@mavhome.dp.ua> References: <1233365217.00068654.1233354838@10.7.7.3> <4988EBAC.3080202@mavhome.dp.ua> <bb4a86c70902031731q83bf261s49e5812a3c208f81@mail.gmail.com> <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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Feb 4, 2009 at 1:51 PM, Alexander Motin <mav@mavhome.dp.ua> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bb4a86c70902041427q37a7dbb4s967b4454f88c7d6f>