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
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bluetooth
To unsubscribe, send any mail to "[email protected]"
