Maksim Yevmenkin wrote:
On Wed, Feb 4, 2009 at 12:13 PM, Alexander Motin <[email protected]> wrote:
Maksim Yevmenkin wrote:
On Wed, Feb 4, 2009 at 11:27 AM, Alexander Motin <[email protected]>
wrote:
Maksim Yevmenkin wrote:
Does actually this binding really necessary? rfcomm somehow works
without
it.
please see Iain's response :) i knew he would chime in :) thanks Iain!
and, yes, i suspected that it would be something related to mac
addresses on virtual ethernet interface. i do not have a copy of spec
handy, but i recall something about setting mac address to be the same
as radio's bd_addr. dont remember if it was a requirement or more of a
guideline.
in any case, i like Iain's suggestion to rewrite mac addresses on the
fly. i would have done it this way. also, i think, nap server should
just act as ethernet hub, i.e. forward everything everywhere. after
all, nap is supposed to be like local ethernet network :)
Hmm. Working like an Ethernet hub also means that every single hub port
(in
our case every single point-to-point BT link) may transmit packets from
different source MAC addresses, that can't be equal to BT adapter
address.
So or I don't understand your example, or something is wrong here.
why do you think it is wrong? logically all the radios are on the same
virtual ethernet network. i think the only issue here is that
apparently some clients are picky about src mac address and that
complicates the case when nap server has multiple radios.
You have told that NAP server works as hub. So, as I have understood, it
retransmits upstream traffic back down to all/some clients. So, it transmits
packets with MAC addresses of other clients via it's BT adapter. So, source
MAC address will not match his BDADDR. Or server is an exception, which can
violate the rule of equal addresses?
well, i think we have a disconnect here ;) you see, bnep strips
ethernet header completely and replaces it with one of the bnep
ethernet headers. your options basically are
1) bnep ethernet header that has both src and dst "mac addresses"
(that is both src and dst radio bd_addr's)
2) bnep ethernet header that has only src "mac address" (that is src
radio bd_addr only)
3) bnep ethernet header that has only dst "mac address" (that is dst
radio bd_addr only)
(2) and (3) are basically short forms of (1) and used when it is
possible to figure out missing dst or src "mac address" (that is
bd_addr really) because there is a directly "attached" rf link.
in other words, if i know that you are the final recipient of the
packet and i have a direct rf link to you, i'm not going to bother to
set dst "mac address" in bnep packet, because you obviously know your
"mac address" (bd_addr).
or
if i generate a packet and i have a direct rf link to you, i'm not
going to set src "mac address" (that is bd_addr really) because you
know that this packet can only come from me and you already know my
"mac address" (bd_addr)
Thanks for the explanation, I have got it. Looking into specification I
see there is even four header formats: no addresses, source, dest and
source+dest.
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.
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?
--
Alexander Motin
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bluetooth
To unsubscribe, send any mail to "[email protected]"
