pan profile support in freebsd

Alexander Motin mav at mavhome.dp.ua
Thu Feb 5 13:18:25 PST 2009


Maksim Yevmenkin wrote:
>> 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.

Ok, as you wish, simplicity is good, but if it sometimes would be not 
difficult to implement 2, it still would be not bad. The only thing 
should be tested is WM compatibility. Iain was written that there is 
some problems he noticed if addresses differs.

-- 
Alexander Motin


More information about the freebsd-bluetooth mailing list