From owner-freebsd-bluetooth@FreeBSD.ORG Mon Oct 17 06:55:53 2005 Return-Path: X-Original-To: freebsd-bluetooth@freebsd.org Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DAE6016A41F for ; Mon, 17 Oct 2005 06:55:53 +0000 (GMT) (envelope-from past@ebs.gr) Received: from fly.ebs.gr (fly.ebs.gr [62.103.84.177]) by mx1.FreeBSD.org (Postfix) with ESMTP id DD1D443D53 for ; Mon, 17 Oct 2005 06:55:52 +0000 (GMT) (envelope-from past@ebs.gr) Received: from ebs.gr (root@hal.ebs.gr [10.1.1.2]) by fly.ebs.gr (8.12.9p1/8.12.9) with ESMTP id j9H6td9V037020; Mon, 17 Oct 2005 09:55:39 +0300 (EEST) (envelope-from past@ebs.gr) Received: from [10.1.1.158] (pc158.ebs.gr [10.1.1.158]) by ebs.gr (8.13.3/8.12.11) with ESMTP id j9H6tpoJ035232; Mon, 17 Oct 2005 09:55:52 +0300 (EEST) (envelope-from past@ebs.gr) Message-ID: <43534AD7.5070809@ebs.gr> Date: Mon, 17 Oct 2005 09:55:19 +0300 From: Panagiotis Astithas Organization: EBS Ltd. User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051008) X-Accept-Language: en-us, en MIME-Version: 1.0 To: vova@fbsd.ru References: <43519460.1090605@ebs.gr> <1129491219.1616.18.camel@localhost> In-Reply-To: <1129491219.1616.18.camel@localhost> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-bluetooth@freebsd.org Subject: Re: [RFC] rc.d integration for the bluetooth subsystem 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: Mon, 17 Oct 2005 06:55:54 -0000 Vladimir Grebenschikov wrote: > В вс, 16/10/2005 в 02:44 +0300, Panagiotis Astithas пишет: > >>Hi all, >> >>I've been playing with integrating the bluetooth subsystem into our rc.d >> infrastructure and I'd like to submit the results of my efforts for >>review. My testing has been centered around my USB bluetooth dongle and >>I know that it works, but I suppose other bluetooth devices should work >>as well. I have taken the existing rc.bluetooth script (that is not >>installed by default) and converted it to rc.d, renaming it as >>'bluetooth'. I also added a couple of other scripts for hcsecd and sdpd, >>that are started from bluetooth, but can also function independently, id >>so desired. Finally I have added a devd configuration file that makes >>sure the bluetooth script gets started on insertion and removal of the >>USB dongle. >> >>With these changes, when I plug in my USB bluetooth dongle, all the >>necessary initialization happens behind the scenes and I can start using >>my bluetooth peripherals right away. When I unplug the dongle all the >>services stop and the necessary shutdown operations are performed on the >>bluetooth stack. There is still some work left, like specifying >>different flags for sdpd & hcsecd, but the defaults work fine. >> >>In order to test this stuff you have to: >> >>- copy bluetooth, hcsecd and sdpd into /etc/rc.d >>- copy ubt.conf into /usr/local/etc/devd (creating it if necessary), or >>add its contents to /etc/devd.conf >>- add a line in /etc/rc.conf with: >> bluetooth_enable="YES" >> >>In an eventual merge into the base system the devd configuration should >>be merged into /etc/devd.conf and /etc/defaults/rc.conf should contain >>the following line instead: >> bluetooth_enable="NO" >> >>I'd appreciate any comments you may have. > > > Great ! It just works, Thank you. > > I've added bthidd script (in attachment) to start human interface daemon > (bt mouse in my case). > > Probably it should load vkbd module, but I am not sure now. Thanks, I don't have a HID device so I forgot all about them. Minor nits: - the rcvar line is not necessary if you don't have/need a bthidd_enable="YES" in rc.conf - bthidd shoud probably REQUIRE: hcsecd, since I suppose the communication wouldn't have been established without authentication Thanks again, Panagiotis From owner-freebsd-bluetooth@FreeBSD.ORG Mon Oct 17 08:22:39 2005 Return-Path: X-Original-To: freebsd-bluetooth@freebsd.org Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D7C3C16A41F for ; Mon, 17 Oct 2005 08:22:39 +0000 (GMT) (envelope-from vova@vbook.fbsd.ru) Received: from vbook.fbsd.ru (swsoft-mipt-nat.sw.ru [195.214.233.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7A80543D75 for ; Mon, 17 Oct 2005 08:22:30 +0000 (GMT) (envelope-from vova@vbook.fbsd.ru) Received: from vova by vbook.fbsd.ru with local (Exim 4.54 (FreeBSD)) id 1EREGJ-0002bJ-Qk; Sun, 16 Oct 2005 23:33:39 +0400 From: Vladimir Grebenschikov To: Panagiotis Astithas In-Reply-To: <43519460.1090605@ebs.gr> References: <43519460.1090605@ebs.gr> Content-Type: multipart/mixed; boundary="=-ZiuFh4KaC3qhqZeeeS+f" Organization: SWsoft Date: Sun, 16 Oct 2005 23:33:39 +0400 Message-Id: <1129491219.1616.18.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.4.1 FreeBSD GNOME Team Port Sender: Vladimir Grebenschikov X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-bluetooth@freebsd.org Subject: Re: [RFC] rc.d integration for the bluetooth subsystem X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: vova@fbsd.ru List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2005 08:22:40 -0000 --=-ZiuFh4KaC3qhqZeeeS+f Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable =F7 =D7=D3, 16/10/2005 =D7 02:44 +0300, Panagiotis Astithas =D0=C9=DB=C5=D4= : > Hi all, >=20 > I've been playing with integrating the bluetooth subsystem into our rc.d=20 > infrastructure and I'd like to submit the results of my efforts for=20 > review. My testing has been centered around my USB bluetooth dongle and=20 > I know that it works, but I suppose other bluetooth devices should work=20 > as well. I have taken the existing rc.bluetooth script (that is not=20 > installed by default) and converted it to rc.d, renaming it as=20 > 'bluetooth'. I also added a couple of other scripts for hcsecd and sdpd,=20 > that are started from bluetooth, but can also function independently, id=20 > so desired. Finally I have added a devd configuration file that makes=20 > sure the bluetooth script gets started on insertion and removal of the=20 > USB dongle. >=20 > With these changes, when I plug in my USB bluetooth dongle, all the=20 > necessary initialization happens behind the scenes and I can start using=20 > my bluetooth peripherals right away. When I unplug the dongle all the=20 > services stop and the necessary shutdown operations are performed on the=20 > bluetooth stack. There is still some work left, like specifying=20 > different flags for sdpd & hcsecd, but the defaults work fine. >=20 > In order to test this stuff you have to: >=20 > - copy bluetooth, hcsecd and sdpd into /etc/rc.d > - copy ubt.conf into /usr/local/etc/devd (creating it if necessary), or=20 > add its contents to /etc/devd.conf > - add a line in /etc/rc.conf with: > bluetooth_enable=3D"YES" >=20 > In an eventual merge into the base system the devd configuration should=20 > be merged into /etc/devd.conf and /etc/defaults/rc.conf should contain=20 > the following line instead: > bluetooth_enable=3D"NO" >=20 > I'd appreciate any comments you may have. Great ! It just works, Thank you. I've added bthidd script (in attachment) to start human interface daemon (bt mouse in my case). Probably it should load vkbd module, but I am not sure now. > Cheers, > Panagiotis --=20 Vladimir B. Grebenschikov vova@fbsd.ru --=-ZiuFh4KaC3qhqZeeeS+f-- From owner-freebsd-bluetooth@FreeBSD.ORG Mon Oct 17 08:45:13 2005 Return-Path: X-Original-To: freebsd-bluetooth@freebsd.org Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2678116A41F; Mon, 17 Oct 2005 08:45:13 +0000 (GMT) (envelope-from vova@vbook.fbsd.ru) Received: from vbook.fbsd.ru (swsoft-mipt-nat.sw.ru [195.214.233.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id A7C2F43D46; Mon, 17 Oct 2005 08:45:12 +0000 (GMT) (envelope-from vova@vbook.fbsd.ru) Received: from vova by vbook.fbsd.ru with local (Exim 4.54 (FreeBSD)) id 1ERQcI-0000NL-NS; Mon, 17 Oct 2005 12:45:10 +0400 From: Vladimir Grebenschikov To: Panagiotis Astithas In-Reply-To: <43534AD7.5070809@ebs.gr> References: <43519460.1090605@ebs.gr> <1129491219.1616.18.camel@localhost> <43534AD7.5070809@ebs.gr> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable Organization: SWsoft Date: Mon, 17 Oct 2005 12:45:09 +0400 Message-Id: <1129538709.1250.10.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.4.1 FreeBSD GNOME Team Port Sender: Vladimir Grebenschikov Cc: freebsd-bluetooth@freebsd.org, imp@freebsd.org Subject: Re: [RFC] rc.d integration for the bluetooth subsystem X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: vova@fbsd.ru List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2005 08:45:13 -0000 =F7 =D0=CE, 17/10/2005 =D7 09:55 +0300, Panagiotis Astithas =D0=C9=DB=C5=D4= : > Vladimir Grebenschikov wrote: > > =F7 =D7=D3, 16/10/2005 =D7 02:44 +0300, Panagiotis Astithas =D0=C9=DB= =C5=D4: > >=20 > >>Hi all, > >> > >>I've been playing with integrating the bluetooth subsystem into our rc.= d=20 > >> infrastructure and I'd like to submit the results of my efforts for=20 > >>review. My testing has been centered around my USB bluetooth dongle and= =20 > >>I know that it works, but I suppose other bluetooth devices should work= =20 > >>as well. I have taken the existing rc.bluetooth script (that is not=20 > >>installed by default) and converted it to rc.d, renaming it as=20 > >>'bluetooth'. I also added a couple of other scripts for hcsecd and sdpd= ,=20 > >>that are started from bluetooth, but can also function independently, i= d=20 > >>so desired. Finally I have added a devd configuration file that makes=20 > >>sure the bluetooth script gets started on insertion and removal of the=20 > >>USB dongle. > >> > >>With these changes, when I plug in my USB bluetooth dongle, all the=20 > >>necessary initialization happens behind the scenes and I can start usin= g=20 > >>my bluetooth peripherals right away. When I unplug the dongle all the=20 > >>services stop and the necessary shutdown operations are performed on th= e=20 > >>bluetooth stack. There is still some work left, like specifying=20 > >>different flags for sdpd & hcsecd, but the defaults work fine. > >> > >>In order to test this stuff you have to: > >> > >>- copy bluetooth, hcsecd and sdpd into /etc/rc.d > >>- copy ubt.conf into /usr/local/etc/devd (creating it if necessary), or= =20 > >>add its contents to /etc/devd.conf > >>- add a line in /etc/rc.conf with: > >> bluetooth_enable=3D"YES" > >> > >>In an eventual merge into the base system the devd configuration should= =20 > >>be merged into /etc/devd.conf and /etc/defaults/rc.conf should contain=20 > >>the following line instead: > >> bluetooth_enable=3D"NO" > >> > >>I'd appreciate any comments you may have. > >=20 > >=20 > > Great ! It just works, Thank you. > >=20 > > I've added bthidd script (in attachment) to start human interface daemo= n > > (bt mouse in my case). > >=20 > > Probably it should load vkbd module, but I am not sure now. >=20 > Thanks, I don't have a HID device so I forgot all about them. Minor nits: > - the rcvar line is not necessary if you don't have/need a=20 > bthidd_enable=3D"YES" in rc.conf Yes, It was my intent. Just because I think not all users need bthidd running with bluetooth stack. Probably there should be some interface between sdpd and devd to report new BT device found. In this case bthidd should be stared on mouse or keyboard appeared in range. Warner, Maksim what you think about the idea ? > - bthidd shoud probably REQUIRE: hcsecd, since I suppose the=20 > communication wouldn't have been established without authentication No, It is not strictly necessary. My mouse works well without authentication. It learns once peer and then do not talk with other devices. > Thanks again, > Panagiotis --=20 Vladimir B. Grebenschikov vova@fbsd.ru From owner-freebsd-bluetooth@FreeBSD.ORG Mon Oct 17 17:13:54 2005 Return-Path: X-Original-To: freebsd-bluetooth@freebsd.org Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 01F9C16A420 for ; Mon, 17 Oct 2005 17:13:54 +0000 (GMT) (envelope-from maksim.yevmenkin@savvis.net) Received: from ismybrain.com (ismybrain.com [64.246.42.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id E352D43D58 for ; Mon, 17 Oct 2005 17:13:52 +0000 (GMT) (envelope-from maksim.yevmenkin@savvis.net) Received: from [10.254.186.111] (localhost.localdomain [127.0.0.1]) by ismybrain.com (8.11.6/8.11.6) with ESMTP id j9HHDZJ20815; Mon, 17 Oct 2005 13:13:39 -0400 Message-ID: <4353DBBC.2000508@savvis.net> Date: Mon, 17 Oct 2005 10:13:32 -0700 From: Maksim Yevmenkin User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050404) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Panagiotis Astithas References: <43519460.1090605@ebs.gr> <1129491219.1616.18.camel@localhost> In-Reply-To: <1129491219.1616.18.camel@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: vova@fbsd.ru, freebsd-bluetooth@freebsd.org Subject: Re: [RFC] rc.d integration for the bluetooth subsystem 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: Mon, 17 Oct 2005 17:13:54 -0000 Panagiotis, it appears i have missed your original email :( not a big problem - i have found it in the archive. please read my comments inline. >> I've been playing with integrating the bluetooth subsystem into our >> rc.d infrastructure and I'd like to submit the results of my >> efforts for review. My testing has been centered around my USB >> bluetooth dongle and I know that it works, but I suppose other >> bluetooth devices should work as well. I have taken the existing >> rc.bluetooth script (that is not installed by default) and >> converted it to rc.d, renaming it as 'bluetooth'. I also added a >> couple of other scripts for hcsecd and sdpd, that are started from >> bluetooth, but can also function independently, id so desired. >> Finally I have added a devd configuration file that makes sure the >> bluetooth script gets started on insertion and removal of the USB >> dongle. that is great. thanks for doing the work! it seems we have been working on this in parallel :) about a week ago i have committed (into -current) hcsecd(8) and sdpd(8) rc.d scripts. they are very similar to what you have done. please see http://www.freebsd.org/cgi/cvsweb.cgi/src/etc/rc.d/hcsecd http://www.freebsd.org/cgi/cvsweb.cgi/src/etc/rc.d/sdpd http://www.freebsd.org/cgi/cvsweb.cgi/src/etc/defaults/rc.conf for more details. >> With these changes, when I plug in my USB bluetooth dongle, all the >> necessary initialization happens behind the scenes and I can start >> using my bluetooth peripherals right away. When I unplug the dongle >> all the services stop and the necessary shutdown operations are >> performed on the bluetooth stack. There is still some work left, >> like specifying different flags for sdpd & hcsecd, but the defaults >> work fine. that sounds just fine. once again - do not worry about hcsecd(8) and sdpd(8) scripts anymore - they are done. >> In order to test this stuff you have to: >> >> - copy bluetooth, hcsecd and sdpd into /etc/rc.d - copy ubt.conf >> into /usr/local/etc/devd (creating it if necessary), or add its >> contents to /etc/devd.conf - add a line in /etc/rc.conf with: >> bluetooth_enable="YES" >> >> In an eventual merge into the base system the devd configuration >> should be merged into /etc/devd.conf and /etc/defaults/rc.conf >> should contain the following line instead: bluetooth_enable="NO" >> >> I'd appreciate any comments you may have. devd(8) configuration (ubt.conf) looks fine. i can merge this info devd.conf for you. hcsecd(8) and sdpd(8) already committed into -current. i have also created bluetooth section in the /etc/defaults/rc.conf file. i have few comments about my original rc.bluetooth script. 1) it probably should not load any kernel modules. the problem is that when one (or more) bluetooth kernel modules compiled into the kernel the kldstat(8) check may fail. this has to do with the way kldstat(8) prints the results and the way rc.bluetooth grep's through them. 2) original rc.bluetooth is very rigid. things like device name, device class, etc. are hardwired into the script. so i'd like to have a bit of flexibility here, i.e. ability to specify per device - device name (change_local_name) - device class (write_class_of_device) - should device be "visible"/discoverable by default (write_scan_enable) - should device request authentication (write_authentication_enable) - should device use encryption (write_encryption_enable) - should device request role switch (write_node_role_switch) and maybe few others. 3) i'd like to have some way to execute a few hccontrol(8) commands after default setup was done. perhaps this could be done with some sort of bluetooth.local rc.d script that will be executed after main script. by default it should be empty. another way to do it is to have something along the bluetooth_extra_commands variable in rc.conf. > Great ! It just works, Thank you. > > I've added bthidd script (in attachment) to start human interface > daemon (bt mouse in my case). Vladimir, could you please forward it to me too (directly). i did not get the attachment. thanks, max From owner-freebsd-bluetooth@FreeBSD.ORG Mon Oct 17 17:37:45 2005 Return-Path: X-Original-To: freebsd-bluetooth@freebsd.org Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 82DEB16A41F for ; Mon, 17 Oct 2005 17:37:45 +0000 (GMT) (envelope-from dmp@bitfreak.org) Received: from mail.bitfreak.org (mail.bitfreak.org [65.75.198.146]) by mx1.FreeBSD.org (Postfix) with ESMTP id 412B343D70 for ; Mon, 17 Oct 2005 17:37:45 +0000 (GMT) (envelope-from dmp@bitfreak.org) Received: from smiley (mail.bitfreak.org [65.75.198.146]) by mail.bitfreak.org (Postfix) with ESMTP id 3356F19F2C for ; Mon, 17 Oct 2005 10:43:22 -0700 (PDT) From: "Darren Pilgrim" To: Date: Mon, 17 Oct 2005 10:37:39 -0700 Message-ID: <001301c5d341$78adfad0$652a15ac@smiley> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <1129538709.1250.10.camel@localhost> Importance: Normal Subject: Bluetooth management software? 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: Mon, 17 Oct 2005 17:37:45 -0000 Now that Bluetooth is edging itself into production with the talk of = merging the related scripts into /etc, I'm wondering if the user side of things = has come along as well? When I got my mouse, phone and PDA working with FreeBSD, it took considerable work: looking at communications, grabbing IDs, manually = editing files, etc. But in certain other OSen, Bluetooth is managed with an app capable of configuring services, searching for and adding new devices. Does such user-land software exist in FreeBSD? Preferably a CLI with an optional = X front end? From owner-freebsd-bluetooth@FreeBSD.ORG Mon Oct 17 18:00:14 2005 Return-Path: X-Original-To: freebsd-bluetooth@FreeBSD.org Delivered-To: freebsd-bluetooth@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BB96616A421 for ; Mon, 17 Oct 2005 18:00:14 +0000 (GMT) (envelope-from pav@FreeBSD.org) Received: from hood.oook.cz (hood.oook.cz [212.27.205.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id E32A143D58 for ; Mon, 17 Oct 2005 18:00:13 +0000 (GMT) (envelope-from pav@FreeBSD.org) Received: from ikaros.oook.cz (localhost [127.0.0.1]) by hood.oook.cz (8.13.4/8.13.4) with ESMTP id j9HI0770019540 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Oct 2005 20:00:07 +0200 (CEST) (envelope-from pav@FreeBSD.org) Received: (from pav@localhost) by ikaros.oook.cz (8.13.4/8.13.4/Submit) id j9HI07Wv019539; Mon, 17 Oct 2005 20:00:07 +0200 (CEST) (envelope-from pav@FreeBSD.org) X-Authentication-Warning: ikaros.oook.cz: pav set sender to pav@FreeBSD.org using -f From: Pav Lucistnik To: Darren Pilgrim In-Reply-To: <001301c5d341$78adfad0$652a15ac@smiley> References: <001301c5d341$78adfad0$652a15ac@smiley> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-c+HseMzrA+TaXGsLy9jF" Date: Mon, 17 Oct 2005 20:00:07 +0200 Message-Id: <1129572007.19407.9.camel@ikaros.oook.cz> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 FreeBSD GNOME Team Port Cc: freebsd-bluetooth@FreeBSD.org Subject: Re: Bluetooth management software? X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pav@FreeBSD.org List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2005 18:00:14 -0000 --=-c+HseMzrA+TaXGsLy9jF Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable Darren Pilgrim p=ED=B9e v po 17. 10. 2005 v 10:37 -0700: > Now that Bluetooth is edging itself into production with the talk of merg= ing > the related scripts into /etc, I'm wondering if the user side of things h= as > come along as well? >=20 > When I got my mouse, phone and PDA working with FreeBSD, it took > considerable work: looking at communications, grabbing IDs, manually edit= ing > files, etc. >=20 > But in certain other OSen, Bluetooth is managed with an app capable of > configuring services, searching for and adding new devices. Does such > user-land software exist in FreeBSD? Preferably a CLI with an optional X > front end? There are some UIs available for Linux, mainly GNOME/KDE things. But they are running on top of bluez library, and none of them is ported to FreeBSD, AFAIK. --=20 Pav Lucistnik You have acquired a scroll entitled 'irk gleknow mizk' (n). This is an IBM Manual scroll. You are permanently confused. --=-c+HseMzrA+TaXGsLy9jF Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQBDU+anntdYP8FOsoIRAo+hAJ0QT9dfvzNtr6LtrYgym1pl0HXdCwCfdhxF cj8lUady2uYsRqKC3JZnetI= =3sso -----END PGP SIGNATURE----- --=-c+HseMzrA+TaXGsLy9jF-- From owner-freebsd-bluetooth@FreeBSD.ORG Mon Oct 17 18:00:52 2005 Return-Path: X-Original-To: freebsd-bluetooth@freebsd.org Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 40F4816A41F for ; Mon, 17 Oct 2005 18:00:52 +0000 (GMT) (envelope-from maksim.yevmenkin@savvis.net) Received: from ismybrain.com (ismybrain.com [64.246.42.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id DC5C643D48 for ; Mon, 17 Oct 2005 18:00:49 +0000 (GMT) (envelope-from maksim.yevmenkin@savvis.net) Received: from [10.254.186.111] (localhost.localdomain [127.0.0.1]) by ismybrain.com (8.11.6/8.11.6) with ESMTP id j9HI0kJ21863; Mon, 17 Oct 2005 14:00:46 -0400 Message-ID: <4353E6CC.2000705@savvis.net> Date: Mon, 17 Oct 2005 11:00:44 -0700 From: Maksim Yevmenkin User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050404) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Darren Pilgrim References: <001301c5d341$78adfad0$652a15ac@smiley> In-Reply-To: <001301c5d341$78adfad0$652a15ac@smiley> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-bluetooth@freebsd.org Subject: Re: Bluetooth management software? 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: Mon, 17 Oct 2005 18:00:52 -0000 Darren, > Now that Bluetooth is edging itself into production with the talk of merging > the related scripts into /etc, I'm wondering if the user side of things has > come along as well? probably not as one would hope. > When I got my mouse, phone and PDA working with FreeBSD, it took > considerable work: looking at communications, grabbing IDs, manually editing > files, etc. well, yes, i agree. things could be better. > But in certain other OSen, Bluetooth is managed with an app capable of > configuring services, searching for and adding new devices. Does such > user-land software exist in FreeBSD? Preferably a CLI with an optional X > front end? i not really sure what are you talking about here. it is true - there is no user gui interface, but cli tools are there. 1) configuring services: if you mean configure services on freebsd side then its up to the application providing service to configure it. for example rfcomm_pppd(8) or obexapp(1) from ports will register services with local sdpd(8). all you need to do is to make sure sdpd(8) is running and when you start rfcomm_pppd(8) or obexapp(1) they will register LAN or OPUSH service with sdpd(8). 2) searching for devices: hccontrol inquiry 3) searching for services: sdpcontrol(8) cli or libsdp(3) application interface 4) i'm not sure what do you mean by "adding new devices". i know in windows you will have a separate com port if you want to use "serial port" service, but freebsd you do not need to. in freebsd you will use pty(4). thanks, max From owner-freebsd-bluetooth@FreeBSD.ORG Mon Oct 17 18:10:31 2005 Return-Path: X-Original-To: freebsd-bluetooth@freebsd.org Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D7BE716A44A for ; Mon, 17 Oct 2005 18:10:31 +0000 (GMT) (envelope-from maksim.yevmenkin@savvis.net) Received: from ismybrain.com (ismybrain.com [64.246.42.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id 74CBA43D46 for ; Mon, 17 Oct 2005 18:10:31 +0000 (GMT) (envelope-from maksim.yevmenkin@savvis.net) Received: from [10.254.186.111] (localhost.localdomain [127.0.0.1]) by ismybrain.com (8.11.6/8.11.6) with ESMTP id j9HIAOJ22066; Mon, 17 Oct 2005 14:10:25 -0400 Message-ID: <4353E90E.7070602@savvis.net> Date: Mon, 17 Oct 2005 11:10:22 -0700 From: Maksim Yevmenkin User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050404) X-Accept-Language: en-us, en MIME-Version: 1.0 To: vova@fbsd.ru References: <43519460.1090605@ebs.gr> <1129491219.1616.18.camel@localhost> <43534AD7.5070809@ebs.gr> <1129538709.1250.10.camel@localhost> In-Reply-To: <1129538709.1250.10.camel@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-bluetooth@freebsd.org, Warner Losh Subject: Re: [RFC] rc.d integration for the bluetooth subsystem 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: Mon, 17 Oct 2005 18:10:32 -0000 [...] >>> Probably it should load vkbd module, but I am not sure now. >> >> Thanks, I don't have a HID device so I forgot all about them. Minor >> nits: - the rcvar line is not necessary if you don't have/need a >> bthidd_enable="YES" in rc.conf > > Yes, It was my intent. Just because I think not all users need bthidd > running with bluetooth stack. > > Probably there should be some interface between sdpd and devd to > report new BT device found. In this case bthidd should be stared on > mouse or keyboard appeared in range. > > Warner, Maksim what you think about the idea ? nope. you do not need anything. just have bthid(8) running at all time and you should be good to go. once bthidd(8) "knows" about the device, i.e. it has entry in /etc/bluetooth/bthidd.conf, it will try to either 1) connect to the device at specified interval or 2) wait for the device to connect bluetooth hid devices have "reconnect initiate" flag that will tell if device will initiate reconnect or it will expect connection from the host. bluetooth mice usually have "reconnect initiate" flag set, meaning that device will initiate reconnect. when mouse goes out of range bthidd(8) kills connection and waits for it to come back. when mouse is back in range and you wiggle it a bit it will try to connect back to bthidd(8). >> - bthidd shoud probably REQUIRE: hcsecd, since I suppose the >> communication wouldn't have been established without authentication > > No, It is not strictly necessary. My mouse works well without > authentication. It learns once peer and then do not talk with other > devices. yes, thats how it usually works. max From owner-freebsd-bluetooth@FreeBSD.ORG Mon Oct 17 22:03:08 2005 Return-Path: X-Original-To: freebsd-bluetooth@freebsd.org Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4022F16A41F for ; Mon, 17 Oct 2005 22:03:08 +0000 (GMT) (envelope-from past@ebs.gr) Received: from fly.ebs.gr (fly.ebs.gr [62.103.84.177]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1F83E43D49 for ; Mon, 17 Oct 2005 22:03:06 +0000 (GMT) (envelope-from past@ebs.gr) Received: from ebs.gr (root@hal.ebs.gr [10.1.1.2]) by fly.ebs.gr (8.12.9p1/8.12.9) with ESMTP id j9HM319V039807; Tue, 18 Oct 2005 01:03:01 +0300 (EEST) (envelope-from past@ebs.gr) Received: from [10.1.1.200] (pptp.ebs.gr [10.1.1.200]) by ebs.gr (8.13.3/8.12.11) with ESMTP id j9HM36oe054229; Tue, 18 Oct 2005 01:03:10 +0300 (EEST) (envelope-from past@ebs.gr) Message-ID: <43541F79.6040008@ebs.gr> Date: Tue, 18 Oct 2005 01:02:33 +0300 From: Panagiotis Astithas Organization: EBS Ltd. User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051008) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Maksim Yevmenkin References: <43519460.1090605@ebs.gr> <1129491219.1616.18.camel@localhost> <4353DBBC.2000508@savvis.net> In-Reply-To: <4353DBBC.2000508@savvis.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: vova@fbsd.ru, freebsd-bluetooth@freebsd.org Subject: Re: [RFC] rc.d integration for the bluetooth subsystem 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: Mon, 17 Oct 2005 22:03:08 -0000 Maksim Yevmenkin wrote: > Panagiotis, > > it appears i have missed your original email :( not a big problem - i > have found it in the archive. please read my comments inline. > >>> I've been playing with integrating the bluetooth subsystem into our >>> rc.d infrastructure and I'd like to submit the results of my >>> efforts for review. My testing has been centered around my USB >>> bluetooth dongle and I know that it works, but I suppose other >>> bluetooth devices should work as well. I have taken the existing >>> rc.bluetooth script (that is not installed by default) and >>> converted it to rc.d, renaming it as 'bluetooth'. I also added a >>> couple of other scripts for hcsecd and sdpd, that are started from >>> bluetooth, but can also function independently, id so desired. >>> Finally I have added a devd configuration file that makes sure the >>> bluetooth script gets started on insertion and removal of the USB >>> dongle. > > > that is great. thanks for doing the work! it seems we have been working > on this in parallel :) about a week ago i have committed (into -current) > hcsecd(8) and sdpd(8) rc.d scripts. they are very similar to what you > have done. please see > > http://www.freebsd.org/cgi/cvsweb.cgi/src/etc/rc.d/hcsecd > > http://www.freebsd.org/cgi/cvsweb.cgi/src/etc/rc.d/sdpd > > http://www.freebsd.org/cgi/cvsweb.cgi/src/etc/defaults/rc.conf > > for more details. Excellent! I missed your commits, although I try to keep up with cvs-src from time to time. You obviously did a better job with these two scripts than me and I appreciate it. >>> With these changes, when I plug in my USB bluetooth dongle, all the >>> necessary initialization happens behind the scenes and I can start >>> using my bluetooth peripherals right away. When I unplug the dongle >>> all the services stop and the necessary shutdown operations are >>> performed on the bluetooth stack. There is still some work left, >>> like specifying different flags for sdpd & hcsecd, but the defaults >>> work fine. > > > that sounds just fine. once again - do not worry about hcsecd(8) and > sdpd(8) scripts anymore - they are done. > >>> In order to test this stuff you have to: >>> >>> - copy bluetooth, hcsecd and sdpd into /etc/rc.d - copy ubt.conf >>> into /usr/local/etc/devd (creating it if necessary), or add its >>> contents to /etc/devd.conf - add a line in /etc/rc.conf with: >>> bluetooth_enable="YES" >>> >>> In an eventual merge into the base system the devd configuration >>> should be merged into /etc/devd.conf and /etc/defaults/rc.conf >>> should contain the following line instead: bluetooth_enable="NO" >>> >>> I'd appreciate any comments you may have. > > > devd(8) configuration (ubt.conf) looks fine. i can merge this info > devd.conf for you. hcsecd(8) and sdpd(8) already committed into > -current. i have also created bluetooth section in the > /etc/defaults/rc.conf file. > > i have few comments about my original rc.bluetooth script. > > 1) it probably should not load any kernel modules. the problem is that > when one (or more) bluetooth kernel modules compiled into the kernel the > kldstat(8) check may fail. this has to do with the way kldstat(8) prints > the results and the way rc.bluetooth grep's through them. > > 2) original rc.bluetooth is very rigid. things like device name, device > class, etc. are hardwired into the script. so i'd like to have a bit of > flexibility here, i.e. ability to specify per device > > - device name (change_local_name) > > - device class (write_class_of_device) > > - should device be "visible"/discoverable by default (write_scan_enable) > > - should device request authentication (write_authentication_enable) > > - should device use encryption (write_encryption_enable) > > - should device request role switch (write_node_role_switch) > > and maybe few others. > > 3) i'd like to have some way to execute a few hccontrol(8) commands > after default setup was done. perhaps this could be done with some sort > of bluetooth.local rc.d script that will be executed after main script. > by default it should be empty. another way to do it is to have something > along the bluetooth_extra_commands variable in rc.conf. Thanks for the comments. I understand your concerns and share some of your reservations regarding the rc.bluetooth script (or my rc.d-fied version of it). Nevertheless, I feel that the lack of (some version of) it in the base system, complicates unnecessary the use of the bluetooth stack. I do agree that the goals you describe should be pursued. I would ask you though to consider adding even this imperfect, rigid version in the meantime, while we plan how we can improve on it further. After all devd must execute something, right? :-) I'd like to think some more about your general plan. I might find some time to help. Thanks, Panagiotis From owner-freebsd-bluetooth@FreeBSD.ORG Tue Oct 18 19:24:14 2005 Return-Path: X-Original-To: freebsd-bluetooth@freebsd.org Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 249B816A41F for ; Tue, 18 Oct 2005 19:24:14 +0000 (GMT) (envelope-from maksim.yevmenkin@savvis.net) Received: from ismybrain.com (ismybrain.com [64.246.42.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id B484743D45 for ; Tue, 18 Oct 2005 19:24:13 +0000 (GMT) (envelope-from maksim.yevmenkin@savvis.net) Received: from [10.254.186.111] (localhost.localdomain [127.0.0.1]) by ismybrain.com (8.11.6/8.11.6) with ESMTP id j9IJO2J17524; Tue, 18 Oct 2005 15:24:02 -0400 Message-ID: <43554BCE.7090309@savvis.net> Date: Tue, 18 Oct 2005 12:23:58 -0700 From: Maksim Yevmenkin User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050404) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Panagiotis Astithas References: <43519460.1090605@ebs.gr> <1129491219.1616.18.camel@localhost> <4353DBBC.2000508@savvis.net> <43541F79.6040008@ebs.gr> In-Reply-To: <43541F79.6040008@ebs.gr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: vova@fbsd.ru, freebsd-bluetooth@freebsd.org Subject: Re: [RFC] rc.d integration for the bluetooth subsystem 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: Tue, 18 Oct 2005 19:24:14 -0000 Panagiotis, [...] >>>> In an eventual merge into the base system the devd configuration >>>> should be merged into /etc/devd.conf and /etc/defaults/rc.conf >>>> should contain the following line instead: bluetooth_enable="NO" >>>> >>>> I'd appreciate any comments you may have. >> >> devd(8) configuration (ubt.conf) looks fine. i can merge this info >> devd.conf for you. hcsecd(8) and sdpd(8) already committed into >> -current. i have also created bluetooth section in the >> /etc/defaults/rc.conf file. >> >> i have few comments about my original rc.bluetooth script. >> >> 1) it probably should not load any kernel modules. the problem is that >> when one (or more) bluetooth kernel modules compiled into the kernel >> the kldstat(8) check may fail. this has to do with the way kldstat(8) >> prints the results and the way rc.bluetooth grep's through them. >> >> 2) original rc.bluetooth is very rigid. things like device name, >> device class, etc. are hardwired into the script. so i'd like to have >> a bit of flexibility here, i.e. ability to specify per device >> >> - device name (change_local_name) >> >> - device class (write_class_of_device) >> >> - should device be "visible"/discoverable by default (write_scan_enable) >> >> - should device request authentication (write_authentication_enable) >> >> - should device use encryption (write_encryption_enable) >> >> - should device request role switch (write_node_role_switch) >> >> and maybe few others. >> >> 3) i'd like to have some way to execute a few hccontrol(8) commands >> after default setup was done. perhaps this could be done with some >> sort of bluetooth.local rc.d script that will be executed after main >> script. by default it should be empty. another way to do it is to have >> something along the bluetooth_extra_commands variable in rc.conf. > > Thanks for the comments. I understand your concerns and share some of > your reservations regarding the rc.bluetooth script (or my rc.d-fied > version of it). Nevertheless, I feel that the lack of (some version of) > it in the base system, complicates unnecessary the use of the bluetooth > stack. I do agree that the goals you describe should be pursued. I would > ask you though to consider adding even this imperfect, rigid version in > the meantime, while we plan how we can improve on it further. After all > devd must execute something, right? :-) that's fine. please give me some time for more careful review. also shouldn't rc.bluetooth be in /etc instead of /etc/rc.d? its similar to /etc/pccard_ether, is it not? > I'd like to think some more about your general plan. I might find some > time to help. great. thanks! max From owner-freebsd-bluetooth@FreeBSD.ORG Wed Oct 19 08:00:47 2005 Return-Path: X-Original-To: freebsd-bluetooth@freebsd.org Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6C1A516A420 for ; Wed, 19 Oct 2005 08:00:47 +0000 (GMT) (envelope-from past@ebs.gr) Received: from fly.ebs.gr (fly.ebs.gr [62.103.84.177]) by mx1.FreeBSD.org (Postfix) with ESMTP id 869DE43D53 for ; Wed, 19 Oct 2005 08:00:43 +0000 (GMT) (envelope-from past@ebs.gr) Received: from ebs.gr (root@hal.ebs.gr [10.1.1.2]) by fly.ebs.gr (8.12.9p1/8.12.9) with ESMTP id j9J80Y9V045647; Wed, 19 Oct 2005 11:00:34 +0300 (EEST) (envelope-from past@ebs.gr) Received: from [10.1.1.158] (pc158.ebs.gr [10.1.1.158]) by ebs.gr (8.13.3/8.12.11) with ESMTP id j9J80kIV083679; Wed, 19 Oct 2005 11:00:46 +0300 (EEST) (envelope-from past@ebs.gr) Message-ID: <4355FD0C.2090702@ebs.gr> Date: Wed, 19 Oct 2005 11:00:12 +0300 From: Panagiotis Astithas Organization: EBS Ltd. User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051008) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Maksim Yevmenkin References: <43519460.1090605@ebs.gr> <1129491219.1616.18.camel@localhost> <4353DBBC.2000508@savvis.net> <43541F79.6040008@ebs.gr> <43554BCE.7090309@savvis.net> In-Reply-To: <43554BCE.7090309@savvis.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: vova@fbsd.ru, freebsd-bluetooth@freebsd.org Subject: Re: [RFC] rc.d integration for the bluetooth subsystem 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, 19 Oct 2005 08:00:47 -0000 Maksim Yevmenkin wrote: > Panagiotis, > > [...] > >>>>> In an eventual merge into the base system the devd configuration >>>>> should be merged into /etc/devd.conf and /etc/defaults/rc.conf >>>>> should contain the following line instead: bluetooth_enable="NO" >>>>> >>>>> I'd appreciate any comments you may have. >>> >>> >>> devd(8) configuration (ubt.conf) looks fine. i can merge this info >>> devd.conf for you. hcsecd(8) and sdpd(8) already committed into >>> -current. i have also created bluetooth section in the >>> /etc/defaults/rc.conf file. >>> >>> i have few comments about my original rc.bluetooth script. >>> >>> 1) it probably should not load any kernel modules. the problem is >>> that when one (or more) bluetooth kernel modules compiled into the >>> kernel the kldstat(8) check may fail. this has to do with the way >>> kldstat(8) prints the results and the way rc.bluetooth grep's through >>> them. >>> >>> 2) original rc.bluetooth is very rigid. things like device name, >>> device class, etc. are hardwired into the script. so i'd like to have >>> a bit of flexibility here, i.e. ability to specify per device >>> >>> - device name (change_local_name) >>> >>> - device class (write_class_of_device) >>> >>> - should device be "visible"/discoverable by default (write_scan_enable) >>> >>> - should device request authentication (write_authentication_enable) >>> >>> - should device use encryption (write_encryption_enable) >>> >>> - should device request role switch (write_node_role_switch) >>> >>> and maybe few others. >>> >>> 3) i'd like to have some way to execute a few hccontrol(8) commands >>> after default setup was done. perhaps this could be done with some >>> sort of bluetooth.local rc.d script that will be executed after main >>> script. by default it should be empty. another way to do it is to >>> have something along the bluetooth_extra_commands variable in rc.conf. >> >> >> Thanks for the comments. I understand your concerns and share some of >> your reservations regarding the rc.bluetooth script (or my rc.d-fied >> version of it). Nevertheless, I feel that the lack of (some version >> of) it in the base system, complicates unnecessary the use of the >> bluetooth stack. I do agree that the goals you describe should be >> pursued. I would ask you though to consider adding even this >> imperfect, rigid version in the meantime, while we plan how we can >> improve on it further. After all devd must execute something, right? :-) > > > that's fine. please give me some time for more careful review. also > shouldn't rc.bluetooth be in /etc instead of /etc/rc.d? its similar to > /etc/pccard_ether, is it not? If you pick rc.bluetooth, yes. On the other hand if you prefer the rc.d version that I posted, it is more like, say /etc/rc.d/netif, so it should be in /etc/rc.d. If you are concerned about having a script in rc.d that is not executed at boot time, there is also the precedent of /etc/rc.d/dhclient and the other scripts with the nostart keyword. It is also my impression that rc.foo scripts in /etc are being deprecated these days, but I might be wrong. We could ask freebsd-rc for a clarification. Thanks, Panagiotis From owner-freebsd-bluetooth@FreeBSD.ORG Wed Oct 19 23:05:28 2005 Return-Path: X-Original-To: freebsd-bluetooth@freebsd.org Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1A9FB16A41F for ; Wed, 19 Oct 2005 23:05:28 +0000 (GMT) (envelope-from maksim.yevmenkin@savvis.net) Received: from ismybrain.com (ismybrain.com [64.246.42.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id ABA2043D6A for ; Wed, 19 Oct 2005 23:05:27 +0000 (GMT) (envelope-from maksim.yevmenkin@savvis.net) Received: from [10.254.186.111] (localhost.localdomain [127.0.0.1]) by ismybrain.com (8.11.6/8.11.6) with ESMTP id j9JN5LJ17763; Wed, 19 Oct 2005 19:05:21 -0400 Message-ID: <4356D12F.7000006@savvis.net> Date: Wed, 19 Oct 2005 16:05:19 -0700 From: Maksim Yevmenkin User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050404) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Panagiotis Astithas References: <43519460.1090605@ebs.gr> <1129491219.1616.18.camel@localhost> <4353DBBC.2000508@savvis.net> <43541F79.6040008@ebs.gr> <43554BCE.7090309@savvis.net> <4355FD0C.2090702@ebs.gr> In-Reply-To: <4355FD0C.2090702@ebs.gr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-bluetooth@freebsd.org Subject: Re: [RFC] rc.d integration for the bluetooth subsystem 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, 19 Oct 2005 23:05:28 -0000 Panagiotis, [...] >> that's fine. please give me some time for more careful review. also >> shouldn't rc.bluetooth be in /etc instead of /etc/rc.d? its >> similar to /etc/pccard_ether, is it not? > > If you pick rc.bluetooth, yes. On the other hand if you prefer the > rc.d version that I posted, it is more like, say /etc/rc.d/netif, so > it should be in /etc/rc.d. If you are concerned about having a script > in rc.d that is not executed at boot time, there is also the > precedent of /etc/rc.d/dhclient and the other scripts with the > nostart keyword. > > It is also my impression that rc.foo scripts in /etc are being > deprecated these days, but I might be wrong. We could ask freebsd-rc > for a clarification. yes. basically i'm not sure where your version of bluetooth rc.d script should go /etc or /etc/rc.d the other questions i have is 1) was there any particular reason to put "shutdown" word into "KEYWORD:"? the way i understand it: your bluetooth script will be called with "stop" command on system shutdown, however there will be no device name, so ${dev} will be unset. am i correct here? 2) what is the reason for calling "/etc/rc.d/{hcsecd,sdpd} {start,stop}" from "bluetooth_start()/bluetooth_stop()"? shouldn't these be controlled by their own xxx_enable variables? for example you do not need sdpd(8) running unless you want to provide services to the remote clients. also both sdpd(8) and hcsecd(8) bind to "any" bd_addr, so there is no reason to restart them even if particular device comes and goes. what is important here is to kill daemons (providing services, such as rfcomm_pppd(8)) if they were bound (i.e. listening) to the device that went away. however this is a corner case. usually service daemons listen on "any" address and thus there is no need to restart them. thanks, max From owner-freebsd-bluetooth@FreeBSD.ORG Thu Oct 20 10:00:22 2005 Return-Path: X-Original-To: freebsd-bluetooth@freebsd.org Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 86EA216A41F for ; Thu, 20 Oct 2005 10:00:22 +0000 (GMT) (envelope-from past@ebs.gr) Received: from fly.ebs.gr (fly.ebs.gr [62.103.84.177]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9D59F43D68 for ; Thu, 20 Oct 2005 10:00:20 +0000 (GMT) (envelope-from past@ebs.gr) Received: from ebs.gr (root@hal.ebs.gr [10.1.1.2]) by fly.ebs.gr (8.12.9p1/8.12.9) with ESMTP id j9KA0I9V050280; Thu, 20 Oct 2005 13:00:18 +0300 (EEST) (envelope-from past@ebs.gr) Received: from [10.1.1.158] (pc158.ebs.gr [10.1.1.158]) by ebs.gr (8.13.3/8.12.11) with ESMTP id j9KA0V8Z006024; Thu, 20 Oct 2005 13:00:32 +0300 (EEST) (envelope-from past@ebs.gr) Message-ID: <43576A9D.1050209@ebs.gr> Date: Thu, 20 Oct 2005 12:59:57 +0300 From: Panagiotis Astithas Organization: EBS Ltd. User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051008) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Maksim Yevmenkin References: <43519460.1090605@ebs.gr> <1129491219.1616.18.camel@localhost> <4353DBBC.2000508@savvis.net> <43541F79.6040008@ebs.gr> <43554BCE.7090309@savvis.net> <4355FD0C.2090702@ebs.gr> <4356D12F.7000006@savvis.net> In-Reply-To: <4356D12F.7000006@savvis.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-bluetooth@freebsd.org Subject: Re: [RFC] rc.d integration for the bluetooth subsystem 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: Thu, 20 Oct 2005 10:00:22 -0000 Maksim Yevmenkin wrote: > Panagiotis, > > [...] > >>> that's fine. please give me some time for more careful review. also >>> shouldn't rc.bluetooth be in /etc instead of /etc/rc.d? its >>> similar to /etc/pccard_ether, is it not? >> >> >> If you pick rc.bluetooth, yes. On the other hand if you prefer the >> rc.d version that I posted, it is more like, say /etc/rc.d/netif, so >> it should be in /etc/rc.d. If you are concerned about having a script >> in rc.d that is not executed at boot time, there is also the >> precedent of /etc/rc.d/dhclient and the other scripts with the >> nostart keyword. >> >> It is also my impression that rc.foo scripts in /etc are being >> deprecated these days, but I might be wrong. We could ask freebsd-rc >> for a clarification. > > > yes. basically i'm not sure where your version of bluetooth rc.d script > should go /etc or /etc/rc.d > > the other questions i have is > > 1) was there any particular reason to put "shutdown" word into > "KEYWORD:"? the way i understand it: your bluetooth script will be > called with "stop" command on system shutdown, however there will be no > device name, so ${dev} will be unset. am i correct here? Actually if you don't put in the "shutdown" keyword, the script is skipped for faster shutdown. I figured there was a need to perform the shutdown_stack subroutine, so I added it. However I think you are right, on system shutdown ${dev} will be unset, so the keyword is probably meaningless. I should try to perform a system shutdown with my USB dongle still plugged in to see if there are any error messages. > 2) what is the reason for calling "/etc/rc.d/{hcsecd,sdpd} {start,stop}" > from "bluetooth_start()/bluetooth_stop()"? shouldn't these be > controlled by their own xxx_enable variables? for example you do not > need sdpd(8) running unless you want to provide services to the remote > clients. also both sdpd(8) and hcsecd(8) bind to "any" bd_addr, so there > is no reason to restart them even if particular device comes and goes. > what is important here is to kill daemons (providing services, such as > rfcomm_pppd(8)) if they were bound (i.e. listening) to the device that > went away. however this is a corner case. usually service daemons listen > on "any" address and thus there is no need to restart them. I opted for simplicity and ease of use. I think users don't comprehend the interactions between sdpd, hcsecd, the bluetooth stack, etc. most of the time. The typical use case I have in mind is a user who plugs in his bluetooth dongle to send or receive files. Since we don't have any user-friendly applications in the base system, I think a user would prefer to initiate a device-to-PC transfer from the device. In this case he will need both hcsecd and sdpd, right? It is also the default behavior in Windows and in Linux KDE, I think. You get all the necessary services running before starting a connection. I am also considering porting gnome-bluetooth for the same reason. I understand that your approach with sdpd_enable and hcsecd_enable is more fine-grained, but I wonder if we could combine it with hassle-free operation for the common case. I agree with all the rest that you mention about the address binding. Regards, Panagiotis From owner-freebsd-bluetooth@FreeBSD.ORG Thu Oct 20 17:06:55 2005 Return-Path: X-Original-To: freebsd-bluetooth@freebsd.org Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 82A2216A41F for ; Thu, 20 Oct 2005 17:06:55 +0000 (GMT) (envelope-from maksim.yevmenkin@savvis.net) Received: from ismybrain.com (ismybrain.com [64.246.42.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id 151CD43D5A for ; Thu, 20 Oct 2005 17:06:54 +0000 (GMT) (envelope-from maksim.yevmenkin@savvis.net) Received: from [10.254.186.111] (localhost.localdomain [127.0.0.1]) by ismybrain.com (8.11.6/8.11.6) with ESMTP id j9KH6lJ06297; Thu, 20 Oct 2005 13:06:47 -0400 Message-ID: <4357CEA5.1000308@savvis.net> Date: Thu, 20 Oct 2005 10:06:45 -0700 From: Maksim Yevmenkin User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050404) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Panagiotis Astithas References: <43519460.1090605@ebs.gr> <1129491219.1616.18.camel@localhost> <4353DBBC.2000508@savvis.net> <43541F79.6040008@ebs.gr> <43554BCE.7090309@savvis.net> <4355FD0C.2090702@ebs.gr> <4356D12F.7000006@savvis.net> <43576A9D.1050209@ebs.gr> In-Reply-To: <43576A9D.1050209@ebs.gr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-bluetooth@freebsd.org Subject: Re: [RFC] rc.d integration for the bluetooth subsystem 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: Thu, 20 Oct 2005 17:06:55 -0000 Panagiotis, [...] >> the other questions i have is >> >> 1) was there any particular reason to put "shutdown" word into >> "KEYWORD:"? the way i understand it: your bluetooth script will be >> called with "stop" command on system shutdown, however there will be >> no device name, so ${dev} will be unset. am i correct here? > > Actually if you don't put in the "shutdown" keyword, the script is > skipped for faster shutdown. I figured there was a need to perform the > shutdown_stack subroutine, so I added it. However I think you are right, > on system shutdown ${dev} will be unset, so the keyword is probably > meaningless. I should try to perform a system shutdown with my USB > dongle still plugged in to see if there are any error messages. fine >> 2) what is the reason for calling "/etc/rc.d/{hcsecd,sdpd} >> {start,stop}" from "bluetooth_start()/bluetooth_stop()"? shouldn't >> these be controlled by their own xxx_enable variables? for example you >> do not need sdpd(8) running unless you want to provide services to the >> remote clients. also both sdpd(8) and hcsecd(8) bind to "any" bd_addr, >> so there is no reason to restart them even if particular device comes >> and goes. what is important here is to kill daemons (providing >> services, such as rfcomm_pppd(8)) if they were bound (i.e. listening) >> to the device that went away. however this is a corner case. usually >> service daemons listen on "any" address and thus there is no need to >> restart them. > > I opted for simplicity and ease of use. I think users don't comprehend > the interactions between sdpd, hcsecd, the bluetooth stack, etc. most of > the time. The typical use case I have in mind is a user who plugs in his > bluetooth dongle to send or receive files. Since we don't have any if one does not understand interaction between hcsecd/sdpd/etc. then perhaps better documentation must be written? if one refuses do read documentation then i'd just say, have "sdpd_enable" and "hcsecd_enable" set because they required. there is harm in having them both running all the time. > user-friendly applications in the base system, I think a user would > prefer to initiate a device-to-PC transfer from the device. In this case device to PC transfer setup is _harder_. simply because you need to run sdpd _and_ service daemon (such as obexapp). so you need to understand how service daemons interact with sdpd etc. as far as user-friendly applications, you can install comms/obexapp from ports. just to send file from pc to device (with obex push) is _very_ simple. you do not need to setup anything. getting files from device (with obex file transfer) is slightly harder because most devices require authentication, so you need to setup pin code with hcsecd and have it running. obexapp (and other things) are made as ports because of gpl. > he will need both hcsecd and sdpd, right? It is also the default > behavior in Windows and in Linux KDE, I think. You get all the necessary > services running before starting a connection. I am also considering > porting gnome-bluetooth for the same reason. once again, kde, gnome-bluetooth etc. are gpl. so they will have to go to ports/. > I understand that your approach with sdpd_enable and hcsecd_enable is > more fine-grained, but I wonder if we could combine it with hassle-free > operation for the common case. I agree with all the rest that you > mention about the address binding. i'm afraid, i have to object to start/stop'ing hcsecd and sdpd from bluetooth rc.d script. it just not right, imo. what if i have more then one bluetooth device connected? the moment i pull one of them off hcsecd and sdpd will be killed. not good. to summarize: 1) hcsecd and sdpd should be considered as "special" daemons. average bluetooth user should have them both running at all times. 2) to make hcsecd less painful for users it has to be enhanced, i.e. it should support helper application for pin codes, i.e. instead of specifying pin code, user specifies a program to be called to obtain pin code. default entry in hcsecd.conf then will be changed to call external program to obtain pin code. something like xdialog. 3) bluetooth rc.d script should only setup devices. it also should have some sort of extension to start/stop service daemons bound to the particular device, however it should not touch hcsecd and sdpd. thanks, max From owner-freebsd-bluetooth@FreeBSD.ORG Thu Oct 20 17:55:16 2005 Return-Path: X-Original-To: freebsd-bluetooth@freebsd.org Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1B2B316A420 for ; Thu, 20 Oct 2005 17:55:15 +0000 (GMT) (envelope-from past@ebs.gr) Received: from fly.ebs.gr (fly.ebs.gr [62.103.84.177]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5D2C643D69 for ; Thu, 20 Oct 2005 17:55:08 +0000 (GMT) (envelope-from past@ebs.gr) Received: from ebs.gr (root@hal.ebs.gr [10.1.1.2]) by fly.ebs.gr (8.12.9p1/8.12.9) with ESMTP id j9KHt59V051716; Thu, 20 Oct 2005 20:55:05 +0300 (EEST) (envelope-from past@ebs.gr) Received: from [10.1.1.200] (pptp.ebs.gr [10.1.1.200]) by ebs.gr (8.13.3/8.12.11) with ESMTP id j9KHtHt4013256; Thu, 20 Oct 2005 20:55:18 +0300 (EEST) (envelope-from past@ebs.gr) Message-ID: <4357D9E2.6010701@ebs.gr> Date: Thu, 20 Oct 2005 20:54:42 +0300 From: Panagiotis Astithas Organization: EBS Ltd. User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051008) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Maksim Yevmenkin References: <43519460.1090605@ebs.gr> <1129491219.1616.18.camel@localhost> <4353DBBC.2000508@savvis.net> <43541F79.6040008@ebs.gr> <43554BCE.7090309@savvis.net> <4355FD0C.2090702@ebs.gr> <4356D12F.7000006@savvis.net> <43576A9D.1050209@ebs.gr> <4357CEA5.1000308@savvis.net> In-Reply-To: <4357CEA5.1000308@savvis.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-bluetooth@freebsd.org Subject: Re: [RFC] rc.d integration for the bluetooth subsystem 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: Thu, 20 Oct 2005 17:55:16 -0000 Maksim Yevmenkin wrote: >>> 2) what is the reason for calling "/etc/rc.d/{hcsecd,sdpd} >>> {start,stop}" from "bluetooth_start()/bluetooth_stop()"? shouldn't >>> these be controlled by their own xxx_enable variables? for example >>> you do not need sdpd(8) running unless you want to provide services >>> to the remote clients. also both sdpd(8) and hcsecd(8) bind to "any" >>> bd_addr, so there is no reason to restart them even if particular >>> device comes and goes. what is important here is to kill daemons >>> (providing services, such as rfcomm_pppd(8)) if they were bound (i.e. >>> listening) to the device that went away. however this is a corner >>> case. usually service daemons listen on "any" address and thus there >>> is no need to restart them. >> >> >> I opted for simplicity and ease of use. I think users don't comprehend >> the interactions between sdpd, hcsecd, the bluetooth stack, etc. most >> of the time. The typical use case I have in mind is a user who plugs >> in his bluetooth dongle to send or receive files. Since we don't have any > > > if one does not understand interaction between hcsecd/sdpd/etc. then > perhaps better documentation must be written? if one refuses do read > documentation then i'd just say, have "sdpd_enable" and "hcsecd_enable" > set because they required. there is harm in having them both running all > the time. > >> user-friendly applications in the base system, I think a user would >> prefer to initiate a device-to-PC transfer from the device. In this case > > > device to PC transfer setup is _harder_. simply because you need to run > sdpd _and_ service daemon (such as obexapp). so you need to understand > how service daemons interact with sdpd etc. as far as user-friendly > applications, you can install comms/obexapp from ports. just to send > file from pc to device (with obex push) is _very_ simple. you do not > need to setup anything. getting files from device (with obex file > transfer) is slightly harder because most devices require > authentication, so you need to setup pin code with hcsecd and have it > running. > > obexapp (and other things) are made as ports because of gpl. > >> he will need both hcsecd and sdpd, right? It is also the default >> behavior in Windows and in Linux KDE, I think. You get all the >> necessary services running before starting a connection. I am also >> considering porting gnome-bluetooth for the same reason. > > > once again, kde, gnome-bluetooth etc. are gpl. so they will have to go > to ports/. > >> I understand that your approach with sdpd_enable and hcsecd_enable is >> more fine-grained, but I wonder if we could combine it with >> hassle-free operation for the common case. I agree with all the rest >> that you mention about the address binding. > > > i'm afraid, i have to object to start/stop'ing hcsecd and sdpd from > bluetooth rc.d script. it just not right, imo. what if i have more then > one bluetooth device connected? the moment i pull one of them off hcsecd > and sdpd will be killed. not good. > > to summarize: > > 1) hcsecd and sdpd should be considered as "special" daemons. average > bluetooth user should have them both running at all times. > > 2) to make hcsecd less painful for users it has to be enhanced, i.e. it > should support helper application for pin codes, i.e. instead of > specifying pin code, user specifies a program to be called to obtain pin > code. default entry in hcsecd.conf then will be changed to call external > program to obtain pin code. something like xdialog. > > 3) bluetooth rc.d script should only setup devices. it also should have > some sort of extension to start/stop service daemons bound to the > particular device, however it should not touch hcsecd and sdpd. I understand all of the above and have no problem whatsoever. I'll wait for you to commit things the way you feel they should be implemented and then I'll try to come up with suggestions for improvement if I can find any. Cheers, Panagiotis