pan profile support in freebsd

[Maksim Yevmenkin]

On Wed, Feb 4, 2009 at 1:51 PM, Alexander Motin <mav at 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