pan profile support in freebsd

[Maksim Yevmenkin]

[...]

>>>>> 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.

its not even interesting anymore :) imo, there is very little reason
to set tap interface to any radio's bd_addr. it makes perfect sense
(to me) to keep whatever mac address assigned to tap by default
because that is the interface on which traffic is flowing. radio is
just a transport.

it is still possible to compress dst address in bnep header, so, like
i said, the overhead is only 6 bytes. that is 6/1500 = 0.4% (!), and,
i bet you won't even be able to measure it. oh, and keep in mind that
bnep _replaces_ original ethernet header, so even if you don't do
_any_ compression at all, you are not doing worse.

this is a very reasonable price to pay to support multiple radios and
listening on wildcard address without adding extra complexity to the
code. plus, like you said, it only can compress src on only one radio
link anyway, so the more radios you have, the less "win" you will get.

thanks,
max