From Alexander at Leidinger.net Wed May 7 17:24:41 2008 From: Alexander at Leidinger.net (Alexander Leidinger) Date: Wed May 7 17:24:45 2008 Subject: Fun with Logitech bluetooth keyboard (diNovo Edge)... Message-ID: <20080507192434.32afce8b@deskjail> Hi, I bought a keyboard with an integrated touchpad from logitech. Just plugging in the BT-dongle gives an usb hub with ums and ukbd. Unfortunately the ums doesn't work for me yet (problem in a separate mail to usb@). I googled a litte bit around and found a posting here (http://lists.freebsd.org/mailman/htdig/freebsd-bluetooth/2006-December/000824.html) which contains a program which puts the device into hci mode (by accessing /dev/uhidX), so that I can use the HID devices with the FreeBSD bluetooth stack directly. I haven't tried this yet (I would have to remove ukbd and ums from the kernel...). Is there the possibility to get this hid2hci feature in our userland (or into the kernel controllable via a sysctl)? I would would be good to have this functionality at boot (in the kernel it would would allow to have ukbd available while still being able to put the device into hci mode). Any hints regarding this specific keyboard/mouse kombo? Bye, Alexander. -- Ferengi Rule of Acquisition #65: Win or lose, there's always Hupyrian beetle snuff. -- ST: Legends of the Ferengi http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From amistry at am-productions.biz Wed May 7 18:53:00 2008 From: amistry at am-productions.biz (Anish Mistry) Date: Wed May 7 18:53:10 2008 Subject: Fun with Logitech bluetooth keyboard (diNovo Edge)... In-Reply-To: <20080507192434.32afce8b@deskjail> References: <20080507192434.32afce8b@deskjail> Message-ID: <200805071432.48331.amistry@am-productions.biz> On Wednesday 07 May 2008, Alexander Leidinger wrote: > Hi, > > I bought a keyboard with an integrated touchpad from logitech. Just > plugging in the BT-dongle gives an usb hub with ums and ukbd. > Unfortunately the ums doesn't work for me yet (problem in a > separate mail to usb@). > > I googled a litte bit around and found a posting here > (http://lists.freebsd.org/mailman/htdig/freebsd-bluetooth/2006-Dece >mber/000824.html) which contains a program which puts the device > into hci mode (by accessing /dev/uhidX), so that I can use the HID > devices with the FreeBSD bluetooth stack directly. I haven't tried > this yet (I would have to remove ukbd and ums from the kernel...). > > Is there the possibility to get this hid2hci feature in our > userland (or into the kernel controllable via a sysctl)? I would > would be good to have this functionality at boot (in the kernel it > would would allow to have ukbd available while still being able to > put the device into hci mode). That program should really be changed so that you don't have to specify a uhid device. I did something similar with my device suspend program where you just specify the uhub device and a port number. I think you might be able to modify the hid2hci program to do that. http://am-productions.biz/docs/upower.c -- Anish Mistry amistry@am-productions.biz AM Productions http://am-productions.biz/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part. Url : http://lists.freebsd.org/pipermail/freebsd-bluetooth/attachments/20080507/e6c893cc/attachment.pgp From maksim.yevmenkin at gmail.com Wed May 7 20:05:09 2008 From: maksim.yevmenkin at gmail.com (Maksim Yevmenkin) Date: Wed May 7 20:05:12 2008 Subject: Fun with Logitech bluetooth keyboard (diNovo Edge)... In-Reply-To: <20080507192434.32afce8b@deskjail> References: <20080507192434.32afce8b@deskjail> Message-ID: On Wed, May 7, 2008 at 10:24 AM, Alexander Leidinger wrote: > Hi, > > I bought a keyboard with an integrated touchpad from logitech. Just > plugging in the BT-dongle gives an usb hub with ums and ukbd. > Unfortunately the ums doesn't work for me yet (problem in a separate > mail to usb@). > > I googled a litte bit around and found a posting here > (http://lists.freebsd.org/mailman/htdig/freebsd-bluetooth/2006-December/000824.html) > which contains a program which puts the device into hci mode (by > accessing /dev/uhidX), so that I can use the HID devices with the > FreeBSD bluetooth stack directly. I haven't tried this yet (I would > have to remove ukbd and ums from the kernel...). > > Is there the possibility to get this hid2hci feature in our userland > (or into the kernel controllable via a sysctl)? I would would be good > to have this functionality at boot (in the kernel it would would allow > to have ukbd available while still being able to put the device into > hci mode). well, someone already ported hid2hci. http://lists.freebsd.org/pipermail/freebsd-bluetooth/2007-July/000989.html is a good starting point. i do not think that using sysctl is good solution for this. last time i looked this stuff was implemented on csr chips using so-called "boot mode" feature. basically, the device has a split personality - in one mode it pretends to be an usb hub with keyboard and mouse attached (hid) to it and in another - bluetooth dongle (hci). to switch between the modes one must set a so-called ps key and perform warm reset. the problems are 1) this is highly device specific 2) there is no good way to know if device can be switched between hid and hci. it is basically left to user to know that. 3) usually hid mode is made default, so device has to be switched into hci mode every time it is attached. the hid mode is really for user's advantage. its makes it possible to use wireless keyboards in bios screens etc. os does not need to know anything about bluetooth. all that is required from the os is usb support. while i do not object to hid2hci utility, personally, i would get a separate bluetooth dongle for another $20 or less. thanks, max From Alexander at Leidinger.net Wed May 7 23:07:55 2008 From: Alexander at Leidinger.net (Alexander Leidinger) Date: Wed May 7 23:08:00 2008 Subject: Fun with Logitech bluetooth keyboard (diNovo Edge)... In-Reply-To: References: <20080507192434.32afce8b@deskjail> Message-ID: <20080508010746.0388b146@deskjail> Quoting "Maksim Yevmenkin" (Wed, 7 May 2008 13:05:02 -0700): > On Wed, May 7, 2008 at 10:24 AM, Alexander Leidinger > wrote: > > Hi, > > > > I bought a keyboard with an integrated touchpad from logitech. Just > > plugging in the BT-dongle gives an usb hub with ums and ukbd. > > Unfortunately the ums doesn't work for me yet (problem in a separate > > mail to usb@). > > > > I googled a litte bit around and found a posting here > > (http://lists.freebsd.org/mailman/htdig/freebsd-bluetooth/2006-December/000824.html) > > which contains a program which puts the device into hci mode (by > > accessing /dev/uhidX), so that I can use the HID devices with the > > FreeBSD bluetooth stack directly. I haven't tried this yet (I would > > have to remove ukbd and ums from the kernel...). > > > > Is there the possibility to get this hid2hci feature in our userland > > (or into the kernel controllable via a sysctl)? I would would be good > > to have this functionality at boot (in the kernel it would would allow > > to have ukbd available while still being able to put the device into > > hci mode). > > well, someone already ported hid2hci. > > http://lists.freebsd.org/pipermail/freebsd-bluetooth/2007-July/000989.html > > is a good starting point. i do not think that using sysctl is good It doesn't make sense to have something like this in the base system? > solution for this. last time i looked this stuff was implemented on > csr chips using so-called "boot mode" feature. basically, the device > has a split personality - in one mode it pretends to be an usb hub > with keyboard and mouse attached (hid) to it and in another - > bluetooth dongle (hci). to switch between the modes one must set a > so-called ps key and perform warm reset. > > the problems are > > 1) this is highly device specific > > 2) there is no good way to know if device can be switched between hid > and hci. it is basically left to user to know that. There's no way to know this based upon some vendor/product IDs? > 3) usually hid mode is made default, so device has to be switched into > hci mode every time it is attached. > > the hid mode is really for user's advantage. its makes it possible to > use wireless keyboards in bios screens etc. os does not need to know Yes, I understand that, the problem is: the ums part does not work for me (8-current from March). > anything about bluetooth. all that is required from the os is usb > support. while i do not object to hid2hci utility, personally, i would > get a separate bluetooth dongle for another $20 or less. I have a separate dongle, but having a second one (the logitech one) would not be bad. We just need a way to say "I want this to be a hci device when I plug it in automatically". Bye, Alexander. -- Fry: I'm not a robot like you. I don't like having disks crammed into me... unless they're Oreos, and then only in the mouth. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From maksim.yevmenkin at gmail.com Wed May 7 23:19:40 2008 From: maksim.yevmenkin at gmail.com (Maksim Yevmenkin) Date: Wed May 7 23:19:43 2008 Subject: Fun with Logitech bluetooth keyboard (diNovo Edge)... In-Reply-To: <20080508010746.0388b146@deskjail> References: <20080507192434.32afce8b@deskjail> <20080508010746.0388b146@deskjail> Message-ID: On Wed, May 7, 2008 at 4:07 PM, Alexander Leidinger wrote: > Quoting "Maksim Yevmenkin" (Wed, 7 May 2008 13:05:02 -0700): > >> On Wed, May 7, 2008 at 10:24 AM, Alexander Leidinger >> wrote: >> > Hi, >> > >> > I bought a keyboard with an integrated touchpad from logitech. Just >> > plugging in the BT-dongle gives an usb hub with ums and ukbd. >> > Unfortunately the ums doesn't work for me yet (problem in a separate >> > mail to usb@). >> > >> > I googled a litte bit around and found a posting here >> > (http://lists.freebsd.org/mailman/htdig/freebsd-bluetooth/2006-December/000824.html) >> > which contains a program which puts the device into hci mode (by >> > accessing /dev/uhidX), so that I can use the HID devices with the >> > FreeBSD bluetooth stack directly. I haven't tried this yet (I would >> > have to remove ukbd and ums from the kernel...). >> > >> > Is there the possibility to get this hid2hci feature in our userland >> > (or into the kernel controllable via a sysctl)? I would would be good >> > to have this functionality at boot (in the kernel it would would allow >> > to have ukbd available while still being able to put the device into >> > hci mode). >> >> well, someone already ported hid2hci. >> >> http://lists.freebsd.org/pipermail/freebsd-bluetooth/2007-July/000989.html >> >> is a good starting point. i do not think that using sysctl is good > > It doesn't make sense to have something like this in the base system? yes, it does. however, one should be careful. original tool is under gpl. there is a lot of code that looks very similar (if not identical) to gpl version. also, at least for csr chips, the utility contain some information about csr chips that they may or may not want be released. i realize that this information is already public (due to gpl tool) but you never know... i think port would be better solution for now. >> solution for this. last time i looked this stuff was implemented on >> csr chips using so-called "boot mode" feature. basically, the device >> has a split personality - in one mode it pretends to be an usb hub >> with keyboard and mouse attached (hid) to it and in another - >> bluetooth dongle (hci). to switch between the modes one must set a >> so-called ps key and perform warm reset. >> >> the problems are >> >> 1) this is highly device specific >> >> 2) there is no good way to know if device can be switched between hid >> and hci. it is basically left to user to know that. > > There's no way to know this based upon some vendor/product IDs? well, yes, that is the only way to know. the thing is that someone has to keep this list up-to-date. >> 3) usually hid mode is made default, so device has to be switched into >> hci mode every time it is attached. >> >> the hid mode is really for user's advantage. its makes it possible to >> use wireless keyboards in bios screens etc. os does not need to know > > Yes, I understand that, the problem is: the ums part does not work for > me (8-current from March). > >> anything about bluetooth. all that is required from the os is usb >> support. while i do not object to hid2hci utility, personally, i would >> get a separate bluetooth dongle for another $20 or less. > > I have a separate dongle, but having a second one (the logitech one) > would not be bad. We just need a way to say "I want this to be a hci > device when I plug it in automatically". devd(8) could be used to run hid2hci automatically when device is plugged. devd.conf entry will contain device name, vendor id/device id pair to match againts. after device warm resets itself it will be recognized (hopefully) as bluetooth dongle. thanks, max From rpaulo at FreeBSD.org Thu May 8 22:21:26 2008 From: rpaulo at FreeBSD.org (Rui Paulo) Date: Thu May 8 22:21:31 2008 Subject: Fun with Logitech bluetooth keyboard (diNovo Edge)... In-Reply-To: References: <20080507192434.32afce8b@deskjail> <20080508010746.0388b146@deskjail> Message-ID: <482376CC.8020108@FreeBSD.org> Maksim Yevmenkin wrote: > On Wed, May 7, 2008 at 4:07 PM, Alexander Leidinger > wrote: >> Quoting "Maksim Yevmenkin" (Wed, 7 May 2008 13:05:02 -0700): >> >>> On Wed, May 7, 2008 at 10:24 AM, Alexander Leidinger >>> wrote: >>>> Hi, >>>> >>>> I bought a keyboard with an integrated touchpad from logitech. Just >>>> plugging in the BT-dongle gives an usb hub with ums and ukbd. >>>> Unfortunately the ums doesn't work for me yet (problem in a separate >>>> mail to usb@). >>>> >>>> I googled a litte bit around and found a posting here >>>> (http://lists.freebsd.org/mailman/htdig/freebsd-bluetooth/2006-December/000824.html) >>>> which contains a program which puts the device into hci mode (by >>>> accessing /dev/uhidX), so that I can use the HID devices with the >>>> FreeBSD bluetooth stack directly. I haven't tried this yet (I would >>>> have to remove ukbd and ums from the kernel...). >>>> >>>> Is there the possibility to get this hid2hci feature in our userland >>>> (or into the kernel controllable via a sysctl)? I would would be good >>>> to have this functionality at boot (in the kernel it would would allow >>>> to have ukbd available while still being able to put the device into >>>> hci mode). >>> well, someone already ported hid2hci. >>> >>> http://lists.freebsd.org/pipermail/freebsd-bluetooth/2007-July/000989.html >>> >>> is a good starting point. i do not think that using sysctl is good >> It doesn't make sense to have something like this in the base system? > > yes, it does. however, one should be careful. original tool is under > gpl. there is a lot of code that looks very similar (if not identical) > to gpl version. also, at least for csr chips, the utility contain some > information about csr chips that they may or may not want be released. > i realize that this information is already public (due to gpl tool) > but you never know... i think port would be better solution for now. Then that's a problem for me because I wrote the utility. IANAL, but I don't think there's a problem here, because: * The utility I wrote reads a file with matching USB IDs. The original one has a list hardcoded into the program * I don't use libusb, I call ioctl()'s specific to the BSD USB stack * I didn't copy any code. * I don't think my program can be considered a derived work There are several open source tools out there that are similar, but have incompatible licenses. This is another case. Also, the author of hid2hci reads this list. If he considered that I have used code from his utility, he would probably have tried to convince me to change it, or even a threat to sue. (I don't know him, I'm just saying out loud what could happen.) Either way, I'm willing to do a port. Thanks, -- Rui Paulo From freebsd-bluetooth at oldach.net Tue May 13 16:25:13 2008 From: freebsd-bluetooth at oldach.net (Helge Oldach) Date: Tue May 13 16:25:17 2008 Subject: any reason to require -t dev in rfcomm_sppd -S ? In-Reply-To: from Maksim Yevmenkin at "21 Apr 2008 11:51:55" Message-ID: <200805131552.m4DFqQOW031043@sep.oldach.net> Maksim Yevmenkin wrote on Mon, 21 Apr 2008 20:51:55 +0200 (CEST): > On Thu, Apr 17, 2008 at 11:06 AM, Luigi Rizzo wrote: > > > > On Thu, Apr 17, 2008 at 10:39:16AM -0700, Maksim Yevmenkin wrote: > > > On Thu, Apr 17, 2008 at 4:56 AM, Luigi Rizzo wrote: > > > > hi, is there any compelling reason to require > > > > the '-t device' option in rfcomm_sppd when used in server mode ? > > > > > > technically, no. just need to be careful who is going to setup tty > > > properly, for example make it 'raw' as rfcomm_sppd(1) does with pty. > > > rfcomm_sppd(1) already can be used inside ppp(8), i.e. one can do > > > something like > > > > > > set device '!/usr/bin/rfcomm_sppd -a mobile -c sp' > > > > > > in /etc/ppp.conf and it will work just fine. rfcomm_sppd(1) does not > > > do anything to tty when running using stdin/stdout in client mode. the > > > assumption here is that whatever calls rfcomm_sppd(1) will setup > > > tty/fd properly. > > > > > > > I tried to disable the one-line that checks it in the code, and > > > > things seem to work - and this makes the program very convenient > > > > to use in a pipeline, e.g. to receive data from a remote bluetooth > > > > device. > > > > > > right. can you please provide usage example? i certainly would not > > > object to making the change you are requesting. > > > > sure - i need to listen to a portable ElectroCardioGram (ECG) device > > which talks to the external world through bluetooth. The device > > must have some kind of modem inside - its console port says it is > > issuing commands such as > > > > AT+ZV SPPConnect XXX > > ... > > > > where XXX is the (manually configured) address of the bluetooth > > dongle on the PC. On the FreeBSD side, running > > "rfcom_sppd -a YYY" (without the -S option, YYY is the ECG address) > > sometimes connects, but most of the times doesnt. > > > > With a patched rfcomm_sppp i can just do > > > > rfcomm_sppd -S -a YYY | my_data_logger > > > > rather than having to manually select an available tty/pty pair > > > > Don't know how many devices behave in this way, but a > > search for "AT+ZV SPPConnect" gives several matches with > > documentation for embedded hardware. > > ok, please try the attached patch and see if it works for you. i > basically removed the check for tty name in server mode, bind to > "wildcard" channel instead of generating one based on pid (if channel > was not specified) and fixed a possible problem with service > registration in server mode (i.e. always register serial port > service). Your patch applies cleanly, but I just get # rfcomm_sppd -S rfcomm_sppd: Could not get socket name # It seems that getsockbyname fails. What is the reason for that anyway? BTW, Luigi's pipe application is interesting, but what about true two-way communcation? For instance, I would like to have something like # rfcomm_sppd -S -c sp -a myPalm -x "coldsync -t serial -s -md" ...meaning: Upon receipt of a SP connection request from myPalm we would fork coldsync to synchronize the Palm (just like USB or serial sync, but now bluetooth). This could even go into /etc/ttys, forking a fresh rfcomm_sppd after the request terminates. I'm currently doing this in two separate steps, first starting rfcomm_sppd with some arbitrary pty, then coldsync talking to that pty. So yes, this definitely works. Regards, Helge From maksim.yevmenkin at gmail.com Tue May 13 16:48:08 2008 From: maksim.yevmenkin at gmail.com (Maksim Yevmenkin) Date: Tue May 13 16:48:12 2008 Subject: any reason to require -t dev in rfcomm_sppd -S ? In-Reply-To: <200805131552.m4DFqQOW031043@sep.oldach.net> References: <200805131552.m4DFqQOW031043@sep.oldach.net> Message-ID: On Tue, May 13, 2008 at 8:52 AM, Helge Oldach wrote: > Maksim Yevmenkin wrote on Mon, 21 Apr 2008 20:51:55 +0200 (CEST): >> On Thu, Apr 17, 2008 at 11:06 AM, Luigi Rizzo wrote: >> > >> > On Thu, Apr 17, 2008 at 10:39:16AM -0700, Maksim Yevmenkin wrote: >> > > On Thu, Apr 17, 2008 at 4:56 AM, Luigi Rizzo wrote: >> > > > hi, is there any compelling reason to require >> > > > the '-t device' option in rfcomm_sppd when used in server mode ? >> > > >> > > technically, no. just need to be careful who is going to setup tty >> > > properly, for example make it 'raw' as rfcomm_sppd(1) does with pty. >> > > rfcomm_sppd(1) already can be used inside ppp(8), i.e. one can do >> > > something like >> > > >> > > set device '!/usr/bin/rfcomm_sppd -a mobile -c sp' >> > > >> > > in /etc/ppp.conf and it will work just fine. rfcomm_sppd(1) does not >> > > do anything to tty when running using stdin/stdout in client mode. the >> > > assumption here is that whatever calls rfcomm_sppd(1) will setup >> > > tty/fd properly. >> > > >> > > > I tried to disable the one-line that checks it in the code, and >> > > > things seem to work - and this makes the program very convenient >> > > > to use in a pipeline, e.g. to receive data from a remote bluetooth >> > > > device. >> > > >> > > right. can you please provide usage example? i certainly would not >> > > object to making the change you are requesting. >> > >> > sure - i need to listen to a portable ElectroCardioGram (ECG) device >> > which talks to the external world through bluetooth. The device >> > must have some kind of modem inside - its console port says it is >> > issuing commands such as >> > >> > AT+ZV SPPConnect XXX >> > ... >> > >> > where XXX is the (manually configured) address of the bluetooth >> > dongle on the PC. On the FreeBSD side, running >> > "rfcom_sppd -a YYY" (without the -S option, YYY is the ECG address) >> > sometimes connects, but most of the times doesnt. >> > >> > With a patched rfcomm_sppp i can just do >> > >> > rfcomm_sppd -S -a YYY | my_data_logger >> > >> > rather than having to manually select an available tty/pty pair >> > >> > Don't know how many devices behave in this way, but a >> > search for "AT+ZV SPPConnect" gives several matches with >> > documentation for embedded hardware. >> >> ok, please try the attached patch and see if it works for you. i >> basically removed the check for tty name in server mode, bind to >> "wildcard" channel instead of generating one based on pid (if channel >> was not specified) and fixed a possible problem with service >> registration in server mode (i.e. always register serial port >> service). > > Your patch applies cleanly, but I just get > > # rfcomm_sppd -S > rfcomm_sppd: Could not get socket name > # > > It seems that getsockbyname fails. What is the reason for that anyway? > > BTW, Luigi's pipe application is interesting, but what about true > two-way communcation? For instance, I would like to have something like > > # rfcomm_sppd -S -c sp -a myPalm -x "coldsync -t serial -s -md" > > ...meaning: Upon receipt of a SP connection request from myPalm we would > fork coldsync to synchronize the Palm (just like USB or serial sync, but > now bluetooth). > > This could even go into /etc/ttys, forking a fresh rfcomm_sppd after the > request terminates. > > I'm currently doing this in two separate steps, first starting > rfcomm_sppd with some arbitrary pty, then coldsync talking to that pty. > So yes, this definitely works. well, there is a problem with my previous patch. please try the attached updated patch. thanks, max -------------- next part -------------- Index: rfcomm_sppd.1 =================================================================== RCS file: /usr/local/cvs/usr.bin/bluetooth/rfcomm_sppd/rfcomm_sppd.1,v retrieving revision 1.10 diff -u -r1.10 rfcomm_sppd.1 --- rfcomm_sppd.1 21 Apr 2008 18:13:23 -0000 1.10 +++ rfcomm_sppd.1 21 Apr 2008 18:37:09 -0000 @@ -25,7 +25,7 @@ .\" $Id: rfcomm_sppd.1,v 1.10 2008/04/21 18:13:23 max Exp $ .\" $FreeBSD: src/usr.bin/bluetooth/rfcomm_sppd/rfcomm_sppd.1,v 1.10 2007/01/25 20:54:59 emax Exp $ .\" -.Dd January 24, 2007 +.Dd April 21, 2008 .Dt RFCOMM_SPPD 1 .Os .Sh NAME @@ -69,14 +69,15 @@ via the .Xr sdpd 8 daemon. -The +If .Fl t -option must be specified; +options was specified, the server side of the virtual serial port is attached to the pseudo-terminal .Ar tty . +Otherwise the virtual serial port is attached to the stdin/stdout. .Nm should be run as root in order to communicate with -.Xr sdp 8 +.Xr sdpd 8 in this case. .Pp The @@ -113,12 +114,18 @@ Detach from the controlling terminal, i.e., run in background. .It Fl c Ar channel In both client and server mode, -this required option specifies the RFCOMM channel to connect to or listen on. +this option specifies the RFCOMM channel to connect to or listen on. In server mode, the channel should be a number between 1 and 30. If not specified, .Nm -will try to allocate RFCOMM channel number based on process ID. +will try to bind to +.Dq wildcard +RFCOMM channel number. +The actual RFCOMM channel will be obtained via +.Xr getsockname 2 +call and will be used to register Serial Port service with +.Xr sdpd 8 . In client mode, the channel could either be a number between 1 and 30 or a service name. Supported service names are: @@ -144,8 +151,6 @@ If not set stdin/stdout will be used. This option is required if .Fl b -or -.Fl S option was specified. .El .Sh FILES Index: rfcomm_sppd.c =================================================================== RCS file: /usr/local/cvs/usr.bin/bluetooth/rfcomm_sppd/rfcomm_sppd.c,v retrieving revision 1.11 diff -u -r1.11 rfcomm_sppd.c --- rfcomm_sppd.c 21 Apr 2008 18:13:23 -0000 1.11 +++ rfcomm_sppd.c 13 May 2008 16:44:24 -0000 @@ -1,6 +1,8 @@ /* * rfcomm_sppd.c - * + */ + +/*- * Copyright (c) 2003 Maksim Yevmenkin * All rights reserved. * @@ -172,7 +174,7 @@ /* Open TTYs */ if (tty == NULL) { - if (background || doserver) + if (background) usage(); amaster = STDIN_FILENO; @@ -189,43 +191,46 @@ if (doserver) { struct sockaddr_rfcomm ma; bdaddr_t bt_addr_any; - sdp_lan_profile_t lan; + sdp_sp_profile_t sp; void *ss; uint32_t sdp_handle; int acceptsock, aaddrlen; - if (channel == 0) { - /* XXX: should check if selected channel is unused */ - channel = (getpid() % 30) + 1; - } acceptsock = socket(PF_BLUETOOTH, SOCK_STREAM, - BLUETOOTH_PROTO_RFCOMM); + BLUETOOTH_PROTO_RFCOMM); if (acceptsock < 0) err(1, "Could not create socket"); + memcpy(&bt_addr_any, NG_HCI_BDADDR_ANY, sizeof(bt_addr_any)); + memset(&ma, 0, sizeof(ma)); ma.rfcomm_len = sizeof(ma); ma.rfcomm_family = AF_BLUETOOTH; + memcpy(&ma.rfcomm_bdaddr, &bt_addr_any, sizeof(bt_addr_any)); ma.rfcomm_channel = channel; if (bind(acceptsock, (struct sockaddr *)&ma, sizeof(ma)) < 0) - err(1, "Could not bind socket -- channel %d in use?", - channel); + err(1, "Could not bind socket on channel %d", channel); if (listen(acceptsock, 10) != 0) err(1, "Could not listen on socket"); + aaddrlen = sizeof(ma); + if (getsockname(acceptsock, (struct sockaddr *)&ma, &aaddrlen) < 0) + err(1, "Could not get socket name"); + channel = ma.rfcomm_channel; + ss = sdp_open_local(NULL); if (ss == NULL) errx(1, "Unable to create local SDP session"); if (sdp_error(ss) != 0) errx(1, "Unable to open local SDP session. %s (%d)", strerror(sdp_error(ss)), sdp_error(ss)); - memset(&lan, 0, sizeof(lan)); - lan.server_channel = channel; + memset(&sp, 0, sizeof(sp)); + sp.server_channel = channel; - memcpy(&bt_addr_any, NG_HCI_BDADDR_ANY, sizeof(bt_addr_any)); - if (sdp_register_service(ss, service, &bt_addr_any, - (void *)&lan, sizeof(lan), &sdp_handle) != 0) { + if (sdp_register_service(ss, SDP_SERVICE_CLASS_SERIAL_PORT, + &bt_addr_any, (void *)&sp, sizeof(sp), + &sdp_handle) != 0) { errx(1, "Unable to register LAN service with " "local SDP daemon. %s (%d)", strerror(sdp_error(ss)), sdp_error(ss)); From maksim.yevmenkin at gmail.com Tue May 13 17:05:22 2008 From: maksim.yevmenkin at gmail.com (Maksim Yevmenkin) Date: Tue May 13 17:05:24 2008 Subject: rfcomm_sppd -S as generic wrapper Message-ID: [...] > BTW, Luigi's pipe application is interesting, but what about true > two-way communcation? For instance, I would like to have something like > > # rfcomm_sppd -S -c sp -a myPalm -x "coldsync -t serial -s -md" > > ...meaning: Upon receipt of a SP connection request from myPalm we would > fork coldsync to synchronize the Palm (just like USB or serial sync, but > now bluetooth). > > This could even go into /etc/ttys, forking a fresh rfcomm_sppd after the > request terminates. well, i thought about this, but not really sure how to do it cleanly. here is what i mean. with rfcomm_pppd(8) (lan service wrapper) we only need to start one server and register one lan service with local sdpd(8). as soon as client connects to rfcomm_pppd(8) it forks and starts separate ppp(8) instance that handles this particular client. this model works well (imo) here. i'm not sure what rfcomm_sppd(8) wrapper behavior should be. what you seems to be suggesting is that a single rfcomm_sppd(8) instance can only handle single client at a time. this could be a reasonable assumption. > I'm currently doing this in two separate steps, first starting > rfcomm_sppd with some arbitrary pty, then coldsync talking to that pty. > So yes, this definitely works. also your idea about putting rfcomm_sppd(8) entries into /etc/ttys should work as it is, no? did you try to put rfcomm_sppd(8) into /etc/tty entry for the pseudo terminal (slave) part and run coldsync on mater pty? thanks, max From freebsd-bluetooth at oldach.net Tue May 13 17:42:32 2008 From: freebsd-bluetooth at oldach.net (Helge Oldach) Date: Tue May 13 17:42:36 2008 Subject: rfcomm_sppd -S as generic wrapper In-Reply-To: from Maksim Yevmenkin at "13 May 2008 10:05:20" Message-ID: <200805131742.m4DHgRUD039969@sep.oldach.net> Maksim Yevmenkin wrote on Tue, 13 May 2008 19:05:20 +0200 (CEST): > > BTW, Luigi's pipe application is interesting, but what about true > > two-way communcation? For instance, I would like to have something like > > > > # rfcomm_sppd -S -c sp -a myPalm -x "coldsync -t serial -s -md" > > > > ...meaning: Upon receipt of a SP connection request from myPalm we would > > fork coldsync to synchronize the Palm (just like USB or serial sync, but > > now bluetooth). > > > > This could even go into /etc/ttys, forking a fresh rfcomm_sppd after the > > request terminates. > > well, i thought about this, but not really sure how to do it cleanly. > here is what i mean. with rfcomm_pppd(8) (lan service wrapper) we > only need to start one server and register one lan service with local > sdpd(8). as soon as client connects to rfcomm_pppd(8) it forks and > starts separate ppp(8) instance that handles this particular client. > this model works well (imo) here. > > i'm not sure what rfcomm_sppd(8) wrapper behavior should be. what you > seems to be suggesting is that a single rfcomm_sppd(8) instance can > only handle single client at a time. this could be a reasonable > assumption. Good point. However rfcomm_sppd can distinguish different BT peers already, wouldn't that work by starting a separate rfcomm_sppd for each BT peer? > > I'm currently doing this in two separate steps, first starting > > rfcomm_sppd with some arbitrary pty, then coldsync talking to that pty. > > So yes, this definitely works. > > also your idea about putting rfcomm_sppd(8) entries into /etc/ttys > should work as it is, no? did you try to put rfcomm_sppd(8) into > /etc/tty entry for the pseudo terminal (slave) part and run coldsync > on mater pty? Yes, it works. But I'd also have coldsync in /etc/ttys, similar to palm "/usr/local/bin/coldsync -t serial -s -md" unknown on Hmm. Thinking about it, indeed in my case coldsync is the "getty replacement". Putting rfcomm_sppd into /etc/ttys is merely a hack, working around the fact that it terminates after each session. So rfcomm_sppd should probably have some "service selection" mechanism, similar to what pppd does. I know I could do my Palm sync task running network sync via TCP via PPP, however that's a fair bit of overhead. PalmOS can talk serial natively, so why not use that straight away? Actually "network sync" is essentially a 1:1 copy of serial sync (which was invented first), as is USB sync. Regards, Helge From maksim.yevmenkin at gmail.com Tue May 13 17:43:50 2008 From: maksim.yevmenkin at gmail.com (Maksim Yevmenkin) Date: Tue May 13 17:43:52 2008 Subject: obexapp 1.4.9 Message-ID: hello, obexapp 1.4.9 was uploaded at http://www.geocities.com/m_evmenkin/obexapp-1.4.9.tar.gz the only (minor) change is work around for dirname(3). some implementations may modify string passed to dirname(3) therefor do not assume const pointer argument in dirname(3) and always pass a local copy. this is done to be compatible with netbsd. thanks, max From freebsd-bluetooth at oldach.net Tue May 13 19:44:48 2008 From: freebsd-bluetooth at oldach.net (Helge Oldach) Date: Tue May 13 19:44:51 2008 Subject: any reason to require -t dev in rfcomm_sppd -S ? In-Reply-To: from Maksim Yevmenkin at "13 May 2008 09:48:06" Message-ID: <200805131944.m4DJieQL002589@sep.oldach.net> Maksim Yevmenkin wrote on Tue, 13 May 2008 18:48:06 +0200 (CEST): > On Tue, May 13, 2008 at 8:52 AM, Helge Oldach wrote: > > Maksim Yevmenkin wrote on Mon, 21 Apr 2008 20:51:55 +0200 (CEST): > >> On Thu, Apr 17, 2008 at 11:06 AM, Luigi Rizzo wrote: > >> > > >> > On Thu, Apr 17, 2008 at 10:39:16AM -0700, Maksim Yevmenkin wrote: > >> > > On Thu, Apr 17, 2008 at 4:56 AM, Luigi Rizzo wrote: > >> > > > hi, is there any compelling reason to require > >> > > > the '-t device' option in rfcomm_sppd when used in server mode ? > >> > > > >> > > rfcomm_sppd(1) does not > >> > > do anything to tty when running using stdin/stdout in client mode. the > >> > > assumption here is that whatever calls rfcomm_sppd(1) will setup > >> > > tty/fd properly. > >> > > > >> > > > I tried to disable the one-line that checks it in the code, and > >> > > > things seem to work - and this makes the program very convenient > >> > > > to use in a pipeline, e.g. to receive data from a remote bluetooth > >> > > > device. > >> > > > >> > > right. can you please provide usage example? i certainly would not > >> > > object to making the change you are requesting. > >> > > >> > sure - i need to listen to a portable ElectroCardioGram (ECG) device > >> > which talks to the external world through bluetooth. The device > >> > must have some kind of modem inside - its console port says it is > >> > issuing commands such as > >> > > >> > AT+ZV SPPConnect XXX > >> > ... > >> > > >> > where XXX is the (manually configured) address of the bluetooth > >> > dongle on the PC. On the FreeBSD side, running > >> > "rfcom_sppd -a YYY" (without the -S option, YYY is the ECG address) > >> > sometimes connects, but most of the times doesnt. > >> > > >> > With a patched rfcomm_sppp i can just do > >> > > >> > rfcomm_sppd -S -a YYY | my_data_logger > >> > > >> > rather than having to manually select an available tty/pty pair > >> > > >> > Don't know how many devices behave in this way, but a > >> > search for "AT+ZV SPPConnect" gives several matches with > >> > documentation for embedded hardware. > >> > >> ok, please try the attached patch and see if it works for you. i > >> basically removed the check for tty name in server mode, bind to > >> "wildcard" channel instead of generating one based on pid (if channel > >> was not specified) and fixed a possible problem with service > >> registration in server mode (i.e. always register serial port > >> service). > > > > Your patch applies cleanly, but I just get > > > > # rfcomm_sppd -S > > rfcomm_sppd: Could not get socket name > > # > > > > It seems that getsockbyname fails. What is the reason for that anyway? > > well, there is a problem with my previous patch. please try the > attached updated patch. Oops, the case is pretty clear. I should have seen that myself. All is fine with this patch. Helge From maksim.yevmenkin at gmail.com Wed May 14 16:55:54 2008 From: maksim.yevmenkin at gmail.com (Maksim Yevmenkin) Date: Wed May 14 16:55:57 2008 Subject: any reason to require -t dev in rfcomm_sppd -S ? In-Reply-To: <200805131944.m4DJieQL002589@sep.oldach.net> References: <200805131944.m4DJieQL002589@sep.oldach.net> Message-ID: [...] >> > Your patch applies cleanly, but I just get >> > >> > # rfcomm_sppd -S >> > rfcomm_sppd: Could not get socket name >> > # >> > >> > It seems that getsockbyname fails. What is the reason for that anyway? >> >> well, there is a problem with my previous patch. please try the >> attached updated patch. > > Oops, the case is pretty clear. I should have seen that myself. > > All is fine with this patch. i've just committed the patch. thanks for your help. max From maksim.yevmenkin at gmail.com Thu May 15 13:58:01 2008 From: maksim.yevmenkin at gmail.com (Maksim Yevmenkin) Date: Thu May 15 13:58:06 2008 Subject: cvs commit: src/usr.bin/bluetooth/rfcomm_sppd rfcomm_sppd.1 rfcomm_sppd.c In-Reply-To: <200805151814.14386.doconnor@gsoft.com.au> References: <200805141647.m4EGlUP1021019@repoman.freebsd.org> <200805151814.14386.doconnor@gsoft.com.au> Message-ID: [moving to freebsd-bluetooth@] On 5/15/08, Daniel O'Connor wrote: > On Thu, 15 May 2008, Maksim Yevmenkin wrote: > > Modified files: > > usr.bin/bluetooth/rfcomm_sppd rfcomm_sppd.1 rfcomm_sppd.c > > Log: > > Make -t optional in server mode. If not specified use > > stdin/stdout. Document this. Do not require channel number in server > > mode. If not specified - bind to ''wildcard'' channel zero. Real > > channel number will be obtained automatically and registered with > > local sdpd(8). While I'm here fix serial port service registration. > > How hard would it be to have a '-t auto' and have it print out the pty > it just allocated? It would make it much easier for scripts to work if > that was possible. > > (Maybe just call openpty()?) not hard at all. however, how would rfcomm_sppd(1) print tty name if, say, it was asked to run in background? perhaps it would be better to teach rfcomm_sppd(1) to work with nmdm(4)? thanks, max From doconnor at gsoft.com.au Sun May 18 10:47:04 2008 From: doconnor at gsoft.com.au (Daniel O'Connor) Date: Sun May 18 10:47:08 2008 Subject: cvs commit: src/usr.bin/bluetooth/rfcomm_sppd rfcomm_sppd.1 rfcomm_sppd.c In-Reply-To: References: <200805141647.m4EGlUP1021019@repoman.freebsd.org> <200805151814.14386.doconnor@gsoft.com.au> Message-ID: <200805181952.00112.doconnor@gsoft.com.au> Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: This is a digitally signed message part. Url : http://lists.freebsd.org/pipermail/freebsd-bluetooth/attachments/20080518/f3a3c5d5/attachment.pgp From lsantagostini at gmail.com Mon May 19 10:45:05 2008 From: lsantagostini at gmail.com (Leonardo Santagostini) Date: Mon May 19 10:45:07 2008 Subject: Problem with a BCM2035B dongle Message-ID: <9ab7eeeb0805190319u30ccbeefq1511afa063bd75fe@mail.gmail.com> Hi List: I was already googling and browsing over Internet about mi problem. Im using FreeBSD 7.0-RELEASE and the problem is that the donlge dont want to work. I tried kldloanding various modeules, here comes my kldstat pcleo# kldstat Id Refs Address Size Name 1 32 0xc0400000 9130cc kernel 2 1 0xc0d14000 ce30 if_wi.ko 3 1 0xc0d21000 14324 snd_hda.ko 4 2 0xc0d36000 4a5ac sound.ko 5 1 0xc0d81000 19f34 if_ral.ko 6 1 0xc0d9b000 80ea28 nvidia.ko 7 2 0xc15aa000 28658 linux.ko 8 1 0xc15d3000 3130 ubtbcmfw.ko 9 1 0xc15d7000 802c ng_ubt.ko 10 6 0xc15e0000 d3a0 netgraph.ko 11 1 0xc15ee000 1bdc wlan_xauth.ko 12 1 0xc15f0000 6a32c acpi.ko 13 4 0xc5529000 2000 ng_bluetooth.ko 14 1 0xc552b000 d000 ng_hci.ko 15 1 0xc5558000 f000 ng_l2cap.ko 16 1 0xc5569000 19000 ng_btsocket.ko 17 1 0xc558b000 4000 ng_socket.ko The /var/log/messages tells: May 19 07:09:47 pcleo root: Unknown USB device: vendor 0x0a5c product 0x2035 bus uhub1 May 19 07:09:47 pcleo kernel: ubt0: on uhub1 May 19 07:09:47 pcleo kernel: ubt0: Interface 0 endpoints: interrupt=0x81, bulk-in=0x82, bulk-out=0x2 May 19 07:09:47 pcleo kernel: ubt0: Interface 1 (alt.config 4) endpoints: isoc-in=0x83, isoc-out=0x3; wMaxPacketSize=64; nframes=5, buffer size=320 May 19 07:09:47 pcleo root: /etc/rc.d/bluetooth: ERROR: Unable to setup Bluetooth stack for device ubt0 i been trying bcmfw without results, in fact, when i do a ls -l /dev/u* i cant see an ubtbcmfw device created. pcleo# ls -l /dev/u* crw-r--r-- 1 root operator 0, 79 May 19 06:29 /dev/uhid0 crw------- 1 root wheel 0, 77 May 19 06:29 /dev/ukbd0 lrwxr-xr-x 1 root wheel 6 May 19 06:29 /dev/urandom -> random crw-rw---- 1 root operator 0, 38 May 19 06:29 /dev/usb crw-rw---- 1 root operator 0, 37 May 19 06:29 /dev/usb0 crw-rw---- 1 root operator 0, 39 May 19 06:29 /dev/usb1 crw-rw---- 1 root operator 0, 40 May 19 06:29 /dev/usb2 I followed the instructions for dumping my device, here is. If you can help me i will really apreciate it. Thanks for all Sincerelly Leonardo Santagostini -------------- next part -------------- A non-text attachment was scrubbed... Name: init.dump Type: application/octet-stream Size: 590 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-bluetooth/attachments/20080519/36f709f1/init.obj From maksim.yevmenkin at gmail.com Mon May 19 17:32:54 2008 From: maksim.yevmenkin at gmail.com (Maksim Yevmenkin) Date: Mon May 19 17:32:56 2008 Subject: Problem with a BCM2035B dongle In-Reply-To: <9ab7eeeb0805190319u30ccbeefq1511afa063bd75fe@mail.gmail.com> References: <9ab7eeeb0805190319u30ccbeefq1511afa063bd75fe@mail.gmail.com> Message-ID: Hello, > I was already googling and browsing over Internet about mi problem. > Im using FreeBSD 7.0-RELEASE and the problem is that the donlge dont want to > work. > > I tried kldloanding various modeules, here comes my kldstat > pcleo# kldstat > Id Refs Address Size Name > 1 32 0xc0400000 9130cc kernel > 2 1 0xc0d14000 ce30 if_wi.ko > 3 1 0xc0d21000 14324 snd_hda.ko > 4 2 0xc0d36000 4a5ac sound.ko > 5 1 0xc0d81000 19f34 if_ral.ko > 6 1 0xc0d9b000 80ea28 nvidia.ko > 7 2 0xc15aa000 28658 linux.ko > 8 1 0xc15d3000 3130 ubtbcmfw.ko > 9 1 0xc15d7000 802c ng_ubt.ko > 10 6 0xc15e0000 d3a0 netgraph.ko > 11 1 0xc15ee000 1bdc wlan_xauth.ko > 12 1 0xc15f0000 6a32c acpi.ko > 13 4 0xc5529000 2000 ng_bluetooth.ko > 14 1 0xc552b000 d000 ng_hci.ko > 15 1 0xc5558000 f000 ng_l2cap.ko > 16 1 0xc5569000 19000 ng_btsocket.ko > 17 1 0xc558b000 4000 ng_socket.ko looks fine > The /var/log/messages tells: > > May 19 07:09:47 pcleo root: Unknown USB device: vendor 0x0a5c product 0x2035 > bus uhub1 > May 19 07:09:47 pcleo kernel: ubt0: rev 2.00/1.00, addr 3> on uhub1 > May 19 07:09:47 pcleo kernel: ubt0: Interface 0 endpoints: interrupt=0x81, > bulk-in=0x82, bulk-out=0x2 > May 19 07:09:47 pcleo kernel: ubt0: Interface 1 (alt.config 4) endpoints: > isoc-in=0x83, isoc-out=0x3; wMaxPacketSize=64; nframes=5, buffer size=320 > May 19 07:09:47 pcleo root: /etc/rc.d/bluetooth: ERROR: Unable to setup > Bluetooth stack for device ubt0 this does not look good. i been trying bcmfw without results, in fact, when i do a ls -l /dev/u* i > cant see an ubtbcmfw device created. > > pcleo# ls -l /dev/u* > crw-r--r-- 1 root operator 0, 79 May 19 06:29 /dev/uhid0 > crw------- 1 root wheel 0, 77 May 19 06:29 /dev/ukbd0 > lrwxr-xr-x 1 root wheel 6 May 19 06:29 /dev/urandom -> random > crw-rw---- 1 root operator 0, 38 May 19 06:29 /dev/usb > crw-rw---- 1 root operator 0, 37 May 19 06:29 /dev/usb0 > crw-rw---- 1 root operator 0, 39 May 19 06:29 /dev/usb1 > crw-rw---- 1 root operator 0, 40 May 19 06:29 /dev/usb2 ubtbcmfw(4) is a firmware driver for broadcom bcm2033 chip based bluetooth usb devices. since you have bcm2035b this driver will not work and you do not even need it. > I followed the instructions for dumping my device, here is. ok, i think, i know what problem is. here is the fragment of the dump you sent, i.e. beetle% ./hcidump -xr ~/init.dump HCIDump - HCI packet analyzer ver 1.5 < HCI Command: Reset(0x03|0x0003) plen 0 > HCI Event: Command Complete(0x0e) plen 4 01 03 0C 00 < HCI Command: Read BD ADDR(0x04|0x0009) plen 0 > HCI Event: Command Complete(0x0e) plen 10 01 09 10 00 00 00 00 00 00 00 it appears that in response to the hci "read bd addr" command your device returns an invalid bd_addr, i.e. 00:00:00:00:00:00. i saw a post in one of the linux bluetooth related mailing lists that describes exactly the same problem (http://www.spinics.net/lists/linux-bluetooth/msg00020.html). i have no idea how to fix it at this point, and, inclined to say that this device is broken or needs some non-standard initialization sequence. i'd suggest to get a different dongle if possible. thanks, max From maksim.yevmenkin at gmail.com Mon May 19 20:07:13 2008 From: maksim.yevmenkin at gmail.com (Maksim Yevmenkin) Date: Mon May 19 20:07:17 2008 Subject: cvs commit: src/usr.bin/bluetooth/rfcomm_sppd rfcomm_sppd.1 rfcomm_sppd.c In-Reply-To: <200805181952.00112.doconnor@gsoft.com.au> References: <200805141647.m4EGlUP1021019@repoman.freebsd.org> <200805151814.14386.doconnor@gsoft.com.au> <200805181952.00112.doconnor@gsoft.com.au> Message-ID: On Sun, May 18, 2008 at 3:21 AM, Daniel O'Connor wrote: > On Thu, 15 May 2008, Maksim Yevmenkin wrote: >> > How hard would it be to have a '-t auto' and have it print out the >> > pty it just allocated? It would make it much easier for scripts to >> > work if that was possible. >> > >> > (Maybe just call openpty()?) >> >> not hard at all. however, how would rfcomm_sppd(1) print tty name if, >> say, it was asked to run in background? perhaps it would be better to >> teach rfcomm_sppd(1) to work with nmdm(4)? > > I don't think nmdm would make a difference in this respect. it depends on usage scenario, imo. please read below. > I am thinking of an operating mode where a script or daemon runs when a > device associates and sets up channels the user has configured. So the > script runs rfcomm_sppd and groks the output to find what PTY has been > allocated and creates a symlink to a human understandable name > (eg /dev/gps0 or whatever) right, that is what i initially wanted to do. the idea was to have complicated configuration file which describes what what rfcomm_sppd(1) should do when a device with a given bd_addr connects on a certain rfcomm channel. then i realized that serial port service is not really good candidate for multiplexing. it all boils down to the fact that only one client can use virtual serial port at a time. i chose pty(4) over nmdm(4) initially to be able to a) call openpty() b) fork() c) redirect child's stdin/out to pty d) exec() something in child. that is similar to how rfcomm_pppd(8) wrapper works (without doing pty part). as i thought about it a bit more, i convinced myself that it probably would be much easier to run multiple instances of rfcomm_sppd(1) on different channels. each instance would then do something different. i still need to write the part where rfcomm_sppd(1) executes something external when client connects. > I have attached a patch which uses openpty() and seems to work fine > (tested quickly against my BT GPS unit & phone). If the patch doesn't > make it you can get it from > http://www.gsoft.com.au/~doconnor/rfcomm_sppd-pty.diff i do not see how slave pty name is being passed back to rfcomm_sppd(1) invoker in _server_ mode. are you suggesting to parse syslog messages? or are you suggesting to have other process that is actively looking for "known" bluetooth devices in range (i.e. perform discovery or ping) and, when found, proactively start rfcomm_sppd(1) in _client_ mode to connect to found devices? > On a related note I find I have to 'kill -9' rfcomm_sppd sometimes if I > have connected to the PTY and then disconnected, eg.. hmm... interesting... i will take a look. just need to find my old bluetooth gps unit. thanks, max From doconnor at gsoft.com.au Mon May 19 23:16:14 2008 From: doconnor at gsoft.com.au (Daniel O'Connor) Date: Mon May 19 23:16:17 2008 Subject: cvs commit: src/usr.bin/bluetooth/rfcomm_sppd rfcomm_sppd.1 rfcomm_sppd.c In-Reply-To: References: <200805141647.m4EGlUP1021019@repoman.freebsd.org> <200805181952.00112.doconnor@gsoft.com.au> Message-ID: <200805200845.57007.doconnor@gsoft.com.au> On Tue, 20 May 2008, Maksim Yevmenkin wrote: > > I am thinking of an operating mode where a script or daemon runs > > when a device associates and sets up channels the user has > > configured. So the script runs rfcomm_sppd and groks the output to > > find what PTY has been allocated and creates a symlink to a human > > understandable name (eg /dev/gps0 or whatever) > > right, that is what i initially wanted to do. the idea was to have > complicated configuration file which describes what what > rfcomm_sppd(1) should do when a device with a given bd_addr connects Shouldn't be that complex ;) > on a certain rfcomm channel. then i realized that serial port service > is not really good candidate for multiplexing. it all boils down to > the fact that only one client can use virtual serial port at a time. Why would you be multiplexing it? It's a virtual serial port, pty sounds like a pretty good match. ie I think I am misunderstanding what you are trying to say. > i chose pty(4) over nmdm(4) initially to be able to > > a) call openpty() > b) fork() > c) redirect child's stdin/out to pty > d) exec() something in child. > > that is similar to how rfcomm_pppd(8) wrapper works (without doing > pty part). as i thought about it a bit more, i convinced myself that > it probably would be much easier to run multiple instances of > rfcomm_sppd(1) on different channels. each instance would then do > something different. i still need to write the part where > rfcomm_sppd(1) executes something external when client connects. OK. > > I have attached a patch which uses openpty() and seems to work fine > > (tested quickly against my BT GPS unit & phone). If the patch > > doesn't make it you can get it from > > http://www.gsoft.com.au/~doconnor/rfcomm_sppd-pty.diff > > i do not see how slave pty name is being passed back to > rfcomm_sppd(1) invoker in _server_ mode. are you suggesting to parse > syslog messages? or are you suggesting to have other process that is Mmm good point :( I was thinking that in server mode it opened the PTY then waited for a connection but that isn't the case.. I guess it could be (although it mangles up the code) > actively looking for "known" bluetooth devices in range (i.e. perform > discovery or ping) and, when found, proactively start rfcomm_sppd(1) > in _client_ mode to connect to found devices? I was thinking basically of only using client mode - I haven't used server mode so it didn't really enter my thoughts :) As you say I was thinking that you poll for known devices (that the user has entered into a config file) and run rfcomm_sppd in client mode to connect to them. I am not sure how/why server mode is actually used - I only have experience with devices that are basically using BT as an RS232 replacement. > > On a related note I find I have to 'kill -9' rfcomm_sppd sometimes > > if I have connected to the PTY and then disconnected, eg.. > > hmm... interesting... i will take a look. just need to find my old > bluetooth gps unit. Thanks.. Could be my dodgy GPS unit of course :) ($35 off ebay) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: This is a digitally signed message part. Url : http://lists.freebsd.org/pipermail/freebsd-bluetooth/attachments/20080519/92860e5e/attachment.pgp From maksim.yevmenkin at gmail.com Mon May 19 23:56:23 2008 From: maksim.yevmenkin at gmail.com (Maksim Yevmenkin) Date: Mon May 19 23:56:25 2008 Subject: cvs commit: src/usr.bin/bluetooth/rfcomm_sppd rfcomm_sppd.1 rfcomm_sppd.c In-Reply-To: <200805200845.57007.doconnor@gsoft.com.au> References: <200805141647.m4EGlUP1021019@repoman.freebsd.org> <200805181952.00112.doconnor@gsoft.com.au> <200805200845.57007.doconnor@gsoft.com.au> Message-ID: On Mon, May 19, 2008 at 4:15 PM, Daniel O'Connor wrote: > On Tue, 20 May 2008, Maksim Yevmenkin wrote: >> > I am thinking of an operating mode where a script or daemon runs >> > when a device associates and sets up channels the user has >> > configured. So the script runs rfcomm_sppd and groks the output to >> > find what PTY has been allocated and creates a symlink to a human >> > understandable name (eg /dev/gps0 or whatever) >> >> right, that is what i initially wanted to do. the idea was to have >> complicated configuration file which describes what what >> rfcomm_sppd(1) should do when a device with a given bd_addr connects > > Shouldn't be that complex ;) well, yes :) >> on a certain rfcomm channel. then i realized that serial port service >> is not really good candidate for multiplexing. it all boils down to >> the fact that only one client can use virtual serial port at a time. > > Why would you be multiplexing it? It's a virtual serial port, pty sounds > like a pretty good match. ie I think I am misunderstanding what you are > trying to say. ok, i will give you an example. lets say i have a couple of bluetooth devices. lets say device #1 is a handheld and device #2 is some other client device that wants to use serial port service on the pc. say, its a bluetooth scanner/keyboard/etc. type device that proactively connects to the host computer and sends stream of data. with virtual serial port there is no real need to register two (or more) serial port services on the host pc. one could argue that rfcomm_sppd(1) should have a configuration file that says if connected to device #1 { execute sync application } if connected to device #2 { dump data } technically, both devices could use the same serial port service registered on the same rfcomm channel on the same host pc. the data coming from two different rfcomm connections from two different devices. the server bluetooth endpoint just happens to be the same, but the server will have two connections and two separate pty's for both clients. this is the soft of multiplexing i'm talking about. the same will work in client mode too. >> > I have attached a patch which uses openpty() and seems to work fine >> > (tested quickly against my BT GPS unit & phone). If the patch >> > doesn't make it you can get it from >> > http://www.gsoft.com.au/~doconnor/rfcomm_sppd-pty.diff >> >> i do not see how slave pty name is being passed back to >> rfcomm_sppd(1) invoker in _server_ mode. are you suggesting to parse >> syslog messages? or are you suggesting to have other process that is > > Mmm good point :( > I was thinking that in server mode it opened the PTY then waited for a > connection but that isn't the case.. this is the case. it opens pty first then it does listen/accept/etc. > I guess it could be (although it mangles up the code) > >> actively looking for "known" bluetooth devices in range (i.e. perform >> discovery or ping) and, when found, proactively start rfcomm_sppd(1) >> in _client_ mode to connect to found devices? > > I was thinking basically of only using client mode - I haven't used > server mode so it didn't really enter my thoughts :) > > As you say I was thinking that you poll for known devices (that the user > has entered into a config file) and run rfcomm_sppd in client mode to > connect to them. > > I am not sure how/why server mode is actually used - I only have > experience with devices that are basically using BT as an RS232 > replacement. right, there aren't many examples of server mode usage, but i was thinking about "serial console" over bluetooth type thing. of course it will never be a real serial console, just another out-of-band access. could be useful to somebody. thanks, max From lsantagostini at gmail.com Tue May 20 01:45:18 2008 From: lsantagostini at gmail.com (Leonardo Santagostini) Date: Tue May 20 01:45:21 2008 Subject: Problem with a BCM2035B dongle In-Reply-To: References: <9ab7eeeb0805190319u30ccbeefq1511afa063bd75fe@mail.gmail.com> Message-ID: <9ab7eeeb0805191845y3e185cb3w42988296b449d35c@mail.gmail.com> Ok thanks for the reply Max. I will try with another dongle But, if you want to make some probes with this dongle, just tellme you will be welcome ;) Sincerely. Leonardo 2008/5/19 Maksim Yevmenkin : > Hello, > > > I was already googling and browsing over Internet about mi problem. > > Im using FreeBSD 7.0-RELEASE and the problem is that the donlge dont want > to > > work. > > > > I tried kldloanding various modeules, here comes my kldstat > > pcleo# kldstat > > Id Refs Address Size Name > > 1 32 0xc0400000 9130cc kernel > > 2 1 0xc0d14000 ce30 if_wi.ko > > 3 1 0xc0d21000 14324 snd_hda.ko > > 4 2 0xc0d36000 4a5ac sound.ko > > 5 1 0xc0d81000 19f34 if_ral.ko > > 6 1 0xc0d9b000 80ea28 nvidia.ko > > 7 2 0xc15aa000 28658 linux.ko > > 8 1 0xc15d3000 3130 ubtbcmfw.ko > > 9 1 0xc15d7000 802c ng_ubt.ko > > 10 6 0xc15e0000 d3a0 netgraph.ko > > 11 1 0xc15ee000 1bdc wlan_xauth.ko > > 12 1 0xc15f0000 6a32c acpi.ko > > 13 4 0xc5529000 2000 ng_bluetooth.ko > > 14 1 0xc552b000 d000 ng_hci.ko > > 15 1 0xc5558000 f000 ng_l2cap.ko > > 16 1 0xc5569000 19000 ng_btsocket.ko > > 17 1 0xc558b000 4000 ng_socket.ko > > looks fine > > > The /var/log/messages tells: > > > > May 19 07:09:47 pcleo root: Unknown USB device: vendor 0x0a5c product > 0x2035 > > bus uhub1 > > May 19 07:09:47 pcleo kernel: ubt0: > rev 2.00/1.00, addr 3> on uhub1 > > May 19 07:09:47 pcleo kernel: ubt0: Interface 0 endpoints: > interrupt=0x81, > > bulk-in=0x82, bulk-out=0x2 > > May 19 07:09:47 pcleo kernel: ubt0: Interface 1 (alt.config 4) endpoints: > > isoc-in=0x83, isoc-out=0x3; wMaxPacketSize=64; nframes=5, buffer size=320 > > May 19 07:09:47 pcleo root: /etc/rc.d/bluetooth: ERROR: Unable to setup > > Bluetooth stack for device ubt0 > > this does not look good. > > i been trying bcmfw without results, in fact, when i do a ls -l /dev/u* i > > cant see an ubtbcmfw device created. > > > > pcleo# ls -l /dev/u* > > crw-r--r-- 1 root operator 0, 79 May 19 06:29 /dev/uhid0 > > crw------- 1 root wheel 0, 77 May 19 06:29 /dev/ukbd0 > > lrwxr-xr-x 1 root wheel 6 May 19 06:29 /dev/urandom -> > random > > crw-rw---- 1 root operator 0, 38 May 19 06:29 /dev/usb > > crw-rw---- 1 root operator 0, 37 May 19 06:29 /dev/usb0 > > crw-rw---- 1 root operator 0, 39 May 19 06:29 /dev/usb1 > > crw-rw---- 1 root operator 0, 40 May 19 06:29 /dev/usb2 > > ubtbcmfw(4) is a firmware driver for broadcom bcm2033 chip based > bluetooth usb devices. since you have bcm2035b this driver will not > work and you do not even need it. > > > I followed the instructions for dumping my device, here is. > > ok, i think, i know what problem is. here is the fragment of the dump > you sent, i.e. > > beetle% ./hcidump -xr ~/init.dump > HCIDump - HCI packet analyzer ver 1.5 > < HCI Command: Reset(0x03|0x0003) plen 0 > > HCI Event: Command Complete(0x0e) plen 4 > 01 03 0C 00 > < HCI Command: Read BD ADDR(0x04|0x0009) plen 0 > > HCI Event: Command Complete(0x0e) plen 10 > 01 09 10 00 00 00 00 00 00 00 > > it appears that in response to the hci "read bd addr" command your > device returns an invalid bd_addr, i.e. 00:00:00:00:00:00. i saw a > post in one of the linux bluetooth related mailing lists that > describes exactly the same problem > (http://www.spinics.net/lists/linux-bluetooth/msg00020.html). i have > no idea how to fix it at this point, and, inclined to say that this > device is broken or needs some non-standard initialization sequence. > i'd suggest to get a different dongle if possible. > > thanks, > max > -- Saludos.- Leonardo Santagostini From lsantagostini at gmail.com Tue May 20 01:48:36 2008 From: lsantagostini at gmail.com (Leonardo Santagostini) Date: Tue May 20 01:48:38 2008 Subject: Problem with a BCM2035B dongle In-Reply-To: References: <9ab7eeeb0805190319u30ccbeefq1511afa063bd75fe@mail.gmail.com> Message-ID: <9ab7eeeb0805191848p11e3b6d4u9bdd423e4e7d2533@mail.gmail.com> Sorry, but, by the way. In the manufacturer page says: The BCM2035 is based on the production and UnPlugFest proven architecture of the BCM2033 Bluetooth baseband core (BBC), peripheral transport unit (PTU) http://broadcom.com/products/Bluetooth/Bluetooth-RF-Silicon-and-Software-Solutions/BCM2035 Do you think we can make something ? Yours, Leonardo 2008/5/19 Maksim Yevmenkin : > Hello, > > > I was already googling and browsing over Internet about mi problem. > > Im using FreeBSD 7.0-RELEASE and the problem is that the donlge dont want > to > > work. > > > > I tried kldloanding various modeules, here comes my kldstat > > pcleo# kldstat > > Id Refs Address Size Name > > 1 32 0xc0400000 9130cc kernel > > 2 1 0xc0d14000 ce30 if_wi.ko > > 3 1 0xc0d21000 14324 snd_hda.ko > > 4 2 0xc0d36000 4a5ac sound.ko > > 5 1 0xc0d81000 19f34 if_ral.ko > > 6 1 0xc0d9b000 80ea28 nvidia.ko > > 7 2 0xc15aa000 28658 linux.ko > > 8 1 0xc15d3000 3130 ubtbcmfw.ko > > 9 1 0xc15d7000 802c ng_ubt.ko > > 10 6 0xc15e0000 d3a0 netgraph.ko > > 11 1 0xc15ee000 1bdc wlan_xauth.ko > > 12 1 0xc15f0000 6a32c acpi.ko > > 13 4 0xc5529000 2000 ng_bluetooth.ko > > 14 1 0xc552b000 d000 ng_hci.ko > > 15 1 0xc5558000 f000 ng_l2cap.ko > > 16 1 0xc5569000 19000 ng_btsocket.ko > > 17 1 0xc558b000 4000 ng_socket.ko > > looks fine > > > The /var/log/messages tells: > > > > May 19 07:09:47 pcleo root: Unknown USB device: vendor 0x0a5c product > 0x2035 > > bus uhub1 > > May 19 07:09:47 pcleo kernel: ubt0: > rev 2.00/1.00, addr 3> on uhub1 > > May 19 07:09:47 pcleo kernel: ubt0: Interface 0 endpoints: > interrupt=0x81, > > bulk-in=0x82, bulk-out=0x2 > > May 19 07:09:47 pcleo kernel: ubt0: Interface 1 (alt.config 4) endpoints: > > isoc-in=0x83, isoc-out=0x3; wMaxPacketSize=64; nframes=5, buffer size=320 > > May 19 07:09:47 pcleo root: /etc/rc.d/bluetooth: ERROR: Unable to setup > > Bluetooth stack for device ubt0 > > this does not look good. > > i been trying bcmfw without results, in fact, when i do a ls -l /dev/u* i > > cant see an ubtbcmfw device created. > > > > pcleo# ls -l /dev/u* > > crw-r--r-- 1 root operator 0, 79 May 19 06:29 /dev/uhid0 > > crw------- 1 root wheel 0, 77 May 19 06:29 /dev/ukbd0 > > lrwxr-xr-x 1 root wheel 6 May 19 06:29 /dev/urandom -> > random > > crw-rw---- 1 root operator 0, 38 May 19 06:29 /dev/usb > > crw-rw---- 1 root operator 0, 37 May 19 06:29 /dev/usb0 > > crw-rw---- 1 root operator 0, 39 May 19 06:29 /dev/usb1 > > crw-rw---- 1 root operator 0, 40 May 19 06:29 /dev/usb2 > > ubtbcmfw(4) is a firmware driver for broadcom bcm2033 chip based > bluetooth usb devices. since you have bcm2035b this driver will not > work and you do not even need it. > > > I followed the instructions for dumping my device, here is. > > ok, i think, i know what problem is. here is the fragment of the dump > you sent, i.e. > > beetle% ./hcidump -xr ~/init.dump > HCIDump - HCI packet analyzer ver 1.5 > < HCI Command: Reset(0x03|0x0003) plen 0 > > HCI Event: Command Complete(0x0e) plen 4 > 01 03 0C 00 > < HCI Command: Read BD ADDR(0x04|0x0009) plen 0 > > HCI Event: Command Complete(0x0e) plen 10 > 01 09 10 00 00 00 00 00 00 00 > > it appears that in response to the hci "read bd addr" command your > device returns an invalid bd_addr, i.e. 00:00:00:00:00:00. i saw a > post in one of the linux bluetooth related mailing lists that > describes exactly the same problem > (http://www.spinics.net/lists/linux-bluetooth/msg00020.html). i have > no idea how to fix it at this point, and, inclined to say that this > device is broken or needs some non-standard initialization sequence. > i'd suggest to get a different dongle if possible. > > thanks, > max > -- Saludos.- Leonardo Santagostini From maksim.yevmenkin at gmail.com Tue May 20 16:50:46 2008 From: maksim.yevmenkin at gmail.com (Maksim Yevmenkin) Date: Tue May 20 16:50:49 2008 Subject: Problem with a BCM2035B dongle In-Reply-To: <9ab7eeeb0805191848p11e3b6d4u9bdd423e4e7d2533@mail.gmail.com> References: <9ab7eeeb0805190319u30ccbeefq1511afa063bd75fe@mail.gmail.com> <9ab7eeeb0805191848p11e3b6d4u9bdd423e4e7d2533@mail.gmail.com> Message-ID: On 5/19/08, Leonardo Santagostini wrote: > Sorry, but, by the way. > In the manufacturer page says: > > The BCM2035 is based on the production and UnPlugFest proven architecture of > the BCM2033 Bluetooth baseband core (BBC), peripheral transport unit (PTU) it really does not mean anything. its just marking buzz words, imo. "architecture" is too much generic word. all it probably means is that the 2035 chip has the same functional blocks as 2033 chip, i.e. cpu, memory, flash, radio etc. > Do you think we can make something ? did your 2035 dongle come with driver cd (for windows)? can you find any .bin or .hex files on the driver cd? what would really be helpful is a usb snoop trace (from windows) that shows how windows initializes this device. thanks, max From Tom at Malcolmson.com Tue May 20 19:29:20 2008 From: Tom at Malcolmson.com (Tom Malcolmson) Date: Tue May 20 19:29:24 2008 Subject: Looking for mini-pci bluetooth adapter Message-ID: <48332249.3010709@Malcolmson.com> Is there a BSD driver for any mini-pci bluetooth adapters? Preferably one that is 'current' - ie. is still available for purchase and supports bluetooth 2.0. Thanks, Tom. From lsantagostini at gmail.com Tue May 20 19:31:02 2008 From: lsantagostini at gmail.com (Leonardo Santagostini) Date: Tue May 20 19:31:05 2008 Subject: Problem with a BCM2035B dongle In-Reply-To: References: <9ab7eeeb0805190319u30ccbeefq1511afa063bd75fe@mail.gmail.com> <9ab7eeeb0805191848p11e3b6d4u9bdd423e4e7d2533@mail.gmail.com> Message-ID: <9ab7eeeb0805201231o65e5058h427f4bafa8d27a39@mail.gmail.com> Max: I have not installed windows at home, but i like challenges and i will install it onto a hard disk and i will find the drivers to make it work on windows. Do you have any tool to make a trace from the usb device ? Thanks really much Yours, Leonardo 2008/5/20 Maksim Yevmenkin : > On 5/19/08, Leonardo Santagostini wrote: > > Sorry, but, by the way. > > In the manufacturer page says: > > > > The BCM2035 is based on the production and UnPlugFest proven architecture > of > > the BCM2033 Bluetooth baseband core (BBC), peripheral transport unit > (PTU) > > it really does not mean anything. its just marking buzz words, imo. > "architecture" is too much generic word. all it probably means is that > the 2035 chip has the same functional blocks as 2033 chip, i.e. cpu, > memory, flash, radio etc. > > > Do you think we can make something ? > > did your 2035 dongle come with driver cd (for windows)? can you find > any .bin or .hex files on the driver cd? > > what would really be helpful is a usb snoop trace (from windows) that > shows how windows initializes this device. > > thanks, > max > -- Saludos.- Leonardo Santagostini From maksim.yevmenkin at gmail.com Tue May 20 23:43:14 2008 From: maksim.yevmenkin at gmail.com (Maksim Yevmenkin) Date: Tue May 20 23:43:18 2008 Subject: Problem with a BCM2035B dongle In-Reply-To: <9ab7eeeb0805201231o65e5058h427f4bafa8d27a39@mail.gmail.com> References: <9ab7eeeb0805190319u30ccbeefq1511afa063bd75fe@mail.gmail.com> <9ab7eeeb0805191848p11e3b6d4u9bdd423e4e7d2533@mail.gmail.com> <9ab7eeeb0805201231o65e5058h427f4bafa8d27a39@mail.gmail.com> Message-ID: On 5/20/08, Leonardo Santagostini wrote: > Max: > > I have not installed windows at home, but i like challenges and i will > install it onto a hard disk and i will find the drivers to make it work on > windows. > > Do you have any tool to make a trace from the usb device ? here is one - never tried to use it myself http://sourceforge.net/projects/usbsnoop/ thanks, max From maksim.yevmenkin at gmail.com Tue May 20 23:52:55 2008 From: maksim.yevmenkin at gmail.com (Maksim Yevmenkin) Date: Tue May 20 23:52:59 2008 Subject: Looking for mini-pci bluetooth adapter In-Reply-To: <48332249.3010709@Malcolmson.com> References: <48332249.3010709@Malcolmson.com> Message-ID: On 5/20/08, Tom Malcolmson wrote: > Is there a BSD driver for any mini-pci bluetooth adapters? Preferably one > that is 'current' - ie. is still available for purchase and supports > bluetooth 2.0. it depends on the particular mini-pci bluetooth card and how it presents itself. it could be a serial port, usb bluetooth device or something else. if the card looks like serial port or usb device then it will likely to work. usually no special drivers are required for usb or serial bluetooth devices. thanks, max From doconnor at gsoft.com.au Wed May 21 00:02:47 2008 From: doconnor at gsoft.com.au (Daniel O'Connor) Date: Wed May 21 00:02:50 2008 Subject: cvs commit: src/usr.bin/bluetooth/rfcomm_sppd rfcomm_sppd.1 rfcomm_sppd.c In-Reply-To: References: <200805141647.m4EGlUP1021019@repoman.freebsd.org> <200805200845.57007.doconnor@gsoft.com.au> Message-ID: <200805210932.40993.doconnor@gsoft.com.au> On Tue, 20 May 2008, Maksim Yevmenkin wrote: > > Why would you be multiplexing it? It's a virtual serial port, pty > > sounds like a pretty good match. ie I think I am misunderstanding > > what you are trying to say. > > ok, i will give you an example. lets say i have a couple of bluetooth > devices. lets say device #1 is a handheld and device #2 is some other > client device that wants to use serial port service on the pc. say, > its a bluetooth scanner/keyboard/etc. type device that proactively > connects to the host computer and sends stream of data. > > with virtual serial port there is no real need to register two (or > more) serial port services on the host pc. one could argue that > rfcomm_sppd(1) should have a configuration file that says > > if connected to device #1 { execute sync application } > if connected to device #2 { dump data } > > technically, both devices could use the same serial port service > registered on the same rfcomm channel on the same host pc. the data > coming from two different rfcomm connections from two different > devices. the server bluetooth endpoint just happens to be the same, > but the server will have two connections and two separate pty's for > both clients. this is the soft of multiplexing i'm talking about. the > same will work in client mode too. OK. > > Mmm good point :( > > I was thinking that in server mode it opened the PTY then waited > > for a connection but that isn't the case.. > > this is the case. it opens pty first then it does listen/accept/etc. Huh yes so it does! > > I am not sure how/why server mode is actually used - I only have > > experience with devices that are basically using BT as an RS232 > > replacement. > > right, there aren't many examples of server mode usage, but i was > thinking about "serial console" over bluetooth type thing. of course > it will never be a real serial console, just another out-of-band > access. could be useful to somebody. Selfishly, I think it's better to focus on the client stuff - heck I use it, so must everyone else ;) I wonder if the server stuff should be split into a separate program. At the moment rfcomm_sppd works perfectly well as a client program (with my patch anyway ;) but server mode needs more work to be properly useful (IMO) as it needs the config file and ability to exec stuff on demand etc.. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: This is a digitally signed message part. Url : http://lists.freebsd.org/pipermail/freebsd-bluetooth/attachments/20080521/50e11937/attachment.pgp From lsantagostini at gmail.com Tue May 27 05:02:17 2008 From: lsantagostini at gmail.com (Leonardo Santagostini) Date: Tue May 27 05:02:22 2008 Subject: Problem with a BCM2035B dongle In-Reply-To: References: <9ab7eeeb0805190319u30ccbeefq1511afa063bd75fe@mail.gmail.com> <9ab7eeeb0805191848p11e3b6d4u9bdd423e4e7d2533@mail.gmail.com> <9ab7eeeb0805201231o65e5058h427f4bafa8d27a39@mail.gmail.com> Message-ID: <9ab7eeeb0805262202p7d20b2eci5caebdd5e4293bef@mail.gmail.com> Max: I couldnt make this dongle work on windows to make a snoop. For sure, i will buy other one. Thanx for your collaboration. PS: do you recomend me a very good one ??? 2008/5/20 Maksim Yevmenkin : > On 5/20/08, Leonardo Santagostini wrote: > > Max: > > > > I have not installed windows at home, but i like challenges and i will > > install it onto a hard disk and i will find the drivers to make it work > on > > windows. > > > > Do you have any tool to make a trace from the usb device ? > > here is one - never tried to use it myself > > http://sourceforge.net/projects/usbsnoop/ > > thanks, > max > -- Saludos.- Leonardo Santagostini From maksim.yevmenkin at gmail.com Tue May 27 17:16:15 2008 From: maksim.yevmenkin at gmail.com (Maksim Yevmenkin) Date: Tue May 27 17:16:18 2008 Subject: Problem with a BCM2035B dongle In-Reply-To: <9ab7eeeb0805262202p7d20b2eci5caebdd5e4293bef@mail.gmail.com> References: <9ab7eeeb0805190319u30ccbeefq1511afa063bd75fe@mail.gmail.com> <9ab7eeeb0805191848p11e3b6d4u9bdd423e4e7d2533@mail.gmail.com> <9ab7eeeb0805201231o65e5058h427f4bafa8d27a39@mail.gmail.com> <9ab7eeeb0805262202p7d20b2eci5caebdd5e4293bef@mail.gmail.com> Message-ID: Leonardo, > I couldnt make this dongle work on windows to make a snoop. ok > For sure, i will buy other one. > > Thanx for your collaboration. > > PS: do you recomend me a very good one ??? i do not think that any particular one is better than other. usually, if it works - it works. most of the time bluetooth dongles are pretty much based on reference designs provided by bluetooth chip manufacturer. if you know what kind of chip is inside the dongle - get a csr based one. it will work for sure. thanks, max