pan profile support in freebsd

[Alexander Motin]

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

> otherwise your
> wired clients will not be able to talk to your nap (wireless) clients.
> and, btw, if i were to do such a setup in real world, i would
> _never_ever_ use bridging unless i _absolutely_ had to. its just soooo
> much easier/cleaner/etc. to put nap (wireless) clients onto a separate
> subnet and use ip routing.
> 
> as far as wifi alternative goes, its not really going to fly, imo.
> range is too short, speed is too slow, and it can only do 7 clients at
> the same time. does not scale at all :( maybe ok for home, but i yet
> to see a laptop/desktop that has bluetooth and does not have wifi :)

WiFi kills my PDA's battery in hour or even less and it's range and 
performance are not much different.

-- 
Alexander Motin