From vova at fbsd.ru Fri Oct 3 12:17:34 2008 From: vova at fbsd.ru (Vladimir Grebenschikov) Date: Fri Oct 3 12:17:41 2008 Subject: Bluetooth audio (once again) In-Reply-To: References: <3a386af20809261420j535680e8pf44453dbf6f84b20@mail.gmail.com> Message-ID: <1223034512.1842.111.camel@localhost> On Fri, 2008-09-26 at 15:04 -0700, Maksim Yevmenkin wrote: > the code _is_ in src. Nice > isoc transfer support was added to ng_ubt(4). there are some known > problems, at least in some cases system crashes when usb dongle is > simply disconnected (without shutting down the stack first). the stack > trace ends up deep in the usb guts and i had no time to look at it. Have you point me on something like test application to try/reproduce issue ? > sco sockets support was also added, however 1) sco sockets hook is > *not* connected by default and 2) there are some known problems with > the code. more specifically problems are related to "broken" bluetooth > devices and the way they report sco buffer size/packet count. i happen > to have few of those devices. we need to have a way to handle those > kind of devices nicely. I have Platronics P590 headset with advanced audio and Nokia headset. I may to check them against our bluetooth stack. > before doing anything else, we need to fix existing code. Let's move forward > thanks, > max > _______________________________________________ > freebsd-bluetooth@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-bluetooth > To unsubscribe, send any mail to "freebsd-bluetooth-unsubscribe@freebsd.org" -- Vladimir B. Grebenschikov vova@fbsd.ru From maksim.yevmenkin at gmail.com Fri Oct 3 16:45:07 2008 From: maksim.yevmenkin at gmail.com (Maksim Yevmenkin) Date: Fri Oct 3 16:45:14 2008 Subject: Bluetooth audio (once again) In-Reply-To: <1223034512.1842.111.camel@localhost> References: <3a386af20809261420j535680e8pf44453dbf6f84b20@mail.gmail.com> <1223034512.1842.111.camel@localhost> Message-ID: > > isoc transfer support was added to ng_ubt(4). there are some known > > problems, at least in some cases system crashes when usb dongle is > > simply disconnected (without shutting down the stack first). the stack > > trace ends up deep in the usb guts and i had no time to look at it. > > Have you point me on something like test application to try/reproduce > issue ? sure. first, you need to run -current. ng_ubt(4) isoc support has not been mfc'ed yet. then you might want to connect sco hook to the sockets layer, i.e. apply something like beetle% diff -u /usr/src/etc/rc.d/bluetooth bluetooth --- /usr/src/etc/rc.d/bluetooth 2008-07-23 10:50:01.000000000 -0700 +++ bluetooth 2008-07-28 11:13:28.000000000 -0700 @@ -126,6 +126,8 @@ ngctl connect ${dev}l2cap: btsock_l2c: l2c ${dev}l2c \ > /dev/null 2>&1 || return 1 +ngctl connect ${dev}hci: btsock_sco: sco ${dev}sco > /dev/null 2>&1 + # Initilalize HCI node ${hccontrol} -n ${dev}hci reset \ > /dev/null 2>&1 || return 1 to your /etc/rc.d/bluetooth script. now you can connect your bluetooth device. kick tires and make sure you can do inquiry etc. then simply pull the device out _without_ stopping the stack first. at least on my system it often leads to panic after a few seconds. > > sco sockets support was also added, however 1) sco sockets hook is > > *not* connected by default and 2) there are some known problems with > > the code. more specifically problems are related to "broken" bluetooth > > devices and the way they report sco buffer size/packet count. i happen > > to have few of those devices. we need to have a way to handle those > > kind of devices nicely. > > I have Platronics P590 headset with advanced audio and Nokia headset. I > may to check them against our bluetooth stack. ok.be warned, you will need to write some code for that. its relatively simple. basically open an rfcomm socket and then open a sco socket. i can provide examples if you want me to. also, receive path (i.e. from headset to pc) kinda works. send path (from pc to headset) needs more work. > > before doing anything else, we need to fix existing code. > > Let's move forward sure :) lets. thanks, max From vova at fbsd.ru Fri Oct 3 20:54:23 2008 From: vova at fbsd.ru (Vladimir Grebenschikov) Date: Fri Oct 3 20:54:30 2008 Subject: Bluetooth audio - crash on USB bluetooth dongle disconnect In-Reply-To: References: <3a386af20809261420j535680e8pf44453dbf6f84b20@mail.gmail.com> <1223034512.1842.111.camel@localhost> Message-ID: <1223067257.2362.6.camel@localhost> On Fri, 2008-10-03 at 09:45 -0700, Maksim Yevmenkin wrote: > now you can connect your bluetooth device. kick tires and make sure > you can do inquiry etc. then simply pull the device out _without_ > stopping the stack first. at least on my system it often leads to > panic after a few seconds. First of all it crashes on disconnect with big probability even without btsock_sco. For me it crashes in uhci interrupt handler on NULL de-reference trace shows something like: usb_transfer_complete uhci_transfer_complete ... digging a bit shows that it crashes in uhci.c:2575 usbd_status uhci_device_isoc_start(usbd_xfer_handle xfer) { struct uhci_pipe *upipe = (struct uhci_pipe *)xfer->pipe; uhci_softc_t *sc = (uhci_softc_t *)upipe->pipe.device->bus; with upipe = NULL on interrupt Looks like it is result of locking changes in usb stack or like. Usb folks, can anybody give a hint what is the reason of such crash ? PS: I have SMP system. > thanks, > max -- Vladimir B. Grebenschikov vova@fbsd.ru From maksim.yevmenkin at gmail.com Fri Oct 3 21:18:28 2008 From: maksim.yevmenkin at gmail.com (Maksim Yevmenkin) Date: Fri Oct 3 21:18:35 2008 Subject: Bluetooth audio - crash on USB bluetooth dongle disconnect In-Reply-To: <1223067257.2362.6.camel@localhost> References: <3a386af20809261420j535680e8pf44453dbf6f84b20@mail.gmail.com> <1223034512.1842.111.camel@localhost> <1223067257.2362.6.camel@localhost> Message-ID: On 10/3/08, Vladimir Grebenschikov wrote: > On Fri, 2008-10-03 at 09:45 -0700, Maksim Yevmenkin wrote: > > > now you can connect your bluetooth device. kick tires and make sure > > you can do inquiry etc. then simply pull the device out _without_ > > stopping the stack first. at least on my system it often leads to > > panic after a few seconds. > > First of all it crashes on disconnect with big probability even without > btsock_sco. yes, i know. isoc transfers seems to be triggering it > For me it crashes in uhci interrupt handler on NULL de-reference > > trace shows something like: > usb_transfer_complete > uhci_transfer_complete > ... > > digging a bit shows that it crashes in uhci.c:2575 > > usbd_status > uhci_device_isoc_start(usbd_xfer_handle xfer) > { > struct uhci_pipe *upipe = (struct uhci_pipe *)xfer->pipe; > uhci_softc_t *sc = (uhci_softc_t *)upipe->pipe.device->bus; > > with upipe = NULL on interrupt > > Looks like it is result of locking changes in usb stack or like. > > Usb folks, can anybody give a hint what is the reason of such crash ? > > PS: I have SMP system. one thing that is different from interrupt and bulk transfers is that ng_ubt(4) always has multiple outstanding incoming isoc transfers. when device is simply pulled out, there is not much driver can do. if i enable debugging i can see my transfer completion routine called with ioerror status or something like that. so, i suspect this is a cleanup issue. i'm not sure who supposed to do the cleanup in this case driver or stack. in any case, can you verify that ubt_reset() is called when device is pulled out? (it should be called as part of hook disconnect). if not - then please try to call ubt_reset() from ubt_detach() just before closing all the pipes. thanks, max From vova at fbsd.ru Fri Oct 3 22:21:09 2008 From: vova at fbsd.ru (Vladimir Grebenschikov) Date: Fri Oct 3 22:21:15 2008 Subject: Bluetooth audio - crash on USB bluetooth dongle disconnect - solved In-Reply-To: References: <3a386af20809261420j535680e8pf44453dbf6f84b20@mail.gmail.com> <1223034512.1842.111.camel@localhost> <1223067257.2362.6.camel@localhost> Message-ID: <1223072464.4832.2.camel@localhost> ? Fri, 03/10/2008 ? 14:18 -0700, Maksim Yevmenkin ?????: > one thing that is different from interrupt and bulk transfers is that > ng_ubt(4) always has multiple outstanding incoming isoc transfers. > when device is simply pulled out, there is not much driver can do. if > i enable debugging i can see my transfer completion routine called > with ioerror status or something like that. so, i suspect this is a > cleanup issue. i'm not sure who supposed to do the cleanup in this > case driver or stack. > > in any case, can you verify that ubt_reset() is called when device is > pulled out? (it should be called as part of hook disconnect). Right guess, it does not called. > if not - then please try to call ubt_reset() from ubt_detach() just before > closing all the pipes. Yes, it fixes crash, patch below. Index: netgraph/bluetooth/drivers/ubt/ng_ubt.c =================================================================== RCS file: /usr/ncvs/src/sys/netgraph/bluetooth/drivers/ubt/ng_ubt.c,v retrieving revision 1.35 diff -u -r1.35 ng_ubt.c --- netgraph/bluetooth/drivers/ubt/ng_ubt.c 29 Jul 2008 00:17:53 -0000 1.35 +++ netgraph/bluetooth/drivers/ubt/ng_ubt.c 3 Oct 2008 22:13:46 -0000 @@ -803,6 +803,9 @@ struct ubt_softc *sc = device_get_softc(self); int i; + /* Reset queues and pipes */ + ubt_reset(sc); + /* Destroy Netgraph node */ if (sc->sc_node != NULL) { NG_NODE_SET_PRIVATE(sc->sc_node, NULL); > thanks, > max -- Vladimir B. Grebenschikov vova@fbsd.ru From maksim.yevmenkin at gmail.com Fri Oct 3 22:42:30 2008 From: maksim.yevmenkin at gmail.com (Maksim Yevmenkin) Date: Fri Oct 3 22:42:36 2008 Subject: Bluetooth audio - crash on USB bluetooth dongle disconnect - solved In-Reply-To: <1223072464.4832.2.camel@localhost> References: <3a386af20809261420j535680e8pf44453dbf6f84b20@mail.gmail.com> <1223034512.1842.111.camel@localhost> <1223067257.2362.6.camel@localhost> <1223072464.4832.2.camel@localhost> Message-ID: 2008/10/3 Vladimir Grebenschikov : > ? Fri, 03/10/2008 ? 14:18 -0700, Maksim Yevmenkin ?????: > >> one thing that is different from interrupt and bulk transfers is that >> ng_ubt(4) always has multiple outstanding incoming isoc transfers. >> when device is simply pulled out, there is not much driver can do. if >> i enable debugging i can see my transfer completion routine called >> with ioerror status or something like that. so, i suspect this is a >> cleanup issue. i'm not sure who supposed to do the cleanup in this >> case driver or stack. >> >> in any case, can you verify that ubt_reset() is called when device is >> pulled out? (it should be called as part of hook disconnect). > > Right guess, it does not called. > >> if not - then please try to call ubt_reset() from ubt_detach() just before >> closing all the pipes. > > Yes, it fixes crash, patch below. thanks for testing it! i have committed slightly different fix to head === Author: emax Date: Fri Oct 3 22:40:42 2008 New Revision: 183576 URL: http://svn.freebsd.org/changeset/base/183576 Log: Abort transfers on all pipes before closing them. This fixes the crash when Bluetooth USB device is pulled out without stopping the stack first. Submitted by: Vladimir Grebenschikov vova at fbsd dot ru MFC after: 1 week Modified: head/sys/netgraph/bluetooth/drivers/ubt/ng_ubt.c === thanks, max From vova at fbsd.ru Sat Oct 4 07:53:13 2008 From: vova at fbsd.ru (Vladimir Grebenschikov) Date: Sat Oct 4 07:53:20 2008 Subject: Bluetooth audio (once again) In-Reply-To: References: <3a386af20809261420j535680e8pf44453dbf6f84b20@mail.gmail.com> <1223034512.1842.111.camel@localhost> Message-ID: <1223106788.4832.25.camel@localhost> ? Fri, 03/10/2008 ? 09:45 -0700, Maksim Yevmenkin ?????: > > > sco sockets support was also added, however 1) sco sockets hook is > > > *not* connected by default and 2) there are some known problems with > > > the code. more specifically problems are related to "broken" bluetooth > > > devices and the way they report sco buffer size/packet count. i happen > > > to have few of those devices. we need to have a way to handle those > > > kind of devices nicely. > > > > I have Platronics P590 headset with advanced audio and Nokia headset. I > > may to check them against our bluetooth stack. I bit strange that I can inquiry and l2ping device, but can't list services: # l2ping -a p590 0 bytes from p590 seq_no=0 time=1794.348 ms result=0x6 0 bytes from p590 seq_no=1 time=2023.401 ms result=0x6 0 bytes from p590 seq_no=2 time=1761.475 ms result=0x6 ^C # l2control -a p590 Read_Channel_List l2control: Could not bind socket, bdaddr=00:19:7f:1b:de:77: Network is down # Should I do "pairing" somehow ? > ok.be warned, you will need to write some code for that. its > relatively simple. basically open an rfcomm socket and then open a sco > socket. i can provide examples if you want me to. Please, send me an example if you have. -- Vladimir B. Grebenschikov vova@fbsd.ru From maksim.yevmenkin at gmail.com Tue Oct 7 16:13:16 2008 From: maksim.yevmenkin at gmail.com (Maksim Yevmenkin) Date: Tue Oct 7 16:13:22 2008 Subject: Bluetooth audio (once again) In-Reply-To: <1223106788.4832.25.camel@localhost> References: <3a386af20809261420j535680e8pf44453dbf6f84b20@mail.gmail.com> <1223034512.1842.111.camel@localhost> <1223106788.4832.25.camel@localhost> Message-ID: On 10/4/08, Vladimir Grebenschikov wrote: > ? Fri, 03/10/2008 ? 09:45 -0700, Maksim Yevmenkin ?????: > > > > > > sco sockets support was also added, however 1) sco sockets hook is > > > > *not* connected by default and 2) there are some known problems with > > > > the code. more specifically problems are related to "broken" bluetooth > > > > devices and the way they report sco buffer size/packet count. i happen > > > > to have few of those devices. we need to have a way to handle those > > > > kind of devices nicely. > > > > > > I have Platronics P590 headset with advanced audio and Nokia headset. I > > > may to check them against our bluetooth stack. > > > I bit strange that I can inquiry and l2ping device, but can't list > services: > > # l2ping -a p590 > 0 bytes from p590 seq_no=0 time=1794.348 ms result=0x6 > 0 bytes from p590 seq_no=1 time=2023.401 ms result=0x6 > 0 bytes from p590 seq_no=2 time=1761.475 ms result=0x6 > ^C > # l2control -a p590 Read_Channel_List > l2control: Could not bind socket, bdaddr=00:19:7f:1b:de:77: Network is > down please read man page for l2control(8) utility. more specifically, " The l2control utility connects to the *local* device with the specified BD_ADDR and attempts to send the specified command. " l2control(8) will dump information about open channels as seen by *local* device. NOT remote. therefor is does not make much sense to put *remote* bd_addr as parameter. it will never work. > Should I do "pairing" somehow ? generally speaking, yes. usually pairing happens when host (i.e. pc) is trying to connect to the headset's rfcomm channel. in most cases, the headset will request authentication. however, if it does not, use hccontrol(8) write_authentication_enable command on host's device to force authentication (i.e. paring) > > ok.be warned, you will need to write some code for that. its > > relatively simple. basically open an rfcomm socket and then open a sco > > socket. i can provide examples if you want me to. > > Please, send me an example if you have. attached thanks, max -------------- next part -------------- A non-text attachment was scrubbed... Name: scotest.c Type: application/octet-stream Size: 4734 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-bluetooth/attachments/20081007/14874022/scotest.obj From vova at fbsd.ru Wed Oct 8 15:00:39 2008 From: vova at fbsd.ru (Vladimir Grebenschikov) Date: Wed Oct 8 15:00:47 2008 Subject: Bluetooth audio (once again) In-Reply-To: References: <3a386af20809261420j535680e8pf44453dbf6f84b20@mail.gmail.com> <1223034512.1842.111.camel@localhost> <1223106788.4832.25.camel@localhost> Message-ID: <1223478034.1864.65.camel@localhost> On Tue, 2008-10-07 at 09:13 -0700, Maksim Yevmenkin wrote: > > > ok.be warned, you will need to write some code for that. its > > > relatively simple. basically open an rfcomm socket and then open a sco > > > socket. i can provide examples if you want me to. > > > > Please, send me an example if you have. > > attached Thank you, I've played a bit with it. So far I was able to establish connection to channel 1 or 2 of my headset (Headset and advanced audio). Both connections (rfcomm and sco) are opened, headset sends zeros through sco connection and does some AT-chat on rfcomm. Looks like I need to implement chat to make headset to work. Then I dig a bit into bluez sources, and found two things - first, looks like we will need to use/re-implement big part of bluez/audio sub-directory to get full-functional audio to work under freebsd. Second, I've found that bluez uses almost same structures and calls to interact with kernel. Probably it worth to try port bluez (or part of bluez related to sound) to freebsd instead of re-writing whole beast ? What do you think ? PS. I spend only about half an our to make whole bluez to compile under freebsd (except network bridging and alsa). but not even tried to start it, though. > thanks, > max -- Vladimir B. Grebenschikov vova@fbsd.ru From maksim.yevmenkin at gmail.com Wed Oct 8 16:25:31 2008 From: maksim.yevmenkin at gmail.com (Maksim Yevmenkin) Date: Wed Oct 8 16:25:38 2008 Subject: Bluetooth audio (once again) In-Reply-To: <1223478034.1864.65.camel@localhost> References: <3a386af20809261420j535680e8pf44453dbf6f84b20@mail.gmail.com> <1223034512.1842.111.camel@localhost> <1223106788.4832.25.camel@localhost> <1223478034.1864.65.camel@localhost> Message-ID: On 10/8/08, Vladimir Grebenschikov wrote: > On Tue, 2008-10-07 at 09:13 -0700, Maksim Yevmenkin wrote: > > > > > > ok.be warned, you will need to write some code for that. its > > > > relatively simple. basically open an rfcomm socket and then open a sco > > > > socket. i can provide examples if you want me to. > > > > > > Please, send me an example if you have. > > > > attached > > > Thank you, I've played a bit with it. > > So far I was able to establish connection to channel 1 or 2 of my > headset (Headset and advanced audio). > > Both connections (rfcomm and sco) are opened, headset sends zeros > through sco connection and does some AT-chat on rfcomm. that sounds about right :) and that is where i left it off for now due to lack of time :( > Looks like I need to implement chat to make headset to work. do not really need to. once sco connection is open, audio should be flowing in both directions. you could try to talk to the headset after opening sco connection and dump all the sco data into the file. the data are basically raw samples in 8khz a/u-law encoding 8bit or linear encoding 16bit (depends on voice settings). you should be able to play those back using sox from ports or something like this. i can dig up my notes and find the recipe if you want me to. rfcomm channel is strictly for control. for example, you can make headset ring by sending "RING" command to it. also headset will send at+ckpd=200 every time button is pressed. there also might be a at+vgm or at+vgs commands to report/set microphone/speaker gain, etc. i suggest reading "headset profile" specification document. if you can not find one on the net, let me know. > Then I dig a bit into bluez sources, and found two things - first, looks > like we will need to use/re-implement big part of bluez/audio > sub-directory to get full-functional audio to work under freebsd. whoa! hold on just a second :) lets not jump the gun here. first lets fix existing code. need to make sure that sco works reliably at least up to the socket layer. the first goal would be to, say, have a tool that can receive/send audio from/to headset. say have a mp3 sent to headset over sco (re-encoding can be done by outside tool like sox) > Second, I've found that bluez uses almost same structures and calls to > interact with kernel. yes, its all very similar. it was intended this way :) > Probably it worth to try port bluez (or part of bluez related to sound) > to freebsd instead of re-writing whole beast ? What do you think ? two things 1) like i said we need to fix existing code first, so lets focus on low hanging fruit here 2) license issues. bluez is gnu, which could be a problem. we could take a look at what netbsd does. > I spend only about half an our to make whole bluez to compile under > freebsd (except network bridging and alsa). but not even tried to start > it, though. ok. thanks for your work! thanks, max From florenzi at gmail.com Wed Oct 8 17:46:37 2008 From: florenzi at gmail.com (Federico Lorenzi) Date: Wed Oct 8 17:47:06 2008 Subject: Bluetooth audio (once again) In-Reply-To: References: <3a386af20809261420j535680e8pf44453dbf6f84b20@mail.gmail.com> <1223034512.1842.111.camel@localhost> <1223106788.4832.25.camel@localhost> <1223478034.1864.65.camel@localhost> Message-ID: <3a386af20810081046h167f1547n18ed07dba439c751@mail.gmail.com> It's nice to see some traffic on this list again! Thanks for the replies, everyone. I'm specifically looking at getting A2DP working. As soon as my computer is finished making world for my EEE, I'm going to give using rfcomm / SCO sockets in Python a shot. From what I have read, it should work just fine. On Wed, Oct 8, 2008 at 6:25 PM, Maksim Yevmenkin wrote: > 2) license issues. bluez is gnu, which could be a problem. Unfortunately so. I can't really seem to find another implementation of the SBC codec (maybe a wishlist item for FFMpeg?), which is mandatory for A2DP. Some headsets support MP3 and others, but I'm not sure how prevalent this is. Cheers, Federico From plunky at rya-online.net Wed Oct 8 18:03:00 2008 From: plunky at rya-online.net (Iain Hibbert) Date: Wed Oct 8 18:03:08 2008 Subject: Bluetooth audio (once again) In-Reply-To: References: <3a386af20809261420j535680e8pf44453dbf6f84b20@mail.gmail.com> <1223034512.1842.111.camel@localhost> <1223106788.4832.25.camel@localhost> <1223478034.1864.65.camel@localhost> Message-ID: <1223486429.658424.1015.nullmailer@galant.ukfsn.org> On Wed, 8 Oct 2008, Maksim Yevmenkin wrote: > 2) license issues. bluez is gnu, which could be a problem. we could > take a look at what netbsd does. Well NetBSD has no A2DP support as yet There is bthset(1) which is a small utility to talk to the command part of a Headset profile, but the audio part is handled inside the kernel by a btsco(4) audio device driver (so in effect, you can just use /dev/audio1 to play audio). However, I don't think that is very easy to port to FreeBSD because our audio(9) API is different. (Also bthset uses libevent :) Something that may be of more immediate use is a port of the hstest program from BlueZ that I made when I was writing the SCO support for NetBSD. It is attached for what its worth (GPL warning) and it should be able to copy audio data in and out. Another thing that might be of interest is the proof of concept bthfp program I wrote to talk to a Handsfree profile (source at http://homepages.rya-online.net/plunky/bthfp-0.1.tar.gz) which alas also uses libevent though I wrote a version that used select and the NetBSD audio device directly (attached) but that doesn't always work properly because our audio device framework won't properly handle errors from the devices (eg disconnects) So in summary, what NetBSD has is probably not of great use but may be of some interest :) iain -------------- next part -------------- A non-text attachment was scrubbed... Name: hstest.tar.gz Type: application/octet-stream Size: 3338 bytes Desc: port of BlueZ hstest utility to NetBSD Url : http://lists.freebsd.org/pipermail/freebsd-bluetooth/attachments/20081008/b470e0a6/hstest.tar.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: bthfp_dev.tar.gz Type: application/octet-stream Size: 7682 bytes Desc: HFP program using select Url : http://lists.freebsd.org/pipermail/freebsd-bluetooth/attachments/20081008/b470e0a6/bthfp_dev.tar.obj From mad at madpilot.net Tue Oct 21 08:57:54 2008 From: mad at madpilot.net (Guido Falsi) Date: Tue Oct 21 08:58:01 2008 Subject: Need help with SDP interface Message-ID: <20081021084239.GA80573@megatron.madpilot.net> Hello, I'm the maintainer of the gnokii port. With the new version the author added some code to automatically find the rfcomm channel to talk with mobiles using AT commands. This function is very BlueZ specific and I'm trying to rewrite it to work with FreeBSD's bluetooth stack. I can't really find some documentation I need about bluetooth, so I thought I could ask for help here. The function as written by Powell Kot (gnokii author) reads out the SDP_ATTR_PRIMARY_LANGUAGE_BASE_ID + SDP_ATTR_SERVICE_NAME_OFFSET attribute of all the RFCOMM enabed profiles, discards some based on this descriptive name and select the first one not being discarded, exctracting the channel attribute. What I can't find is the data structure of the NAME attribute, and hot to read it using the SDP_DATA_* functions. Anyone is willing to help, I think I just need the the pdf or links to documentation. I've checked through the sdpcontrol functions, and got some idea of how things work. I'm also doing a little cut & paste of code, so I wil need permission from Maksim before submitting the code to the gnokii project. Please don't judge me too hard, I'm no C programmer, just a system administrator with some coding abilities :) Thank you in advance. -- Guido Falsi From maksim.yevmenkin at gmail.com Tue Oct 21 17:15:29 2008 From: maksim.yevmenkin at gmail.com (Maksim Yevmenkin) Date: Tue Oct 21 17:15:36 2008 Subject: Need help with SDP interface In-Reply-To: <20081021084239.GA80573@megatron.madpilot.net> References: <20081021084239.GA80573@megatron.madpilot.net> Message-ID: On 10/21/08, Guido Falsi wrote: > Hello, I'm the maintainer of the gnokii port. > > With the new version the author added some code to automatically find > the rfcomm channel to talk with mobiles using AT commands. is it looking for serial port service? if so, you can use rfcomm_sppd(1) source code as an example on how to find rfcomm channel number. you can also use sdpcontrol(8) source code to see how it searches/parses sdp record attributes > This function is very BlueZ specific and I'm trying to rewrite it to > work with FreeBSD's bluetooth stack. > > I can't really find some documentation I need about bluetooth, so I > thought I could ask for help here. > > The function as written by Powell Kot (gnokii author) reads out the > SDP_ATTR_PRIMARY_LANGUAGE_BASE_ID + SDP_ATTR_SERVICE_NAME_OFFSET > attribute of all the RFCOMM enabed profiles, discards some based on this > descriptive name and select the first one not being discarded, > exctracting the channel attribute. > > What I can't find is the data structure of the NAME attribute, and hot > to read it using the SDP_DATA_* functions. the data structures for sdp described in the particular bluetooth profile document. > Anyone is willing to help, I think I just need the the pdf or links > to documentation. > > I've checked through the sdpcontrol functions, and got some idea of how > things work. good ;) > I'm also doing a little cut & paste of code, so I wil need permission > from Maksim before submitting the code to the gnokii project. do not need to ;) my code is under bsd license, so everything should be fine as long as you comply with the term of the license thanks, max From plunky at rya-online.net Tue Oct 21 20:08:46 2008 From: plunky at rya-online.net (Iain Hibbert) Date: Tue Oct 21 20:08:53 2008 Subject: Need help with SDP interface Message-ID: <48fe2eab.261.35fd.334498095@rya-online.net> On Tue, 21 Oct 2008, Guido Falsi wrote: > With the new version the author added some code to automatically find > the rfcomm channel to talk with mobiles using AT commands. > > This function is very BlueZ specific and I'm trying to rewrite it to > work with FreeBSD's bluetooth stack. > > I can't really find some documentation I need about bluetooth, so I > thought I could ask for help here. all (most :) documents are at www.bluetooth.com > The function as written by Powell Kot (gnokii author) reads out the > SDP_ATTR_PRIMARY_LANGUAGE_BASE_ID + SDP_ATTR_SERVICE_NAME_OFFSET > attribute of all the RFCOMM enabed profiles, discards some based on this > descriptive name and select the first one not being discarded, > exctracting the channel attribute. What is it looking for (or discarding)? I'm not sure this is the right way to do it.. normally you look for a service class which is a specified number (look for some of these defined in /usr/include/sdp.h) I think you may be looking for 'Serial Port' profile. > What I can't find is the data structure of the NAME attribute, and hot > to read it using the SDP_DATA_* functions. I think it is just a SDP_STRING that you have to parse for that? iain From mad at madpilot.net Tue Oct 21 22:00:13 2008 From: mad at madpilot.net (Guido Falsi) Date: Tue Oct 21 22:00:20 2008 Subject: Need help with SDP interface In-Reply-To: <48fe2eab.261.35fd.334498095@rya-online.net> References: <48fe2eab.261.35fd.334498095@rya-online.net> Message-ID: <48FE50E8.7010701@madpilot.net> Iain Hibbert wrote: > all (most :) documents are at www.bluetooth.com > The site is quite messy, and I get annoyed easily by that kind of website design, so it took a few days worth of tries to get to the docs :P Now I have the relevant PDF, I'll try to make something worth of it. > > What is it looking for (or discarding)? I'm not sure this > is the right > way to do it.. normally you look for a service class which > is a specified > number (look for some of these defined in > /usr/include/sdp.h) I don't like the idea too much either, the problem is that most mobile phones expose a mlot of services, most marked as RFCOMM, some of which are not working in any way or are just used for some proprietary protocoll, so the code discards that kind of crap. For example it is discarding: "Nokia PC Suite" "Bluetooth Serial Port" "m-Router Connectivity" all of which, if present, are marked as rfcomm, but don't take at commands(which the software uses to talk to the phone). I think some better way exists, but I thought it would be easier to clone the existing logic and then refine it, than reinvent it right away. I'd also like to ha ve feedback from the gnokii developer, if my code is ok he could include it in his project too. > > I think you may be looking for 'Serial Port' profile. > >> What I can't find is the data structure of the NAME > attribute, and hot >> to read it using the SDP_DATA_* functions. > > I think it is just a SDP_STRING that you have to parse for > that? Yes, the original code is using strstr() to check them. -- Guido Falsi From mad at madpilot.net Tue Oct 21 22:03:23 2008 From: mad at madpilot.net (Guido Falsi) Date: Tue Oct 21 22:03:30 2008 Subject: Need help with SDP interface In-Reply-To: References: <20081021084239.GA80573@megatron.madpilot.net> Message-ID: <48FE51A7.8080400@madpilot.net> Maksim Yevmenkin wrote: > is it looking for serial port service? if so, you can use > rfcomm_sppd(1) source code as an example on how to find rfcomm channel > number. > Did not think about it...I'll have a look tomorrow. I'll see if I can get some ideas. >> I'm also doing a little cut & paste of code, so I wil need permission >> from Maksim before submitting the code to the gnokii project. > > do not need to ;) my code is under bsd license, so everything should > be fine as long as you comply with the term of the license > Well, even if the BSD license allows that I like asking anyway. I'll for sure insert a comment pointing to your code and license for what I took. first of all I need something which actually works though :) -- Guido Falsi From samm at os2.kiev.ua Fri Oct 31 09:53:02 2008 From: samm at os2.kiev.ua (Alex Samorukov) Date: Fri Oct 31 09:53:36 2008 Subject: bt dev questions Message-ID: <490B331F.6020305@os2.kiev.ua> Hi all I ported to FreeBSD anyRemote utility (http://anyremote.sourceforge.net/), and while porting I got some issues which i`m not able to resolve myself. They are not critical (program is working), but a bit annoying. 1) Why sdpd require root permission to open session? As for me it`s enough to check use file permissions on control socket. In Linux its possible to register service w/o root permissions, so in ported version I need to run it as root and then setuid to normal user. What is the reason for this? 2) I was not able to find how to change provider name and server description in SDP_SERVICE_CLASS_SERIAL_PORT profile. anyRemote using usual serial over bluetooth, but with changed service name field. I found howto change channel (server_channel) but not description. Is it possible at all? I`m planning to submit my patches to the ports tree at nearest time. From maksim.yevmenkin at gmail.com Fri Oct 31 10:40:39 2008 From: maksim.yevmenkin at gmail.com (Maksim Yevmenkin) Date: Fri Oct 31 10:40:51 2008 Subject: bt dev questions In-Reply-To: <490B331F.6020305@os2.kiev.ua> References: <490B331F.6020305@os2.kiev.ua> Message-ID: Alex, > 1) Why sdpd require root permission to open session? As for me it`s enough > to check use file permissions on control socket. In Linux its possible to > register service w/o root permissions, so in ported version I need to run it > as root and then setuid to normal user. What is the reason for this? to have better control over what services are offered. basically, i do not want to have any random application go and register bunch of non-existent services. requiring 'root' permission is may be a little bit excessive, but its easy to fix. could teach sdpd to accept connections from specified group (or even list of groups/users). > 2) I was not able to find how to change provider name and server > description in SDP_SERVICE_CLASS_SERIAL_PORT profile. anyRemote using usual > serial over bluetooth, but with changed service name field. I found howto > change channel (server_channel) but not description. Is it possible at all? not at this time. > I`m planning to submit my patches to the ports tree at nearest time. thanks for your work. thanks, max