On Wed, Feb 4, 2009 at 1:51 PM, Alexander Motin <m...@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 _______________________________________________ freebsd-bluetooth@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bluetooth To unsubscribe, send any mail to "freebsd-bluetooth-unsubscr...@freebsd.org"
