Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 04 Feb 2009 21:27:49 +0200
From:      Alexander Motin <mav@mavhome.dp.ua>
To:        Maksim Yevmenkin <maksim.yevmenkin@gmail.com>
Cc:        "freebsd-bluetooth@freebsd.org" <freebsd-bluetooth@freebsd.org>
Subject:   Re: pan profile support in freebsd
Message-ID:  <4989EC35.80502@mavhome.dp.ua>
In-Reply-To: <bb4a86c70902040947q13da3b4ag6b972da4c1a16a30@mail.gmail.com>
References:  <1233365217.00068654.1233354838@10.7.7.3>	 <4988DCCC.80201@mavhome.dp.ua>	 <bb4a86c70902031622hdc5231g1c9ce33f17842a1e@mail.gmail.com>	 <4988EBAC.3080202@mavhome.dp.ua>	 <bb4a86c70902031731q83bf261s49e5812a3c208f81@mail.gmail.com>	 <4988F857.5080407@mavhome.dp.ua> <bb4a86c70902040947q13da3b4ag6b972da4c1a16a30@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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.

>>> btw, obtaining bdaddr is really easy. in 99.9% cases (where there is
>>> only one bluetooth device connected to the system) 'hccontrol
>>> read_bd_addr' will do the trick :)
>> Indeed. But general number of BT tools, daemons and their options just
>> making me sad.
> 
> i'm not sure how to read that :) there is, like, less than 10
> bluetooth related daemons in total. each has, like, may be 10 options.
> compare this to the number of options ls(1) has :) not sure what could
> possibly make you sad here. if you feel that the documentation is not
> adequate, please feel free to fix it :)

10 daemons is understood, as BT is not that simple and IP stack also 
have many different tools. But anyway having about 70 defined and 
undocumented arguments of hccontrol alone, one of which should be used 
for such basic thing as getting local btaddr, are not looking so funny 
for anybody who are not BT guru. May be writing of some man page with 
some BT basics to cross reference that basic tools could help. Or just 
better cross reference existing pages.

-- 
Alexander Motin



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4989EC35.80502>