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