From owner-freebsd-bluetooth@FreeBSD.ORG Wed Feb 4 20:02:35 2009 Return-Path: Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3BF71106564A for ; Wed, 4 Feb 2009 20:02:35 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.29]) by mx1.freebsd.org (Postfix) with ESMTP id E482C8FC08 for ; Wed, 4 Feb 2009 20:02:34 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by yw-out-2324.google.com with SMTP id 9so1100564ywe.13 for ; Wed, 04 Feb 2009 12:02:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=cESM/YtUm1hMywSeOJOd1vJygCRWWKs713TQf/vHAMY=; b=KEBkU9hPZv+n/w7II/QJAzADMWL/cRJUKP/yWZu5eJmnrsE4lvF2FlWXRDXI/5ltnX WJmg/hKnmqM5P1dbcJJotuToAFWXmmz8uPwy+h20TiOKyfEBIrPypB/IRIvRK33F3Atq KEHt6Eo2as9Zb+Iu/rtbx7TcuRvPunuBHfso0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=sMQGzJo4g5FwbnhktGnYU7HjS+svghdd80fEvQos62jY96LfZ/Joco00cpXoSeBr5W TRCkcFaoot2pFKlPXeASMJdvmdz9yTCFDVeX3zqQThl9g389IHZbqr+62nqYGSoSoaqG hMXyYuVY+hSICTa2vzLT2zfcSGVW0hcxndBBw= MIME-Version: 1.0 Received: by 10.231.32.70 with SMTP id b6mr948989ibd.33.1233777753863; Wed, 04 Feb 2009 12:02:33 -0800 (PST) In-Reply-To: <4989EC35.80502@mavhome.dp.ua> References: <1233365217.00068654.1233354838@10.7.7.3> <4988DCCC.80201@mavhome.dp.ua> <4988EBAC.3080202@mavhome.dp.ua> <4988F857.5080407@mavhome.dp.ua> <4989EC35.80502@mavhome.dp.ua> Date: Wed, 4 Feb 2009 12:02:33 -0800 Message-ID: From: Maksim Yevmenkin To: Alexander Motin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "freebsd-bluetooth@freebsd.org" Subject: Re: pan profile support in freebsd X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2009 20:02:35 -0000 On Wed, Feb 4, 2009 at 11:27 AM, Alexander Motin 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. [...] >>> 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. oh, please :) man hccontrol(8) gives you all the commands. it also tells you to use 'help ' to get more information. also help for each command is taken directly from the bluetooth specification. i'm not sure how much more documentation can we put here. there are also man pages for ng_hci(4) and ng_l2cap(4). that is already so much more information than you can ever get on vast majority of bluetooth enabled gadgets. oh, and btw, users are not even supposed to know/touch any of this stuff. so if your bluetooth gadget does not work - you sh*t out of luck for the most of the time :) in ideal world, everything should just work. in real world, like everything that has to do with rf, sometimes it doesn't :) i agree, documentation could always be better, and i repeatedly asked for help here. i do not know why, but for whatever reason people prefer to put stuff on their private webpages/blogs/forums/etc. instead of just saying "hey, i had this problem and here is how i fixed it. wouldn't it be nice if you could document this in man page/handbook. btw, here is the patch." thanks, max