39 messages in org.freebsd.freebsd-bluetoothRe: pan profile support in freebsd| From | Sent On | Attachments |
|---|---|---|
| Alexander Motin | Feb 3, 2009 4:09 pm | |
| Maksim Yevmenkin | Feb 3, 2009 4:21 pm | |
| Alexander Motin | Feb 3, 2009 5:12 pm | |
| Maksim Yevmenkin | Feb 3, 2009 5:31 pm | |
| Alexander Motin | Feb 3, 2009 6:06 pm | |
| Iain Hibbert | Feb 4, 2009 6:41 am | |
| Iain Hibbert | Feb 4, 2009 6:57 am | |
| Iain Hibbert | Feb 4, 2009 7:10 am | |
| Maksim Yevmenkin | Feb 4, 2009 9:46 am | |
| Maksim Yevmenkin | Feb 4, 2009 9:59 am | |
| Alexander Motin | Feb 4, 2009 10:39 am | |
| Alexander Motin | Feb 4, 2009 11:07 am | |
| Alexander Motin | Feb 4, 2009 11:27 am | |
| Iain Hibbert | Feb 4, 2009 11:31 am | |
| Alexander Motin | Feb 4, 2009 11:53 am | |
| Maksim Yevmenkin | Feb 4, 2009 12:01 pm | |
| Alexander Motin | Feb 4, 2009 12:13 pm | |
| Iain Hibbert | Feb 4, 2009 12:26 pm | |
| Maksim Yevmenkin | Feb 4, 2009 1:16 pm | |
| Alexander Motin | Feb 4, 2009 1:50 pm | |
| Maksim Yevmenkin | Feb 4, 2009 2:27 pm | |
| Alexander Motin | Feb 4, 2009 2:40 pm | |
| Maksim Yevmenkin | Feb 4, 2009 3:00 pm | |
| Alexander Motin | Feb 4, 2009 10:36 pm | |
| Federico Lorenzi | Feb 5, 2009 12:05 am | |
| Iain Hibbert | Feb 5, 2009 6:28 am | |
| Iain Hibbert | Feb 5, 2009 6:45 am | |
| Maksim Yevmenkin | Feb 5, 2009 9:50 am | |
| Maksim Yevmenkin | Feb 5, 2009 9:55 am | |
| Maksim Yevmenkin | Feb 5, 2009 10:00 am | |
| Alexander Motin | Feb 5, 2009 11:31 am | |
| Maksim Yevmenkin | Feb 5, 2009 1:04 pm | |
| Alexander Motin | Feb 5, 2009 1:17 pm | |
| Iain Hibbert | Feb 6, 2009 3:30 am | |
| Maksim Yevmenkin | Feb 13, 2009 5:17 pm |  .txt |
| Iain Hibbert | Feb 14, 2009 1:52 am | |
| Maksim Yevmenkin | Mar 5, 2009 11:03 am | .txt |
| Iain Hibbert | Mar 5, 2009 12:14 pm | |
| Maksim Yevmenkin | Mar 5, 2009 2:59 pm | .txt |
| Subject: | Re: pan profile support in freebsd | |
|---|---|---|
| From: | Alexander Motin (ma...@mavhome.dp.ua) | |
| Date: | Feb 4, 2009 2:40:06 pm | |
| List: | org.freebsd.freebsd-bluetooth | |
Maksim Yevmenkin wrote:
As I understand it's just a form of header compression. As soon as each side knows address of the peer it can compress MAC address if it matches to respective BDADDR. And that's all.
exactly. i must admit that saving up to 14 bytes on relatively slow bluetooth link does not exactly strike me as a huge win :) but what do i know anyway :)
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 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.
-- Alexander Motin
_______________________________________________ free...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bluetooth To unsubscribe, send any mail to "free...@freebsd.org"