From owner-freebsd-bluetooth@FreeBSD.ORG Sun Dec 4 07:39:38 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 D81D016A41F for ; Sun, 4 Dec 2005 07:39:38 +0000 (GMT) (envelope-from marcel@holtmann.org) Received: from mail.holtmann.net (coyote.holtmann.net [217.160.111.169]) by mx1.FreeBSD.org (Postfix) with ESMTP id F0F6A43D62 for ; Sun, 4 Dec 2005 07:39:37 +0000 (GMT) (envelope-from marcel@holtmann.org) Received: from blade (p5487EA2A.dip.t-dialin.net [84.135.234.42]) by mail.holtmann.net (8.13.4/8.13.4/Debian-3) with ESMTP id jB47dob9017891 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sun, 4 Dec 2005 08:39:51 +0100 From: Marcel Holtmann To: "P. Durante" In-Reply-To: <9307f5f20512031333x61e9d141u85ea578711740712@mail.gmail.com> References: <9307f5f20512030807x6eadc73cq9d9acc9dd5503a5b@mail.gmail.com> <4391E320.2090006@savvis.net> <9307f5f20512031333x61e9d141u85ea578711740712@mail.gmail.com> Content-Type: text/plain; charset=utf-8 Date: Sun, 04 Dec 2005 08:39:58 +0100 Message-Id: <1133681998.4427.7.camel@blade> Mime-Version: 1.0 X-Mailer: Evolution 2.5.2 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=1.2 required=5.0 tests=BAYES_00, DATE_IN_FUTURE_12_24 autolearn=no version=3.0.3 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on coyote.holtmann.net X-Virus-Scanned: ClamAV 0.84/1202/Sun Dec 4 04:41:04 2005 on coyote.holtmann.net X-Virus-Status: Clean Cc: freebsd-bluetooth@freebsd.org Subject: Re: Automatic bluetooth device initialization 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: Sun, 04 Dec 2005 07:39:39 -0000 Hi Paul, > To solve such (not uncommon) problems, the dbus system[¹] is being > developed, dbus is getting very popular (maybe too much) and it > provides a simple and secure messaging system to let different > programs talk to one another, in our example, let one program be the > bluetooth daemon, it provides a well-known interface and hides > platform-specific implementation details, on the other side we have > the other programs, which are just frontends (with a Qt/Gtk/textual > interface, it doesn't matter) and can run on every operating system > where the aforementioned interface is available, I think something > like this wouldn't hurt to any "desktop-unix" operating system. start looking at the D-Bus effort of BlueZ. We are moving into that direction and one of the main goals is to not even abstract from the operating system details, we also wanna abstract from the HCI specific details of Bluetooth. Feel free to join-in and help defining the new D-Bus interface for Bluetooth. Regards Marcel From owner-freebsd-bluetooth@FreeBSD.ORG Sun Dec 4 22:36:36 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 B344716A459 for ; Sun, 4 Dec 2005 22:36:36 +0000 (GMT) (envelope-from maksim.yevmenkin@savvis.net) Received: from mta10.adelphia.net (mta10.adelphia.net [68.168.78.202]) by mx1.FreeBSD.org (Postfix) with ESMTP id D3CCA43D55 for ; Sun, 4 Dec 2005 22:36:35 +0000 (GMT) (envelope-from maksim.yevmenkin@savvis.net) Received: from [192.168.1.254] (really [70.32.199.60]) by mta10.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with ESMTP id <20051204223634.HFHO1186.mta10.adelphia.net@[192.168.1.254]>; Sun, 4 Dec 2005 17:36:34 -0500 Message-ID: <43936F6B.1090003@savvis.net> Date: Sun, 04 Dec 2005 14:36:27 -0800 From: Maksim Yevmenkin User-Agent: Mozilla Thunderbird 0.7.1 (Windows/20040626) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "P. Durante" References: <9307f5f20512030807x6eadc73cq9d9acc9dd5503a5b@mail.gmail.com> <4391E320.2090006@savvis.net> <9307f5f20512031333x61e9d141u85ea578711740712@mail.gmail.com> In-Reply-To: <9307f5f20512031333x61e9d141u85ea578711740712@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-bluetooth@freebsd.org Subject: Re: Automatic bluetooth device initialization 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: Sun, 04 Dec 2005 22:36:37 -0000 Paul, >> fine. if you could please tell us a little bit more and explain >> what is wrong with the current way of doing things in linux and/or >> freebsd. > > don't get me wrong, there isn't anything wrong with the current state > of bluetooth configuration utilities. If you've spent some time > reading the freebsd handbook or some unofficial bluez tutorials and > you're accustomed to the command line (like most of the people on > this list, I assume) then you're just set.. ..but if you take into > account the regular desktop user (like how linux and freebsd are > trying to do right now) you see the need for something more intuitive > and immediate than the 'current way of doing things', this basically > involves some sort of user interface, at the very least. Even on this i though we are talking about bluetooth device _initialization_. right now, in freebsd, user does not have to do anything except loading the drivers and plugging the device. all configuration parameters are in one file and documented. adjusting configuration for bluetooth devices in freebsd is not that much different from putting stuff into /etc/rc.conf etc. i agree with you, there is no gnome/kde/whatever gui applet that knows about bluetooth in freebsd. i also admit that there are no gui based bluetooth tools in freebsd. however, this, in my opinion, has nothing to do with bluetooth devices initialization. > mailing list, little time ago, there was a request about porting the > excellent kde bluetooth framework to freebsd, but, as you noted, in > it's current form kdebluetooth has very deep roots in bluez, and it > also has deep roots in KDE, so even adapting to another desktop > manager would be difficult. To solve such (not uncommon) problems, > the dbus system[¹] is being developed, dbus is getting very popular > (maybe too much) and it provides a simple and secure messaging system > to let different programs talk to one another, in our example, let > one program be the bluetooth daemon, it provides a well-known > interface and hides platform-specific implementation details, on the > other side we have the other programs, which are just frontends (with > a Qt/Gtk/textual interface, it doesn't matter) and can run on every > operating system where the aforementioned interface is available, I > think something like this wouldn't hurt to any "desktop-unix" > operating system. while i appreciate your effort in this area, i'm skeptical that d-bus and/or whatever api will solve this problem. i think, instead of introducing yet another compatibility layer that sits on top of native api, everyone would be much better off if native api was the same. what would solve this problem, imo, is the standard (something like posix) that would define api etc. in the very beginning, i asked linux bluez folks if they are willing to release their user space code under dual (gpl/bsd) license. someone immediately shoot me down with the statement that bluez code is gpl and it will remain so forever. i admit, it was a very weak attempt and i did not push it any further. instead, i choose to write my own code under bsd license so it can be included into freebsd. i took a very quick look at kde-bluetooth sources and i could not find anything that would suggest that kde-bluetooth is trying to work on non linux-bluez systems. it seems like all that needs to be done is to teach libkbluetooth about other non linux-bluez systems. thanks, max From owner-freebsd-bluetooth@FreeBSD.ORG Mon Dec 5 10:14:42 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 307AB16A41F for ; Mon, 5 Dec 2005 10:14:42 +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 8EEDA43D66 for ; Mon, 5 Dec 2005 10:14:39 +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 jB5AEbZm070025; Mon, 5 Dec 2005 12:14:37 +0200 (EET) (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 jB5AEuFM049847; Mon, 5 Dec 2005 12:14:56 +0200 (EET) (envelope-from past@ebs.gr) Message-ID: <43941309.4090202@ebs.gr> Date: Mon, 05 Dec 2005 12:14:33 +0200 From: Panagiotis Astithas Organization: EBS Ltd. User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051106) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Maksim Yevmenkin References: <9307f5f20512030807x6eadc73cq9d9acc9dd5503a5b@mail.gmail.com> <4391E320.2090006@savvis.net> <9307f5f20512031333x61e9d141u85ea578711740712@mail.gmail.com> <43936F6B.1090003@savvis.net> In-Reply-To: <43936F6B.1090003@savvis.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-bluetooth@freebsd.org Subject: Re: Automatic bluetooth device initialization 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, 05 Dec 2005 10:14:42 -0000 Maksim Yevmenkin wrote: > Paul, > >>> fine. if you could please tell us a little bit more and explain >>> what is wrong with the current way of doing things in linux and/or >>> freebsd. >> >> >> don't get me wrong, there isn't anything wrong with the current state >> of bluetooth configuration utilities. If you've spent some time >> reading the freebsd handbook or some unofficial bluez tutorials and >> you're accustomed to the command line (like most of the people on >> this list, I assume) then you're just set.. ..but if you take into >> account the regular desktop user (like how linux and freebsd are >> trying to do right now) you see the need for something more intuitive >> and immediate than the 'current way of doing things', this basically >> involves some sort of user interface, at the very least. Even on this > > > i though we are talking about bluetooth device _initialization_. right > now, in freebsd, user does not have to do anything except loading the > drivers and plugging the device. all configuration parameters are in one > file and documented. adjusting configuration for bluetooth devices in > freebsd is not that much different from putting stuff into /etc/rc.conf > etc. > > i agree with you, there is no gnome/kde/whatever gui applet that knows > about bluetooth in freebsd. i also admit that there are no gui based > bluetooth tools in freebsd. however, this, in my opinion, has nothing to > do with bluetooth devices initialization. > >> mailing list, little time ago, there was a request about porting the >> excellent kde bluetooth framework to freebsd, but, as you noted, in >> it's current form kdebluetooth has very deep roots in bluez, and it >> also has deep roots in KDE, so even adapting to another desktop >> manager would be difficult. To solve such (not uncommon) problems, >> the dbus system[¹] is being developed, dbus is getting very popular >> (maybe too much) and it provides a simple and secure messaging system >> to let different programs talk to one another, in our example, let >> one program be the bluetooth daemon, it provides a well-known >> interface and hides platform-specific implementation details, on the >> other side we have the other programs, which are just frontends (with >> a Qt/Gtk/textual interface, it doesn't matter) and can run on every >> operating system where the aforementioned interface is available, I >> think something like this wouldn't hurt to any "desktop-unix" >> operating system. > > > while i appreciate your effort in this area, i'm skeptical that d-bus > and/or whatever api will solve this problem. i think, instead of > introducing yet another compatibility layer that sits on top of native > api, everyone would be much better off if native api was the same. what > would solve this problem, imo, is the standard (something like posix) > that would define api etc. > > in the very beginning, i asked linux bluez folks if they are willing to > release their user space code under dual (gpl/bsd) license. someone > immediately shoot me down with the statement that bluez code is gpl and > it will remain so forever. i admit, it was a very weak attempt and i did > not push it any further. instead, i choose to write my own code under > bsd license so it can be included into freebsd. > > i took a very quick look at kde-bluetooth sources and i could not find > anything that would suggest that kde-bluetooth is trying to work on non > linux-bluez systems. it seems like all that needs to be done is to teach > libkbluetooth about other non linux-bluez systems. The same holds for libbtctl of gnome-bluetooth. I wouldn't dismiss an effort to standardize on a dbus API, though. I can see quite a few advantages in such an approach: - dbus is already ported to FreeBSD and many other systems - porting kde-bluetooth or gnome-bluetooth would essentially require a new (albeit slim) portability layer in order to minimize synchronization effort with the upstream sources - the bluetooh subsystem speed requirements are not very high, as to prohibit a (hopefully efficient) portability layer - it seems much more feasible to target the compatibility on a dbus API than to reach consensus on a posix-like API Nevertheless, if you are confident that we can achieve standardization in a lower level, I'm definitely all for it. Regards, Panagiotis From owner-freebsd-bluetooth@FreeBSD.ORG Mon Dec 5 16:40:26 2005 Return-Path: X-Original-To: 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 10C4416A424 for ; Mon, 5 Dec 2005 16:40:26 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from mh2.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 57D9B43D58 for ; Mon, 5 Dec 2005 16:40:04 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from [10.177.171.220] (neutrino.centtech.com [10.177.171.220]) by mh2.centtech.com (8.13.1/8.13.1) with ESMTP id jB5Ge1X7058547; Mon, 5 Dec 2005 10:40:01 -0600 (CST) (envelope-from anderson@centtech.com) Message-ID: <43946D44.2070907@centtech.com> Date: Mon, 05 Dec 2005 10:39:32 -0600 From: Eric Anderson User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051204) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Maksim Yevmenkin References: <437B2E58.50709@centtech.com> <437B52FF.9040407@savvis.net> <437B5CE2.5000601@centtech.com> <437B93CF.4000403@savvis.net> <437BA490.1010704@centtech.com> <437BAF32.5030502@savvis.net> <437C8547.3060708@centtech.com> <437CC544.6080509@savvis.net> <437D32F7.10706@centtech.com> <437DCBF8.1080000@centtech.com> <437E129A.9000204@savvis.net> In-Reply-To: <437E129A.9000204@savvis.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.82/1204/Mon Dec 5 04:09:54 2005 on mh2.centtech.com X-Virus-Status: Clean Cc: bluetooth Subject: Re: No route to host for bluetooth devices 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, 05 Dec 2005 16:40:26 -0000 Maksim Yevmenkin wrote: > Eric, > >>>>> Well, here's more information. First, it's reproducable every >>>>> time I boot up. Doing: >>>>> /etc/rc.d/bluetooth start ubt0 >>>>> does not fix it by itself, but doing: >>>>> /etc/rc.d/bluetooth stop ubt0 >>>>> /etc/rc.d/bluetooth start ubt0 >>>>> does. >>>> >>>> >>>> now, i really puzzled. because device fails on to start at boot >>>> time, /etc/rc.d/bluetooth should have backed out and removed all >>>> netgraph nodes it tried to create (except device node and socket >>>> nodes). so i do not understand why do you need to do 'stop' before >>>> 'start'. 'stop' should really be a noop in this case. >>>> >>>> could you please do the following >>>> >>>> 1) do a fresh boot with bluetooth device turned on >>>> >>>> 2) after system boots (and bluetooth device failed to start) please >>>> run as root >>>> >>>> # ngctl li >>> >>> >>> There are 7 total nodes: >>> Name: ngctl992 Type: socket ID: 0000001d Num >>> hooks: 0 >>> Name: ubt0l2cap Type: l2cap ID: 00000017 Num >>> hooks: 3 >>> Name: ubt0hci Type: hci ID: 00000013 Num >>> hooks: 3 >>> Name: btsock_l2c Type: btsock_l2c ID: 00000004 Num >>> hooks: 1 >>> Name: btsock_l2c_raw Type: btsock_l2c_raw ID: 00000003 Num >>> hooks: 1 >>> Name: btsock_hci_raw Type: btsock_hci_raw ID: 00000002 Num >>> hooks: 1 >>> Name: ubt0 Type: ubt ID: 00000001 Num >>> hooks: 1 >> > > hmm... that does not make much sense to me. somehow you still have all > nodes connected even if bluetooth device failed to initialize! that > explains why do you need 'stop' command before 'start'. > > just a crazy idea. please double that you are not initializing device > twice, i.e. you use new rc.d scripts and some leftovers from old > system. or may be you have devd(8) configuration in both /etc in > /usr/local/etc? > >>>>> I also tried a fresh boot, then switching the bluetooth off, >>>>> waiting about 20 seconds, and flipping it back on, which *did* in >>>>> fact work. I may not have waited long enough the previous time >>>>> that failed. >>>> >>>> >>>> ah, ok. could you please check the /var/log/messages file to see if >>>> you get a message saying ubt0 is detached/attached? >>> >>> >>> Here's the snippet upon boot: >>> >>> Nov 17 19:31:32 neutrino kernel: ubt0: ALPS UGX, rev 1.10/11.68, addr 3 >>> Nov 17 19:31:32 neutrino kernel: ubt0: ALPS UGX, rev 1.10/11.68, addr 3 >>> Nov 17 19:31:32 neutrino kernel: ubt0: Interface 0 endpoints: >>> interrupt=0x81, bulk-in=0x82, bulk-out=0x2 >>> Nov 17 19:31:32 neutrino kernel: ubt0: Interface 1 (alt.config 5) >>> endpoints: isoc-in=0x83, isoc-out=0x3; wMaxPacketSize=49; nframes=6, >>> buffer size=294 >> > > [...] > >>> Nov 17 19:31:41 neutrino kernel: ng_hci_process_command_timeout: >>> ubt0hci - unable to complete HCI command OGF=0x3, OCF=0x3. Timeout >> > > device failed to initialize and rc.d/bluetooth should have cleaned the > nodes, but it did not happen > >>> Nov 17 19:31:45 neutrino sdpd[659]: Could not bind control socket. >>> Permission denied (13) >> > > hmm... this is bad too. can you double check if you have sdpd running? > >>> now I'll run the bluetooth stop, which produces no output. >>> >>> ngctl li now looks like: >>> There are 5 total nodes: >>> Name: ngctl1015 Type: socket ID: 00000020 Num >>> hooks: 0 >>> Name: btsock_l2c Type: btsock_l2c ID: 00000004 Num >>> hooks: 0 >>> Name: btsock_l2c_raw Type: btsock_l2c_raw ID: 00000003 Num >>> hooks: 0 >>> Name: btsock_hci_raw Type: btsock_hci_raw ID: 00000002 Num >>> hooks: 0 >>> Name: ubt0 Type: ubt ID: 00000001 Num >>> hooks: 0 >> > > that is fine. that is what the output should look like when device is > failed to initialize. > >>> Now I ran bluetooth start, which produces no output, and nothing in >>> /var/log/messages. >>> >>> ngctl li now looks like this: >>> There are 7 total nodes: >>> Name: ngctl1045 Type: socket ID: 0000002c Num >>> hooks: 0 >>> Name: ubt0l2cap Type: l2cap ID: 00000026 Num >>> hooks: 3 >>> Name: ubt0hci Type: hci ID: 00000022 Num >>> hooks: 3 >>> Name: btsock_l2c Type: btsock_l2c ID: 00000004 Num >>> hooks: 1 >>> Name: btsock_l2c_raw Type: btsock_l2c_raw ID: 00000003 Num >>> hooks: 1 >>> Name: btsock_hci_raw Type: btsock_hci_raw ID: 00000002 Num >>> hooks: 1 >>> Name: ubt0 Type: ubt ID: 00000001 Num >>> hooks: 1 >> > > and that is fine too - this is what output should look like when all > nodes are properly connected. > >>> Now I wiggle my mouse, and I see this in /var/log/messages: >>> Nov 17 19:47:58 neutrino bthidd[603]: Accepted control connection >>> from 00:07:61:31:27:15 >>> Nov 17 19:47:58 neutrino bthidd[603]: Accepted interrupt connection >>> from 00:07:61:31:27:15 >>> >>> and my mouse now works. >>> >>>>> Oddly enough, I never had a problem before now. I previously >>>>> started the bluetooth stuff from rc.local. The only things I have >>>>> changed are: updated to latest -current, removed inet6 from >>>>> kernel, rebuilt world/kernel, switched to new rc.d bluetooth >>>>> scripts. I can try anything you like. >>>> >>>> >>>> one thing you could try to do is to comment out ubt0 section in >>>> /etc/devd.conf and go back to old style rc.bluetooth script to see >>>> if you have the same problem. if you do - then its not bluetooth >>>> related, if you dont - then its related to new bluetooth rc.d scripts. >>> >>> >>> I can do that if you'd like.. >> > > yes please, if you can. > >> Something else I just tried: booted up, no mouse as usual. Ran >> /etc/rc.d/bluetooth start ubt0, and got this error: >> >> # /etc/rc.d/bluetooth start ubt0 >> /etc/rc.d/bluetooth: ERROR: Unable to setup Bluetooth stack for >> device ubt0 >> >> and mouse still does not work.. >> >> Then, ran it again: >> # /etc/rc.d/bluetooth start ubt0 >> >> no error, and voila! my mouse works. Didn't run the 'stop' part at >> all, just the 'start' twice. > > > again the explanation for this is: after the boot device failed to > initialize, but for whatever reason, all nodes are still connected. > when you do the 'start' command it tries to connect nodes, but it > fails because nodes are already connected. because it fails - it tries > to clean up after itself and removes all the nodes. thus resetting > back to defaults. the next 'start' runs fine, because now everything > as it should be. > > we need to figure out why nodes are still connected after your device > failed on boot. > > thanks, > max After upgrading to the latest current, this problem is gone. Go figure. Maybe I caught it somewhere in between, I have no idea. Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology Anything that works is better than anything that doesn't. ------------------------------------------------------------------------ From owner-freebsd-bluetooth@FreeBSD.ORG Mon Dec 5 20:34:03 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 E673E16A41F for ; Mon, 5 Dec 2005 20:34:03 +0000 (GMT) (envelope-from Gabor@Zahemszky.HU) Received: from akac.mail.t-online.hu (akac.mail.t-online.hu [195.228.240.96]) by mx1.FreeBSD.org (Postfix) with ESMTP id CB82843DC5 for ; Mon, 5 Dec 2005 20:33:38 +0000 (GMT) (envelope-from Gabor@Zahemszky.HU) Received: from [192.168.1.3] (dsl51B645A4.pool.t-online.hu [81.182.69.164]) by akac.mail.t-online.hu (8.13.4/8.12.11) with ESMTP id jB5KXXDT026385 for ; Mon, 5 Dec 2005 21:33:34 +0100 (CET) Message-ID: <4394A53E.1050109@Zahemszky.HU> Date: Mon, 05 Dec 2005 21:38:22 +0100 From: =?ISO-8859-2?Q?Zahemszky_G=E1bor?= User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051203) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-bluetooth@freebsd.org Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit X-vbmsrv: scanned Subject: Local browsing: permission denied 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, 05 Dec 2005 20:34:04 -0000 Hi! I'm using 6-stable, with the new bluetooth-rc system. It works fine, but with sdpcontrol, I have a little problem. If I try it as a regular user: $ sdpcontrol -l browse Could not execute command "browse". Permission denied $ sdpcontrol -a my-t610 browse # BT if off on my tel. Could not execute command "browse". Host is down $ sdpcontrol -a zahygabi-t610 browse # BT is on Record Handle: 0x00010000 blabla .... So why I can't browse local servers? Bye: Gabor Zahy < Gabor at Zahemszky dot HU > PS: and search doesn't work, either -- #!/bin/ksh Z='21N16I25C25E30, 40M30E33E25T15U!';IFS=' ABCDEFGHIJKLMNOPQRSTUVWXYZ ';set -- $Z;for i;{ [[ $i = ? ]]&&print $i&&break;[[ $i = ??? ]]&&j=$i&&i=${i%?};typeset -i40 i=8#$i;print -n ${i#???};[[ "$j" = ??? ]]&&print -n "${j#??} "&&j=;typeset +i i;};IFS=' 0123456789 ';set -- $Z;for i;{ [[ $i = , ]]&&i=2;[[ $i = ?? ]]||typeset -l i;j="$j $i";typeset +l i;};print "$j" From owner-freebsd-bluetooth@FreeBSD.ORG Mon Dec 5 21:24:59 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 5AF8C16A42C for ; Mon, 5 Dec 2005 21:24:59 +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 0604443DA5 for ; Mon, 5 Dec 2005 21:24:43 +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 jB5LOQJ15123; Mon, 5 Dec 2005 16:24:26 -0500 Message-ID: <4394B006.2050808@savvis.net> Date: Mon, 05 Dec 2005 13:24:22 -0800 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: <9307f5f20512030807x6eadc73cq9d9acc9dd5503a5b@mail.gmail.com> <4391E320.2090006@savvis.net> <9307f5f20512031333x61e9d141u85ea578711740712@mail.gmail.com> <43936F6B.1090003@savvis.net> <43941309.4090202@ebs.gr> In-Reply-To: <43941309.4090202@ebs.gr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-bluetooth@freebsd.org Subject: Re: Automatic bluetooth device initialization 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, 05 Dec 2005 21:24:59 -0000 [...] >> while i appreciate your effort in this area, i'm skeptical that d-bus >> and/or whatever api will solve this problem. i think, instead of >> introducing yet another compatibility layer that sits on top of native >> api, everyone would be much better off if native api was the same. >> what would solve this problem, imo, is the standard (something like >> posix) that would define api etc. >> >> in the very beginning, i asked linux bluez folks if they are willing >> to release their user space code under dual (gpl/bsd) license. someone >> immediately shoot me down with the statement that bluez code is gpl >> and it will remain so forever. i admit, it was a very weak attempt and >> i did not push it any further. instead, i choose to write my own code >> under bsd license so it can be included into freebsd. >> >> i took a very quick look at kde-bluetooth sources and i could not find >> anything that would suggest that kde-bluetooth is trying to work on >> non linux-bluez systems. it seems like all that needs to be done is to >> teach libkbluetooth about other non linux-bluez systems. > > The same holds for libbtctl of gnome-bluetooth. > > I wouldn't dismiss an effort to standardize on a dbus API, though. I can > see quite a few advantages in such an approach: > > - dbus is already ported to FreeBSD and many other systems so what? how about other things like sysv message queues, fifo's, unix sockets, and, what the hell, solaris doors. i'm sure other folks can also name a few. those can be used just as easily to implement any message passing protocol. > - porting kde-bluetooth or gnome-bluetooth would essentially require a > new (albeit slim) portability layer in order to minimize synchronization > effort with the upstream sources have you even looked at what it takes to port libkbluetooth onto freebsd? it seems that majority of the work can be done in one afternoon. all you need is to change headers, some structure names, constants and things like this. i bet all it takes is a couple of .h files with lots of #ifdef's. another few days is to hook up this to gnu autoconf. i have ported few tools from bluez to freebsd. its not hard at all. for example, hcidump from ports _is_ ported from bluez. i'm 100% sure adding dbus or whatever layer is much _more_ work. the main problem here, imo, is to get kde-bluetooth folks (and others gnu developers) to recognize the fact that there are other systems besides linux. for example, gammu/gnoki port is quite capable to use bluetooth on freebsd. my point is that just because dbus exists it does not mean everybody have to use it for everything. i'm sure there are projects where it can be quite useful, but, i think, in this case its too much work for too little gain. kde/gnome already have enough bloat, and, quite frankly, i do not understand why would someone want more bloat. personally, i can not run kde/gnome on my laptop, because otherwise i can not do anything else. > - the bluetooh subsystem speed requirements are not very high, as to > prohibit a (hopefully efficient) portability layer still does not mean you have to add the overhead. > - it seems much more feasible to target the compatibility on a dbus API > than to reach consensus on a posix-like API i doubt it. whatever api is being invented right now is being invented on/for linux/bluez. in fact, i'm quite surprised (in a good way) that Paul sent this email and told us about his work. i really appreciate his effort in this area. i'm just suggesting that, perhaps, dbus does not suite very well in this case. and, perhaps, simple set of user-space wrapper libraries released under both gnu and bsd license is all that is needed here. thanks, max From owner-freebsd-bluetooth@FreeBSD.ORG Mon Dec 5 21:33: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 7D8B216A42A for ; Mon, 5 Dec 2005 21:33:22 +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 AC1CC43D75 for ; Mon, 5 Dec 2005 21:33:16 +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 jB5LX6J15336; Mon, 5 Dec 2005 16:33:07 -0500 Message-ID: <4394B211.1080503@savvis.net> Date: Mon, 05 Dec 2005 13:33:05 -0800 From: Maksim Yevmenkin User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050404) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Zahemszky_G=E1bor?= References: <4394A53E.1050109@Zahemszky.HU> In-Reply-To: <4394A53E.1050109@Zahemszky.HU> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-bluetooth@freebsd.org Subject: Re: Local browsing: permission denied 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, 05 Dec 2005 21:33:23 -0000 Hello, > I'm using 6-stable, with the new bluetooth-rc system. It works fine, but > with sdpcontrol, I have a little problem. If I try it as a regular user: > > $ sdpcontrol -l browse > Could not execute command "browse". Permission denied '-l' means query services registered with _local_ sdpd(8) daemon. it means query will go via control socket. here is the quote from sdpd(8) man page === CAVEAT ... Access rights on the control socket define which application can regis- ter, remove or change the service. The application must be able to write to and read from the control socket in order to perform any query to the Service Database via control socket. === so you need to run "sdpcontrol -l browse" as root. > $ sdpcontrol -a my-t610 browse # BT if off on my tel. > Could not execute command "browse". Host is down this is normal. you have turned off bluetooth on the phone. > $ sdpcontrol -a zahygabi-t610 browse # BT is on > > Record Handle: 0x00010000 > blabla .... this is normal too. > So why I can't browse local servers? because sdpcontrol(8) does not have enough permissions to write to the control socket. yes, i agree, its not very convenient for user. i'm currently thinking about better way to handle this type of queries. thanks, max From owner-freebsd-bluetooth@FreeBSD.ORG Mon Dec 5 21:44:00 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 1169916A41F for ; Mon, 5 Dec 2005 21:44:00 +0000 (GMT) (envelope-from marcel@holtmann.org) Received: from mail.holtmann.net (coyote.holtmann.net [217.160.111.169]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4AC0543D5C for ; Mon, 5 Dec 2005 21:43:58 +0000 (GMT) (envelope-from marcel@holtmann.org) Received: from localhost.localdomain (localhost [127.0.0.1]) by mail.holtmann.net (8.13.4/8.13.4/Debian-3) with ESMTP id jB5LiGsF015161 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 5 Dec 2005 22:44:16 +0100 From: Marcel Holtmann To: Maksim Yevmenkin In-Reply-To: <43936F6B.1090003@savvis.net> References: <9307f5f20512030807x6eadc73cq9d9acc9dd5503a5b@mail.gmail.com> <4391E320.2090006@savvis.net> <9307f5f20512031333x61e9d141u85ea578711740712@mail.gmail.com> <43936F6B.1090003@savvis.net> Content-Type: text/plain Date: Mon, 05 Dec 2005 22:44:57 +0100 Message-Id: <1133819097.4559.15.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.5.2 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DATE_IN_FUTURE_48_96 autolearn=failed version=3.0.3 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on coyote.holtmann.net X-Virus-Scanned: ClamAV 0.84/1204/Mon Dec 5 11:09:54 2005 on coyote.holtmann.net X-Virus-Status: Clean Cc: freebsd-bluetooth@freebsd.org Subject: Re: Automatic bluetooth device initialization 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, 05 Dec 2005 21:44:00 -0000 Hi Maksim, > while i appreciate your effort in this area, i'm skeptical that d-bus > and/or whatever api will solve this problem. i think, instead of > introducing yet another compatibility layer that sits on top of native > api, everyone would be much better off if native api was the same. what > would solve this problem, imo, is the standard (something like posix) > that would define api etc. I don't really like D-Bus, but it will be the way to go for a general API for the desktop. It has multiple language bindings already and our goal is to make it totally generic (no BlueZ specific definitions). Regards Marcel From owner-freebsd-bluetooth@FreeBSD.ORG Mon Dec 5 23:00:30 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 A13CB16A41F for ; Mon, 5 Dec 2005 23:00:30 +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 B99B343D62 for ; Mon, 5 Dec 2005 23:00: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 jB5N0PJ17542; Mon, 5 Dec 2005 18:00:26 -0500 Message-ID: <4394C687.9060108@savvis.net> Date: Mon, 05 Dec 2005 15:00:23 -0800 From: Maksim Yevmenkin User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050404) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-bluetooth@freebsd.org References: <4394A53E.1050109@Zahemszky.HU> <4394B211.1080503@savvis.net> In-Reply-To: <4394B211.1080503@savvis.net> Content-Type: multipart/mixed; boundary="------------060006020806080006030503" Cc: =?ISO-8859-1?Q?Zahemszky_G=E1bor?= Subject: Re: [PATCH] Local browsing: permission denied 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, 05 Dec 2005 23:00:30 -0000 This is a multi-part message in MIME format. --------------060006020806080006030503 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hello, please try the attached patch for sdpd(8) daemon. with this patch sdpd(8) will 1) change permission on the control socket, 2) check peer's credential 3) accept register/remove/change service requests only if peer has effective user id the same as 'root' user id it should be now possible to run 'sdpcontrol -l' as regular user. thanks, max --------------060006020806080006030503 Content-Type: text/plain; name="sdpd.diff.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="sdpd.diff.txt" Index: scr.c =================================================================== RCS file: /usr/local/cvs/usr.sbin/bluetooth/sdpd/scr.c,v retrieving revision 1.2 diff -u -r1.2 scr.c --- scr.c 23 Aug 2004 18:42:21 -0000 1.2 +++ scr.c 5 Dec 2005 22:46:47 -0000 @@ -58,7 +58,8 @@ * value32 - handle 4 bytes */ - if (!srv->fdidx[fd].control || req_end - req < 4) + if (!srv->fdidx[fd].control || + !srv->fdidx[fd].priv || req_end - req < 4) return (SDP_ERROR_CODE_INVALID_REQUEST_SYNTAX); /* Get handle */ Index: server.c =================================================================== RCS file: /usr/local/cvs/usr.sbin/bluetooth/sdpd/server.c,v retrieving revision 1.7 diff -u -r1.7 server.c --- server.c 23 Aug 2004 18:42:21 -0000 1.7 +++ server.c 5 Dec 2005 22:34:33 -0000 @@ -29,14 +29,18 @@ * $FreeBSD: src/usr.sbin/bluetooth/sdpd/server.c,v 1.1 2004/01/20 20:48:26 emax Exp $ */ +#include #include +#include #include +#include #include #include #include #include #include #include +#include #include #include #include @@ -96,6 +100,13 @@ return (-1); } + if (chmod(control, S_IRWXU|S_IRWXG|S_IRWXO) < 0) { + log_crit("Could not change permissions on control socket. " \ + "%s (%d)", strerror(errno), errno); + close(unsock); + return (-1); + } + if (listen(unsock, 10) < 0) { log_crit("Could not listen on control socket. %s (%d)", strerror(errno), errno); @@ -185,6 +196,7 @@ srv->fdidx[unsock].valid = 1; srv->fdidx[unsock].server = 1; srv->fdidx[unsock].control = 1; + srv->fdidx[unsock].priv = 0; srv->fdidx[unsock].rsp_cs = 0; srv->fdidx[unsock].rsp_size = 0; srv->fdidx[unsock].rsp_limit = 0; @@ -195,6 +207,7 @@ srv->fdidx[l2sock].valid = 1; srv->fdidx[l2sock].server = 1; srv->fdidx[l2sock].control = 0; + srv->fdidx[l2sock].priv = 0; srv->fdidx[l2sock].rsp_cs = 0; srv->fdidx[l2sock].rsp_size = 0; srv->fdidx[l2sock].rsp_limit = 0; @@ -276,7 +289,7 @@ server_accept_client(server_p srv, int32_t fd) { uint8_t *rsp = NULL; - int32_t cfd, size; + int32_t cfd, size, priv; uint16_t omtu; do { @@ -293,6 +306,8 @@ assert(!FD_ISSET(cfd, &srv->fdset)); assert(!srv->fdidx[cfd].valid); + priv = 0; + if (!srv->fdidx[fd].control) { /* Get local BD_ADDR */ size = sizeof(srv->req_sa); @@ -326,6 +341,28 @@ return; } } else { + struct xucred cr; + struct passwd *pw; + + /* Get peer's credentials */ + memset(&cr, 0, sizeof(cr)); + size = sizeof(cr); + + if (getsockopt(cfd, 0, LOCAL_PEERCRED, &cr, &size) < 0) { + log_err("Could not get peer's credentials. %s (%d)", + strerror(errno), errno); + close(cfd); + return; + } + + /* Check credentials */ + pw = getpwuid(cr.cr_uid); + if (pw != NULL) + priv = (strcmp(pw->pw_name, "root") == 0); + else + log_warning("Could not verify credentials for uid %d", + cr.cr_uid); + memcpy(&srv->req_sa.l2cap_bdaddr, NG_HCI_BDADDR_ANY, sizeof(srv->req_sa.l2cap_bdaddr)); @@ -351,6 +388,7 @@ srv->fdidx[cfd].valid = 1; srv->fdidx[cfd].server = 0; srv->fdidx[cfd].control = srv->fdidx[fd].control; + srv->fdidx[cfd].priv = priv; srv->fdidx[cfd].rsp_cs = 0; srv->fdidx[cfd].rsp_size = 0; srv->fdidx[cfd].rsp_limit = 0; Index: server.h =================================================================== RCS file: /usr/local/cvs/usr.sbin/bluetooth/sdpd/server.h,v retrieving revision 1.6 diff -u -r1.6 server.h --- server.h 23 Aug 2004 18:42:21 -0000 1.6 +++ server.h 5 Dec 2005 22:30:31 -0000 @@ -41,7 +41,8 @@ unsigned valid : 1; /* descriptor is valid */ unsigned server : 1; /* descriptor is listening */ unsigned control : 1; /* descriptor is a control socket */ - unsigned reserved : 2; + unsigned priv : 1; /* descriptor is privileged */ + unsigned reserved : 1; unsigned rsp_cs : 11; /* response continuation state */ uint16_t rsp_size; /* response size */ uint16_t rsp_limit; /* response limit */ Index: srr.c =================================================================== RCS file: /usr/local/cvs/usr.sbin/bluetooth/sdpd/srr.c,v retrieving revision 1.2 diff -u -r1.2 srr.c --- srr.c 23 Aug 2004 18:42:21 -0000 1.2 +++ srr.c 5 Dec 2005 22:47:20 -0000 @@ -65,7 +65,8 @@ * bdaddr - BD_ADDR 6 bytes */ - if (!srv->fdidx[fd].control || req_end - req < 8) + if (!srv->fdidx[fd].control || + !srv->fdidx[fd].priv || req_end - req < 8) return (SDP_ERROR_CODE_INVALID_REQUEST_SYNTAX); /* Get ServiceClass UUID */ Index: sur.c =================================================================== RCS file: /usr/local/cvs/usr.sbin/bluetooth/sdpd/sur.c,v retrieving revision 1.2 diff -u -r1.2 sur.c --- sur.c 23 Aug 2004 18:42:21 -0000 1.2 +++ sur.c 5 Dec 2005 22:47:36 -0000 @@ -58,7 +58,8 @@ * value32 - uuid 4 bytes */ - if (!srv->fdidx[fd].control || req_end - req < 4) + if (!srv->fdidx[fd].control || + !srv->fdidx[fd].priv || req_end - req < 4) return (SDP_ERROR_CODE_INVALID_REQUEST_SYNTAX); /* Get handle */ --------------060006020806080006030503-- From owner-freebsd-bluetooth@FreeBSD.ORG Tue Dec 6 00:58:50 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 308AD16A41F for ; Tue, 6 Dec 2005 00:58:50 +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 94E4C43D60 for ; Tue, 6 Dec 2005 00:58: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 jB60wiJ19796; Mon, 5 Dec 2005 19:58:45 -0500 Message-ID: <4394E242.7030401@savvis.net> Date: Mon, 05 Dec 2005 16:58:42 -0800 From: Maksim Yevmenkin User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050404) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Marcel Holtmann References: <9307f5f20512030807x6eadc73cq9d9acc9dd5503a5b@mail.gmail.com> <4391E320.2090006@savvis.net> <9307f5f20512031333x61e9d141u85ea578711740712@mail.gmail.com> <43936F6B.1090003@savvis.net> <1133819097.4559.15.camel@localhost.localdomain> In-Reply-To: <1133819097.4559.15.camel@localhost.localdomain> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-bluetooth@freebsd.org Subject: Re: Automatic bluetooth device initialization 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, 06 Dec 2005 00:58:50 -0000 Marcel, >> while i appreciate your effort in this area, i'm skeptical that >> d-bus and/or whatever api will solve this problem. i think, instead >> of introducing yet another compatibility layer that sits on top of >> native api, everyone would be much better off if native api was the >> same. what would solve this problem, imo, is the standard >> (something like posix) that would define api etc. > > I don't really like D-Bus, but it will be the way to go for a general > API for the desktop. It has multiple language bindings already and > our goal is to make it totally generic (no BlueZ specific > definitions). perhaps, we are talking about different things here. i do not really understand what multiple language bindings have do with bluetooth device initialization and lower level api. it very much possible that d-bus is very well suited for inter-application communications in kde/gnome/whatever desktop. after all, this is what it is being developed for. what i do not understand is why d-bus is being pushed all the way down and even suggested as replacement for hci? instead of creating numerous d-bus bluetooth applications that know how to work on particular system, why not just create one d-bus bluetooth application that uses common low level bluetooth api? what about not-kde/gnome/whatever applications (i.e. non-d-bus)? are those just out of luck? i admit kde/gnome folks did a lot of work by integrating bluetooth, but their work can not be re-used :( i wish their work would be in a form of re-usable user space modules. i wish they would make it so anybody can just pick this or that module and re-use it. for example, if i want to run obex file server, i do not have to run kde/gnome/d-bus etc. thanks, max From owner-freebsd-bluetooth@FreeBSD.ORG Tue Dec 6 03:37:15 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 2465616A41F for ; Tue, 6 Dec 2005 03:37:15 +0000 (GMT) (envelope-from shackan@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.195]) by mx1.FreeBSD.org (Postfix) with ESMTP id 707F543D53 for ; Tue, 6 Dec 2005 03:37:14 +0000 (GMT) (envelope-from shackan@gmail.com) Received: by zproxy.gmail.com with SMTP id z31so1252179nzd for ; Mon, 05 Dec 2005 19:37:13 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=VF1yKUU0rArh31KMHYPwYy0ssAALAmZmwCSgseYV9akzw2EGt6Ddnkm1Qzkl6N0GHGDRzasDgpJqJ8CDUG4VKM/QGzDOKw7L0gII8E3XaxiNtN13nRmQSJ6XC053CjnTqvD5AiUABZKpcn/S9wxk1bbW0WmsREPXaZ1ohdw54fU= Received: by 10.65.112.20 with SMTP id p20mr10756qbm; Mon, 05 Dec 2005 19:37:12 -0800 (PST) Received: by 10.65.196.7 with HTTP; Mon, 5 Dec 2005 19:37:11 -0800 (PST) Message-ID: <9307f5f20512051937h26e4a99awb00083dccca21180@mail.gmail.com> Date: Tue, 6 Dec 2005 04:37:11 +0100 From: "P. Durante" To: Maksim Yevmenkin In-Reply-To: <4394E242.7030401@savvis.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <9307f5f20512030807x6eadc73cq9d9acc9dd5503a5b@mail.gmail.com> <4391E320.2090006@savvis.net> <9307f5f20512031333x61e9d141u85ea578711740712@mail.gmail.com> <43936F6B.1090003@savvis.net> <1133819097.4559.15.camel@localhost.localdomain> <4394E242.7030401@savvis.net> Cc: freebsd-bluetooth@freebsd.org Subject: Re: Automatic bluetooth device initialization 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, 06 Dec 2005 03:37:15 -0000 > perhaps, we are talking about different things here. i do not really > understand what multiple language bindings have do with bluetooth device > initialization and lower level api. > since coding gui applications in C is the second most boring thing on earth (the first being writing gui applications in asm :-) it's a good idea to do it in a higher level language, and since those clients have to communicate over dbus with the daemon, you'll need dbus bindings for your language of choice, and dbus does have them. > it very much possible that d-bus is very well suited for > inter-application communications in kde/gnome/whatever desktop. after > all, this is what it is being developed for. what i do not understand is > why d-bus is being pushed all the way down and even suggested as > replacement for hci? > I think marcel was talking about a dbus replacement for hcid, the linux bluetooth daemon. (after all HCI is part of the bluetooth specification and you can't replace that one :-) > instead of creating numerous d-bus bluetooth > applications that know how to work on particular system, why not just > create one d-bus bluetooth application that uses common low level > bluetooth api? > yes, that's how it would work in an ideal world... in this world, bluez has one way of doing things, freebsd has another, for example freebsd had its SDP api rewritten from scratch even if sdp has very little low-level programming involved and could easily have borrowed the bluez sdp code, but we all know licensing issues are a Bad Thing so let's not get over this again please. In the end, if you have a well-defined d-bus interface, you'll have applications that DO run regardless of the os. > what about not-kde/gnome/whatever applications (i.e. > non-d-bus)? are those just out of luck? > fell free to suggest alternatives, but all the major linux distributions now have dbus, freebsd does have it, solaris will come along (but I don't know if opensolaris has a bluetooth stack yet ;-) and after 1.0 is out it will become quite a standard (no, I don't like creating dependencies, and I like even less adding new "standards", I _have_ been looking for alternatives, if there was a common low-level api probably noone wouldn't need a d-bus layer in the middle but this is not the case so...) > i admit kde/gnome folks did a lot of work by integrating bluetooth, but > their work can not be re-used :( > yes, that's the point > i wish their work would be in a form of > re-usable user space modules. i wish they would make it so anybody can > just pick this or that module and re-use it. for example, if i want to > run obex file server, i do not have to run kde/gnome/d-bus etc. > but you could make a server which runs on top of the dbus interface, which isn't that bad. strictly speaking the only requirement is dbus, regardless of your favourite desktop manager; of course _clients_ may be more or less integrated into a particular desktop enviroment, for example some developer might want to implement an obex _client_ as a KIOslave for kde, another as a nautilus-vfs extension, yet another as something else, but the fact that there are soo many desktop environments to chose from (like the fact that every operating system has his own low-level api for the bluetooth stack) and that there's no established standard among them is something we have to live with :-( regards, Paul From owner-freebsd-bluetooth@FreeBSD.ORG Tue Dec 6 09:44:35 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 50DE616A41F for ; Tue, 6 Dec 2005 09:44:35 +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 3134343D60 for ; Tue, 6 Dec 2005 09:44:32 +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 jB69iTZm074800; Tue, 6 Dec 2005 11:44:29 +0200 (EET) (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 jB69imCA092883; Tue, 6 Dec 2005 11:44:49 +0200 (EET) (envelope-from past@ebs.gr) Message-ID: <43955D78.4080208@ebs.gr> Date: Tue, 06 Dec 2005 11:44:24 +0200 From: Panagiotis Astithas Organization: EBS Ltd. User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051106) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Maksim Yevmenkin References: <4394A53E.1050109@Zahemszky.HU> <4394B211.1080503@savvis.net> <4394C687.9060108@savvis.net> In-Reply-To: <4394C687.9060108@savvis.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-bluetooth@freebsd.org, =?ISO-8859-1?Q?Zahemszky_G=E1bor?= Subject: Re: [PATCH] Local browsing: permission denied 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, 06 Dec 2005 09:44:35 -0000 Maksim Yevmenkin wrote: > Hello, > > please try the attached patch for sdpd(8) daemon. with this patch > sdpd(8) will > > 1) change permission on the control socket, > > 2) check peer's credential > > 3) accept register/remove/change service requests only if peer has > effective user id the same as 'root' user id > > it should be now possible to run 'sdpcontrol -l' as regular user. > > thanks, > max This patch works fine for me on RELENG_6. Thanks, Panagiotis From owner-freebsd-bluetooth@FreeBSD.ORG Tue Dec 6 18:22:40 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 192E816A41F for ; Tue, 6 Dec 2005 18:22:40 +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 4AA3C43D6A for ; Tue, 6 Dec 2005 18:22:39 +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 jB6IMWJ28987; Tue, 6 Dec 2005 13:22:33 -0500 Message-ID: <4395D6E6.6090103@savvis.net> Date: Tue, 06 Dec 2005 10:22:30 -0800 From: Maksim Yevmenkin User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050404) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "P. Durante" References: <9307f5f20512030807x6eadc73cq9d9acc9dd5503a5b@mail.gmail.com> <4391E320.2090006@savvis.net> <9307f5f20512031333x61e9d141u85ea578711740712@mail.gmail.com> <43936F6B.1090003@savvis.net> <1133819097.4559.15.camel@localhost.localdomain> <4394E242.7030401@savvis.net> <9307f5f20512051937h26e4a99awb00083dccca21180@mail.gmail.com> In-Reply-To: <9307f5f20512051937h26e4a99awb00083dccca21180@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-bluetooth@freebsd.org Subject: Re: Automatic bluetooth device initialization 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, 06 Dec 2005 18:22:40 -0000 Paul, >> perhaps, we are talking about different things here. i do not >> really understand what multiple language bindings have do with >> bluetooth device initialization and lower level api. > > since coding gui applications in C is the second most boring thing on > earth (the first being writing gui applications in asm :-) it's a > good idea to do it in a higher level language, and since those > clients have to communicate over dbus with the daemon, you'll need > dbus bindings for your language of choice, and dbus does have them. perhaps i'm wrong, but you seem to be thinking about this in terms of gui. if so, then i can compare it to building a house starting from the roof. without foundation and walls it will fall down. gui, imo, should be the very last thing to worry about. it will be trivial to write any gui when you have defined low level api. if you like you can use d-bus or whatever messaging protocol of the day. >> it very much possible that d-bus is very well suited for >> inter-application communications in kde/gnome/whatever desktop. >> after all, this is what it is being developed for. what i do not >> understand is why d-bus is being pushed all the way down and even >> suggested as replacement for hci? > > I think marcel was talking about a dbus replacement for hcid, the > linux bluetooth daemon. (after all HCI is part of the bluetooth > specification and you can't replace that one :-) again, what is _wrong_ with raw hci sockets? >> instead of creating numerous d-bus bluetooth applications that know >> how to work on particular system, why not just create one d-bus >> bluetooth application that uses common low level bluetooth api? > > yes, that's how it would work in an ideal world... in this world, > bluez has one way of doing things, freebsd has another, for example > freebsd had its SDP api rewritten from scratch even if sdp has very > little low-level programming involved and could easily have borrowed > the bluez sdp code, but we all know licensing issues are a Bad Thing > so let's not get over this again please. In the end, if you have a > well-defined d-bus interface, you'll have applications that DO run > regardless of the os. > >> what about not-kde/gnome/whatever applications (i.e. non-d-bus)? >> are those just out of luck? > > fell free to suggest alternatives, but all the major linux > distributions now have dbus, freebsd does have it, solaris will come > along (but I don't know if opensolaris has a bluetooth stack yet ;-) > and after 1.0 is out it will become quite a standard (no, I don't > like creating dependencies, and I like even less adding new > "standards", I _have_ been looking for alternatives, if there was a > common low-level api probably noone wouldn't need a d-bus layer in > the middle but this is not the case so...) as i tried to explain, the alternative would be common low level api. please, PLEASE, accept the fact that other (than linux) systems do things _differently_. please do not think that you could just port d-bus and/or whatever to freebsd/solaris/etc. but rather understand that the major requirement is that bluetooth should be usable on out-of-the-box system. in particular, on freebsd that means, i do not have to install _any_ third party application, etc. if/when d-bus will be included into the base freebsd installation, i will not have any problem with it. until then _any_ work based on _optional_ software will be _optional_. which means we will have to maintain two sets of bluetooth tools/libraries/etc. one is d-bus based and other is not. imo, this is not going to solve the problem. >> i admit kde/gnome folks did a lot of work by integrating bluetooth, >> but their work can not be re-used :( > > yes, that's the point > >> i wish their work would be in a form of re-usable user space >> modules. i wish they would make it so anybody can just pick this or >> that module and re-use it. for example, if i want to run obex file >> server, i do not have to run kde/gnome/d-bus etc. > > but you could make a server which runs on top of the dbus interface, > which isn't that bad. strictly speaking the only requirement is dbus, > regardless of your favourite desktop manager; of course _clients_ may > be more or less integrated into a particular desktop enviroment, for > example some developer might want to implement an obex _client_ as a > KIOslave for kde, another as a nautilus-vfs extension, yet another as > something else, but the fact that there are soo many desktop > environments to chose from (like the fact that every operating system > has his own low-level api for the bluetooth stack) and that there's > no established standard among them is something we have to live with > :-( like i said, d-bus is likely not going to help you here. at least, not on freebsd. everybody should sit down and talk. perhaps even write a draft and send it to bluetooth sig, so they can publish it as a standard. thanks, max