From maksim.yevmenkin at gmail.com Tue Feb 3 16:22:16 2009 From: maksim.yevmenkin at gmail.com (Maksim Yevmenkin) Date: Tue Feb 3 16:22:22 2009 Subject: pan profile support in freebsd In-Reply-To: <4988DCCC.80201@mavhome.dp.ua> References: <1233365217.00068654.1233354838@10.7.7.3> <4988DCCC.80201@mavhome.dp.ua> Message-ID: Alexander, [...] > Thanks for the good news and your work. I have managed to use by Qtek S200 > running WM 6.1 Internet Sharing service (NAP profile). It has worked just > out of the box. thanks for the report! > The only newbie problem I had is what to specify in -d argument. NetBSD > examples specifying adapter name there, while FreeBSD does not accepts this. > I have spent some time looking for my adapter BDADDR. well, it kinda does. you can edit /etc/bluetooth/hosts file and add your adapter's bd_addr there, i.e. 00:11:22:33:44:55 mydevice and then use -d mydevice with btpand(8). > PS: I have one small indirectly related, annoying problem. After some time > of being unused Qtek goes to some kind of sleep, which makes it not > responding on BT requests (both rfcomm and btpand), reporting "No route to > host". After several retries or just by running l2ping and waiting for 3-5 > seconds it successfully wakes up and working, but it makes using it a bit > annoying. Is there any known workaround for it? it depends. i'm guessing qtek device is probably putting idle connection into 'sniff' or 'hold' (or even 'park') mode to conserve battery life. you should be able to see what is going by running hcidump. in any case, it should be possible to add something that 'tickles' connection once in a short while to prevent it from going completely idle. it will drain the battery faster though. thanks, max From mav at mavhome.dp.ua Tue Feb 3 17:09:47 2009 From: mav at mavhome.dp.ua (Alexander Motin) Date: Tue Feb 3 17:09:54 2009 Subject: pan profile support in freebsd In-Reply-To: <1233365217.00068654.1233354838@10.7.7.3> References: <1233365217.00068654.1233354838@10.7.7.3> Message-ID: <4988DCCC.80201@mavhome.dp.ua> Maksim Yevmenkin wrote: > i'm pleased to announce that i've just imported btpand(8) daemon from > netbsd. this daemon provides support for NAP, GN and PANU profiles. > i've briefly tested it with a couple of PAN-enabled devices (i.e. my > windows-xp laptop and old hp ipaq 1940 running windows ce 4.20). Thanks for the good news and your work. I have managed to use by Qtek S200 running WM 6.1 Internet Sharing service (NAP profile). It has worked just out of the box. The only newbie problem I had is what to specify in -d argument. NetBSD examples specifying adapter name there, while FreeBSD does not accepts this. I have spent some time looking for my adapter BDADDR. PS: I have one small indirectly related, annoying problem. After some time of being unused Qtek goes to some kind of sleep, which makes it not responding on BT requests (both rfcomm and btpand), reporting "No route to host". After several retries or just by running l2ping and waiting for 3-5 seconds it successfully wakes up and working, but it makes using it a bit annoying. Is there any known workaround for it? PPS: Thanks again! -- Alexander Motin From mav at mavhome.dp.ua Tue Feb 3 17:13:12 2009 From: mav at mavhome.dp.ua (Alexander Motin) Date: Tue Feb 3 17:13:18 2009 Subject: pan profile support in freebsd In-Reply-To: References: <1233365217.00068654.1233354838@10.7.7.3> <4988DCCC.80201@mavhome.dp.ua> Message-ID: <4988EBAC.3080202@mavhome.dp.ua> Maksim Yevmenkin wrote: >> The only newbie problem I had is what to specify in -d argument. NetBSD >> examples specifying adapter name there, while FreeBSD does not accepts this. >> I have spent some time looking for my adapter BDADDR. > > well, it kinda does. you can edit /etc/bluetooth/hosts file and add > your adapter's bd_addr there, i.e. > > 00:11:22:33:44:55 mydevice > > and then use -d mydevice with btpand(8). I have done exactly the same, it just was not intuitive and differs from NetBSD as I understood it. It was probably the first time when I needed to know my adapter BDADDR. >> PS: I have one small indirectly related, annoying problem. After some time >> of being unused Qtek goes to some kind of sleep, which makes it not >> responding on BT requests (both rfcomm and btpand), reporting "No route to >> host". After several retries or just by running l2ping and waiting for 3-5 >> seconds it successfully wakes up and working, but it makes using it a bit >> annoying. Is there any known workaround for it? > > it depends. i'm guessing qtek device is probably putting idle > connection into 'sniff' or 'hold' (or even 'park') mode to conserve > battery life. you should be able to see what is going by running > hcidump. in any case, it should be possible to add something that > 'tickles' connection once in a short while to prevent it from going > completely idle. it will drain the battery faster though. It does not happens when connection is alive, only when connection establishes. So may be there some kind of timeout can be tuned, or device can be forcefully woken up in some other way? One more minor fact. Unlike rfcomm_pppd I haven't found an option to run btpand in foreground to track connection status. -- Alexander Motin From maksim.yevmenkin at gmail.com Tue Feb 3 17:32:01 2009 From: maksim.yevmenkin at gmail.com (Maksim Yevmenkin) Date: Tue Feb 3 17:32:08 2009 Subject: pan profile support in freebsd In-Reply-To: <4988EBAC.3080202@mavhome.dp.ua> References: <1233365217.00068654.1233354838@10.7.7.3> <4988DCCC.80201@mavhome.dp.ua> <4988EBAC.3080202@mavhome.dp.ua> Message-ID: On Tue, Feb 3, 2009 at 5:13 PM, Alexander Motin wrote: > Maksim Yevmenkin wrote: >>> >>> The only newbie problem I had is what to specify in -d argument. NetBSD >>> examples specifying adapter name there, while FreeBSD does not accepts >>> this. >>> I have spent some time looking for my adapter BDADDR. >> >> well, it kinda does. you can edit /etc/bluetooth/hosts file and add >> your adapter's bd_addr there, i.e. >> >> 00:11:22:33:44:55 mydevice >> >> and then use -d mydevice with btpand(8). > > I have done exactly the same, it just was not intuitive and differs from > NetBSD as I understood it. It was probably the first time when I needed to > know my adapter BDADDR. and what name would you like to use? ubt0? something else? dont forget we dont create nodes under /dev for bluetooth devices. just netgraph nodes. i have plan to implement libhci (a-la linux bluez etc.) shim eventually :) if someone feels like beating me to it, i would certainly not object to it :) btw, obtaining bdaddr is really easy. in 99.9% cases (where there is only one bluetooth device connected to the system) 'hccontrol read_bd_addr' will do the trick :) >>> PS: I have one small indirectly related, annoying problem. After some >>> time >>> of being unused Qtek goes to some kind of sleep, which makes it not >>> responding on BT requests (both rfcomm and btpand), reporting "No route >>> to >>> host". After several retries or just by running l2ping and waiting for >>> 3-5 >>> seconds it successfully wakes up and working, but it makes using it a bit >>> annoying. Is there any known workaround for it? >> >> it depends. i'm guessing qtek device is probably putting idle >> connection into 'sniff' or 'hold' (or even 'park') mode to conserve >> battery life. you should be able to see what is going by running >> hcidump. in any case, it should be possible to add something that >> 'tickles' connection once in a short while to prevent it from going >> completely idle. it will drain the battery faster though. > > It does not happens when connection is alive, only when connection > establishes. So may be there some kind of timeout can be tuned, or device > can be forcefully woken up in some other way? oh, i misunderstood then. are you saying that initial connection setup is slow? if so, then i'm guessing your qtek device is maybe missing initial paging attempts. either this or something else is going on. when you do inquiry what do Page Scan Rep. Mode Page Scan Period Mode Page Scan Mode say for your qtek device? you can try to increase page timeout, i.e. 'hccontrol write_page_timeout' if your qtek device is timing out during initial page attempt (default timeout is ~5sec). in any case hcidump that shows the problem would be a good start. > One more minor fact. Unlike rfcomm_pppd I haven't found an option to run > btpand in foreground to track connection status. because there isn't one :) can be added though :) please feel free to send in the patches :) thanks, max From mav at mavhome.dp.ua Tue Feb 3 18:07:15 2009 From: mav at mavhome.dp.ua (Alexander Motin) Date: Tue Feb 3 18:07:21 2009 Subject: pan profile support in freebsd In-Reply-To: References: <1233365217.00068654.1233354838@10.7.7.3> <4988DCCC.80201@mavhome.dp.ua> <4988EBAC.3080202@mavhome.dp.ua> Message-ID: <4988F857.5080407@mavhome.dp.ua> Maksim Yevmenkin wrote: > On Tue, Feb 3, 2009 at 5:13 PM, Alexander Motin wrote: >> Maksim Yevmenkin wrote: >>>> The only newbie problem I had is what to specify in -d argument. NetBSD >>>> examples specifying adapter name there, while FreeBSD does not accepts >>>> this. >>>> I have spent some time looking for my adapter BDADDR. >>> well, it kinda does. you can edit /etc/bluetooth/hosts file and add >>> your adapter's bd_addr there, i.e. >>> >>> 00:11:22:33:44:55 mydevice >>> >>> and then use -d mydevice with btpand(8). >> I have done exactly the same, it just was not intuitive and differs from >> NetBSD as I understood it. It was probably the first time when I needed to >> know my adapter BDADDR. > > and what name would you like to use? ubt0? something else? dont forget > we dont create nodes under /dev for bluetooth devices. just netgraph > nodes. i have plan to implement libhci (a-la linux bluez etc.) shim > eventually :) if someone feels like beating me to it, i would > certainly not object to it :) Actually yes, ubt0. System reports it on boot, it is reported to the peered devices in hostname and NetBSD does so. IMHO it is not a bad choice from user's point of view. Does actually this binding really necessary? rfcomm somehow works without it. > btw, obtaining bdaddr is really easy. in 99.9% cases (where there is > only one bluetooth device connected to the system) 'hccontrol > read_bd_addr' will do the trick :) Indeed. But general number of BT tools, daemons and their options just making me sad. >>>> PS: I have one small indirectly related, annoying problem. After some >>>> time >>>> of being unused Qtek goes to some kind of sleep, which makes it not >>>> responding on BT requests (both rfcomm and btpand), reporting "No route >>>> to >>>> host". After several retries or just by running l2ping and waiting for >>>> 3-5 >>>> seconds it successfully wakes up and working, but it makes using it a bit >>>> annoying. Is there any known workaround for it? >>> it depends. i'm guessing qtek device is probably putting idle >>> connection into 'sniff' or 'hold' (or even 'park') mode to conserve >>> battery life. you should be able to see what is going by running >>> hcidump. in any case, it should be possible to add something that >>> 'tickles' connection once in a short while to prevent it from going >>> completely idle. it will drain the battery faster though. >> It does not happens when connection is alive, only when connection >> establishes. So may be there some kind of timeout can be tuned, or device >> can be forcefully woken up in some other way? > > oh, i misunderstood then. are you saying that initial connection setup > is slow? if so, then i'm guessing your qtek device is maybe missing > initial paging attempts. either this or something else is going on. > when you do inquiry what do > > Page Scan Rep. Mode > Page Scan Period Mode > Page Scan Mode Page Scan Rep. Mode: 0x1 Page Scan Period Mode: 00 Page Scan Mode: 00 > say for your qtek device? you can try to increase page timeout, i.e. > 'hccontrol write_page_timeout' if your qtek device is timing out > during initial page attempt (default timeout is ~5sec). > > in any case hcidump that shows the problem would be a good start. First run: < HCI Command: Create Connection(0x01|0x0005) plen 13 > HCI Event: Command Status(0x0f) plen 4 > HCI Event: Connect Complete(0x03) plen 11 btpand[4215]: NAP: Host is down Second run: < HCI Command: Create Connection(0x01|0x0005) plen 13 > HCI Event: Command Status(0x0f) plen 4 > HCI Event: Connect Complete(0x03) plen 11 < HCI Command: Write Link Policy Settings(0x02|0x000d) plen 4 < ACL data: handle 0x000b flags 0x02 dlen 12 L2CAP(s): Connect req: psm 1 scid 0x00b0 > HCI Event: Command Complete(0x0e) plen 6 > HCI Event: Max Slots Change(0x1b) plen 3 btpand[4222]: Searching for NAP service at 00:12:d1:38:4a:fa btpand[4222]: Found PSM 15 for service NAP btpand[4222]: Opening connection to service 0x1116 at 00:12:d1:38:4a:fa btpand[4222]: channel_open: (fd#4) btpand[4222]: Using interface tap10 with addr 00:00:d9:fb:48:16 btpand[4222]: channel_open: (fd#5) -- Alexander Motin From plunky at rya-online.net Wed Feb 4 07:58:35 2009 From: plunky at rya-online.net (Iain Hibbert) Date: Wed Feb 4 07:58:52 2009 Subject: pan profile support in freebsd In-Reply-To: <4988F857.5080407@mavhome.dp.ua> References: <1233365217.00068654.1233354838@10.7.7.3> <4988DCCC.80201@mavhome.dp.ua> <4988EBAC.3080202@mavhome.dp.ua> <4988F857.5080407@mavhome.dp.ua> Message-ID: <1233759463.493208.401.nullmailer@galant.ukfsn.org> On Wed, 4 Feb 2009, Alexander Motin wrote: [relating to -d device] > Does actually this binding really necessary? rfcomm somehow works without it. This binding is used (in original version) to set the tap interface address to be the same as the bdaddr. I did consider allowing to use it without setting that but then ethernet packets are being transmitted with a source address that is not the bdaddr. Now, IIRC it would seem that the spec allows this, but my windows mobile device (for instance) fails to route packets back to the computer. there are a couple of ways around this I could see 1. skip the bdaddr_any(local_bdaddr) check while validating the command line options, but add something to set it if it is unset. That would be the easiest option I guess but you need to be able to find the device with the best route to remote (could be first device, could be we already have a connection to remote device - I don't know what FreeBSD provides here?) 2. perform 'address rewriting' on ethernet packets. Actually this is not that difficult to do and I had it going during testing (when receiving packets, if the source address is the same as the remote bdaddr, or the ethernet tap address, set it to NULL. When sending, if the source is NULL, use the local bdaddr or ethernet tap address.) This also allows a single btpand instance to straddle multiple controllers but I thought it might be better to keep it simple in the beginning. the fact of it requiring the commandline argument at first I prefer - because its always possible to relax a requirement but not to tighten one up :) iain From plunky at rya-online.net Wed Feb 4 07:58:35 2009 From: plunky at rya-online.net (Iain Hibbert) Date: Wed Feb 4 07:58:52 2009 Subject: pan profile support in freebsd In-Reply-To: <4988EBAC.3080202@mavhome.dp.ua> References: <1233365217.00068654.1233354838@10.7.7.3> <4988DCCC.80201@mavhome.dp.ua> <4988EBAC.3080202@mavhome.dp.ua> Message-ID: <1233760229.131312.504.nullmailer@galant.ukfsn.org> On Wed, 4 Feb 2009, Alexander Motin wrote: > One more minor fact. Unlike rfcomm_pppd I haven't found an option to run > btpand in foreground to track connection status. what would you like to accomplish? I made some effort for it to not detach until the setup is complete, but it kind of needs to then in order for 'connection up' activities to commence (eg proceeding to run dhclient).. at least on my machine I have logging turned up and do get some shutdown messages on the console when it detaches. I have not run it as a NAP or GN so I'm not sure if anything needs to happen when connections come and go there but I thought maybe not as its similar to plugging other computers in the other side of a switch. iain From plunky at rya-online.net Wed Feb 4 07:58:36 2009 From: plunky at rya-online.net (Iain Hibbert) Date: Wed Feb 4 07:58:52 2009 Subject: libhci (was Re: pan profile support in freebsd) In-Reply-To: References: <1233365217.00068654.1233354838@10.7.7.3> <4988DCCC.80201@mavhome.dp.ua> <4988EBAC.3080202@mavhome.dp.ua> Message-ID: <1233758519.360141.162.nullmailer@galant.ukfsn.org> On Tue, 3 Feb 2009, Maksim Yevmenkin wrote: > i have plan to implement libhci (a-la linux bluez etc.) shim > eventually :) if someone feels like beating me to it, i would > certainly not object to it :) what api would you envisage? iain From maksim.yevmenkin at gmail.com Wed Feb 4 09:47:13 2009 From: maksim.yevmenkin at gmail.com (Maksim Yevmenkin) Date: Wed Feb 4 09:47:21 2009 Subject: pan profile support in freebsd In-Reply-To: <4988F857.5080407@mavhome.dp.ua> References: <1233365217.00068654.1233354838@10.7.7.3> <4988DCCC.80201@mavhome.dp.ua> <4988EBAC.3080202@mavhome.dp.ua> <4988F857.5080407@mavhome.dp.ua> Message-ID: [...] >> and what name would you like to use? ubt0? something else? dont forget >> we dont create nodes under /dev for bluetooth devices. just netgraph >> nodes. i have plan to implement libhci (a-la linux bluez etc.) shim >> eventually :) if someone feels like beating me to it, i would >> certainly not object to it :) > > Actually yes, ubt0. System reports it on boot, it is reported to the peered > devices in hostname and NetBSD does so. IMHO it is not a bad choice from > user's point of view. ok, i will look into it. this will definitely be after hci shims. enumerating all the radios in the system is the job for hci shim. there is something already in hccontrol(8) to do that, but i do not want to duplicate the code and rather move it into hci shim. > Does actually this binding really necessary? rfcomm somehow works without > it. please see Iain's response :) i knew he would chime in :) thanks Iain! and, yes, i suspected that it would be something related to mac addresses on virtual ethernet interface. i do not have a copy of spec handy, but i recall something about setting mac address to be the same as radio's bd_addr. dont remember if it was a requirement or more of a guideline. in any case, i like Iain's suggestion to rewrite mac addresses on the fly. i would have done it this way. also, i think, nap server should just act as ethernet hub, i.e. forward everything everywhere. after all, nap is supposed to be like local ethernet network :) >> btw, obtaining bdaddr is really easy. in 99.9% cases (where there is >> only one bluetooth device connected to the system) 'hccontrol >> read_bd_addr' will do the trick :) > > Indeed. But general number of BT tools, daemons and their options just > making me sad. i'm not sure how to read that :) there is, like, less than 10 bluetooth related daemons in total. each has, like, may be 10 options. compare this to the number of options ls(1) has :) not sure what could possibly make you sad here. if you feel that the documentation is not adequate, please feel free to fix it :) [....] >>> It does not happens when connection is alive, only when connection >>> establishes. So may be there some kind of timeout can be tuned, or device >>> can be forcefully woken up in some other way? >> >> oh, i misunderstood then. are you saying that initial connection setup >> is slow? if so, then i'm guessing your qtek device is maybe missing >> initial paging attempts. either this or something else is going on. >> when you do inquiry what do >> >> Page Scan Rep. Mode >> Page Scan Period Mode >> Page Scan Mode > > Page Scan Rep. Mode: 0x1 > Page Scan Period Mode: 00 > Page Scan Mode: 00 ah, so your device wants to use r1 page scan repetition mode. off-the-shelf dongles usually use r2 mode. that is basically defines how radio will scan for page/attempt to page. its basically baseband/link manager (aka firmware on the device itself - not stack) >> say for your qtek device? you can try to increase page timeout, i.e. >> 'hccontrol write_page_timeout' if your qtek device is timing out >> during initial page attempt (default timeout is ~5sec). >> >> in any case hcidump that shows the problem would be a good start. > > First run: > > < HCI Command: Create Connection(0x01|0x0005) plen 13 >> HCI Event: Command Status(0x0f) plen 4 >> HCI Event: Connect Complete(0x03) plen 11 > > btpand[4215]: NAP: Host is down > > Second run: > > < HCI Command: Create Connection(0x01|0x0005) plen 13 >> HCI Event: Command Status(0x0f) plen 4 >> HCI Event: Connect Complete(0x03) plen 11 > < HCI Command: Write Link Policy Settings(0x02|0x000d) plen 4 > < ACL data: handle 0x000b flags 0x02 dlen 12 > L2CAP(s): Connect req: psm 1 scid 0x00b0 >> HCI Event: Command Complete(0x0e) plen 6 >> HCI Event: Max Slots Change(0x1b) plen 3 > > btpand[4222]: Searching for NAP service at 00:12:d1:38:4a:fa > btpand[4222]: Found PSM 15 for service NAP > btpand[4222]: Opening connection to service 0x1116 at 00:12:d1:38:4a:fa > btpand[4222]: channel_open: (fd#4) > btpand[4222]: Using interface tap10 with addr 00:00:d9:fb:48:16 > btpand[4222]: channel_open: (fd#5) right, next time please either user '-x' or '-w' option to hcidump. in this case, it does not matter, since, in failure case, clearly nothing happens after connection_complete event, so we could not even establish baseband connection (i can not see the error code on the dump but i'm guessing its page timeout). like i said, you could try to increase page timeout of your local radio, or, you could try to find if your device has knobs that would allow to set radio's scan window and scan interval. thanks, max From maksim.yevmenkin at gmail.com Wed Feb 4 10:00:20 2009 From: maksim.yevmenkin at gmail.com (Maksim Yevmenkin) Date: Wed Feb 4 10:00:26 2009 Subject: libhci (was Re: pan profile support in freebsd) In-Reply-To: <1233758519.360141.162.nullmailer@galant.ukfsn.org> References: <1233365217.00068654.1233354838@10.7.7.3> <4988DCCC.80201@mavhome.dp.ua> <4988EBAC.3080202@mavhome.dp.ua> <1233758519.360141.162.nullmailer@galant.ukfsn.org> Message-ID: On Wed, Feb 4, 2009 at 6:41 AM, Iain Hibbert wrote: > On Tue, 3 Feb 2009, Maksim Yevmenkin wrote: > >> i have plan to implement libhci (a-la linux bluez etc.) shim >> eventually :) if someone feels like beating me to it, i would >> certainly not object to it :) > > what api would you envisage? i was thinking about doing most of the http://git.kernel.org/?p=bluetooth/bluez.git;a=blob_plain;f=lib/hci.c;hb=1fa3750cb917358a6fb6bc718429c9000dd61ab3 starting from int hci_inquiry(...) and all the way down to the end of the file :) basically map dev_id to unit numbers, i.e. dev_id 0 is "ubt0" node, etc. i'm a bit concerned that if we follow linux too closely someone might throw a hissy fit about bsd stealing linux's code and not using gpl :) so we have to tread lightly here, imo :) and, btw, i do not think i'm going to create a separate libhci for this. existing libbluetooth is perfectly fine. thanks, max From mav at mavhome.dp.ua Wed Feb 4 10:39:48 2009 From: mav at mavhome.dp.ua (Alexander Motin) Date: Wed Feb 4 10:39:54 2009 Subject: pan profile support in freebsd In-Reply-To: <1233760229.131312.504.nullmailer@galant.ukfsn.org> References: <1233365217.00068654.1233354838@10.7.7.3> <4988DCCC.80201@mavhome.dp.ua> <4988EBAC.3080202@mavhome.dp.ua> <1233760229.131312.504.nullmailer@galant.ukfsn.org> Message-ID: <4989E0F7.3020301@mavhome.dp.ua> Iain Hibbert wrote: > On Wed, 4 Feb 2009, Alexander Motin wrote: > >> One more minor fact. Unlike rfcomm_pppd I haven't found an option to run >> btpand in foreground to track connection status. > > what would you like to accomplish? For example, to initiate reconnect on connection failure. Sure it can be done in many other ways, but running in foreground seems to be usual practice for many places, like ppp. > I made some effort for it to not detach until the setup is complete, but > it kind of needs to then in order for 'connection up' activities to > commence (eg proceeding to run dhclient).. at least on my machine I have > logging turned up and do get some shutdown messages on the console when it > detaches. I think dhclient, for example, could be run via devd when interface comes up, alike to normal Ethernet. Not sure TAP supports devd not, but I think it could be fixed. -- Alexander Motin From mav at mavhome.dp.ua Wed Feb 4 11:07:59 2009 From: mav at mavhome.dp.ua (Alexander Motin) Date: Wed Feb 4 11:08:04 2009 Subject: pan profile support in freebsd In-Reply-To: <1233759463.493208.401.nullmailer@galant.ukfsn.org> References: <1233365217.00068654.1233354838@10.7.7.3> <4988DCCC.80201@mavhome.dp.ua> <4988EBAC.3080202@mavhome.dp.ua> <4988F857.5080407@mavhome.dp.ua> <1233759463.493208.401.nullmailer@galant.ukfsn.org> Message-ID: <4989E793.2030503@mavhome.dp.ua> Iain Hibbert wrote: > On Wed, 4 Feb 2009, Alexander Motin wrote: > [relating to -d device] >> Does actually this binding really necessary? rfcomm somehow works without it. > > This binding is used (in original version) to set the tap interface > address to be the same as the bdaddr. I did consider allowing to use it > without setting that but then ethernet packets are being transmitted with > a source address that is not the bdaddr. Now, IIRC it would seem that the > spec allows this, but my windows mobile device (for instance) fails to > route packets back to the computer. > > there are a couple of ways around this I could see > > 1. skip the bdaddr_any(local_bdaddr) check while validating the command > line options, but add something to set it if it is unset. That would > be the easiest option I guess but you need to be able to find the > device with the best route to remote (could be first device, could be > we already have a connection to remote device - I don't know what > FreeBSD provides here?) Have no idea how routing expected to work in case of several BT adapters, this it is interesting, but I think quite rare case. I think it could be good to be implemented alike to usual inet connectivity, when unbinded accepting connection sets remotely requested IP as it's local, and outgoing connecting socket choose local IP using routing table. I am not sure if terms or routing applicable here, but at least we have some mesh of peered devices and if there is several peered, we could choose one of using some algorithm, depending on load or order, or just round-robin. > 2. perform 'address rewriting' on ethernet packets. Actually this is not > that difficult to do and I had it going during testing (when receiving > packets, if the source address is the same as the remote bdaddr, or the > ethernet tap address, set it to NULL. When sending, if the source is > NULL, use the local bdaddr or ethernet tap address.) This also allows > a single btpand instance to straddle multiple controllers but I thought > it might be better to keep it simple in the beginning. I don't very like idea of rewriting. It looks like a hack and may confuse somebody. Also if it works as plain Ethernet, then you will probably have to rewrite ARP for IPv4 and it's equivalent for IPv6, and something other for other protocols. It could become a permanent pain. > the fact of it requiring the commandline argument at first I prefer - > because its always possible to relax a requirement but not to tighten one > up :) -- Alexander Motin From mav at mavhome.dp.ua Wed Feb 4 11:27:44 2009 From: mav at mavhome.dp.ua (Alexander Motin) Date: Wed Feb 4 11:27:51 2009 Subject: pan profile support in freebsd In-Reply-To: References: <1233365217.00068654.1233354838@10.7.7.3> <4988DCCC.80201@mavhome.dp.ua> <4988EBAC.3080202@mavhome.dp.ua> <4988F857.5080407@mavhome.dp.ua> Message-ID: <4989EC35.80502@mavhome.dp.ua> Maksim Yevmenkin wrote: >> Does actually this binding really necessary? rfcomm somehow works without >> it. > > please see Iain's response :) i knew he would chime in :) thanks Iain! > > and, yes, i suspected that it would be something related to mac > addresses on virtual ethernet interface. i do not have a copy of spec > handy, but i recall something about setting mac address to be the same > as radio's bd_addr. dont remember if it was a requirement or more of a > guideline. > > in any case, i like Iain's suggestion to rewrite mac addresses on the > fly. i would have done it this way. also, i think, nap server should > just act as ethernet hub, i.e. forward everything everywhere. after > all, nap is supposed to be like local ethernet network :) Hmm. Working like an Ethernet hub also means that every single hub port (in our case every single point-to-point BT link) may transmit packets from different source MAC addresses, that can't be equal to BT adapter address. So or I don't understand your example, or something is wrong here. >>> btw, obtaining bdaddr is really easy. in 99.9% cases (where there is >>> only one bluetooth device connected to the system) 'hccontrol >>> read_bd_addr' will do the trick :) >> Indeed. But general number of BT tools, daemons and their options just >> making me sad. > > i'm not sure how to read that :) there is, like, less than 10 > bluetooth related daemons in total. each has, like, may be 10 options. > compare this to the number of options ls(1) has :) not sure what could > possibly make you sad here. if you feel that the documentation is not > adequate, please feel free to fix it :) 10 daemons is understood, as BT is not that simple and IP stack also have many different tools. But anyway having about 70 defined and undocumented arguments of hccontrol alone, one of which should be used for such basic thing as getting local btaddr, are not looking so funny for anybody who are not BT guru. May be writing of some man page with some BT basics to cross reference that basic tools could help. Or just better cross reference existing pages. -- Alexander Motin From plunky at rya-online.net Wed Feb 4 11:32:06 2009 From: plunky at rya-online.net (Iain Hibbert) Date: Wed Feb 4 11:32:13 2009 Subject: pan profile support in freebsd In-Reply-To: <4989E0F7.3020301@mavhome.dp.ua> References: <1233365217.00068654.1233354838@10.7.7.3> <4988DCCC.80201@mavhome.dp.ua> <4988EBAC.3080202@mavhome.dp.ua> <1233760229.131312.504.nullmailer@galant.ukfsn.org> <4989E0F7.3020301@mavhome.dp.ua> Message-ID: <1233775908.626621.2538.nullmailer@galant.ukfsn.org> On Wed, 4 Feb 2009, Alexander Motin wrote: > Iain Hibbert wrote: > > On Wed, 4 Feb 2009, Alexander Motin wrote: > > > > > One more minor fact. Unlike rfcomm_pppd I haven't found an option to run > > > btpand in foreground to track connection status. > > > > what would you like to accomplish? > > For example, to initiate reconnect on connection failure. Sure it can be done > in many other ways, but running in foreground seems to be usual practice for > many places, like ppp. > > > I made some effort for it to not detach until the setup is complete, but > > it kind of needs to then in order for 'connection up' activities to > > commence (eg proceeding to run dhclient).. at least on my machine I have > > logging turned up and do get some shutdown messages on the console when it > > detaches. > > I think dhclient, for example, could be run via devd when interface comes up, > alike to normal Ethernet. Not sure TAP supports devd not, but I think it could > be fixed. One thing that I have in mind is to make btpand shutdown the tap interface when exiting (as it marks it up when starting). Would that make it possible to use devd to trigger a reconnect if desired? I think its better to have a "event->action" model rather than hang it all together with scripts. iain From mav at mavhome.dp.ua Wed Feb 4 11:53:32 2009 From: mav at mavhome.dp.ua (Alexander Motin) Date: Wed Feb 4 11:53:46 2009 Subject: pan profile support in freebsd In-Reply-To: <1233775908.626621.2538.nullmailer@galant.ukfsn.org> References: <1233365217.00068654.1233354838@10.7.7.3> <4988DCCC.80201@mavhome.dp.ua> <4988EBAC.3080202@mavhome.dp.ua> <1233760229.131312.504.nullmailer@galant.ukfsn.org> <4989E0F7.3020301@mavhome.dp.ua> <1233775908.626621.2538.nullmailer@galant.ukfsn.org> Message-ID: <4989F23F.8040102@mavhome.dp.ua> Iain Hibbert wrote: > On Wed, 4 Feb 2009, Alexander Motin wrote: > >> Iain Hibbert wrote: >>> On Wed, 4 Feb 2009, Alexander Motin wrote: >>> >>>> One more minor fact. Unlike rfcomm_pppd I haven't found an option to run >>>> btpand in foreground to track connection status. >>> what would you like to accomplish? >> For example, to initiate reconnect on connection failure. Sure it can be done >> in many other ways, but running in foreground seems to be usual practice for >> many places, like ppp. >> >>> I made some effort for it to not detach until the setup is complete, but >>> it kind of needs to then in order for 'connection up' activities to >>> commence (eg proceeding to run dhclient).. at least on my machine I have >>> logging turned up and do get some shutdown messages on the console when it >>> detaches. >> I think dhclient, for example, could be run via devd when interface comes up, >> alike to normal Ethernet. Not sure TAP supports devd not, but I think it could >> be fixed. > > One thing that I have in mind is to make btpand shutdown the tap interface > when exiting (as it marks it up when starting). Would that make it > possible to use devd to trigger a reconnect if desired? I think its > better to have a "event->action" model rather than hang it all together > with scripts. It already removes UP status from interface, so there is action which could be tracked by devd. No need to destroy interface if it was not created by you. But from other side devd is more complicated and system-wide case that some trivial custom shell script, so I would prefer to use it just for something common, like running dhclient with adding something like ifconfig_tap1="DHCP" to rc.conf alike to normal Ethernets. -- Alexander Motin From maksim.yevmenkin at gmail.com Wed Feb 4 12:02:35 2009 From: maksim.yevmenkin at gmail.com (Maksim Yevmenkin) Date: Wed Feb 4 12:02:42 2009 Subject: pan profile support in freebsd In-Reply-To: <4989EC35.80502@mavhome.dp.ua> References: <1233365217.00068654.1233354838@10.7.7.3> <4988DCCC.80201@mavhome.dp.ua> <4988EBAC.3080202@mavhome.dp.ua> <4988F857.5080407@mavhome.dp.ua> <4989EC35.80502@mavhome.dp.ua> Message-ID: On Wed, Feb 4, 2009 at 11:27 AM, Alexander Motin wrote: > Maksim Yevmenkin wrote: >>> >>> Does actually this binding really necessary? rfcomm somehow works without >>> it. >> >> please see Iain's response :) i knew he would chime in :) thanks Iain! >> >> and, yes, i suspected that it would be something related to mac >> addresses on virtual ethernet interface. i do not have a copy of spec >> handy, but i recall something about setting mac address to be the same >> as radio's bd_addr. dont remember if it was a requirement or more of a >> guideline. >> >> in any case, i like Iain's suggestion to rewrite mac addresses on the >> fly. i would have done it this way. also, i think, nap server should >> just act as ethernet hub, i.e. forward everything everywhere. after >> all, nap is supposed to be like local ethernet network :) > > Hmm. Working like an Ethernet hub also means that every single hub port (in > our case every single point-to-point BT link) may transmit packets from > different source MAC addresses, that can't be equal to BT adapter address. > So or I don't understand your example, or something is wrong here. why do you think it is wrong? logically all the radios are on the same virtual ethernet network. i think the only issue here is that apparently some clients are picky about src mac address and that complicates the case when nap server has multiple radios. [...] >>> Indeed. But general number of BT tools, daemons and their options just >>> making me sad. >> >> i'm not sure how to read that :) there is, like, less than 10 >> bluetooth related daemons in total. each has, like, may be 10 options. >> compare this to the number of options ls(1) has :) not sure what could >> possibly make you sad here. if you feel that the documentation is not >> adequate, please feel free to fix it :) > > 10 daemons is understood, as BT is not that simple and IP stack also have > many different tools. But anyway having about 70 defined and undocumented > arguments of hccontrol alone, one of which should be used for such basic > thing as getting local btaddr, are not looking so funny for anybody who are > not BT guru. May be writing of some man page with some BT basics to cross > reference that basic tools could help. Or just better cross reference > existing pages. oh, please :) man hccontrol(8) gives you all the commands. it also tells you to use 'help ' to get more information. also help for each command is taken directly from the bluetooth specification. i'm not sure how much more documentation can we put here. there are also man pages for ng_hci(4) and ng_l2cap(4). that is already so much more information than you can ever get on vast majority of bluetooth enabled gadgets. oh, and btw, users are not even supposed to know/touch any of this stuff. so if your bluetooth gadget does not work - you sh*t out of luck for the most of the time :) in ideal world, everything should just work. in real world, like everything that has to do with rf, sometimes it doesn't :) i agree, documentation could always be better, and i repeatedly asked for help here. i do not know why, but for whatever reason people prefer to put stuff on their private webpages/blogs/forums/etc. instead of just saying "hey, i had this problem and here is how i fixed it. wouldn't it be nice if you could document this in man page/handbook. btw, here is the patch." thanks, max From mav at mavhome.dp.ua Wed Feb 4 12:13:18 2009 From: mav at mavhome.dp.ua (Alexander Motin) Date: Wed Feb 4 12:13:25 2009 Subject: pan profile support in freebsd In-Reply-To: References: <1233365217.00068654.1233354838@10.7.7.3> <4988DCCC.80201@mavhome.dp.ua> <4988EBAC.3080202@mavhome.dp.ua> <4988F857.5080407@mavhome.dp.ua> <4989EC35.80502@mavhome.dp.ua> Message-ID: <4989F6E3.9020702@mavhome.dp.ua> Maksim Yevmenkin wrote: > On Wed, Feb 4, 2009 at 11:27 AM, Alexander Motin wrote: >> Maksim Yevmenkin wrote: >>>> Does actually this binding really necessary? rfcomm somehow works without >>>> it. >>> please see Iain's response :) i knew he would chime in :) thanks Iain! >>> >>> and, yes, i suspected that it would be something related to mac >>> addresses on virtual ethernet interface. i do not have a copy of spec >>> handy, but i recall something about setting mac address to be the same >>> as radio's bd_addr. dont remember if it was a requirement or more of a >>> guideline. >>> >>> in any case, i like Iain's suggestion to rewrite mac addresses on the >>> fly. i would have done it this way. also, i think, nap server should >>> just act as ethernet hub, i.e. forward everything everywhere. after >>> all, nap is supposed to be like local ethernet network :) >> Hmm. Working like an Ethernet hub also means that every single hub port (in >> our case every single point-to-point BT link) may transmit packets from >> different source MAC addresses, that can't be equal to BT adapter address. >> So or I don't understand your example, or something is wrong here. > > why do you think it is wrong? logically all the radios are on the same > virtual ethernet network. i think the only issue here is that > apparently some clients are picky about src mac address and that > complicates the case when nap server has multiple radios. You have told that NAP server works as hub. So, as I have understood, it retransmits upstream traffic back down to all/some clients. So, it transmits packets with MAC addresses of other clients via it's BT adapter. So, source MAC address will not match his BDADDR. Or server is an exception, which can violate the rule of equal addresses? -- Alexander Motin From plunky at rya-online.net Wed Feb 4 12:27:03 2009 From: plunky at rya-online.net (Iain Hibbert) Date: Wed Feb 4 12:27:10 2009 Subject: pan profile support in freebsd In-Reply-To: <4989F23F.8040102@mavhome.dp.ua> References: <1233365217.00068654.1233354838@10.7.7.3> <4988DCCC.80201@mavhome.dp.ua> <4988EBAC.3080202@mavhome.dp.ua> <1233760229.131312.504.nullmailer@galant.ukfsn.org> <4989E0F7.3020301@mavhome.dp.ua> <1233775908.626621.2538.nullmailer@galant.ukfsn.org> <4989F23F.8040102@mavhome.dp.ua> Message-ID: <1233779207.215414.2993.nullmailer@galant.ukfsn.org> On Wed, 4 Feb 2009, Alexander Motin wrote: > Iain Hibbert wrote: > > One thing that I have in mind is to make btpand shutdown the tap interface > > when exiting (as it marks it up when starting). Would that make it > > possible to use devd to trigger a reconnect if desired? I think its > > better to have a "event->action" model rather than hang it all together > > with scripts. > > It already removes UP status from interface, so there is action which could be > tracked by devd. Ah, I see. That is a difference in FreeBSD tap(4) device and I wondered about that but will put it on my list to see if its desireable for NetBSD, rather than modifying btpand to do the same. > No need to destroy interface if it was not created by you. no, thats all automatic > But from other side devd is more complicated and system-wide case that some > trivial custom shell script, so I would prefer to use it just for something > common, like running dhclient with adding something like ifconfig_tap1="DHCP" > to rc.conf alike to normal Ethernets. There may be trouble there because network is started before bluetooth, but adding a 'stay in foreground' switch should not be difficult. iain From maksim.yevmenkin at gmail.com Wed Feb 4 13:17:07 2009 From: maksim.yevmenkin at gmail.com (Maksim Yevmenkin) Date: Wed Feb 4 13:17:14 2009 Subject: pan profile support in freebsd In-Reply-To: <4989F6E3.9020702@mavhome.dp.ua> References: <1233365217.00068654.1233354838@10.7.7.3> <4988DCCC.80201@mavhome.dp.ua> <4988EBAC.3080202@mavhome.dp.ua> <4988F857.5080407@mavhome.dp.ua> <4989EC35.80502@mavhome.dp.ua> <4989F6E3.9020702@mavhome.dp.ua> Message-ID: On Wed, Feb 4, 2009 at 12:13 PM, Alexander Motin wrote: > Maksim Yevmenkin wrote: >> >> On Wed, Feb 4, 2009 at 11:27 AM, Alexander Motin >> wrote: >>> >>> Maksim Yevmenkin wrote: >>>>> >>>>> Does actually this binding really necessary? rfcomm somehow works >>>>> without >>>>> it. >>>> >>>> please see Iain's response :) i knew he would chime in :) thanks Iain! >>>> >>>> and, yes, i suspected that it would be something related to mac >>>> addresses on virtual ethernet interface. i do not have a copy of spec >>>> handy, but i recall something about setting mac address to be the same >>>> as radio's bd_addr. dont remember if it was a requirement or more of a >>>> guideline. >>>> >>>> in any case, i like Iain's suggestion to rewrite mac addresses on the >>>> fly. i would have done it this way. also, i think, nap server should >>>> just act as ethernet hub, i.e. forward everything everywhere. after >>>> all, nap is supposed to be like local ethernet network :) >>> >>> Hmm. Working like an Ethernet hub also means that every single hub port >>> (in >>> our case every single point-to-point BT link) may transmit packets from >>> different source MAC addresses, that can't be equal to BT adapter >>> address. >>> So or I don't understand your example, or something is wrong here. >> >> why do you think it is wrong? logically all the radios are on the same >> virtual ethernet network. i think the only issue here is that >> apparently some clients are picky about src mac address and that >> complicates the case when nap server has multiple radios. > > You have told that NAP server works as hub. So, as I have understood, it > retransmits upstream traffic back down to all/some clients. So, it transmits > packets with MAC addresses of other clients via it's BT adapter. So, source > MAC address will not match his BDADDR. Or server is an exception, which can > violate the rule of equal addresses? well, i think we have a disconnect here ;) you see, bnep strips ethernet header completely and replaces it with one of the bnep ethernet headers. your options basically are 1) bnep ethernet header that has both src and dst "mac addresses" (that is both src and dst radio bd_addr's) 2) bnep ethernet header that has only src "mac address" (that is src radio bd_addr only) 3) bnep ethernet header that has only dst "mac address" (that is dst radio bd_addr only) (2) and (3) are basically short forms of (1) and used when it is possible to figure out missing dst or src "mac address" (that is bd_addr really) because there is a directly "attached" rf link. in other words, if i know that you are the final recipient of the packet and i have a direct rf link to you, i'm not going to bother to set dst "mac address" in bnep packet, because you obviously know your "mac address" (bd_addr). or if i generate a packet and i have a direct rf link to you, i'm not going to set src "mac address" (that is bd_addr really) because you know that this packet can only come from me and you already know my "mac address" (bd_addr) so, imo, there is nothing really prevents us from using multiple local radios. also mac address on tap interface is really does not matter, because its get stripped anyway. that is unless tap interface checks dst mac address and make sure it matches (like freebsd does) before passing packet up the stack. if any case, setting promisc. flag on interface will fix it. the only mess here is that arp responses for local tap interface will contain mac address of tap interface and not bd_addr of (one of the) local radio(s). i say, who cares, as long as its properly encapsulated into bnep, imo, it should work. so even if both endpoints have a direct rf link, it will look like they are not. thanks, max From mav at mavhome.dp.ua Wed Feb 4 13:51:24 2009 From: mav at mavhome.dp.ua (Alexander Motin) Date: Wed Feb 4 13:51:30 2009 Subject: pan profile support in freebsd In-Reply-To: References: <1233365217.00068654.1233354838@10.7.7.3> <4988DCCC.80201@mavhome.dp.ua> <4988EBAC.3080202@mavhome.dp.ua> <4988F857.5080407@mavhome.dp.ua> <4989EC35.80502@mavhome.dp.ua> <4989F6E3.9020702@mavhome.dp.ua> Message-ID: <498A0DDF.1050605@mavhome.dp.ua> Maksim Yevmenkin wrote: > On Wed, Feb 4, 2009 at 12:13 PM, Alexander Motin wrote: >> Maksim Yevmenkin wrote: >>> On Wed, Feb 4, 2009 at 11:27 AM, Alexander Motin >>> wrote: >>>> Maksim Yevmenkin wrote: >>>>>> Does actually this binding really necessary? rfcomm somehow works >>>>>> without >>>>>> it. >>>>> please see Iain's response :) i knew he would chime in :) thanks Iain! >>>>> >>>>> and, yes, i suspected that it would be something related to mac >>>>> addresses on virtual ethernet interface. i do not have a copy of spec >>>>> handy, but i recall something about setting mac address to be the same >>>>> as radio's bd_addr. dont remember if it was a requirement or more of a >>>>> guideline. >>>>> >>>>> in any case, i like Iain's suggestion to rewrite mac addresses on the >>>>> fly. i would have done it this way. also, i think, nap server should >>>>> just act as ethernet hub, i.e. forward everything everywhere. after >>>>> all, nap is supposed to be like local ethernet network :) >>>> Hmm. Working like an Ethernet hub also means that every single hub port >>>> (in >>>> our case every single point-to-point BT link) may transmit packets from >>>> different source MAC addresses, that can't be equal to BT adapter >>>> address. >>>> So or I don't understand your example, or something is wrong here. >>> why do you think it is wrong? logically all the radios are on the same >>> virtual ethernet network. i think the only issue here is that >>> apparently some clients are picky about src mac address and that >>> complicates the case when nap server has multiple radios. >> You have told that NAP server works as hub. So, as I have understood, it >> retransmits upstream traffic back down to all/some clients. So, it transmits >> packets with MAC addresses of other clients via it's BT adapter. So, source >> MAC address will not match his BDADDR. Or server is an exception, which can >> violate the rule of equal addresses? > > well, i think we have a disconnect here ;) you see, bnep strips > ethernet header completely and replaces it with one of the bnep > ethernet headers. your options basically are > > 1) bnep ethernet header that has both src and dst "mac addresses" > (that is both src and dst radio bd_addr's) > > 2) bnep ethernet header that has only src "mac address" (that is src > radio bd_addr only) > > 3) bnep ethernet header that has only dst "mac address" (that is dst > radio bd_addr only) > > (2) and (3) are basically short forms of (1) and used when it is > possible to figure out missing dst or src "mac address" (that is > bd_addr really) because there is a directly "attached" rf link. > > in other words, if i know that you are the final recipient of the > packet and i have a direct rf link to you, i'm not going to bother to > set dst "mac address" in bnep packet, because you obviously know your > "mac address" (bd_addr). > > or > > if i generate a packet and i have a direct rf link to you, i'm not > going to set src "mac address" (that is bd_addr really) because you > know that this packet can only come from me and you already know my > "mac address" (bd_addr) Thanks for the explanation, I have got it. Looking into specification I see there is even four header formats: no addresses, source, dest and source+dest. As I understand it's just a form of header compression. As soon as each side knows address of the peer it can compress MAC address if it matches to respective BDADDR. And that's all. > so, imo, there is nothing really prevents us from using multiple local > radios. also mac address on tap interface is really does not matter, > because its get stripped anyway. that is unless tap interface checks > dst mac address and make sure it matches (like freebsd does) before > passing packet up the stack. if any case, setting promisc. flag on > interface will fix it. the only mess here is that arp responses for > local tap interface will contain mac address of tap interface and not > bd_addr of (one of the) local radio(s). i say, who cares, as long as > its properly encapsulated into bnep, imo, it should work. so even if > both endpoints have a direct rf link, it will look like they are not. I still think we should not do such hacks. As I understand there is OK to bridge completely unrelated Ethernet traffic via BNEP link. As soon as MAC addresses does not match to BDADDRs, packets should just be transmitter with full uncompressed Ethernet header. We should keep TAP MAC address equal to BDADDR just as much as possible to maximally benefit from header compression. But if we have single TAP interface on server, which handles several links via different adapters, I understand it should be fine to just choose one of BDADDRs as MAC address to be completely honest to everybody. If there is only one adapter, then all headers will be compressed, if there is several - only part of them. Am I right? -- Alexander Motin From maksim.yevmenkin at gmail.com Wed Feb 4 14:27:55 2009 From: maksim.yevmenkin at gmail.com (Maksim Yevmenkin) Date: Wed Feb 4 14:28:01 2009 Subject: pan profile support in freebsd In-Reply-To: <498A0DDF.1050605@mavhome.dp.ua> References: <1233365217.00068654.1233354838@10.7.7.3> <4988EBAC.3080202@mavhome.dp.ua> <4988F857.5080407@mavhome.dp.ua> <4989EC35.80502@mavhome.dp.ua> <4989F6E3.9020702@mavhome.dp.ua> <498A0DDF.1050605@mavhome.dp.ua> Message-ID: On Wed, Feb 4, 2009 at 1:51 PM, Alexander Motin wrote: [...] >>>>> Hmm. Working like an Ethernet hub also means that every single hub port >>>>> (in >>>>> our case every single point-to-point BT link) may transmit packets from >>>>> different source MAC addresses, that can't be equal to BT adapter >>>>> address. >>>>> So or I don't understand your example, or something is wrong here. >>>> >>>> why do you think it is wrong? logically all the radios are on the same >>>> virtual ethernet network. i think the only issue here is that >>>> apparently some clients are picky about src mac address and that >>>> complicates the case when nap server has multiple radios. >>> >>> You have told that NAP server works as hub. So, as I have understood, it >>> retransmits upstream traffic back down to all/some clients. So, it >>> transmits >>> packets with MAC addresses of other clients via it's BT adapter. So, >>> source >>> MAC address will not match his BDADDR. Or server is an exception, which >>> can >>> violate the rule of equal addresses? >> >> well, i think we have a disconnect here ;) you see, bnep strips >> ethernet header completely and replaces it with one of the bnep >> ethernet headers. your options basically are >> >> 1) bnep ethernet header that has both src and dst "mac addresses" >> (that is both src and dst radio bd_addr's) >> >> 2) bnep ethernet header that has only src "mac address" (that is src >> radio bd_addr only) >> >> 3) bnep ethernet header that has only dst "mac address" (that is dst >> radio bd_addr only) >> >> (2) and (3) are basically short forms of (1) and used when it is >> possible to figure out missing dst or src "mac address" (that is >> bd_addr really) because there is a directly "attached" rf link. >> >> in other words, if i know that you are the final recipient of the >> packet and i have a direct rf link to you, i'm not going to bother to >> set dst "mac address" in bnep packet, because you obviously know your >> "mac address" (bd_addr). >> >> or >> >> if i generate a packet and i have a direct rf link to you, i'm not >> going to set src "mac address" (that is bd_addr really) because you >> know that this packet can only come from me and you already know my >> "mac address" (bd_addr) > > Thanks for the explanation, I have got it. Looking into specification I see > there is even four header formats: no addresses, source, dest and > source+dest. oh yes, i forgot about "no src, no dst" packet :) its been a while since i looked at bnep specification :) so, yes, "no src, no dst" is used when both packet originator and receiver's radios are directly connected via rf link. > As I understand it's just a form of header compression. As soon as each side > knows address of the peer it can compress MAC address if it matches to > respective BDADDR. And that's all. exactly. i must admit that saving up to 14 bytes on relatively slow bluetooth link does not exactly strike me as a huge win :) but what do i know anyway :) >> so, imo, there is nothing really prevents us from using multiple local >> radios. also mac address on tap interface is really does not matter, >> because its get stripped anyway. that is unless tap interface checks >> dst mac address and make sure it matches (like freebsd does) before >> passing packet up the stack. if any case, setting promisc. flag on >> interface will fix it. the only mess here is that arp responses for >> local tap interface will contain mac address of tap interface and not >> bd_addr of (one of the) local radio(s). i say, who cares, as long as >> its properly encapsulated into bnep, imo, it should work. so even if >> both endpoints have a direct rf link, it will look like they are not. > > I still think we should not do such hacks. As I understand there is OK to > bridge completely unrelated Ethernet traffic via BNEP link. As soon as MAC > addresses does not match to BDADDRs, packets should just be transmitter with > full uncompressed Ethernet header. We should keep TAP MAC address equal to > BDADDR just as much as possible to maximally benefit from header > compression. But if we have single TAP interface on server, which handles > several links via different adapters, I understand it should be fine to just > choose one of BDADDRs as MAC address to be completely honest to everybody. > If there is only one adapter, then all headers will be compressed, if there > is several - only part of them. > > Am I right? well, yes and no. somehow you need to map multiple local bd_addr to either one bd_addr or completely different mac address on tap interface. somehow i think that having completely different mac address on tap interface and map all the local bd_addr's to it makes it cleaner. even if we have to transfer 6 extra bytes in bnep header. i like the ability to bind to wildcard address, it allows us to run bluetooth servers even if there are no bluetooth radios connected to the system. for example, i run sdpd, hcsecd etc. on my laptop always. when i need, i simply plug my usb bluetooth dongle it - presto - it all works. magic! :) if you bind to a particular radio, then you tied to it. cant do anything before radio is present and cant do anything after radio is gone. thanks, max From mav at mavhome.dp.ua Wed Feb 4 14:40:34 2009 From: mav at mavhome.dp.ua (Alexander Motin) Date: Wed Feb 4 14:40:49 2009 Subject: pan profile support in freebsd In-Reply-To: References: <1233365217.00068654.1233354838@10.7.7.3> <4988EBAC.3080202@mavhome.dp.ua> <4988F857.5080407@mavhome.dp.ua> <4989EC35.80502@mavhome.dp.ua> <4989F6E3.9020702@mavhome.dp.ua> <498A0DDF.1050605@mavhome.dp.ua> Message-ID: <498A1966.4030600@mavhome.dp.ua> Maksim Yevmenkin wrote: >> As I understand it's just a form of header compression. As soon as each side >> knows address of the peer it can compress MAC address if it matches to >> respective BDADDR. And that's all. > > exactly. i must admit that saving up to 14 bytes on relatively slow > bluetooth link does not exactly strike me as a huge win :) but what do > i know anyway :) > >>> so, imo, there is nothing really prevents us from using multiple local >>> radios. also mac address on tap interface is really does not matter, >>> because its get stripped anyway. that is unless tap interface checks >>> dst mac address and make sure it matches (like freebsd does) before >>> passing packet up the stack. if any case, setting promisc. flag on >>> interface will fix it. the only mess here is that arp responses for >>> local tap interface will contain mac address of tap interface and not >>> bd_addr of (one of the) local radio(s). i say, who cares, as long as >>> its properly encapsulated into bnep, imo, it should work. so even if >>> both endpoints have a direct rf link, it will look like they are not. >> I still think we should not do such hacks. As I understand there is OK to >> bridge completely unrelated Ethernet traffic via BNEP link. As soon as MAC >> addresses does not match to BDADDRs, packets should just be transmitter with >> full uncompressed Ethernet header. We should keep TAP MAC address equal to >> BDADDR just as much as possible to maximally benefit from header >> compression. But if we have single TAP interface on server, which handles >> several links via different adapters, I understand it should be fine to just >> choose one of BDADDRs as MAC address to be completely honest to everybody. >> If there is only one adapter, then all headers will be compressed, if there >> is several - only part of them. >> >> Am I right? > > well, yes and no. somehow you need to map multiple local bd_addr to > either one bd_addr or completely different mac address on tap > interface. somehow i think that having completely different mac > address on tap interface and map all the local bd_addr's to it makes > it cleaner. even if we have to transfer 6 extra bytes in bnep header. > i like the ability to bind to wildcard address, it allows us to run > bluetooth servers even if there are no bluetooth radios connected to > the system. for example, i run sdpd, hcsecd etc. on my laptop always. > when i need, i simply plug my usb bluetooth dongle it - presto - it > all works. magic! :) if you bind to a particular radio, then you tied > to it. cant do anything before radio is present and cant do anything > after radio is gone. If there is no any radio present yet, you can just choose any random MAC address for TAP and transfer it via BNEP later. You will loose 6 bytes per packet due to addresses mismatch, but it should work. By doing unconditional translation of TAP MAC address into BDADDR, you will make impossible bridging between Bluetooth and local network, which is interesting, as can be used, for example, as cheap and low power WiFi alternative. -- Alexander Motin From maksim.yevmenkin at gmail.com Wed Feb 4 15:00:50 2009 From: maksim.yevmenkin at gmail.com (Maksim Yevmenkin) Date: Wed Feb 4 15:00:59 2009 Subject: pan profile support in freebsd In-Reply-To: <498A1966.4030600@mavhome.dp.ua> References: <1233365217.00068654.1233354838@10.7.7.3> <4988F857.5080407@mavhome.dp.ua> <4989EC35.80502@mavhome.dp.ua> <4989F6E3.9020702@mavhome.dp.ua> <498A0DDF.1050605@mavhome.dp.ua> <498A1966.4030600@mavhome.dp.ua> Message-ID: [...] >>>> so, imo, there is nothing really prevents us from using multiple local >>>> radios. also mac address on tap interface is really does not matter, >>>> because its get stripped anyway. that is unless tap interface checks >>>> dst mac address and make sure it matches (like freebsd does) before >>>> passing packet up the stack. if any case, setting promisc. flag on >>>> interface will fix it. the only mess here is that arp responses for >>>> local tap interface will contain mac address of tap interface and not >>>> bd_addr of (one of the) local radio(s). i say, who cares, as long as >>>> its properly encapsulated into bnep, imo, it should work. so even if >>>> both endpoints have a direct rf link, it will look like they are not. >>> >>> I still think we should not do such hacks. As I understand there is OK to >>> bridge completely unrelated Ethernet traffic via BNEP link. As soon as >>> MAC >>> addresses does not match to BDADDRs, packets should just be transmitter >>> with >>> full uncompressed Ethernet header. We should keep TAP MAC address equal >>> to >>> BDADDR just as much as possible to maximally benefit from header >>> compression. But if we have single TAP interface on server, which handles >>> several links via different adapters, I understand it should be fine to >>> just >>> choose one of BDADDRs as MAC address to be completely honest to >>> everybody. >>> If there is only one adapter, then all headers will be compressed, if >>> there >>> is several - only part of them. >>> >>> Am I right? >> >> well, yes and no. somehow you need to map multiple local bd_addr to >> either one bd_addr or completely different mac address on tap >> interface. somehow i think that having completely different mac >> address on tap interface and map all the local bd_addr's to it makes >> it cleaner. even if we have to transfer 6 extra bytes in bnep header. >> i like the ability to bind to wildcard address, it allows us to run >> bluetooth servers even if there are no bluetooth radios connected to >> the system. for example, i run sdpd, hcsecd etc. on my laptop always. >> when i need, i simply plug my usb bluetooth dongle it - presto - it >> all works. magic! :) if you bind to a particular radio, then you tied >> to it. cant do anything before radio is present and cant do anything >> after radio is gone. > > If there is no any radio present yet, you can just choose any random MAC > address for TAP and transfer it via BNEP later. You will loose 6 bytes per > packet due to addresses mismatch, but it should work. By doing unconditional tap is already getting "randomly" selected mac address by default. > translation of TAP MAC address into BDADDR, you will make impossible > bridging between Bluetooth and local network, which is interesting, as can > be used, for example, as cheap and low power WiFi alternative. huh? please explain why. i think if you want to put your nap (wireless) clients onto the same wired lan you might have on your nap server you will have to do bridging no matter what. otherwise your wired clients will not be able to talk to your nap (wireless) clients. and, btw, if i were to do such a setup in real world, i would _never_ever_ use bridging unless i _absolutely_ had to. its just soooo much easier/cleaner/etc. to put nap (wireless) clients onto a separate subnet and use ip routing. as far as wifi alternative goes, its not really going to fly, imo. range is too short, speed is too slow, and it can only do 7 clients at the same time. does not scale at all :( maybe ok for home, but i yet to see a laptop/desktop that has bluetooth and does not have wifi :) thanks, max From mav at mavhome.dp.ua Wed Feb 4 22:37:02 2009 From: mav at mavhome.dp.ua (Alexander Motin) Date: Wed Feb 4 22:37:09 2009 Subject: pan profile support in freebsd In-Reply-To: References: <1233365217.00068654.1233354838@10.7.7.3> <4988F857.5080407@mavhome.dp.ua> <4989EC35.80502@mavhome.dp.ua> <4989F6E3.9020702@mavhome.dp.ua> <498A0DDF.1050605@mavhome.dp.ua> <498A1966.4030600@mavhome.dp.ua> Message-ID: <498A8912.9050208@mavhome.dp.ua> Maksim Yevmenkin wrote: > [...] > >>>>> so, imo, there is nothing really prevents us from using multiple local >>>>> radios. also mac address on tap interface is really does not matter, >>>>> because its get stripped anyway. that is unless tap interface checks >>>>> dst mac address and make sure it matches (like freebsd does) before >>>>> passing packet up the stack. if any case, setting promisc. flag on >>>>> interface will fix it. the only mess here is that arp responses for >>>>> local tap interface will contain mac address of tap interface and not >>>>> bd_addr of (one of the) local radio(s). i say, who cares, as long as >>>>> its properly encapsulated into bnep, imo, it should work. so even if >>>>> both endpoints have a direct rf link, it will look like they are not. >>>> I still think we should not do such hacks. As I understand there is OK to >>>> bridge completely unrelated Ethernet traffic via BNEP link. As soon as >>>> MAC >>>> addresses does not match to BDADDRs, packets should just be transmitter >>>> with >>>> full uncompressed Ethernet header. We should keep TAP MAC address equal >>>> to >>>> BDADDR just as much as possible to maximally benefit from header >>>> compression. But if we have single TAP interface on server, which handles >>>> several links via different adapters, I understand it should be fine to >>>> just >>>> choose one of BDADDRs as MAC address to be completely honest to >>>> everybody. >>>> If there is only one adapter, then all headers will be compressed, if >>>> there >>>> is several - only part of them. >>>> >>>> Am I right? >>> well, yes and no. somehow you need to map multiple local bd_addr to >>> either one bd_addr or completely different mac address on tap >>> interface. somehow i think that having completely different mac >>> address on tap interface and map all the local bd_addr's to it makes >>> it cleaner. even if we have to transfer 6 extra bytes in bnep header. >>> i like the ability to bind to wildcard address, it allows us to run >>> bluetooth servers even if there are no bluetooth radios connected to >>> the system. for example, i run sdpd, hcsecd etc. on my laptop always. >>> when i need, i simply plug my usb bluetooth dongle it - presto - it >>> all works. magic! :) if you bind to a particular radio, then you tied >>> to it. cant do anything before radio is present and cant do anything >>> after radio is gone. >> If there is no any radio present yet, you can just choose any random MAC >> address for TAP and transfer it via BNEP later. You will loose 6 bytes per >> packet due to addresses mismatch, but it should work. By doing unconditional > > tap is already getting "randomly" selected mac address by default. > >> translation of TAP MAC address into BDADDR, you will make impossible >> bridging between Bluetooth and local network, which is interesting, as can >> be used, for example, as cheap and low power WiFi alternative. > > huh? please explain why. i think if you want to put your nap > (wireless) clients onto the same wired lan you might have on your nap > server you will have to do bridging no matter what. I just mean that bridging should be clean, you should pass LAN MAC addresses to Bluetooth directly without mapping to BDADDR and without compression. > otherwise your > wired clients will not be able to talk to your nap (wireless) clients. > and, btw, if i were to do such a setup in real world, i would > _never_ever_ use bridging unless i _absolutely_ had to. its just soooo > much easier/cleaner/etc. to put nap (wireless) clients onto a separate > subnet and use ip routing. > > as far as wifi alternative goes, its not really going to fly, imo. > range is too short, speed is too slow, and it can only do 7 clients at > the same time. does not scale at all :( maybe ok for home, but i yet > to see a laptop/desktop that has bluetooth and does not have wifi :) WiFi kills my PDA's battery in hour or even less and it's range and performance are not much different. -- Alexander Motin From florenzi at gmail.com Thu Feb 5 00:38:58 2009 From: florenzi at gmail.com (Federico Lorenzi) Date: Thu Feb 5 00:39:04 2009 Subject: pan profile support in freebsd Message-ID: <3jnVJlwzBVVF.cHr1JC0S@smtp.gmail.com> From: Alexander Motin Date: 05/02/2009 08:37 > WiFi kills my PDA's battery in hour or even less and it's range and >performance are not much different. Interesting, in a few tests that I've done, my phone's (Nokia E66) WiFI is significantly faster then Bluetooth, over 2MBps vs 70KBps, and range is far greater, although I can vouch for the battery point. Cheers, Federico (Apologies if the formatting of this message is off) From plunky at rya-online.net Thu Feb 5 06:47:20 2009 From: plunky at rya-online.net (Iain Hibbert) Date: Thu Feb 5 06:47:32 2009 Subject: pan profile support in freebsd In-Reply-To: References: <1233365217.00068654.1233354838@10.7.7.3> <4988EBAC.3080202@mavhome.dp.ua> <4988F857.5080407@mavhome.dp.ua> <4989EC35.80502@mavhome.dp.ua> <4989F6E3.9020702@mavhome.dp.ua> <498A0DDF.1050605@mavhome.dp.ua> Message-ID: <1233844132.485077.7695.nullmailer@galant.ukfsn.org> On Wed, 4 Feb 2009, Maksim Yevmenkin wrote: > the system. for example, i run sdpd, hcsecd etc. on my laptop always. > when i need, i simply plug my usb bluetooth dongle it - presto - it > all works. magic! :) if you bind to a particular radio, then you tied > to it. cant do anything before radio is present and cant do anything > after radio is gone. You are [presumably] using devd to [notice that you inserted the dongle and] configure it anyway, there is no reason it can't start any other services you might require.. iain From plunky at rya-online.net Thu Feb 5 06:47:22 2009 From: plunky at rya-online.net (Iain Hibbert) Date: Thu Feb 5 06:47:32 2009 Subject: libhci In-Reply-To: References: <1233365217.00068654.1233354838@10.7.7.3> <4988DCCC.80201@mavhome.dp.ua> <4988EBAC.3080202@mavhome.dp.ua> <1233758519.360141.162.nullmailer@galant.ukfsn.org> Message-ID: <1233845167.798942.24919.nullmailer@galant.ukfsn.org> On Wed, 4 Feb 2009, Maksim Yevmenkin wrote: > int hci_inquiry(...) > > and all the way down to the end of the file :) basically map dev_id to > unit numbers, i.e. dev_id 0 is "ubt0" node, etc. Well, I really dislike that dev_id method to start with. But anyway, I think they are working on a new API that is somewhat higher level and more related to the dbus access. Also, I think that looking at that code, it was written in the beginning and is full of 'good ideas' that somebody might want to use, but in reality much of it has no need to be in a shared library. hci_inquiry() is perhaps the only function that really needs to have a generic cross platform API and it would be nice if it was oriented towards application level rather than tied to a lower layer implementation. I do not know what kind of API the Microsoft (Widcom?) or Apple stacks expose to applications for this, but I suspect they would be a better place to start. iain From maksim.yevmenkin at gmail.com Thu Feb 5 09:51:29 2009 From: maksim.yevmenkin at gmail.com (Maksim Yevmenkin) Date: Thu Feb 5 09:51:35 2009 Subject: pan profile support in freebsd In-Reply-To: <498A8912.9050208@mavhome.dp.ua> References: <1233365217.00068654.1233354838@10.7.7.3> <4989EC35.80502@mavhome.dp.ua> <4989F6E3.9020702@mavhome.dp.ua> <498A0DDF.1050605@mavhome.dp.ua> <498A1966.4030600@mavhome.dp.ua> <498A8912.9050208@mavhome.dp.ua> Message-ID: On Wed, Feb 4, 2009 at 10:37 PM, Alexander Motin wrote: > Maksim Yevmenkin wrote: >> >> [...] >> >>>>>> so, imo, there is nothing really prevents us from using multiple local >>>>>> radios. also mac address on tap interface is really does not matter, >>>>>> because its get stripped anyway. that is unless tap interface checks >>>>>> dst mac address and make sure it matches (like freebsd does) before >>>>>> passing packet up the stack. if any case, setting promisc. flag on >>>>>> interface will fix it. the only mess here is that arp responses for >>>>>> local tap interface will contain mac address of tap interface and not >>>>>> bd_addr of (one of the) local radio(s). i say, who cares, as long as >>>>>> its properly encapsulated into bnep, imo, it should work. so even if >>>>>> both endpoints have a direct rf link, it will look like they are not. >>>>> >>>>> I still think we should not do such hacks. As I understand there is OK >>>>> to >>>>> bridge completely unrelated Ethernet traffic via BNEP link. As soon as >>>>> MAC >>>>> addresses does not match to BDADDRs, packets should just be transmitter >>>>> with >>>>> full uncompressed Ethernet header. We should keep TAP MAC address equal >>>>> to >>>>> BDADDR just as much as possible to maximally benefit from header >>>>> compression. But if we have single TAP interface on server, which >>>>> handles >>>>> several links via different adapters, I understand it should be fine to >>>>> just >>>>> choose one of BDADDRs as MAC address to be completely honest to >>>>> everybody. >>>>> If there is only one adapter, then all headers will be compressed, if >>>>> there >>>>> is several - only part of them. >>>>> >>>>> Am I right? >>>> >>>> well, yes and no. somehow you need to map multiple local bd_addr to >>>> either one bd_addr or completely different mac address on tap >>>> interface. somehow i think that having completely different mac >>>> address on tap interface and map all the local bd_addr's to it makes >>>> it cleaner. even if we have to transfer 6 extra bytes in bnep header. >>>> i like the ability to bind to wildcard address, it allows us to run >>>> bluetooth servers even if there are no bluetooth radios connected to >>>> the system. for example, i run sdpd, hcsecd etc. on my laptop always. >>>> when i need, i simply plug my usb bluetooth dongle it - presto - it >>>> all works. magic! :) if you bind to a particular radio, then you tied >>>> to it. cant do anything before radio is present and cant do anything >>>> after radio is gone. >>> >>> If there is no any radio present yet, you can just choose any random MAC >>> address for TAP and transfer it via BNEP later. You will loose 6 bytes >>> per >>> packet due to addresses mismatch, but it should work. By doing >>> unconditional >> >> tap is already getting "randomly" selected mac address by default. >> >>> translation of TAP MAC address into BDADDR, you will make impossible >>> bridging between Bluetooth and local network, which is interesting, as >>> can >>> be used, for example, as cheap and low power WiFi alternative. >> >> huh? please explain why. i think if you want to put your nap >> (wireless) clients onto the same wired lan you might have on your nap >> server you will have to do bridging no matter what. > > I just mean that bridging should be clean, you should pass LAN MAC addresses > to Bluetooth directly without mapping to BDADDR and without compression. i'm very confused now :) of course wired lan addresses will be passed to wireless clients as is, and, without any header compression. i'm talking about mapping local (to nap server) radio(s) bd_addr to local (to nap server) tap interface mac address. the nap server should never give any reason, to any directly attached wireless client, to use radio's bd_addr instead of tap interface mac address. in other words, the nap server should never use "no src" nor "no src, no dst" bnep headers. all locally (on the nap server) generated packets should always have src address set in bnep header and this src address should be the mac address set on the tap interface. on receiving side, the nap server should check "dst" address against the tap interface mac address and if they match, put packet into the tap device. also, assuming things are working correctly, the nap server should never get packets without "dst" set in bnep header. so, other than wasting 6 bytes, i do not see any downside to this approach. did i miss anything here? >> as far as wifi alternative goes, its not really going to fly, imo. >> range is too short, speed is too slow, and it can only do 7 clients at >> the same time. does not scale at all :( maybe ok for home, but i yet >> to see a laptop/desktop that has bluetooth and does not have wifi :) > > WiFi kills my PDA's battery in hour or even less and it's range and > performance are not much different. well, yes. bluetooth puts less of strain on a battery, but that's really because its low power and thus short range wireless link (inverse square law is really a bitch :) class 1 radio has a max power level of 1mW / 0dBm (rare - up to 1 meter) class 2 radio has a max power level of 2.5mW / 4dBm (most common - up to 10 meters) class 3 radio has a max power level of 100mW / 20dBm (un-common - up to 100 meters) wifi max permitted power levels vary from country to country, but you can (somewhat) compare it to bluetooth class 3 radio. of course you can play games with antennas and stuff, but that is another can of worms :) thanks, max From maksim.yevmenkin at gmail.com Thu Feb 5 09:55:44 2009 From: maksim.yevmenkin at gmail.com (Maksim Yevmenkin) Date: Thu Feb 5 09:55:51 2009 Subject: pan profile support in freebsd In-Reply-To: <1233844132.485077.7695.nullmailer@galant.ukfsn.org> References: <1233365217.00068654.1233354838@10.7.7.3> <4988F857.5080407@mavhome.dp.ua> <4989EC35.80502@mavhome.dp.ua> <4989F6E3.9020702@mavhome.dp.ua> <498A0DDF.1050605@mavhome.dp.ua> <1233844132.485077.7695.nullmailer@galant.ukfsn.org> Message-ID: On Thu, Feb 5, 2009 at 6:28 AM, Iain Hibbert wrote: > On Wed, 4 Feb 2009, Maksim Yevmenkin wrote: > >> the system. for example, i run sdpd, hcsecd etc. on my laptop always. >> when i need, i simply plug my usb bluetooth dongle it - presto - it >> all works. magic! :) if you bind to a particular radio, then you tied >> to it. cant do anything before radio is present and cant do anything >> after radio is gone. > > You are [presumably] using devd to [notice that you inserted the dongle > and] configure it anyway, there is no reason it can't start any other > services you might require.. yes, devd is used to start stack when device is attached. yes, devd also can be used to start all the service daemons, but why makes things complicated? dealing with possible multiple failures (i.e. one service daemon refused to start) is a pain. also a pain when you need to use multiple radios (i.e. make sure service is not stopped if another radio is present, etc.). its just easier, imo, to have service daemons to listen on wildcard addresses and be done with it. thanks, max From maksim.yevmenkin at gmail.com Thu Feb 5 10:01:05 2009 From: maksim.yevmenkin at gmail.com (Maksim Yevmenkin) Date: Thu Feb 5 10:01:11 2009 Subject: libhci In-Reply-To: <1233845167.798942.24919.nullmailer@galant.ukfsn.org> References: <1233365217.00068654.1233354838@10.7.7.3> <4988DCCC.80201@mavhome.dp.ua> <4988EBAC.3080202@mavhome.dp.ua> <1233758519.360141.162.nullmailer@galant.ukfsn.org> <1233845167.798942.24919.nullmailer@galant.ukfsn.org> Message-ID: On Thu, Feb 5, 2009 at 6:46 AM, Iain Hibbert wrote: > On Wed, 4 Feb 2009, Maksim Yevmenkin wrote: > >> int hci_inquiry(...) >> >> and all the way down to the end of the file :) basically map dev_id to >> unit numbers, i.e. dev_id 0 is "ubt0" node, etc. > > Well, I really dislike that dev_id method to start with. But anyway, I > think they are working on a new API that is somewhat higher level and more > related to the dbus access. of course they are :) its linux :) they always working on something new and improved :) anyway, what would you suggest to use instead of dev_id? device name (i.e. ubt0)? anything else? cant use bd_addr because (in freebsd at least) device has to be "initialized" before bd_addr is known. > Also, I think that looking at that code, it was written in the beginning > and is full of 'good ideas' that somebody might want to use, but in > reality much of it has no need to be in a shared library. > > hci_inquiry() is perhaps the only function that really needs to have a > generic cross platform API and it would be nice if it was oriented towards > application level rather than tied to a lower layer implementation. I do > not know what kind of API the Microsoft (Widcom?) or Apple stacks expose > to applications for this, but I suspect they would be a better place to > start. i will take a look at ms api. but surely we have ability to send and receive hci commands/events and enumerate all radios in the system in addition to inquiry, dont you think? thanks, max From mav at mavhome.dp.ua Thu Feb 5 11:31:50 2009 From: mav at mavhome.dp.ua (Alexander Motin) Date: Thu Feb 5 11:31:58 2009 Subject: pan profile support in freebsd In-Reply-To: References: <1233365217.00068654.1233354838@10.7.7.3> <4989EC35.80502@mavhome.dp.ua> <4989F6E3.9020702@mavhome.dp.ua> <498A0DDF.1050605@mavhome.dp.ua> <498A1966.4030600@mavhome.dp.ua> <498A8912.9050208@mavhome.dp.ua> Message-ID: <498B3EA9.1030403@mavhome.dp.ua> Maksim Yevmenkin wrote: > On Wed, Feb 4, 2009 at 10:37 PM, Alexander Motin wrote: >> Maksim Yevmenkin wrote: >>> [...] >>> >>>>>>> so, imo, there is nothing really prevents us from using multiple local >>>>>>> radios. also mac address on tap interface is really does not matter, >>>>>>> because its get stripped anyway. that is unless tap interface checks >>>>>>> dst mac address and make sure it matches (like freebsd does) before >>>>>>> passing packet up the stack. if any case, setting promisc. flag on >>>>>>> interface will fix it. the only mess here is that arp responses for >>>>>>> local tap interface will contain mac address of tap interface and not >>>>>>> bd_addr of (one of the) local radio(s). i say, who cares, as long as >>>>>>> its properly encapsulated into bnep, imo, it should work. so even if >>>>>>> both endpoints have a direct rf link, it will look like they are not. >>>>>> I still think we should not do such hacks. As I understand there is OK >>>>>> to >>>>>> bridge completely unrelated Ethernet traffic via BNEP link. As soon as >>>>>> MAC >>>>>> addresses does not match to BDADDRs, packets should just be transmitter >>>>>> with >>>>>> full uncompressed Ethernet header. We should keep TAP MAC address equal >>>>>> to >>>>>> BDADDR just as much as possible to maximally benefit from header >>>>>> compression. But if we have single TAP interface on server, which >>>>>> handles >>>>>> several links via different adapters, I understand it should be fine to >>>>>> just >>>>>> choose one of BDADDRs as MAC address to be completely honest to >>>>>> everybody. >>>>>> If there is only one adapter, then all headers will be compressed, if >>>>>> there >>>>>> is several - only part of them. >>>>>> >>>>>> Am I right? >>>>> well, yes and no. somehow you need to map multiple local bd_addr to >>>>> either one bd_addr or completely different mac address on tap >>>>> interface. somehow i think that having completely different mac >>>>> address on tap interface and map all the local bd_addr's to it makes >>>>> it cleaner. even if we have to transfer 6 extra bytes in bnep header. >>>>> i like the ability to bind to wildcard address, it allows us to run >>>>> bluetooth servers even if there are no bluetooth radios connected to >>>>> the system. for example, i run sdpd, hcsecd etc. on my laptop always. >>>>> when i need, i simply plug my usb bluetooth dongle it - presto - it >>>>> all works. magic! :) if you bind to a particular radio, then you tied >>>>> to it. cant do anything before radio is present and cant do anything >>>>> after radio is gone. >>>> If there is no any radio present yet, you can just choose any random MAC >>>> address for TAP and transfer it via BNEP later. You will loose 6 bytes >>>> per >>>> packet due to addresses mismatch, but it should work. By doing >>>> unconditional >>> tap is already getting "randomly" selected mac address by default. >>> >>>> translation of TAP MAC address into BDADDR, you will make impossible >>>> bridging between Bluetooth and local network, which is interesting, as >>>> can >>>> be used, for example, as cheap and low power WiFi alternative. >>> huh? please explain why. i think if you want to put your nap >>> (wireless) clients onto the same wired lan you might have on your nap >>> server you will have to do bridging no matter what. >> I just mean that bridging should be clean, you should pass LAN MAC addresses >> to Bluetooth directly without mapping to BDADDR and without compression. > > i'm very confused now :) of course wired lan addresses will be passed > to wireless clients as is, and, without any header compression. i'm > talking about mapping local (to nap server) radio(s) bd_addr to local > (to nap server) tap interface mac address. the nap server should never > give any reason, to any directly attached wireless client, to use > radio's bd_addr instead of tap interface mac address. in other words, > the nap server should never use "no src" nor "no src, no dst" bnep > headers. all locally (on the nap server) generated packets should > always have src address set in bnep header and this src address should > be the mac address set on the tap interface. on receiving side, the > nap server should check "dst" address against the tap interface mac > address and if they match, put packet into the tap device. also, > assuming things are working correctly, the nap server should never get > packets without "dst" set in bnep header. > > so, other than wasting 6 bytes, i do not see any downside to this > approach. did i miss anything here? Sorry, looks like I have misunderstood your: "map multiple local bd_addr to either one bd_addr". I have read it as you are going to interpret fake TAP address as equal to BDADDR and silently compress it. I was against that. I would like to say about that we can: 1) or, as you have just said, set completely fake TAP address and never compress it, as it is never equal, 2) or, as I have told recently, get real BDADDR of any adapter present in system (preferably related) and use it's address for TAP, then for traffic passing via that adapter compression could be used, saving 6 bytes. For usual systems with one adapter it will make that all locally originated/terminated traffic will have compressed src/dst address. -- Alexander Motin From maksim.yevmenkin at gmail.com Thu Feb 5 13:05:24 2009 From: maksim.yevmenkin at gmail.com (Maksim Yevmenkin) Date: Thu Feb 5 13:05:29 2009 Subject: pan profile support in freebsd In-Reply-To: <498B3EA9.1030403@mavhome.dp.ua> References: <1233365217.00068654.1233354838@10.7.7.3> <4989F6E3.9020702@mavhome.dp.ua> <498A0DDF.1050605@mavhome.dp.ua> <498A1966.4030600@mavhome.dp.ua> <498A8912.9050208@mavhome.dp.ua> <498B3EA9.1030403@mavhome.dp.ua> Message-ID: [...] >>>>> If there is no any radio present yet, you can just choose any random >>>>> MAC >>>>> address for TAP and transfer it via BNEP later. You will loose 6 bytes >>>>> per >>>>> packet due to addresses mismatch, but it should work. By doing >>>>> unconditional >>>> >>>> tap is already getting "randomly" selected mac address by default. >>>> >>>>> translation of TAP MAC address into BDADDR, you will make impossible >>>>> bridging between Bluetooth and local network, which is interesting, as >>>>> can >>>>> be used, for example, as cheap and low power WiFi alternative. >>>> >>>> huh? please explain why. i think if you want to put your nap >>>> (wireless) clients onto the same wired lan you might have on your nap >>>> server you will have to do bridging no matter what. >>> >>> I just mean that bridging should be clean, you should pass LAN MAC >>> addresses >>> to Bluetooth directly without mapping to BDADDR and without compression. >> >> i'm very confused now :) of course wired lan addresses will be passed >> to wireless clients as is, and, without any header compression. i'm >> talking about mapping local (to nap server) radio(s) bd_addr to local >> (to nap server) tap interface mac address. the nap server should never >> give any reason, to any directly attached wireless client, to use >> radio's bd_addr instead of tap interface mac address. in other words, >> the nap server should never use "no src" nor "no src, no dst" bnep >> headers. all locally (on the nap server) generated packets should >> always have src address set in bnep header and this src address should >> be the mac address set on the tap interface. on receiving side, the >> nap server should check "dst" address against the tap interface mac >> address and if they match, put packet into the tap device. also, >> assuming things are working correctly, the nap server should never get >> packets without "dst" set in bnep header. >> >> so, other than wasting 6 bytes, i do not see any downside to this >> approach. did i miss anything here? > > Sorry, looks like I have misunderstood your: "map multiple local bd_addr to > either one bd_addr". I have read it as you are going to interpret fake TAP > address as equal to BDADDR and silently compress it. I was against that. > > I would like to say about that we can: > 1) or, as you have just said, set completely fake TAP address and never > compress it, as it is never equal, > 2) or, as I have told recently, get real BDADDR of any adapter present in > system (preferably related) and use it's address for TAP, then for traffic > passing via that adapter compression could be used, saving 6 bytes. For > usual systems with one adapter it will make that all locally > originated/terminated traffic will have compressed src/dst address. its not even interesting anymore :) imo, there is very little reason to set tap interface to any radio's bd_addr. it makes perfect sense (to me) to keep whatever mac address assigned to tap by default because that is the interface on which traffic is flowing. radio is just a transport. it is still possible to compress dst address in bnep header, so, like i said, the overhead is only 6 bytes. that is 6/1500 = 0.4% (!), and, i bet you won't even be able to measure it. oh, and keep in mind that bnep _replaces_ original ethernet header, so even if you don't do _any_ compression at all, you are not doing worse. this is a very reasonable price to pay to support multiple radios and listening on wildcard address without adding extra complexity to the code. plus, like you said, it only can compress src on only one radio link anyway, so the more radios you have, the less "win" you will get. thanks, max From mav at mavhome.dp.ua Thu Feb 5 13:18:25 2009 From: mav at mavhome.dp.ua (Alexander Motin) Date: Thu Feb 5 13:18:32 2009 Subject: pan profile support in freebsd In-Reply-To: References: <1233365217.00068654.1233354838@10.7.7.3> <4989F6E3.9020702@mavhome.dp.ua> <498A0DDF.1050605@mavhome.dp.ua> <498A1966.4030600@mavhome.dp.ua> <498A8912.9050208@mavhome.dp.ua> <498B3EA9.1030403@mavhome.dp.ua> Message-ID: <498B57A5.6080406@mavhome.dp.ua> Maksim Yevmenkin wrote: >> I would like to say about that we can: >> 1) or, as you have just said, set completely fake TAP address and never >> compress it, as it is never equal, >> 2) or, as I have told recently, get real BDADDR of any adapter present in >> system (preferably related) and use it's address for TAP, then for traffic >> passing via that adapter compression could be used, saving 6 bytes. For >> usual systems with one adapter it will make that all locally >> originated/terminated traffic will have compressed src/dst address. > > its not even interesting anymore :) imo, there is very little reason > to set tap interface to any radio's bd_addr. it makes perfect sense > (to me) to keep whatever mac address assigned to tap by default > because that is the interface on which traffic is flowing. radio is > just a transport. > > it is still possible to compress dst address in bnep header, so, like > i said, the overhead is only 6 bytes. that is 6/1500 = 0.4% (!), and, > i bet you won't even be able to measure it. oh, and keep in mind that > bnep _replaces_ original ethernet header, so even if you don't do > _any_ compression at all, you are not doing worse. > > this is a very reasonable price to pay to support multiple radios and > listening on wildcard address without adding extra complexity to the > code. plus, like you said, it only can compress src on only one radio > link anyway, so the more radios you have, the less "win" you will get. Ok, as you wish, simplicity is good, but if it sometimes would be not difficult to implement 2, it still would be not bad. The only thing should be tested is WM compatibility. Iain was written that there is some problems he noticed if addresses differs. -- Alexander Motin From plunky at rya-online.net Fri Feb 6 03:32:44 2009 From: plunky at rya-online.net (Iain Hibbert) Date: Fri Feb 6 03:32:50 2009 Subject: libhci In-Reply-To: References: <1233365217.00068654.1233354838@10.7.7.3> <4988DCCC.80201@mavhome.dp.ua> <4988EBAC.3080202@mavhome.dp.ua> <1233758519.360141.162.nullmailer@galant.ukfsn.org> <1233845167.798942.24919.nullmailer@galant.ukfsn.org> Message-ID: <1233919880.530235.10843.nullmailer@galant.ukfsn.org> On Thu, 5 Feb 2009, Maksim Yevmenkin wrote: > anyway, what would you suggest to use instead of dev_id? device name > (i.e. ubt0)? anything else? cant use bd_addr because (in freebsd at > least) device has to be "initialized" before bd_addr is known. for sure, a generic API would need to use the device name. Internally it can translate to whatever the local hardware control API uses. > i will take a look at ms api. but surely we have ability to send and > receive hci commands/events and enumerate all radios in the system in > addition to inquiry, dont you think? enumerating the radios is useful, yes, but having a function to set the afh_map or some other setting? I think that this is only required by the administrator program (hccontrol in your case) so why does it need to be in a shared library? In a way, its similar for the string functions. What program needs to be able to print the features list? Only a shell based admin tool in reality, even a graphical program might want to provide such a feature list in a different format anyway.. iain From subscr1024 at mail.ru Sat Feb 7 20:01:54 2009 From: subscr1024 at mail.ru (Subscriber) Date: Sat Feb 7 20:02:01 2009 Subject: bluetooth not worked after upgrade to xorg 7.4 Message-ID: <498E4ED9.7010903@mail.ru> I'm not sure about proper mail list... After update xorg my bluetooth mouse (Logitech v470) won't work in graphic mode. Just after boot up, when in console, mouse work as expected, but after typing 'startx\n' I can use only built-in touchpad. However randomly (with probability, say, 1/10) it work in graphic mode too - until next reboot. If mouse not work, I tried to restart hcsecd and bthidd, bring mouse visible via 'connect' button. All this actions seems no effect in graphic mode. -- Best regards. From rnoland at FreeBSD.org Sun Feb 8 01:13:27 2009 From: rnoland at FreeBSD.org (Robert Noland) Date: Sun Feb 8 01:13:34 2009 Subject: bluetooth not worked after upgrade to xorg 7.4 In-Reply-To: <498E4ED9.7010903@mail.ru> References: <498E4ED9.7010903@mail.ru> Message-ID: <1234082252.1562.76.camel@ferret.2hip.net> On Sun, 2009-02-08 at 06:17 +0300, Subscriber wrote: > I'm not sure about proper mail list... > > After update xorg my bluetooth mouse (Logitech v470) won't work in graphic > mode. Just after boot up, when in console, mouse work as expected, but after > typing 'startx\n' I can use only built-in touchpad. However randomly (with > probability, say, 1/10) it work in graphic mode too - until next reboot. > > If mouse not work, I tried to restart hcsecd and bthidd, bring mouse visible > via 'connect' button. All this actions seems no effect in graphic mode. This sounds like it may be the hald/xorg race. I just committed a patch to the xserver that should address this. Try updating xorg-server and see if that helps. robert. > > -- > Best regards. > _______________________________________________ > freebsd-x11@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-x11 > To unsubscribe, send any mail to "freebsd-x11-unsubscribe@freebsd.org" -- Robert Noland FreeBSD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-bluetooth/attachments/20090208/786d712a/attachment.pgp From subscr1024 at mail.ru Sun Feb 8 04:19:12 2009 From: subscr1024 at mail.ru (Subscriber) Date: Sun Feb 8 04:19:20 2009 Subject: bluetooth not worked after upgrade to xorg 7.4 In-Reply-To: <498E4ED9.7010903@mail.ru> References: <498E4ED9.7010903@mail.ru> Message-ID: <498ECCB9.1020805@mail.ru> Excuse me for too short message. I use 8-CURRENT on MSI GX710 notebook. Basic info follows. Subscriber ?????: > I'm not sure about proper mail list... > > After update xorg my bluetooth mouse (Logitech v470) won't work in > graphic mode. Just after boot up, when in console, mouse work as > expected, but after typing 'startx\n' I can use only built-in touchpad. > However randomly (with probability, say, 1/10) it work in graphic mode > too - until next reboot. > > If mouse not work, I tried to restart hcsecd and bthidd, bring mouse > visible via 'connect' button. All this actions seems no effect in > graphic mode. > > > -- > Best regards. # uname -a FreeBSD user 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Fri Feb 6 04:25:02 MSK 2009 user@user:/usr/obj/usr/src/sys/GX710.8 amd64 #dmesg Copyright (c) 1992-2009 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.0-CURRENT #0: Fri Feb 6 04:25:02 MSK 2009 user@user:/usr/obj/usr/src/sys/GX710.8 link_elf_obj: symbol unit2minor undefined KLD file kqemu.ko - could not finalize loading Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Turion(tm) 64 X2 Mobile Technology TL-64 (798.00-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x60f81 Stepping = 1 Features=0x178bfbff Features2=0x2001 AMD Features=0xea500800 AMD Features2=0x11f Cores per package: 2 usable memory = 4284547072 (4086 MB) avail memory = 4120961024 (3930 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0 irqs 0-23 on motherboard wlan: mac acl policy registered kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) ACPI Error (evregion-0427): No handler for Region [EC__] (0xffffff000166cc80) [EmbeddedControl] [20070320] ACPI Error (exfldio-0390): Region EmbeddedControl(3) has no handler [20070320] **** Exception AE_NOT_EXIST during execution of method [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xffffff000166f880) Method Execution Stack: Method [_STA] executing: MBTS Local Variables for method [_STA]: Local0: 0 Local1: 0 Local2: 0 Local3: 0 Local4: 0 Local5: 0 Local6: 0 Local7: 0 Arguments for Method [_STA]: (0 arguments defined, max concurrency = 0) Arg0: 0 Arg1: 0 Arg2: 0 Arg3: 0 Arg4: 0 Arg5: 0 Arg6: 0 ACPI Error (psparse-0626): Method parse/execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xffffff000166f880), AE_NOT_EXIST ACPI Error (uteval-0309): Method execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xffffff000166f880), AE_NOT_EXIST ACPI Error (evregion-0427): No handler for Region [EC__] (0xffffff000166cc80) [EmbeddedControl] [20070320] ACPI Error (exfldio-0390): Region EmbeddedControl(3) has no handler [20070320] **** Exception AE_NOT_EXIST during execution of method [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xffffff000166f880) Method Execution Stack: Method [_STA] executing: MBTS Local Variables for method [_STA]: Local0: 0 Local1: 0 Local2: 0 Local3: 0 Local4: 0 Local5: 0 Local6: 0 Local7: 0 Arguments for Method [_STA]: (0 arguments defined, max concurrency = 0) Arg0: 0 Arg1: 0 Arg2: 0 Arg3: 0 Arg4: 0 Arg5: 0 Arg6: 0 ACPI Error (psparse-0626): Method parse/execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xffffff000166f880), AE_NOT_EXIST ACPI Error (uteval-0309): Method execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xffffff000166f880), AE_NOT_EXIST ACPI Error (evregion-0427): No handler for Region [EC__] (0xffffff000166cc80) [EmbeddedControl] [20070320] ACPI Error (exfldio-0390): Region EmbeddedControl(3) has no handler [20070320] **** Exception AE_NOT_EXIST during execution of method [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xffffff000166f880) Method Execution Stack: Method [_STA] executing: MBTS Local Variables for method [_STA]: Local0: 0 Local1: 0 Local2: 0 Local3: 0 Local4: 0 Local5: 0 Local6: 0 Local7: 0 Arguments for Method [_STA]: (0 arguments defined, max concurrency = 0) Arg0: 0 Arg1: 0 Arg2: 0 Arg3: 0 Arg4: 0 Arg5: 0 Arg6: 0 ACPI Error (psparse-0626): Method parse/execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xffffff000166f880), AE_NOT_EXIST ACPI Error (uteval-0309): Method execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xffffff000166f880), AE_NOT_EXIST ACPI Error (evregion-0427): No handler for Region [EC__] (0xffffff000166cc80) [EmbeddedControl] [20070320] ACPI Error (exfldio-0390): Region EmbeddedControl(3) has no handler [20070320] **** Exception AE_NOT_EXIST during execution of method [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xffffff000166f880) Method Execution Stack: Method [_STA] executing: MBTS Local Variables for method [_STA]: Local0: 0 Local1: 0 Local2: 0 Local3: 0 Local4: 0 Local5: 0 Local6: 0 Local7: 0 Arguments for Method [_STA]: (0 arguments defined, max concurrency = 0) Arg0: 0 Arg1: 0 Arg2: 0 Arg3: 0 Arg4: 0 Arg5: 0 Arg6: 0 ACPI Error (psparse-0626): Method parse/execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xffffff000166f880), AE_NOT_EXIST ACPI Error (uteval-0309): Method execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xffffff000166f880), AE_NOT_EXIST ACPI Error (evregion-0427): No handler for Region [EC__] (0xffffff000166cc80) [EmbeddedControl] [20070320] ACPI Error (exfldio-0390): Region EmbeddedControl(3) has no handler [20070320] **** Exception AE_NOT_EXIST during execution of method [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xffffff000166f880) Method Execution Stack: Method [_STA] executing: MBTS Local Variables for method [_STA]: Local0: 0 Local1: 0 Local2: 0 Local3: 0 Local4: 0 Local5: 0 Local6: 0 Local7: 0 Arguments for Method [_STA]: (0 arguments defined, max concurrency = 0) Arg0: 0 Arg1: 0 Arg2: 0 Arg3: 0 Arg4: 0 Arg5: 0 Arg6: 0 ACPI Error (psparse-0626): Method parse/execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xffffff000166f880), AE_NOT_EXIST ACPI Error (uteval-0309): Method execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xffffff000166f880), AE_NOT_EXIST ACPI Error (evregion-0427): No handler for Region [EC__] (0xffffff000166cc80) [EmbeddedControl] [20070320] ACPI Error (exfldio-0390): Region EmbeddedControl(3) has no handler [20070320] **** Exception AE_NOT_EXIST during execution of method [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xffffff000166f880) Method Execution Stack: Method [_STA] executing: MBTS Local Variables for method [_STA]: Local0: 0 Local1: 0 Local2: 0 Local3: 0 Local4: 0 Local5: 0 Local6: 0 Local7: 0 Arguments for Method [_STA]: (0 arguments defined, max concurrency = 0) Arg0: 0 Arg1: 0 Arg2: 0 Arg3: 0 Arg4: 0 Arg5: 0 Arg6: 0 ACPI Error (psparse-0626): Method parse/execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xffffff000166f880), AE_NOT_EXIST ACPI Error (uteval-0309): Method execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xffffff000166f880), AE_NOT_EXIST ACPI Error (evregion-0427): No handler for Region [EC__] (0xffffff000166cc80) [EmbeddedControl] [20070320] ACPI Error (exfldio-0390): Region EmbeddedControl(3) has no handler [20070320] **** Exception AE_NOT_EXIST during execution of method [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xffffff000166f880) Method Execution Stack: Method [_STA] executing: MBTS Local Variables for method [_STA]: Local0: 0 Local1: 0 Local2: 0 Local3: 0 Local4: 0 Local5: 0 Local6: 0 Local7: 0 Arguments for Method [_STA]: (0 arguments defined, max concurrency = 0) Arg0: 0 Arg1: 0 Arg2: 0 Arg3: 0 Arg4: 0 Arg5: 0 Arg6: 0 ACPI Error (psparse-0626): Method parse/execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xffffff000166f880), AE_NOT_EXIST ACPI Error (uteval-0309): Method execution failed [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xffffff000166f880), AE_NOT_EXIST acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, cff00000 (3) failed ACPI HPET table warning: Sequence is non-zero (2) Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 acpi_ec0: port 0x62,0x66 on acpi0 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 2.0 on pci0 pci1: on pcib1 vgapci0: port 0xb000-0xb0ff mem 0xd0000000-0xdfffffff,0xfd6f0000-0xfd6fffff irq 18 at device 0.0 on pci1 acpi_video0: on vgapci0 hdac0: mem 0xfd6ec000-0xfd6effff irq 19 at device 0.1 on pci1 hdac0: HDA Driver Revision: 20090131_0127 hdac0: [ITHREAD] pcib2: at device 4.0 on pci0 pci2: on pcib2 ath0: mem 0xfd7f0000-0xfd7fffff irq 16 at device 0.0 on pci2 ath0: [ITHREAD] ath0: WARNING: using obsoleted if_watchdog interface ath0: mac 14.2 phy 7.0 radio 10.2 pcib3: at device 6.0 on pci0 pci3: on pcib3 pcib4: at device 7.0 on pci0 pci5: on pcib4 re0: port 0xc800-0xc8ff mem 0xfe2ff000-0xfe2fffff irq 19 at device 0.0 on pci5 re0: turning off MSI enable bit. re0: Chip rev. 0x38000000 re0: MAC rev. 0x00000000 miibus0: on re0 rgephy0: PHY 1 on miibus0 rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto re0: Ethernet address: 00:1d:92:4b:18:11 re0: [FILTER] atapci0: port 0xa000-0xa007,0x9000-0x9003,0x8000-0x8007,0x7000-0x7003,0x6000-0x600f mem 0xfd5ff800-0xfd5ffbff irq 22 at device 18.0 on pci0 atapci0: [ITHREAD] atapci0: AHCI Version 01.10 controller with 4 ports PM supported ata2: on atapci0 ata2: [ITHREAD] ata3: on atapci0 ata3: [ITHREAD] ata4: on atapci0 ata4: [ITHREAD] ata5: on atapci0 ata5: [ITHREAD] ohci0: mem 0xfd5fe000-0xfd5fefff irq 16 at device 19.0 on pci0 ohci0: [GIANT-LOCKED] ohci0: [ITHREAD] usb0: OHCI version 1.0, legacy support usb0: on ohci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered ohci1: mem 0xfd5fd000-0xfd5fdfff irq 17 at device 19.1 on pci0 ohci1: [GIANT-LOCKED] ohci1: [ITHREAD] usb1: OHCI version 1.0, legacy support usb1: on ohci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered ohci2: mem 0xfd5fc000-0xfd5fcfff irq 18 at device 19.2 on pci0 ohci2: [GIANT-LOCKED] ohci2: [ITHREAD] usb2: OHCI version 1.0, legacy support usb2: on ohci2 usb2: USB revision 1.0 uhub2: on usb2 uhub2: 2 ports with 2 removable, self powered ohci3: mem 0xfd5fb000-0xfd5fbfff irq 17 at device 19.3 on pci0 ohci3: [GIANT-LOCKED] ohci3: [ITHREAD] usb3: OHCI version 1.0, legacy support usb3: on ohci3 usb3: USB revision 1.0 uhub3: on usb3 uhub3: 2 ports with 2 removable, self powered ohci4: mem 0xfd5fa000-0xfd5fafff irq 18 at device 19.4 on pci0 ohci4: [GIANT-LOCKED] ohci4: [ITHREAD] usb4: OHCI version 1.0, legacy support usb4: on ohci4 usb4: USB revision 1.0 uhub4: on usb4 uhub4: 2 ports with 2 removable, self powered ehci0: mem 0xfd5ff000-0xfd5ff0ff irq 19 at device 19.5 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb5: EHCI version 1.0 usb5: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4 usb5: on ehci0 usb5: USB revision 2.0 uhub5: on usb5 uhub5: 10 ports with 10 removable, self powered ugen0: on uhub5 pci0: at device 20.0 (no driver attached) atapci1: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xff00-0xff0f at device 20.1 on pci0 ata0: on atapci1 ata0: [ITHREAD] hdac1: mem 0xfd5f4000-0xfd5f7fff irq 16 at device 20.2 on pci0 hdac1: HDA Driver Revision: 20090131_0127 hdac1: [ITHREAD] isab0: at device 20.3 on pci0 isa0: on isab0 pcib5: at device 20.4 on pci0 pci6: on pcib5 cbb0: irq 20 at device 4.0 on pci6 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 cbb0: [FILTER] pci6: at device 4.2 (no driver attached) pci6: at device 4.3 (no driver attached) fwohci0: <1394 Open Host Controller Interface> mem 0xfe3fd000-0xfe3fdfff,0xfe3ff000-0xfe3ff7ff irq 20 at device 4.4 on pci6 fwohci0: [ITHREAD] fwohci0: OHCI version 1.10 (ROM=0) fwohci0: No. of Isochronous channels is 8. fwohci0: EUI64 00:dc:10:00:af:43:34:01 fwohci0: Phy 1394a available S400, 2 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 sbp0: on firewire0 dcons_crom0: on firewire0 dcons_crom0: bus_addr 0x15fc000 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 02:dc:10:43:34:01 fwe0: Ethernet address: 02:dc:10:43:34:01 fwip0: on firewire0 fwip0: Firewire address: 00:dc:10:00:af:43:34:01 @ 0xfffe00000000, S400, maxrec 2048 fwohci0: Initiate bus reset fwohci0: BUS reset fwohci0: node_id=0x00000000, SelfID Count=1, CYCLEMASTER mode k8temp0: on hostb4 acpi_button0: on acpi0 acpi_tz0: on acpi0 atrtc0: port 0x70-0x71 irq 8 on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model IntelliMouse, device ID 3 acpi_acad0: on acpi0 battery0: on acpi0 acpi_lid0: on acpi0 cpu0: on acpi0 acpi_throttle0: on cpu0 acpi_throttle0: CLK_VAL field overlaps THT_EN bit device_attach: acpi_throttle0 attach returned 6 powernow0: on cpu0 cpu1: on acpi0 powernow1: on cpu1 orm0: at iomem 0xcf000-0xcffff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ugen1: on uhub3 ubt0: on uhub3 ubt0: Interface 0 endpoints: interrupt=0x81, bulk-in=0x82, bulk-out=0x2 ubt0: Interface 1 (alt.config 5) endpoints: isoc-in=0x83, isoc-out=0x3; wMaxPacketSize=49; nframes=10, buffer size=490 Timecounters tick every 1.000 msec firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) firewire0: bus manager 0 (me) acd0: DVDR at ata0-master UDMA33 ad4: 238475MB at ata2-master SATA150 hdac0: HDA Codec #0: ATI R6xx HDMI pcm0: at cad 0 nid 1 on hdac0 hdac1: HDA Codec #0: Realtek ALC888 hdac1: HDA Codec #1: Lucent/Agere Systems (Unknown) pcm1: at cad 0 nid 1 on hdac1 pcm2: at cad 0 nid 1 on hdac1 GEOM: ad4s1: geometry does not match label (255h,63s != 16h,63s). acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 (probe7:ata0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (probe7:ata0:0:0:0): CAM Status: SCSI Status Error (probe7:ata0:0:0:0): SCSI Status: Check Condition (probe7:ata0:0:0:0): NOT READY asc:3a,0 (probe7:ata0:0:0:0): Medium not present (probe7:ata0:0:0:0): Unretryable error SMP: AP CPU #1 Launched! cd0 at ata0 bus 0 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 33.000MB/s transfers cd0: Attempt to query device size failed: NOT READY, Medium not present Trying to mount root from ufs:/dev/ad4s1a This module (opensolaris) contains code covered by the Common Development and Distribution License (CDDL) see http://opensolaris.org/os/licensing/opensolaris_license/ WARNING: ZFS is considered to be an experimental feature in FreeBSD. ZFS filesystem version 13 ZFS storage pool version 13 wlan0: Ethernet address: 00:15:af:54:f6:25 wlan0: link state changed to UP acpi_ec0: wait timed out (response), forcing polled mode # pkg_info | grep "xorg\|xf86" libXxf86dga-1.0.2 X DGA Extension libXxf86misc-1.0.1 X XF86-Misc Extension libXxf86vm-1.0.2 X Vidmode Extension linux-xorg-libs-6.8.2_5 Xorg libraries, linux binaries xf86-input-keyboard-1.3.2 X.Org keyboard input driver xf86-input-mouse-1.4.0_3 X.Org mouse input driver xf86-video-radeonhd-1.2.4_1 X.Org ati RadeonHD display driver xf86-video-vesa-2.1.0 X.Org vesa display driver xf86bigfontproto-1.1.2 XFree86-Bigfont extension headers xf86dga-1.0.2_1 Test program for the XFree86-DGA extension xf86dgaproto-2.0.3 XFree86-DGA extension headers xf86driproto-2.0.4 XFree86-DRI extension headers xf86miscproto-0.9.2 XFree86-Misc extension headers xf86rushproto-1.1.2 XFree86-Rush extension headers xf86vidmodeproto-2.2.2 XFree86-VidModeExtension extension headers xorg-7.4 X.Org complete distribution metaport xorg-apps-7.4_1 X.org apps meta-port xorg-cf-files-1.0.2_3 X.org cf files for use with imake builds xorg-docs-1.4,1 X.org documentation files xorg-drivers-7.4 X.org drivers meta-port xorg-fonts-100dpi-7.4 X.Org 100dpi bitmap fonts xorg-fonts-7.4 X.org fonts meta-port xorg-fonts-75dpi-7.4 X.Org 75dpi bitmap fonts xorg-fonts-cyrillic-7.4 X.Org Cyrillic bitmap fonts xorg-fonts-miscbitmaps-7.4 X.Org miscellaneous bitmap fonts xorg-fonts-truetype-7.4 X.Org TrueType fonts xorg-fonts-type1-7.4 X.Org Type1 fonts xorg-libraries-7.4 X.org libraries meta-port xorg-macros-1.2.1 X.Org development aclocal macros xorg-server-1.5.3_4,1 X.Org X server and related programs From oleg.nauman at gmail.com Thu Feb 12 01:31:18 2009 From: oleg.nauman at gmail.com (Oleg Nauman) Date: Thu Feb 12 01:31:25 2009 Subject: Trouble connecting HP Compaq 6720s with Nokia 3610 cell phone Message-ID: <46cbfbb80902120107x6ef309efs3d6b03e76c82fa78@mail.gmail.com> Hello list members, I have a trouble connecting my Nokia 3610 cell phone via bluetooth link. Initial setup was performed accordingly to http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/network-bluetooth.html, devices are paired ( well accordingly to Nokia's report at least ) but any attempts to connect my cell phone to notebook are rejected. Here is related log messages: Feb 12 10:34:21 rainhaven kernel: ng_hci_process_event: ubt0hci - got HCI event=0x4, length=10 Feb 12 10:34:21 rainhaven kernel: ng_hci_process_event: ubt0hci - got HCI event=0xf, length=4 Feb 12 10:34:21 rainhaven kernel: ng_hci_process_event: ubt0hci - got HCI event=0x12, length=8 Feb 12 10:34:21 rainhaven kernel: ng_l2cap_lp_receive: ubt0l2cap - got ACL data packet, con_handle=11, PB=0x1, length=0 Feb 12 10:34:21 rainhaven kernel: ng_l2cap_lp_receive: ubt0l2cap - unexpected ACL data packet. Connection does not exist, con_handle=11 Feb 12 10:34:22 rainhaven kernel: ng_hci_process_event: ubt0hci - got HCI event=0x3, length=11 Feb 12 10:34:22 rainhaven kernel: ng_hci_process_event: ubt0hci - got HCI event=0xe, length=6 Feb 12 10:34:22 rainhaven kernel: ng_hci_process_event: ubt0hci - got HCI event=0x1b, length=3 Feb 12 10:34:22 rainhaven kernel: ng_l2cap_lp_receive: ubt0l2cap - got ACL data packet, con_handle=11, PB=0x2, length=12 Feb 12 10:34:22 rainhaven kernel: ng_l2cap_lp_receive: ubt0l2cap - staring new L2CAP packet, con_handle=11, length=8 Feb 12 10:34:22 rainhaven kernel: ng_l2cap_lp_send: ubt0l2cap - attaching ACL packet, con_handle=11, PB=0x2, length=16 Feb 12 10:34:22 rainhaven kernel: ng_l2cap_lp_deliver: ubt0l2cap - sending ACL packet, con_handle=11, len=21 Feb 12 10:34:22 rainhaven kernel: ng_hci_send_data: ubt0hci - sending ACL data packets, count=8 Feb 12 10:34:22 rainhaven kernel: send_data_packets: ubt0hci - sending data packet, handle=11, len=21 Feb 12 10:34:22 rainhaven kernel: ng_hci_send_data: ubt0hci - sending SCO data packets, count=1 Feb 12 10:34:22 rainhaven kernel: ng_l2cap_lp_deliver: ubt0l2cap - 1 ACL packets have been sent, con_handle=11 Feb 12 10:34:22 rainhaven kernel: ng_l2cap_lower_rcvmsg: ubt0l2cap - sync HCI connection queue, con_handle=11, pending=1, completed=1 Feb 12 10:34:22 rainhaven kernel: ng_l2cap_lp_receive: ubt0l2cap - got ACL data packet, con_handle=11, PB=0x2, length=16 Feb 12 10:34:22 rainhaven kernel: ng_l2cap_lp_receive: ubt0l2cap - staring new L2CAP packet, con_handle=11, length=12 Feb 12 10:34:22 rainhaven kernel: ng_l2cap_lp_send: ubt0l2cap - attaching ACL packet, con_handle=11, PB=0x2, length=14 Feb 12 10:34:22 rainhaven kernel: ng_l2cap_lp_deliver: ubt0l2cap - sending ACL packet, con_handle=11, len=19 Feb 12 10:34:22 rainhaven kernel: ng_hci_send_data: ubt0hci - sending ACL data packets, count=7 Feb 12 10:34:22 rainhaven kernel: send_data_packets: ubt0hci - sending data packet, handle=11, len=19 Feb 12 10:34:22 rainhaven kernel: ng_hci_send_data: ubt0hci - sending SCO data packets, count=1 Feb 12 10:34:22 rainhaven kernel: ng_l2cap_lp_deliver: ubt0l2cap - 1 ACL packets have been sent, con_handle=11 Feb 12 10:34:22 rainhaven kernel: ng_l2cap_lower_rcvmsg: ubt0l2cap - sync HCI connection queue, con_handle=11, pending=1, completed=1 Feb 12 10:34:22 rainhaven kernel: ng_l2cap_lp_send: ubt0l2cap - attaching ACL packet, con_handle=11, PB=0x2, length=12 Feb 12 10:34:22 rainhaven kernel: ng_l2cap_lp_deliver: ubt0l2cap - sending ACL packet, con_handle=11, len=17 Feb 12 10:34:22 rainhaven kernel: ng_hci_send_data: ubt0hci - sending ACL data packets, count=6 Feb 12 10:34:22 rainhaven kernel: send_data_packets: ubt0hci - sending data packet, handle=11, len=17 Feb 12 10:34:22 rainhaven kernel: ng_hci_send_data: ubt0hci - sending SCO data packets, count=1 Feb 12 10:34:22 rainhaven kernel: ng_l2cap_lp_deliver: ubt0l2cap - 1 ACL packets have been sent, con_handle=11 Feb 12 10:34:22 rainhaven kernel: ng_l2cap_lower_rcvmsg: ubt0l2cap - sync HCI connection queue, con_handle=11, pending=1, completed=1 Feb 12 10:34:22 rainhaven kernel: ng_hci_process_event: ubt0hci - got HCI event=0x13, length=5 Feb 12 10:34:22 rainhaven kernel: ng_hci_send_data: ubt0hci - sending ACL data packets, count=7 Feb 12 10:34:22 rainhaven kernel: ng_hci_send_data: ubt0hci - sending SCO data packets, count=1 Feb 12 10:34:22 rainhaven kernel: ng_l2cap_lp_receive: ubt0l2cap - got ACL data packet, con_handle=11, PB=0x2, length=14 Feb 12 10:34:22 rainhaven kernel: ng_l2cap_lp_receive: ubt0l2cap - staring new L2CAP packet, con_handle=11, length=10 Feb 12 10:34:22 rainhaven kernel: ng_l2cap_lp_receive: ubt0l2cap - got ACL data packet, con_handle=11, PB=0x2, length=17 Feb 12 10:34:22 rainhaven kernel: ng_l2cap_lp_receive: ubt0l2cap - staring new L2CAP packet, con_handle=11, length=13 Feb 12 10:34:22 rainhaven kernel: ng_l2cap_lp_send: ubt0l2cap - attaching ACL packet, con_handle=11, PB=0x2, length=14 Feb 12 10:34:22 rainhaven kernel: ng_l2cap_lp_deliver: ubt0l2cap - sending ACL packet, con_handle=11, len=19 Feb 12 10:34:22 rainhaven kernel: ng_hci_send_data: ubt0hci - sending ACL data packets, count=7 Feb 12 10:34:22 rainhaven kernel: send_data_packets: ubt0hci - sending data packet, handle=11, len=19 Feb 12 10:34:22 rainhaven kernel: ng_hci_send_data: ubt0hci - sending SCO data packets, count=1 Feb 12 10:34:22 rainhaven kernel: ng_l2cap_lp_deliver: ubt0l2cap - 1 ACL packets have been sent, con_handle=11 Feb 12 10:34:22 rainhaven kernel: ng_l2cap_lower_rcvmsg: ubt0l2cap - sync HCI connection queue, con_handle=11, pending=1, completed=1 Feb 12 10:34:22 rainhaven kernel: ng_hci_process_event: ubt0hci - got HCI event=0x13, length=5 Feb 12 10:34:22 rainhaven kernel: ng_hci_send_data: ubt0hci - sending ACL data packets, count=8 Feb 12 10:34:22 rainhaven kernel: ng_hci_send_data: ubt0hci - sending SCO data packets, count=1 Feb 12 10:34:22 rainhaven kernel: ng_l2cap_lp_receive: ubt0l2cap - got ACL data packet, con_handle=11, PB=0x2, length=12 Feb 12 10:34:22 rainhaven kernel: ng_l2cap_lp_receive: ubt0l2cap - staring new L2CAP packet, con_handle=11, length=8 Feb 12 10:34:22 rainhaven kernel: ng_l2cap_lp_send: ubt0l2cap - attaching ACL packet, con_handle=11, PB=0x2, length=12 Feb 12 10:34:22 rainhaven kernel: ng_l2cap_lp_deliver: ubt0l2cap - sending ACL packet, con_handle=11, len=17 Feb 12 10:34:22 rainhaven kernel: ng_l2cap_lp_deliver: ubt0l2cap - 1 ACL packets have been sent, con_handle=11 Feb 12 10:34:22 rainhaven kernel: ng_hci_send_data: ubt0hci - sending ACL data packets, count=8 Feb 12 10:34:22 rainhaven kernel: send_data_packets: ubt0hci - sending data packet, handle=11, len=17 Feb 12 10:34:22 rainhaven kernel: ng_l2cap_lower_rcvmsg: ubt0l2cap - sync HCI connection queue, con_handle=11, pending=1, completed=1 Feb 12 10:34:22 rainhaven kernel: ng_hci_send_data: ubt0hci - sending SCO data packets, count=1 Feb 12 10:34:22 rainhaven kernel: ng_l2cap_lp_receive: ubt0l2cap - got ACL data packet, con_handle=11, PB=0x2, length=12 Feb 12 10:34:22 rainhaven kernel: ng_l2cap_lp_receive: ubt0l2cap - staring new L2CAP packet, con_handle=11, length=8 Feb 12 10:34:22 rainhaven kernel: ng_l2cap_lp_send: ubt0l2cap - attaching ACL packet, con_handle=11, PB=0x2, length=16 Feb 12 10:34:22 rainhaven kernel: ng_l2cap_lp_deliver: ubt0l2cap - sending ACL packet, con_handle=11, len=21 Feb 12 10:34:22 rainhaven kernel: ng_hci_send_data: ubt0hci - sending ACL data packets, count=7 Feb 12 10:34:22 rainhaven kernel: send_data_packets: ubt0hci - sending data packet, handle=11, len=21 Feb 12 10:34:22 rainhaven kernel: ng_hci_send_data: ubt0hci - sending SCO data packets, count=1 Feb 12 10:34:22 rainhaven kernel: ng_l2cap_lp_deliver: ubt0l2cap - 1 ACL packets have been sent, con_handle=11 Feb 12 10:34:22 rainhaven kernel: ng_l2cap_lower_rcvmsg: ubt0l2cap - sync HCI connection queue, con_handle=11, pending=1, completed=1 Feb 12 10:34:22 rainhaven kernel: ng_hci_process_event: ubt0hci - got HCI event=0x13, length=5 Feb 12 10:34:22 rainhaven kernel: ng_hci_send_data: ubt0hci - sending ACL data packets, count=8 Feb 12 10:34:22 rainhaven kernel: ng_hci_send_data: ubt0hci - sending SCO data packets, count=1 Feb 12 10:34:22 rainhaven kernel: ng_l2cap_lp_receive: ubt0l2cap - got ACL data packet, con_handle=11, PB=0x2, length=16 Feb 12 10:34:22 rainhaven kernel: ng_l2cap_lp_receive: ubt0l2cap - staring new L2CAP packet, con_handle=11, length=12 Feb 12 10:34:22 rainhaven kernel: ng_l2cap_lp_send: ubt0l2cap - attaching ACL packet, con_handle=11, PB=0x2, length=14 Feb 12 10:34:22 rainhaven kernel: ng_l2cap_lp_deliver: ubt0l2cap - sending ACL packet, con_handle=11, len=19 Feb 12 10:34:22 rainhaven kernel: ng_hci_send_data: ubt0hci - sending ACL data packets, count=8 Feb 12 10:34:22 rainhaven kernel: send_data_packets: ubt0hci - sending data packet, handle=11, len=19 Feb 12 10:34:22 rainhaven kernel: ng_hci_send_data: ubt0hci - sending SCO data packets, count=1 Feb 12 10:34:22 rainhaven kernel: ng_l2cap_lp_deliver: ubt0l2cap - 1 ACL packets have been sent, con_handle=11 Feb 12 10:34:22 rainhaven kernel: ng_l2cap_lower_rcvmsg: ubt0l2cap - sync HCI connection queue, con_handle=11, pending=1, completed=1 Feb 12 10:34:22 rainhaven kernel: ng_l2cap_lp_send: ubt0l2cap - attaching ACL packet, con_handle=11, PB=0x2, length=12 Feb 12 10:34:22 rainhaven kernel: ng_l2cap_lp_deliver: ubt0l2cap - sending ACL packet, con_handle=11, len=17 Feb 12 10:34:22 rainhaven kernel: ng_hci_send_data: ubt0hci - sending ACL data packets, count=7 Feb 12 10:34:22 rainhaven kernel: send_data_packets: ubt0hci - sending data packet, handle=11, len=17 Feb 12 10:34:22 rainhaven kernel: ng_hci_send_data: ubt0hci - sending SCO data packets, count=1 Feb 12 10:34:22 rainhaven kernel: ng_l2cap_lp_deliver: ubt0l2cap - 1 ACL packets have been sent, con_handle=11 Feb 12 10:34:22 rainhaven kernel: ng_l2cap_lower_rcvmsg: ubt0l2cap - sync HCI connection queue, con_handle=11, pending=1, completed=1 Feb 12 10:34:22 rainhaven kernel: ng_hci_process_event: ubt0hci - got HCI event=0x13, length=5 Feb 12 10:34:22 rainhaven kernel: ng_hci_send_data: ubt0hci - sending ACL data packets, count=8 Feb 12 10:34:22 rainhaven kernel: ng_hci_send_data: ubt0hci - sending SCO data packets, count=1 Feb 12 10:34:22 rainhaven kernel: ng_l2cap_lp_receive: ubt0l2cap - got ACL data packet, con_handle=11, PB=0x2, length=14 Feb 12 10:34:22 rainhaven kernel: ng_l2cap_lp_receive: ubt0l2cap - staring new L2CAP packet, con_handle=11, length=10 Feb 12 10:34:22 rainhaven kernel: ng_l2cap_lp_receive: ubt0l2cap - got ACL data packet, con_handle=11, PB=0x2, length=17 Feb 12 10:34:22 rainhaven kernel: ng_l2cap_lp_receive: ubt0l2cap - staring new L2CAP packet, con_handle=11, length=13 Feb 12 10:34:22 rainhaven kernel: ng_l2cap_lp_send: ubt0l2cap - attaching ACL packet, con_handle=11, PB=0x2, length=14 Feb 12 10:34:22 rainhaven kernel: ng_l2cap_lp_deliver: ubt0l2cap - sending ACL packet, con_handle=11, len=19 Feb 12 10:34:22 rainhaven kernel: ng_hci_send_data: ubt0hci - sending ACL data packets, count=8 Feb 12 10:34:22 rainhaven kernel: send_data_packets: ubt0hci - sending data packet, handle=11, len=19 Feb 12 10:34:22 rainhaven kernel: ng_hci_send_data: ubt0hci - sending SCO data packets, count=1 Feb 12 10:34:22 rainhaven kernel: ng_l2cap_lp_deliver: ubt0l2cap - 1 ACL packets have been sent, con_handle=11 Feb 12 10:34:22 rainhaven kernel: ng_l2cap_lower_rcvmsg: ubt0l2cap - sync HCI connection queue, con_handle=11, pending=1, completed=1 Feb 12 10:34:22 rainhaven kernel: ng_l2cap_lp_receive: ubt0l2cap - got ACL data packet, con_handle=11, PB=0x2, length=12 Feb 12 10:34:22 rainhaven kernel: ng_l2cap_lp_receive: ubt0l2cap - staring new L2CAP packet, con_handle=11, length=8 Feb 12 10:34:22 rainhaven kernel: ng_l2cap_lp_send: ubt0l2cap - attaching ACL packet, con_handle=11, PB=0x2, length=12 Feb 12 10:34:22 rainhaven kernel: ng_l2cap_lp_deliver: ubt0l2cap - sending ACL packet, con_handle=11, len=17 Feb 12 10:34:22 rainhaven kernel: ng_l2cap_lp_deliver: ubt0l2cap - 1 ACL packets have been sent, con_handle=11 Feb 12 10:34:22 rainhaven kernel: ng_hci_send_data: ubt0hci - sending ACL data packets, count=7 Feb 12 10:34:22 rainhaven kernel: send_data_packets: ubt0hci - sending data packet, handle=11, len=17 Feb 12 10:34:22 rainhaven kernel: ng_l2cap_lower_rcvmsg: ubt0l2cap - sync HCI connection queue, con_handle=11, pending=1, completed=1 Feb 12 10:34:22 rainhaven kernel: ng_hci_send_data: ubt0hci - sending SCO data packets, count=1 Feb 12 10:34:22 rainhaven kernel: ng_hci_process_event: ubt0hci - got HCI event=0x13, length=5 Feb 12 10:34:22 rainhaven kernel: ng_hci_send_data: ubt0hci - sending ACL data packets, count=8 Feb 12 10:34:22 rainhaven kernel: ng_hci_send_data: ubt0hci - sending SCO data packets, count=1 Feb 12 10:34:22 rainhaven kernel: ng_l2cap_lp_receive: ubt0l2cap - got ACL data packet, con_handle=11, PB=0x2, length=12 Feb 12 10:34:22 rainhaven kernel: ng_l2cap_lp_receive: ubt0l2cap - staring new L2CAP packet, con_handle=11, length=8 Feb 12 10:34:22 rainhaven kernel: ng_l2cap_lp_send: ubt0l2cap - attaching ACL packet, con_handle=11, PB=0x2, length=16 Feb 12 10:34:22 rainhaven kernel: ng_l2cap_lp_deliver: ubt0l2cap - sending ACL packet, con_handle=11, len=21 Feb 12 10:34:22 rainhaven kernel: ng_hci_send_data: ubt0hci - sending ACL data packets, count=8 Feb 12 10:34:22 rainhaven kernel: send_data_packets: ubt0hci - sending data packet, handle=11, len=21 Feb 12 10:34:22 rainhaven kernel: ng_hci_send_data: ubt0hci - sending SCO data packets, count=1 Feb 12 10:34:22 rainhaven kernel: ng_l2cap_lp_deliver: ubt0l2cap - 1 ACL packets have been sent, con_handle=11 Feb 12 10:34:22 rainhaven kernel: ng_l2cap_lower_rcvmsg: ubt0l2cap - sync HCI connection queue, con_handle=11, pending=1, completed=1 Feb 12 10:34:22 rainhaven kernel: ng_l2cap_lp_receive: ubt0l2cap - got ACL data packet, con_handle=11, PB=0x2, length=16 Feb 12 10:34:22 rainhaven kernel: ng_l2cap_lp_receive: ubt0l2cap - staring new L2CAP packet, con_handle=11, length=12 Feb 12 10:34:22 rainhaven kernel: ng_l2cap_lp_send: ubt0l2cap - attaching ACL packet, con_handle=11, PB=0x2, length=14 Feb 12 10:34:22 rainhaven kernel: ng_l2cap_lp_deliver: ubt0l2cap - sending ACL packet, con_handle=11, len=19 Feb 12 10:34:22 rainhaven kernel: ng_hci_send_data: ubt0hci - sending ACL data packets, count=7 Feb 12 10:34:22 rainhaven kernel: send_data_packets: ubt0hci - sending data packet, handle=11, len=19 Feb 12 10:34:22 rainhaven kernel: ng_hci_send_data: ubt0hci - sending SCO data packets, count=1 Feb 12 10:34:22 rainhaven kernel: ng_l2cap_lp_deliver: ubt0l2cap - 1 ACL packets have been sent, con_handle=11 Feb 12 10:34:22 rainhaven kernel: ng_l2cap_lower_rcvmsg: ubt0l2cap - sync HCI connection queue, con_handle=11, pending=1, completed=1 Feb 12 10:34:22 rainhaven kernel: ng_l2cap_lp_send: ubt0l2cap - attaching ACL packet, con_handle=11, PB=0x2, length=12 Feb 12 10:34:22 rainhaven kernel: ng_l2cap_lp_deliver: ubt0l2cap - sending ACL packet, con_handle=11, len=17 Feb 12 10:34:22 rainhaven kernel: ng_hci_send_data: ubt0hci - sending ACL data packets, count=6 Feb 12 10:34:22 rainhaven kernel: send_data_packets: ubt0hci - sending data packet, handle=11, len=17 Feb 12 10:34:22 rainhaven kernel: ng_hci_send_data: ubt0hci - sending SCO data packets, count=1 Feb 12 10:34:22 rainhaven kernel: ng_l2cap_lp_deliver: ubt0l2cap - 1 ACL packets have been sent, con_handle=11 Feb 12 10:34:22 rainhaven kernel: ng_l2cap_lower_rcvmsg: ubt0l2cap - sync HCI connection queue, con_handle=11, pending=1, completed=1 Feb 12 10:34:22 rainhaven kernel: ng_hci_process_event: ubt0hci - got HCI event=0x13, length=5 Feb 12 10:34:22 rainhaven kernel: ng_hci_send_data: ubt0hci - sending ACL data packets, count=7 Feb 12 10:34:22 rainhaven kernel: ng_hci_send_data: ubt0hci - sending SCO data packets, count=1 Feb 12 10:34:22 rainhaven kernel: ng_l2cap_lp_receive: ubt0l2cap - got ACL data packet, con_handle=11, PB=0x2, length=14 Feb 12 10:34:22 rainhaven kernel: Feb 12 10:34:22 rainhaven kernel: ng_l2cap_lp_receive: ubt0l2cap - staring new L2CAP packet, con_handle=11, length=10 Feb 12 10:34:22 rainhaven kernel: ng_l2cap_lp_receive: ubt0l2cap - got ACL data packet, con_handle=11, PB=0x2, length=17 Feb 12 10:34:22 rainhaven kernel: ng_l2cap_lp_receive: ubt0l2cap - staring new L2CAP packet, con_handle=11, length=13 Feb 12 10:34:22 rainhaven kernel: ng_l2cap_lp_send: ubt0l2cap - attaching ACL packet, con_handle=11, PB=0x2, length=14 Feb 12 10:34:22 rainhaven kernel: ng_l2cap_lp_deliver: ubt0l2cap - sending ACL packet, con_handle=11, len=19 Feb 12 10:34:22 rainhaven kernel: ng_hci_send_data: ubt0hci - sending ACL data packets, count=7 Feb 12 10:34:22 rainhaven kernel: send_data_packets: ubt0hci - sending data packet, handle=11, len=19 Feb 12 10:34:22 rainhaven kernel: ng_hci_send_data: ubt0hci - sending SCO data packets, count=1 Feb 12 10:34:22 rainhaven kernel: ng_l2cap_lp_deliver: ubt0l2cap - 1 ACL packets have been sent, con_handle=11 Feb 12 10:34:22 rainhaven kernel: ng_l2cap_lower_rcvmsg: ubt0l2cap - sync HCI connection queue, con_handle=11, pending=1, completed=1 Feb 12 10:34:22 rainhaven kernel: ng_hci_process_event: ubt0hci - got HCI event=0x13, length=5 Feb 12 10:34:22 rainhaven kernel: ng_hci_send_data: ubt0hci - sending ACL data packets, count=8 Feb 12 10:34:22 rainhaven kernel: ng_hci_send_data: ubt0hci - sending SCO data packets, count=1 Feb 12 10:34:22 rainhaven kernel: ng_l2cap_lp_receive: ubt0l2cap - got ACL data packet, con_handle=11, PB=0x2, length=12 Feb 12 10:34:22 rainhaven kernel: ng_l2cap_lp_receive: ubt0l2cap - staring new L2CAP packet, con_handle=11, length=8 Feb 12 10:34:22 rainhaven kernel: ng_l2cap_lp_send: ubt0l2cap - attaching ACL packet, con_handle=11, PB=0x2, length=12 Feb 12 10:34:22 rainhaven kernel: ng_l2cap_lp_deliver: ubt0l2cap - sending ACL packet, con_handle=11, len=17 Feb 12 10:34:22 rainhaven kernel: ng_l2cap_lp_deliver: ubt0l2cap - 1 ACL packets have been sent, con_handle=11 Feb 12 10:34:22 rainhaven kernel: ng_hci_send_data: ubt0hci - sending ACL data packets, count=8 Feb 12 10:34:22 rainhaven kernel: send_data_packets: ubt0hci - sending data packet, handle=11, len=17 Feb 12 10:34:22 rainhaven kernel: ng_l2cap_lower_rcvmsg: ubt0l2cap - sync HCI connection queue, con_handle=11, pending=1, completed=1 Feb 12 10:34:22 rainhaven kernel: ng_hci_send_data: ubt0hci - sending SCO data packets, count=1 Feb 12 10:34:22 rainhaven kernel: ng_hci_process_event: ubt0hci - got HCI event=0x13, length=5 Feb 12 10:34:22 rainhaven kernel: ng_hci_send_data: ubt0hci - sending ACL data packets, count=8 Feb 12 10:34:22 rainhaven kernel: ng_hci_send_data: ubt0hci - sending SCO data packets, count=1 Feb 12 10:34:24 rainhaven kernel: ng_hci_process_event: ubt0hci - got HCI event=0x5, length=4 Feb 12 10:34:24 rainhaven kernel: ng_l2cap_con_fail: ubt0l2cap - ACL connection failed, result=19 Feb 12 10:34:24 rainhaven kernel: ng_hci_lp_discon_ind: ubt0hci - SCO hook is not connected or not valid, hook=0 How is it looks like accordingly to hcidump -a output: HCIDump - HCI packet analyzer ver 1.5 device: any snap_len: 65535 filter: 0xffffffff > HCI Event: Connect Request(0x04) plen 10 . . . f " . . . Z . < HCI Command: Accept Connection Request(0x01|0x0009) plen 7 . . . f " . . > HCI Event: Command Status(0x0f) plen 4 . . . . > HCI Event: Role Change(0x12) plen 8 . . . . f " . . > ACL data: handle 0x000b flags 0x01 dlen 0 > HCI Event: Connect Complete(0x03) plen 11 . . . . . . f " . . . < HCI Command: Write Link Policy Settings(0x02|0x000d) plen 4 . . . . > HCI Event: Command Complete(0x0e) plen 6 . . . . . . > HCI Event: Max Slots Change(0x1b) plen 3 . . . > ACL data: handle 0x000b flags 0x02 dlen 12 L2CAP(s): Connect req: psm 1 scid 0x0040 < ACL data: handle 0x000b flags 0x02 dlen 16 L2CAP(s): Connect rsp: dcid 0x005b scid 0x0040 result 0 status 0 > ACL data: handle 0x000b flags 0x02 dlen 16 L2CAP(s): Config req: dcid 0x005b flags 0x0000 clen 4 MTU 65535 < ACL data: handle 0x000b flags 0x02 dlen 14 L2CAP(s): Config rsp: scid 0x0040 flags 0x0000 result 0 clen 0 < ACL data: handle 0x000b flags 0x02 dlen 12 L2CAP(s): Config req: dcid 0x0040 flags 0x0000 clen 0 > HCI Event: Number of Completed Packets(0x13) plen 5 . . . . . > ACL data: handle 0x000b flags 0x02 dlen 14 L2CAP(s): Config rsp: scid 0x005b flags 0x0000 result 0 clen 0 > ACL data: handle 0x000b flags 0x02 dlen 17 L2CAP(d): cid 0x5b len 13 [psm 1] SDP SS Req: tid 0x1c len 0x8 pat uuid-16 0x111e max 0xff cont 00 < ACL data: handle 0x000b flags 0x02 dlen 14 L2CAP(d): cid 0x40 len 10 [psm 1] SDP SS Rsp: tid 0x1c len 0x5 tot 0x0 cur 0x0 cont 00 > HCI Event: Number of Completed Packets(0x13) plen 5 . . . . . > ACL data: handle 0x000b flags 0x02 dlen 12 L2CAP(s): Disconn req: dcid 0x005b scid 0x0040 < ACL data: handle 0x000b flags 0x02 dlen 12 L2CAP(s): Disconn rsp: dcid 0x005b scid 0x0040 > ACL data: handle 0x000b flags 0x02 dlen 12 L2CAP(s): Connect req: psm 1 scid 0x0040 < ACL data: handle 0x000b flags 0x02 dlen 16 L2CAP(s): Connect rsp: dcid 0x005c scid 0x0040 result 0 status 0 > HCI Event: Number of Completed Packets(0x13) plen 5 . . . . . > ACL data: handle 0x000b flags 0x02 dlen 16 L2CAP(s): Config req: dcid 0x005c flags 0x0000 clen 4 MTU 65535 < ACL data: handle 0x000b flags 0x02 dlen 14 L2CAP(s): Config rsp: scid 0x0040 flags 0x0000 result 0 clen 0 < ACL data: handle 0x000b flags 0x02 dlen 12 L2CAP(s): Config req: dcid 0x0040 flags 0x0000 clen 0 > HCI Event: Number of Completed Packets(0x13) plen 5 . . . . . > ACL data: handle 0x000b flags 0x02 dlen 14 L2CAP(s): Config rsp: scid 0x005c flags 0x0000 result 0 clen 0 > ACL data: handle 0x000b flags 0x02 dlen 17 L2CAP(d): cid 0x5c len 13 [psm 1] SDP SS Req: tid 0x1d len 0x8 pat uuid-16 0x1108 (Headset) max 0xff cont 00 < ACL data: handle 0x000b flags 0x02 dlen 14 L2CAP(d): cid 0x40 len 10 [psm 1] SDP SS Rsp: tid 0x1d len 0x5 tot 0x0 cur 0x0 cont 00 > ACL data: handle 0x000b flags 0x02 dlen 12 L2CAP(s): Disconn req: dcid 0x005c scid 0x0040 < ACL data: handle 0x000b flags 0x02 dlen 12 L2CAP(s): Disconn rsp: dcid 0x005c scid 0x0040 > HCI Event: Number of Completed Packets(0x13) plen 5 . . . . . > ACL data: handle 0x000b flags 0x02 dlen 12 L2CAP(s): Connect req: psm 1 scid 0x0040 < ACL data: handle 0x000b flags 0x02 dlen 16 L2CAP(s): Connect rsp: dcid 0x005d scid 0x0040 result 0 status 0 > ACL data: handle 0x000b flags 0x02 dlen 16 L2CAP(s): Config req: dcid 0x005d flags 0x0000 clen 4 MTU 65535 < ACL data: handle 0x000b flags 0x02 dlen 14 L2CAP(s): Config rsp: scid 0x0040 flags 0x0000 result 0 clen 0 < ACL data: handle 0x000b flags 0x02 dlen 12 L2CAP(s): Config req: dcid 0x0040 flags 0x0000 clen 0 > HCI Event: Number of Completed Packets(0x13) plen 5 . . . . . > ACL data: handle 0x000b flags 0x02 dlen 14 L2CAP(s): Config rsp: scid 0x005d flags 0x0000 result 0 clen 0 > ACL data: handle 0x000b flags 0x02 dlen 17 L2CAP(d): cid 0x5d len 13 [psm 1] SDP SS Req: tid 0x1e len 0x8 pat uuid-16 0x110b max 0xff cont 00 < ACL data: handle 0x000b flags 0x02 dlen 14 L2CAP(d): cid 0x40 len 10 [psm 1] SDP SS Rsp: tid 0x1e len 0x5 tot 0x0 cur 0x0 cont 00 > HCI Event: Number of Completed Packets(0x13) plen 5 . . . . . > ACL data: handle 0x000b flags 0x02 dlen 12 L2CAP(s): Disconn req: dcid 0x005d scid 0x0040 < ACL data: handle 0x000b flags 0x02 dlen 12 L2CAP(s): Disconn rsp: dcid 0x005d scid 0x0040 > HCI Event: Number of Completed Packets(0x13) plen 5 . . . . . > HCI Event: Disconn Complete(0x05) plen 4 . . . . Some additional info: # uname -msr FreeBSD 7.1-STABLE i386 # grep ubt0 /var/run/dmesg.boot ubt0: on uhub0 ubt0: Interface 0 endpoints: interrupt=0x81, bulk-in=0x82, bulk-out=0x2 ubt0: Interface 1 (alt.config 4) endpoints: isoc-in=0x83, isoc-out=0x3; wMaxPacketSize=64; nframes=5, buffer size=320 ng_hci_process_event: ubt0hci - got HCI event=0xe, length=4 ng_hci_process_event: ubt0hci - got HCI event=0xe, length=10 ng_hci_process_event: ubt0hci - got HCI event=0xe, length=12 ng_hci_process_event: ubt0hci - got HCI event=0xe, length=11 ng_hci_process_event: ubt0hci - got HCI event=0xe, length=4 ng_hci_process_event: ubt0hci - got HCI event=0xe, length=4 ng_hci_process_event: ubt0hci - got HCI event=0xe, length=4 ng_hci_process_event: ubt0hci - got HCI event=0xe, length=4 ng_hci_process_event: ubt0hci - got HCI event=0xe, length=4 ng_l2cap_lower_rcvmsg: ubt0l2cap - HCI node is up, bdaddr: 0:21:86:d:2d:e7, pkt_size=1017 bytes, num_pkts=8 # grep -v -E "^#|^$" /etc/bluetooth/ubt0.conf authentication_enable="NO" connectable="YES" discoverable="YES" hci_debug_level="4" l2cap_debug_level="4" local_name="rainhaven" role_switch="YES" Was trying to turn role_switch to "NO" and authentication_enable to "YES" without any visible effect Here is relevant entry from /etc/bluetooth/hcsecd.conf: device { bdaddr 00:22:66:fd:07:10; name "Nokia 3610a"; key nokey; pin "12345"; } # l2ping -a Nokia 0 bytes from Nokia seq_no=0 time=563.631 ms result=0 0 bytes from Nokia seq_no=1 time=9.720 ms result=0 0 bytes from Nokia seq_no=2 time=13.445 ms result=0 0 bytes from Nokia seq_no=3 time=31.631 ms result=0 # sdpcontrol -l browse Record Handle: 00000000 Service Class ID List: Service Discovery Server (0x1000) Protocol Descriptor List: L2CAP (0x0100) Protocol specific parameter #1: u/int/uuid16 1 Protocol specific parameter #2: u/int/uuid16 1 Record Handle: 0x00000001 Service Class ID List: Browse Group Descriptor (0x1001) Record Handle: 0x00000002 Service Class ID List: LAN Access Using PPP (0x1102) Protocol Descriptor List: L2CAP (0x0100) RFCOMM (0x0003) Protocol specific parameter #1: u/int8/bool 1 Bluetooth Profile Descriptor List: LAN Access Using PPP (0x1102) ver. 1.0 "My phone's visiblity" set to "Shown to all" and my Nokia lists notebook as paired device Please tell me where is I'm wrong From plunky at rya-online.net Thu Feb 12 02:42:55 2009 From: plunky at rya-online.net (Iain Hibbert) Date: Thu Feb 12 02:43:02 2009 Subject: Trouble connecting HP Compaq 6720s with Nokia 3610 cell phone In-Reply-To: <46cbfbb80902120107x6ef309efs3d6b03e76c82fa78@mail.gmail.com> References: <46cbfbb80902120107x6ef309efs3d6b03e76c82fa78@mail.gmail.com> Message-ID: <1234435359.358996.1563.nullmailer@galant.ukfsn.org> On Thu, 12 Feb 2009, Oleg Nauman wrote: > I have a trouble connecting my Nokia 3610 cell phone via bluetooth link. what are you wanting to do with the 'connection' ? > How is it looks like accordingly to hcidump -a output: according to this, the phone connects to your laptop and looks for some services: > > ACL data: handle 0x000b flags 0x02 dlen 17 > L2CAP(d): cid 0x5b len 13 [psm 1] > SDP SS Req: tid 0x1c len 0x8 > pat uuid-16 0x111e > max 0xff > cont 00 That is "Handsfree" > < ACL data: handle 0x000b flags 0x02 dlen 14 > L2CAP(d): cid 0x40 len 10 [psm 1] > SDP SS Rsp: tid 0x1c len 0x5 > tot 0x0 cur 0x0 > cont 00 but you don't provide it > > ACL data: handle 0x000b flags 0x02 dlen 17 > L2CAP(d): cid 0x5c len 13 [psm 1] > SDP SS Req: tid 0x1d len 0x8 > pat uuid-16 0x1108 (Headset) > max 0xff > cont 00 > < ACL data: handle 0x000b flags 0x02 dlen 14 > L2CAP(d): cid 0x40 len 10 [psm 1] > SDP SS Rsp: tid 0x1d len 0x5 > tot 0x0 cur 0x0 > cont 00 neither "Headset" service > > ACL data: handle 0x000b flags 0x02 dlen 17 > L2CAP(d): cid 0x5d len 13 [psm 1] > SDP SS Req: tid 0x1e len 0x8 > pat uuid-16 0x110b > max 0xff > cont 00 > < ACL data: handle 0x000b flags 0x02 dlen 14 > L2CAP(d): cid 0x40 len 10 [psm 1] > SDP SS Rsp: tid 0x1e len 0x5 > tot 0x0 cur 0x0 > cont 00 and not "Audio Sink" service > # sdpcontrol -l browse > > Record Handle: 0x00000002 > Service Class ID List: > LAN Access Using PPP (0x1102) > Protocol Descriptor List: > L2CAP (0x0100) > RFCOMM (0x0003) > Protocol specific parameter #1: u/int8/bool 1 > Bluetooth Profile Descriptor List: > LAN Access Using PPP (0x1102) ver. 1.0 you provide only one service but the phone did not look for that.. regards, iain From maksim.yevmenkin at gmail.com Thu Feb 12 09:37:10 2009 From: maksim.yevmenkin at gmail.com (Maksim Yevmenkin) Date: Thu Feb 12 09:37:17 2009 Subject: Trouble connecting HP Compaq 6720s with Nokia 3610 cell phone In-Reply-To: <46cbfbb80902120107x6ef309efs3d6b03e76c82fa78@mail.gmail.com> References: <46cbfbb80902120107x6ef309efs3d6b03e76c82fa78@mail.gmail.com> Message-ID: Oleg, > I have a trouble connecting my Nokia 3610 cell phone via bluetooth link. as Iain already asked :) what exactly are you trying to do? are you trying to put/get something to/from your phone (for example pictures, ring tones, etc)? if so, then use comm/obexapp from ports. are you trying to use your phone as wireless modem to connect your laptop to the net? if so, then you should be using rfcomm_pppd(8) in _client_ mode and connect to dun (or lan, if your phone supports it) service on your phone. another option is to use rfcomm_sppd(8) in _client_ mode and ppp(8). basically use set device "!/usr/bin/rfcomm_sppd -a BD_ADDR" in your /etc/ppp/ppp.conf and use something similar to rfcomm-dialup example mentioned in the rfcomm_pppd(8) man page. thanks, max From maksim.yevmenkin at gmail.com Fri Feb 13 08:05:58 2009 From: maksim.yevmenkin at gmail.com (Maksim Yevmenkin) Date: Fri Feb 13 08:06:04 2009 Subject: Trouble connecting HP Compaq 6720s with Nokia 3610 cell phone In-Reply-To: <46cbfbb80902130153y10469bbdn1d2b1c04b1824358@mail.gmail.com> References: <46cbfbb80902120107x6ef309efs3d6b03e76c82fa78@mail.gmail.com> <46cbfbb80902130153y10469bbdn1d2b1c04b1824358@mail.gmail.com> Message-ID: Oleg, please keep freebsd-bluetooth@ cc'd. >>> I have a trouble connecting my Nokia 3610 cell phone via bluetooth link. >> >> as Iain already asked :) what exactly are you trying to do? > > Was trying to establish connection in both directions but failed. > Many thanks to Iain for this issue explanation - it seems my Nokia > searching for audio enhancements only. Was thinking it is part of > another trouble - I'm unable to start a session through obexapp (file > transfer for example). > > How is it looks like: > > # sdpcontrol -a Nokia search FTRN > > Record Handle: 0x00010002 > Service Class ID List: > OBEX File Transfer (0x1106) > Protocol Descriptor List: > L2CAP (0x0100) > RFCOMM (0x0003) > Protocol specific parameter #1: u/int8/bool 10 > OBEX (0x0008) > Bluetooth Profile Descriptor List: > OBEX File Transfer (0x1106) ver. 1.0 ok this looks promising. > # obexapp -c -a Nokia -C FTRN -f > > Just sits there ( well yes I know Bluetooth is slow enough so was > waiting for two hours first time ) well, this is not good :) > And what I can see in the log: first of all, please set those "hci_debug_level" and "l2cap_debug_level" knobs in you ubt0.conf back to their default values (or just remove them completely from your ubt0.conf). those should really be used in a controlled environment when debugging confirmed problem in the stack. the trace you sent is very low level and does not give me much context. hcidump(1) from the ports collection is the primary tool for troubleshooting problems like yours. when running hcidump(1) please make sure to write dump to a file, i.e. use -w switch. no need to set/change "connectable", "discoverable" and/or "role_switch" knobs because they set to "yes" by default. it is a good idea to always start hcsecd(8), i.e add "hcsecd_enable="yes'" to your /etc/rc.conf and make sure you have entries for all your bluetooth devices that require paring/authentication/encryption. so, if you could please 1) remove "hci_debug_level" and "l2cap_debug_level" knobs from your ubt0.conf and restart bluetooth device (/etc/rc.d/bluetooth restart ubt0) 2) start hcsecd(8), i.e. add hcsecd_enable="yes" to your /etc/rc.conf and then /etc/rc.d/hcsecd restart (i assume you already added pin code for your phone) 3) run (as root) hcidump -w nokia3610.bin 4) in another window run obexapp(1) client 5) wait for it to hang/stop/etc and then wait another minute or so. 6) terminate obexapp(1) client with ^C 7) terminate hcidump(1) with ^C 8) send me nokia3610.bin > So something is wrong I think and my question "Where is I'm wrong" i can not answer this question yet :) > still remains open. Or it is just a good example how is Bluetooth link > unreliable ? its not *that* unreliable :) thanks, max From maksim.yevmenkin at gmail.com Fri Feb 13 17:17:55 2009 From: maksim.yevmenkin at gmail.com (Maksim Yevmenkin) Date: Fri Feb 13 17:18:02 2009 Subject: libhci In-Reply-To: <1233919880.530235.10843.nullmailer@galant.ukfsn.org> References: <1233365217.00068654.1233354838@10.7.7.3> <4988DCCC.80201@mavhome.dp.ua> <4988EBAC.3080202@mavhome.dp.ua> <1233758519.360141.162.nullmailer@galant.ukfsn.org> <1233845167.798942.24919.nullmailer@galant.ukfsn.org> <1233919880.530235.10843.nullmailer@galant.ukfsn.org> Message-ID: Iain, >> anyway, what would you suggest to use instead of dev_id? device name >> (i.e. ubt0)? anything else? cant use bd_addr because (in freebsd at >> least) device has to be "initialized" before bd_addr is known. > > for sure, a generic API would need to use the device name. Internally it > can translate to whatever the local hardware control API uses. > >> i will take a look at ms api. but surely we have ability to send and >> receive hci commands/events and enumerate all radios in the system in >> addition to inquiry, dont you think? > > enumerating the radios is useful, yes, but having a function to set the > afh_map or some other setting? I think that this is only required by the > administrator program (hccontrol in your case) so why does it need to be > in a shared library? > > In a way, its similar for the string functions. What program needs to be > able to print the features list? Only a shell based admin tool in > reality, even a graphical program might want to provide such a feature > list in a different format anyway.. i kinda started to work on hci/bluetooth shims. please take a look at the attached patch. this is basically to implement bt_devname() and bt_devaddr() similar to netbsd and i also added bt_hci_devinfo() and bt_hci_devenum() inspired by linux-bluez. i also plan to add bt_hci_devinquiry() and possibly bt_hci_devreq(), bt_hci_devsend() and bt_hci_devrecv(). the later 2 are to send command and receive event only. thanks, max -------------- next part -------------- Index: dev.c =================================================================== --- dev.c (revision 0) +++ dev.c (revision 0) @@ -0,0 +1,93 @@ +/* + * dev.c + */ + +/*- + * Copyright (c) 2009 Maksim Yevmenkin + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + * + * $FreeBSD$ + */ + +#include +#include +#include + +struct bt_devaddr_match_arg +{ + char devname[HCI_DEVNAME_SIZE]; + bdaddr_t const *bdaddr; +}; + +static bt_hci_devenum_cb_t bt_devaddr_match; + +int +bt_devaddr(char const *devname, bdaddr_t *addr) +{ + struct bt_hci_devinfo di; + + if (bt_hci_devinfo(devname, &di) < 0) + return (0); + + if (addr != NULL) + bdaddr_copy(addr, &di.bdaddr); + + return (1); +} + +int +bt_devname(char *devname, bdaddr_t const *addr) +{ + struct bt_devaddr_match_arg arg; + + memset(&arg, 0, sizeof(arg)); + arg.bdaddr = addr; + + if (bt_hci_devenum(0, &bt_devaddr_match, &arg) < 0) + return (0); + + if (arg.devname[0] == '\0') { + errno = ENXIO; + return (0); + } + + if (devname != NULL) + strlcpy(devname, arg.devname, HCI_DEVNAME_SIZE); + + return (1); +} + +static int +bt_devaddr_match(int s, struct bt_hci_devinfo const *di, void *arg) +{ + struct bt_devaddr_match_arg *m = (struct bt_devaddr_match_arg *)arg; + + if (!bdaddr_same(&di->bdaddr, m->bdaddr)) + return (0); + + strlcpy(m->devname, di->devname, sizeof(m->devname)); + + return (1); +} + Index: hci.c =================================================================== --- hci.c (revision 0) +++ hci.c (revision 0) @@ -0,0 +1,246 @@ +/* + * hci.c + */ + +/*- + * Copyright (c) 2009 Maksim Yevmenkin + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + * + * $FreeBSD$ + */ + +#include +#include +#include +#include +#include + +static char * bt_hci_dev2node (char const *devname, char *nodename, int nnlen); + +int +bt_hci_devinfo(char const *devname, struct bt_hci_devinfo *di) +{ + union { + struct ng_btsocket_hci_raw_node_state r0; + struct ng_btsocket_hci_raw_node_bdaddr r1; + struct ng_btsocket_hci_raw_node_features r2; + struct ng_btsocket_hci_raw_node_buffer r3; + struct ng_btsocket_hci_raw_node_stat r4; + struct ng_btsocket_hci_raw_node_link_policy_mask r5; + struct ng_btsocket_hci_raw_node_packet_mask r6; + struct ng_btsocket_hci_raw_node_role_switch r7; + struct ng_btsocket_hci_raw_node_debug r8; + } rp; + struct sockaddr_hci ha; + int s, success; + + if (devname == NULL || di == NULL) { + errno = EINVAL; + return (0); + } + + memset(&ha, 0, sizeof(ha)); + ha.hci_len = sizeof(ha); + ha.hci_family = AF_BLUETOOTH; + + if (bt_aton(devname, &rp.r1.bdaddr)) { + if (!bt_devname(ha.hci_node, &rp.r1.bdaddr)) + return (0); + } else if (bt_hci_dev2node(devname, ha.hci_node, + sizeof(ha.hci_node)) == NULL) { + errno = ENXIO; + return (0); + } + + s = socket(PF_BLUETOOTH, SOCK_RAW, BLUETOOTH_PROTO_HCI); + if (s < 0) + return (0); + + success = 0; + + if (bind(s, (struct sockaddr *) &ha, sizeof(ha)) < 0 || + connect(s, (struct sockaddr *) &ha, sizeof(ha)) < 0) + goto bad; + strlcpy(di->devname, ha.hci_node, sizeof(di->devname)); + + if (ioctl(s, SIOC_HCI_RAW_NODE_GET_STATE, &rp.r0, sizeof(rp.r0)) < 0) + goto bad; + di->state = rp.r0.state; + + if (ioctl(s, SIOC_HCI_RAW_NODE_GET_BDADDR, &rp.r1, sizeof(rp.r1)) < 0) + goto bad; + bdaddr_copy(&di->bdaddr, &rp.r1.bdaddr); + + if (ioctl(s, SIOC_HCI_RAW_NODE_GET_FEATURES, &rp.r2, sizeof(rp.r2)) < 0) + goto bad; + memcpy(di->features, rp.r2.features, sizeof(di->features)); + + if (ioctl(s, SIOC_HCI_RAW_NODE_GET_BUFFER, &rp.r3, sizeof(rp.r3)) < 0) + goto bad; + di->cmd_free = rp.r3.buffer.cmd_free; + di->sco_size = rp.r3.buffer.sco_size; + di->sco_pkts = rp.r3.buffer.sco_pkts; + di->sco_free = rp.r3.buffer.sco_free; + di->acl_size = rp.r3.buffer.acl_size; + di->acl_pkts = rp.r3.buffer.acl_pkts; + di->acl_free = rp.r3.buffer.acl_free; + + if (ioctl(s, SIOC_HCI_RAW_NODE_GET_STAT, &rp.r4, sizeof(rp.r4)) < 0) + goto bad; + di->cmd_sent = rp.r4.stat.cmd_sent; + di->evnt_recv = rp.r4.stat.evnt_recv; + di->acl_recv = rp.r4.stat.acl_recv; + di->acl_sent = rp.r4.stat.acl_sent; + di->sco_recv = rp.r4.stat.sco_recv; + di->sco_sent = rp.r4.stat.sco_sent; + di->bytes_recv = rp.r4.stat.bytes_recv; + di->bytes_sent = rp.r4.stat.bytes_sent; + + if (ioctl(s, SIOC_HCI_RAW_NODE_GET_LINK_POLICY_MASK, + &rp.r5, sizeof(rp.r5)) < 0) + goto bad; + di->link_policy_info = rp.r5.policy_mask; + + if (ioctl(s, SIOC_HCI_RAW_NODE_GET_PACKET_MASK, + &rp.r6, sizeof(rp.r6)) < 0) + goto bad; + di->packet_type_info = rp.r6.packet_mask; + + if (ioctl(s, SIOC_HCI_RAW_NODE_GET_ROLE_SWITCH, + &rp.r7, sizeof(rp.r7)) < 0) + goto bad; + di->role_switch_info = rp.r7.role_switch; + + if (ioctl(s, SIOC_HCI_RAW_NODE_GET_DEBUG, &rp.r8, sizeof(rp.r8)) < 0) + goto bad; + di->debug = rp.r8.debug; + + success = 1; +bad: + close(s); + + return (success); +} + +int +bt_hci_devenum(int limit, bt_hci_devenum_cb_t cb, void *arg) +{ + struct ng_btsocket_hci_raw_node_list_names rp; + struct bt_hci_devinfo di; + struct sockaddr_hci ha; + int s, i; + + if (cb == NULL || limit < 0) { + errno = EINVAL; + return (0); + } + + rp.num_names = (limit > 0)? limit : 16; /* XXX why 16?? */ + rp.names = (struct nodeinfo *) calloc(rp.num_names, + sizeof(struct nodeinfo)); + if (rp.names == NULL) { + errno = ENOMEM; + return (0); + } + + memset(&ha, 0, sizeof(ha)); + ha.hci_len = sizeof(ha); + ha.hci_family = AF_BLUETOOTH; + ha.hci_node[0] = 'x'; + + s = socket(PF_BLUETOOTH, SOCK_RAW, BLUETOOTH_PROTO_HCI); + if (s < 0) { + free(rp.names); + + return (0); + } + + if (bind(s, (struct sockaddr *) &ha, sizeof(ha)) < 0 || + connect(s, (struct sockaddr *) &ha, sizeof(ha)) < 0 || + ioctl(s, SIOC_HCI_RAW_NODE_LIST_NAMES, &rp, sizeof(rp)) < 0) { + close(s); + free(rp.names); + + return (0); + } + + for (i = 0; i < rp.num_names; i ++) { + if (bt_hci_devinfo(rp.names[i].name, &di) < 0) + continue; + + strlcpy(ha.hci_node, rp.names[i].name, sizeof(ha.hci_node)); + + if (bind(s, (struct sockaddr *) &ha, sizeof(ha)) < 0 || + connect(s, (struct sockaddr *) &ha, sizeof(ha)) < 0) + continue; + + if ((*cb)(s, &di, arg) > 0) + break; + } + + close (s); + free(rp.names); + + return (1); +} + +static char * +bt_hci_dev2node(char const *devname, char *nodename, int nnlen) +{ + static char const * bt_dev_prefix[] = { + "btccc", /* 3Com Bluetooth PC-CARD */ + "h4", /* UART/serial Bluetooth devices */ + "ubt", /* Bluetooth USB devices */ + NULL /* should be last */ + }; + + static char _nodename[HCI_DEVNAME_SIZE]; + char const **p; + char *ep; + int plen, unit; + + if (nodename == NULL) { + nodename = _nodename; + nnlen = HCI_DEVNAME_SIZE; + } + + for (p = bt_dev_prefix; *p != NULL; p ++) { + plen = strlen(*p); + if (strncmp(devname, *p, plen) != 0) + continue; + + unit = strtoul(devname + plen, &ep, 10); + if (*ep != '\0' && + strcmp(ep, "hci") != 0 && + strcmp(ep, "l2cap") != 0) + return (NULL); /* can't make sense of device name */ + + snprintf(nodename, nnlen, "%s%uhci", *p, unit); + + return (nodename); + } + + return (NULL); +} + Index: bluetooth.3 =================================================================== --- bluetooth.3 (revision 188108) +++ bluetooth.3 (working copy) @@ -1,4 +1,4 @@ -.\" Copyright (c) 2003 Maksim Yevmenkin +. Copyright (c) 2003-2009 Maksim Yevmenkin .\" All rights reserved. .\" .\" Redistribution and use in source and binary forms, with or without @@ -25,7 +25,7 @@ .\" $Id: bluetooth.3,v 1.5 2003/05/20 23:04:30 max Exp $ .\" $FreeBSD$ .\" -.Dd August 13, 2008 +.Dd February 13, 2009 .Dt BLUETOOTH 3 .Os .Sh NAME @@ -74,6 +74,16 @@ .Ft const char * .Fn bt_ntoa "const bdaddr_t *ba" "char *str" .Ft int +.Fn bt_devaddr "const char *devname" "bdaddr_t *addr" +.Ft int +.Fn bt_devname "char *devname" "const bdaddr_t *addr" +.Ft int +.Fn (bt_hci_devenum_cb_t) "int s" "struct bt_hci_devinfo const *di" "void *arg" +.Ft int +.Fn bt_hci_devinfo "char const *devname" "struct bt_hci_devinfo *di" +.Ft int +.Fn bt_hci_devenum "int limit" "bt_hci_devenum_cb_t *cb" "void *arg" +.Ft int .Fn bdaddr_same "const bdaddr_t *a" "const bdaddr_t *b" .Ft int .Fn bdaddr_any "const bdaddr_t *a" @@ -197,6 +207,113 @@ If no buffer was provided then internal static buffer will be used. .Pp The +.Fn bt_devaddr +function interprets the specified +.Fa devname +string as the address or device name of a Bluetooth device on the local system, +and places the device address in the provided +.Fa bdaddr , +if any. +The function returns 1 if the string was successfully interpreted, +or 0 if the string did not match any local device. +The +.Fn bt_devname +function takes a Bluetooth device address and copies the local device +name associated with that address into the buffer provided, +if any. +Caller must ensure that provided buffer is at least +.Dv HCI_DEVNAME_SIZE +characters in size. +The function returns 1 when the device was found, +otherwise 0. +.Pp +The +.Fn bt_hci_devinfo +function populates prodivded +.Vt bt_hci_devinfo +structure with the information about Bluetooth device +.Fa devname . +The function returns 1 when successful otherwise 0. +The +.Vt bt_hci_devinfo +structure is defined as follows +.Bd -literal -offset indent +struct bt_hci_devinfo +{ + char devname[HCI_DEVNAME_SIZE]; + + uint32_t state; + + bdaddr_t bdaddr; + uint16_t _reserved0; + + uint8_t features[HCI_DEVFEATURES_SIZE]; + + /* buffer info */ + uint16_t _reserved1; + uint16_t cmd_free; + uint16_t sco_size; + uint16_t sco_pkts; + uint16_t sco_free; + uint16_t acl_size; + uint16_t acl_pkts; + uint16_t acl_free; + + /* stats */ + uint32_t cmd_sent; + uint32_t evnt_recv; + uint32_t acl_recv; + uint32_t acl_sent; + uint32_t sco_recv; + uint32_t sco_sent; + uint32_t bytes_recv; + uint32_t bytes_sent; + + /* misc/specific */ + uint32_t link_policy_info; + uint32_t packet_type_info; + uint32_t role_switch_info; + uint32_t debug; +}; +.Ed +.Pp +The +.Fn bt_hci_devenum +function enumerates up to +.Fa limit +Bluetooth devices present in the system. +If passed +.Fa limit +is zero, the internal default limit will be used. +For every device found, +the function will call provided +.Fa cb +callback function which should be of +.Vt bt_hci_devenum_cb_t +type. +The callback function is passed a connected +.Dv HCI +socket +.Fa s , +fully populated +.Vt bt_hci_devinfo +structure +.Fa di +and +.Fa arg +argument provided to the +.Fn bt_hci_devenum . +The callback function can stop enumeration by returning a value of less +or equal to zero. +The +.Fn bt_hci_devenum +uses the same socket for the duration of enumeration. +The function guarantees that the socket, +passed to the callback function, +will be bound and connected to the Bluetooth device being enumerated. +The function returns 1 when enumeration was successful otherwise 0. +.Pp +The .Fn bdaddr_same , .Fn bdaddr_any and @@ -287,7 +404,8 @@ .Xr getprotobynumber 3 , .Xr herror 3 , .Xr inet_aton 3 , -.Xr inet_ntoa 3 +.Xr inet_ntoa 3 , +.Xr ng_hci 4 .Sh CAVEAT The .Fn bt_gethostent Index: bluetooth.c =================================================================== --- bluetooth.c (revision 188108) +++ bluetooth.c (working copy) @@ -1,7 +1,9 @@ /* * bluetooth.c - * - * Copyright (c) 2001-2003 Maksim Yevmenkin + */ + +/*- + * Copyright (c) 2001-2009 Maksim Yevmenkin * All rights reserved. * * Redistribution and use in source and binary forms, with or without Index: bluetooth.h =================================================================== --- bluetooth.h (revision 188108) +++ bluetooth.h (working copy) @@ -1,7 +1,9 @@ /* * bluetooth.h - * - * Copyright (c) 2001-2003 Maksim Yevmenkin + */ + +/*- + * Copyright (c) 2001-2009 Maksim Yevmenkin * All rights reserved. * * Redistribution and use in source and binary forms, with or without @@ -35,9 +37,12 @@ #include #include #include +#include #include #include +#include #include +#include #include #include #include @@ -72,6 +77,60 @@ char const * bt_ntoa (bdaddr_t const *ba, char *str); int bt_aton (char const *str, bdaddr_t *ba); +/* bt_devXXXX() functions (inspired by NetBSD) */ +int bt_devaddr (char const *devname, bdaddr_t *addr); +int bt_devname (char *devname, bdaddr_t const *addr); + +/* + * Bluetooth HCI functions + */ + +#define HCI_DEVNAME_SIZE NG_NODESIZ +#define HCI_DEVFEATURES_SIZE NG_HCI_FEATURES_SIZE + +struct bt_hci_devinfo +{ + char devname[HCI_DEVNAME_SIZE]; + + uint32_t state; + + bdaddr_t bdaddr; + uint16_t _reserved0; + + uint8_t features[HCI_DEVFEATURES_SIZE]; + + /* buffer info */ + uint16_t _reserved1; + uint16_t cmd_free; + uint16_t sco_size; + uint16_t sco_pkts; + uint16_t sco_free; + uint16_t acl_size; + uint16_t acl_pkts; + uint16_t acl_free; + + /* stats */ + uint32_t cmd_sent; + uint32_t evnt_recv; + uint32_t acl_recv; + uint32_t acl_sent; + uint32_t sco_recv; + uint32_t sco_sent; + uint32_t bytes_recv; + uint32_t bytes_sent; + + /* misc/specific */ + uint32_t link_policy_info; + uint32_t packet_type_info; + uint32_t role_switch_info; + uint32_t debug; +}; + +typedef int (bt_hci_devenum_cb_t)(int,struct bt_hci_devinfo const *,void *); + +int bt_hci_devinfo (char const *devname, struct bt_hci_devinfo *di); +int bt_hci_devenum (int limit, bt_hci_devenum_cb_t *cb, void *arg); + /* * bdaddr utility functions (from NetBSD) */ Index: Makefile =================================================================== --- Makefile (revision 188108) +++ Makefile (working copy) @@ -7,9 +7,11 @@ WARNS?= 2 CFLAGS+= -I${.CURDIR} -I${.CURDIR}/../../sys +DEBUG_FLAGS= -g + SHLIB_MAJOR= 3 -SRCS= bluetooth.c +SRCS= bluetooth.c dev.c hci.c INCS= bluetooth.h MLINKS+= bluetooth.3 bt_gethostbyname.3 @@ -27,6 +29,12 @@ MLINKS+= bluetooth.3 bt_ntoa.3 MLINKS+= bluetooth.3 bt_aton.3 +MLINKS+= bluetooth.3 bt_devaddr.3 +MLINKS+= bluetooth.3 bt_devname.3 + +MLINKS+= bluetooth.3 bt_hci_devinfo.3 +MLINKS+= bluetooth.3 bt_hci_devenum.3 + MLINKS+= bluetooth.3 bdaddr_same.3 MLINKS+= bluetooth.3 bdaddr_any.3 MLINKS+= bluetooth.3 bdaddr_copy.3 From plunky at rya-online.net Sat Feb 14 01:53:26 2009 From: plunky at rya-online.net (Iain Hibbert) Date: Sat Feb 14 01:53:32 2009 Subject: libhci In-Reply-To: References: <1233365217.00068654.1233354838@10.7.7.3> <4988DCCC.80201@mavhome.dp.ua> <4988EBAC.3080202@mavhome.dp.ua> <1233758519.360141.162.nullmailer@galant.ukfsn.org> <1233845167.798942.24919.nullmailer@galant.ukfsn.org> <1233919880.530235.10843.nullmailer@galant.ukfsn.org> Message-ID: <1234605178.990729.799.nullmailer@galant.ukfsn.org> On Fri, 13 Feb 2009, Maksim Yevmenkin wrote: > i kinda started to work on hci/bluetooth shims. please take a look at > the attached patch. this is basically to implement bt_devname() and > bt_devaddr() similar to netbsd and i also added bt_hci_devinfo() and > bt_hci_devenum() inspired by linux-bluez. some quick comments as I'm on battery and ENOTIME - I think it should lose the "_hci" part of the name :) - count = bt_devenum(cb, arg) no limits in API (no objection to underlying implementation limit :) the callback can signal, if it has seen enough. (could allow callback=NULL to just count the devices) - len = bt_devinfo(name, buffer, sizeof(buffer)) the calling program gives buffer and size, allowing the devinfo to be extended later without breaking ABI. len == 0 means not found also, reserved slots in the structure become unnecessary, let the compiler handle padding. (size and name could be passed in devinfo?) (is variable size struct perhaps too ugly to handle? what about 'version' field?) iain From oleg.nauman at gmail.com Mon Feb 16 01:08:41 2009 From: oleg.nauman at gmail.com (Oleg Nauman) Date: Mon Feb 16 01:08:47 2009 Subject: Trouble connecting HP Compaq 6720s with Nokia 3610 cell phone In-Reply-To: References: <46cbfbb80902120107x6ef309efs3d6b03e76c82fa78@mail.gmail.com> <46cbfbb80902130153y10469bbdn1d2b1c04b1824358@mail.gmail.com> Message-ID: <46cbfbb80902160103s73de97d9v6f5f8846d56c8a14@mail.gmail.com> On Fri, Feb 13, 2009 at 6:05 PM, Maksim Yevmenkin wrote: > Oleg, > > please keep freebsd-bluetooth@ cc'd. Still feels unfamiliar with Gmail interface sorry. > >>>> I have a trouble connecting my Nokia 3610 cell phone via bluetooth link. >>> >>> as Iain already asked :) what exactly are you trying to do? >> >> Was trying to establish connection in both directions but failed. >> Many thanks to Iain for this issue explanation - it seems my Nokia >> searching for audio enhancements only. Was thinking it is part of >> another trouble - I'm unable to start a session through obexapp (file >> transfer for example). >> >> How is it looks like: >> >> # sdpcontrol -a Nokia search FTRN >> >> Record Handle: 0x00010002 >> Service Class ID List: >> OBEX File Transfer (0x1106) >> Protocol Descriptor List: >> L2CAP (0x0100) >> RFCOMM (0x0003) >> Protocol specific parameter #1: u/int8/bool 10 >> OBEX (0x0008) >> Bluetooth Profile Descriptor List: >> OBEX File Transfer (0x1106) ver. 1.0 > > ok this looks promising. > >> # obexapp -c -a Nokia -C FTRN -f >> >> Just sits there ( well yes I know Bluetooth is slow enough so was >> waiting for two hours first time ) > > well, this is not good :) Looks like it was issue with obexapp itself. Upgrading obexapp to latest in the ports (1.4.10) makes bluetooth connection working as expected. Thank you very much for your help From mad at madpilot.net Wed Feb 18 06:29:50 2009 From: mad at madpilot.net (Guido Falsi) Date: Wed Feb 18 06:29:58 2009 Subject: ports using sdp when mpeg4ip is installed Message-ID: <20090218141028.GB48065@megatron.madpilot.net> Hello, I maintain a few ports, between those there are gnokii and the ports package for obexapp, written by Maksim. I already had to deal with the problem in the subject some time ago (PR ports/108428) and now that gnokii has sdp support PR ports/131778 has correctly been filed. As exlained in the PRs the problem is mpeg4ip is installing an sdp.h file and an libsdp.so library in /usr/local/(include|lib), which are preferred by the ports systems(especially the autotools) on the system ones breaking software build. The solution is doing jumps through hoops to make autotools and other pieces behave, hardcoding base system paths or the like. I could not find better ways. Whth gnokii right now I'm having big problems making libtool behave. I could try patching the system wide one to manage this situation, but I don't really understand it's internals, if anyone could point me in the right direction here that would be very appreciated. We could just fix the includes problem by moving one of the two sdp.h files in a subdirectory of include, but the libraries problem would remain. How should I act? Doing the hoop jumping is not a big problem to me, but in the future with more programs taking advantage of bluetooth/sdp functionality this problem will be even more frequent, and I don't think fixing every single case by hand to be a good solution. Could we try to find a system or ports wide solution? Sorry for the lenghty email, but I wanted to explain the situation fully. BTW should I also send a resume of this email to gnats for historic purposes? Thanks in advance for any help, opinions, revision or also confort on this. -- Guido Falsi From maksim.yevmenkin at gmail.com Wed Feb 18 10:21:34 2009 From: maksim.yevmenkin at gmail.com (Maksim Yevmenkin) Date: Wed Feb 18 10:21:41 2009 Subject: ports using sdp when mpeg4ip is installed In-Reply-To: <20090218141028.GB48065@megatron.madpilot.net> References: <20090218141028.GB48065@megatron.madpilot.net> Message-ID: On Wed, Feb 18, 2009 at 6:10 AM, Guido Falsi wrote: > Hello, > > I maintain a few ports, between those there are gnokii and the ports > package for obexapp, written by Maksim. > > I already had to deal with the problem in the subject some time ago > (PR ports/108428) and now that gnokii has sdp support PR ports/131778 > has correctly been filed. > > As exlained in the PRs the problem is mpeg4ip is installing an sdp.h > file and an libsdp.so library in /usr/local/(include|lib), which > are preferred by the ports systems(especially the autotools) on the > system ones breaking software build. > > The solution is doing jumps through hoops to make autotools and > other pieces behave, hardcoding base system paths or the like. I > could not find better ways. Whth gnokii right now I'm having big > problems making libtool behave. I could try patching the system > wide one to manage this situation, but I don't really understand > it's internals, if anyone could point me in the right direction > here that would be very appreciated. > > We could just fix the includes problem by moving one of the two > sdp.h files in a subdirectory of include, but the libraries problem > would remain. > > How should I act? Doing the hoop jumping is not a big problem to me, but in > the future with more programs taking advantage of bluetooth/sdp > functionality this problem will be even more frequent, and I don't think > fixing every single case by hand to be a good solution. > > Could we try to find a system or ports wide solution? > > Sorry for the lenghty email, but I wanted to explain the situation > fully. > > BTW should I also send a resume of this email to gnats for historic > purposes? > > Thanks in advance for any help, opinions, revision or also confort on > this. thanks for keeping the ports up to date! i think the only reasonable solution is to move sdp.h (and bluetooth.h while we at it) into /usr/include/bluetooth/ i will see what can be done here. it should be much easier to move files now when we have svn :) thanks, max From mad at madpilot.net Wed Feb 18 12:31:59 2009 From: mad at madpilot.net (Guido Falsi) Date: Wed Feb 18 12:32:12 2009 Subject: ports using sdp when mpeg4ip is installed In-Reply-To: References: <20090218141028.GB48065@megatron.madpilot.net> Message-ID: <499C703A.7020606@madpilot.net> Maksim Yevmenkin wrote: > thanks for keeping the ports up to date! > That's a pleasure, when time is available :) > i think the only reasonable solution is to move sdp.h (and bluetooth.h > while we at it) into /usr/include/bluetooth/ > > i will see what can be done here. it should be much easier to move > files now when we have svn :) I second this idea and it sure will solve the includes problem. It will not solve the problem with libsdp.so though. Look at the following log: /bin/sh ../libtool --tag=CC --mode=link cc -I../include -O2 -fno-strict-aliasing -pipe -march=athlon-xp -Wall -Wno-pointer-sign -fvisibility=hidden -fno-strict-aliasing -L/usr/local/lib -o gnokii gnokii-gnokii.o gnokii-gnokii-calendar.o gnokii-gnokii-dial.o gnokii-gnokii-file.o gnokii-gnokii-logo.o gnokii-gnokii-monitor.o gnokii-gnokii-other.o gnokii-gnokii-phonebook.o gnokii-gnokii-profile.o gnokii-gnokii-ringtone.o gnokii-gnokii-security.o gnokii-gnokii-settings.o gnokii-gnokii-sms.o gnokii-gnokii-todo.o gnokii-gnokii-utils.o gnokii-gnokii-wap.o ../common/libgnokii.la -lintl -lreadline -lncurses mkdir .libs cc -I../include -O2 -fno-strict-aliasing -pipe -march=athlon-xp -Wall -Wno-pointer-sign -fvisibility=hidden -fno-strict-aliasing -o .libs/gnokii gnokii-gnokii.o gnokii-gnokii-calendar.o gnokii-gnokii-dial.o gnokii-gnokii-file.o gnokii-gnokii-logo.o gnokii-gnokii-monitor.o gnokii-gnokii-other.o gnokii-gnokii-phonebook.o gnokii-gnokii-profile.o gnokii-gnokii-ringtone.o gnokii-gnokii-security.o gnokii-gnokii-settings.o gnokii-gnokii-sms.o gnokii-gnokii-todo.o gnokii-gnokii-utils.o gnokii-gnokii-wap.o -L/usr/local/lib ../common/.libs/libgnokii.so /usr/local/lib/libusb.so /usr/local/lib/libsdp.so /usr/local/lib/libmp4v2.so /usr/local/lib/libmp4av.so /usr/local/lib/libmpeg4ip_gnu.so -pthread -lbluetooth /usr/local/lib/libXpm.so /usr/local/lib/libX11.so /usr/local/lib/libxcb.so /usr/local/lib/libXau.so /usr/local/lib/libXdmcp.so -lrpcsvc -lroken -lcrypt /usr/local/lib/libintl.so /usr/local/lib/libiconv.so -lreadline -lncurses -Wl,--rpath -Wl,/usr/local/lib ../common/.libs/libgnokii.so: undefined reference to `sdp_close' ../common/.libs/libgnokii.so: undefined reference to `sdp_error' ../common/.libs/libgnokii.so: undefined reference to `sdp_search' ../common/.libs/libgnokii.so: undefined reference to `sdp_open' gmake[1]: *** [gnokii] Error 1 gmake[1]: Leaving directory `/usr/home/mad/src/gnokii/work/gnokii-0.6.27/gnokii' gmake: *** [all-recursive] Error 1 *** Error code 2 Stop in /usr/home/mad/src/gnokii. *** Error code 1 Stop in /usr/home/mad/src/gnokii. After fixing the include(by hardcoding the path for now) I got this error. As you can see libtool prefers libsdp.so found in localbase. I'm not sure what a solution to this could be. in fact having two libraries with the same name looks like a problem anyway. I don't like the idea of FreeBSD adopting to any software which happens to name a library like ours...But I don't know who to blame. -- Guido Falsi From plunky at rya-online.net Wed Feb 18 13:09:18 2009 From: plunky at rya-online.net (Iain Hibbert) Date: Wed Feb 18 13:09:24 2009 Subject: ports using sdp when mpeg4ip is installed In-Reply-To: <499C703A.7020606@madpilot.net> References: <20090218141028.GB48065@megatron.madpilot.net> <499C703A.7020606@madpilot.net> Message-ID: <1234991336.235532.1915.nullmailer@galant.ukfsn.org> On Wed, 18 Feb 2009, Guido Falsi wrote: > Maksim Yevmenkin wrote: > > > i think the only reasonable solution is to move sdp.h (and bluetooth.h > > while we at it) into /usr/include/bluetooth/ > > > > i will see what can be done here. it should be much easier to move > > files now when we have svn :) btw don't get too excited, you probably only need to change the Makefile to get it installed to a different place :) > I second this idea and it sure will solve the includes problem. > > It will not solve the problem with libsdp.so though. would it make sense to merge the sdp functions into libbluetooth? IIRC with BlueZ only one library is required.. iain (I have a massive update to libsdp in the works anyway, perhaps it would make sense to do that at the same time) From olli at lurza.secnetix.de Thu Feb 19 07:17:49 2009 From: olli at lurza.secnetix.de (Oliver Fromme) Date: Thu Feb 19 07:17:57 2009 Subject: ports using sdp when mpeg4ip is installed In-Reply-To: <1234991336.235532.1915.nullmailer@galant.ukfsn.org> Message-ID: <200902191517.n1JFHjqI092809@lurza.secnetix.de> Iain Hibbert wrote: > Guido Falsi wrote: > > I second this idea and it sure will solve the includes problem. > > > > It will not solve the problem with libsdp.so though. > > would it make sense to merge the sdp functions into libbluetooth? > IIRC with BlueZ only one library is required.. Either that, or rename it to libbtsdp. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Gesch?ftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M?n- chen, HRB 125758, Gesch?ftsf?hrer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "Software gets slower faster than hardware gets faster." -- Niklaus Wirth From maksim.yevmenkin at gmail.com Mon Feb 23 10:49:58 2009 From: maksim.yevmenkin at gmail.com (Maksim Yevmenkin) Date: Mon Feb 23 10:50:04 2009 Subject: obexapp outgoing problem In-Reply-To: <1235324110.44220.1.camel@hood.oook.cz> References: <1235324110.44220.1.camel@hood.oook.cz> Message-ID: Hi Pav, > I'm having troubles sending files to phone over obexapp, similar to > > http://www.freebsd.org/cgi/query-pr.cgi?pr=128297 > > except this time it's on 7-STABLE and the messages goes about ubt bulk > transfer having SHORT_XFER error first and then TIMEOUT. > > The box panics inside UHCI code, or just hangs. > > What can I do to help it? is that a new behavior? or was it always like that? since you have mentioned ng_ubt(4), i assume you are using usb1 (and not HPS's usb2) stack, right? the only big change that went into ng_ubt(4) (long time ago) is support for isoc. transfers. however, this change was not mfc'd, and you said you are running 7-stable, so this can not be it. if it was working before then i would try to revert back to the time when it was working, then incrementally updating trying to pinpoint time frame when it stopped working. once you know the time frame look closely for commits that could have affected it. thanks, max From pav at FreeBSD.org Mon Feb 23 13:30:12 2009 From: pav at FreeBSD.org (Pav Lucistnik) Date: Mon Feb 23 13:30:18 2009 Subject: obexapp outgoing problem In-Reply-To: References: <1235324110.44220.1.camel@hood.oook.cz> Message-ID: <1235422984.72242.2.camel@hood.oook.cz> Maksim Yevmenkin p??e v po 23. 02. 2009 v 10:49 -0800: > Hi Pav, > > > I'm having troubles sending files to phone over obexapp, similar to > > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=128297 > > > > except this time it's on 7-STABLE and the messages goes about ubt bulk > > transfer having SHORT_XFER error first and then TIMEOUT. > > > > The box panics inside UHCI code, or just hangs. > > > > What can I do to help it? > > is that a new behavior? or was it always like that? since you have > mentioned ng_ubt(4), i assume you are using usb1 (and not HPS's usb2) > stack, right? the only big change that went into ng_ubt(4) (long time > ago) is support for isoc. transfers. however, this change was not > mfc'd, and you said you are running 7-stable, so this can not be it. > > if it was working before then i would try to revert back to the time > when it was working, then incrementally updating trying to pinpoint > time frame when it stopped working. once you know the time frame look > closely for commits that could have affected it. It's 7-STABLE so OLDUSB. I don't know if it's new behaviour, this is first time I tried sending files over Bluetooth to the phone, instead of mailing them. PS: other way (phone -> PC) using obexapp -s works flawlessly. -- Pav Lucistnik God is real unless declared integer. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: Toto je =?UTF-8?Q?digit=C3=A1ln=C4=9B?= =?ISO-8859-1?Q?_podepsan=E1?= =?UTF-8?Q?_=C4=8D=C3=A1st?= =?ISO-8859-1?Q?_zpr=E1vy?= Url : http://lists.freebsd.org/pipermail/freebsd-bluetooth/attachments/20090223/b68fcc4d/attachment.pgp From maksim.yevmenkin at gmail.com Mon Feb 23 13:43:00 2009 From: maksim.yevmenkin at gmail.com (Maksim Yevmenkin) Date: Mon Feb 23 13:43:06 2009 Subject: obexapp outgoing problem In-Reply-To: <1235422984.72242.2.camel@hood.oook.cz> References: <1235324110.44220.1.camel@hood.oook.cz> <1235422984.72242.2.camel@hood.oook.cz> Message-ID: 2009/2/23 Pav Lucistnik : > Maksim Yevmenkin p??e v po 23. 02. 2009 v 10:49 -0800: >> Hi Pav, >> >> > I'm having troubles sending files to phone over obexapp, similar to >> > >> > http://www.freebsd.org/cgi/query-pr.cgi?pr=128297 >> > >> > except this time it's on 7-STABLE and the messages goes about ubt bulk >> > transfer having SHORT_XFER error first and then TIMEOUT. >> > >> > The box panics inside UHCI code, or just hangs. >> > >> > What can I do to help it? >> >> is that a new behavior? or was it always like that? since you have >> mentioned ng_ubt(4), i assume you are using usb1 (and not HPS's usb2) >> stack, right? the only big change that went into ng_ubt(4) (long time >> ago) is support for isoc. transfers. however, this change was not >> mfc'd, and you said you are running 7-stable, so this can not be it. >> >> if it was working before then i would try to revert back to the time >> when it was working, then incrementally updating trying to pinpoint >> time frame when it stopped working. once you know the time frame look >> closely for commits that could have affected it. > > It's 7-STABLE so OLDUSB. I don't know if it's new behaviour, this is > first time I tried sending files over Bluetooth to the phone, instead of > mailing them. > > PS: other way (phone -> PC) using obexapp -s works flawlessly. ok, could you please try the following patch. its cut-and-paste so you may need redo it manually (its simple enough). diff -u10 ng_ubt.c.orig ng_ubt.c --- ng_ubt.c.orig 2007-07-12 19:19:51.000000000 -0700 +++ ng_ubt.c 2009-02-23 13:39:32.000000000 -0800 @@ -1378,21 +1378,21 @@ m_copydata(m, 0, m->m_pkthdr.len, sc->sc_bulk_out_buffer); /* Initialize a bulk-out USB transfer and then schedule it */ usbd_setup_xfer( sc->sc_bulk_out_xfer, sc->sc_bulk_out_pipe, (usbd_private_handle) sc->sc_node, sc->sc_bulk_out_buffer, m->m_pkthdr.len, - USBD_NO_COPY, + USBD_FORCE_SHORT_XFER | USBD_NO_COPY, USBD_DEFAULT_TIMEOUT, /* XXX */ ubt_bulk_out_complete); NG_NODE_REF(sc->sc_node); status = usbd_transfer(sc->sc_bulk_out_xfer); if (status != USBD_NORMAL_COMPLETION && status != USBD_IN_PROGRESS) { NG_UBT_ERR( "%s: %s - Could not start bulk-out transfer. %s (%d)\n", __func__, device_get_nameunit(sc->sc_dev), usbd_errstr(status), === thanks, max From pav at FreeBSD.org Mon Feb 23 14:15:06 2009 From: pav at FreeBSD.org (Pav Lucistnik) Date: Mon Feb 23 14:17:38 2009 Subject: obexapp outgoing problem In-Reply-To: References: <1235324110.44220.1.camel@hood.oook.cz> <1235422984.72242.2.camel@hood.oook.cz> Message-ID: <1235427294.1166.0.camel@hood.oook.cz> Maksim Yevmenkin p??e v po 23. 02. 2009 v 13:42 -0800: > 2009/2/23 Pav Lucistnik : > > Maksim Yevmenkin p??e v po 23. 02. 2009 v 10:49 -0800: > >> Hi Pav, > >> > >> > I'm having troubles sending files to phone over obexapp, similar to > >> > > >> > http://www.freebsd.org/cgi/query-pr.cgi?pr=128297 > >> > > >> > except this time it's on 7-STABLE and the messages goes about ubt bulk > >> > transfer having SHORT_XFER error first and then TIMEOUT. > >> > > >> > The box panics inside UHCI code, or just hangs. > >> > > >> > What can I do to help it? > >> > >> is that a new behavior? or was it always like that? since you have > >> mentioned ng_ubt(4), i assume you are using usb1 (and not HPS's usb2) > >> stack, right? the only big change that went into ng_ubt(4) (long time > >> ago) is support for isoc. transfers. however, this change was not > >> mfc'd, and you said you are running 7-stable, so this can not be it. > >> > >> if it was working before then i would try to revert back to the time > >> when it was working, then incrementally updating trying to pinpoint > >> time frame when it stopped working. once you know the time frame look > >> closely for commits that could have affected it. > > > > It's 7-STABLE so OLDUSB. I don't know if it's new behaviour, this is > > first time I tried sending files over Bluetooth to the phone, instead of > > mailing them. > > > > PS: other way (phone -> PC) using obexapp -s works flawlessly. > > ok, could you please try the following patch. its cut-and-paste so you > may need redo it manually (its simple enough). > > diff -u10 ng_ubt.c.orig ng_ubt.c > --- ng_ubt.c.orig 2007-07-12 19:19:51.000000000 -0700 > +++ ng_ubt.c 2009-02-23 13:39:32.000000000 -0800 > @@ -1378,21 +1378,21 @@ > > m_copydata(m, 0, m->m_pkthdr.len, sc->sc_bulk_out_buffer); > > /* Initialize a bulk-out USB transfer and then schedule it */ > usbd_setup_xfer( > sc->sc_bulk_out_xfer, > sc->sc_bulk_out_pipe, > (usbd_private_handle) sc->sc_node, > sc->sc_bulk_out_buffer, > m->m_pkthdr.len, > - USBD_NO_COPY, > + USBD_FORCE_SHORT_XFER | USBD_NO_COPY, > USBD_DEFAULT_TIMEOUT, /* XXX */ > ubt_bulk_out_complete); > > NG_NODE_REF(sc->sc_node); > > status = usbd_transfer(sc->sc_bulk_out_xfer); > if (status != USBD_NORMAL_COMPLETION && status != USBD_IN_PROGRESS) { > NG_UBT_ERR( > "%s: %s - Could not start bulk-out transfer. %s (%d)\n", > __func__, device_get_nameunit(sc->sc_dev), > usbd_errstr(status), No change, now I get bulk-out transfer error SHORT_XFER twice and hang. -- Pav Lucistnik Pain clots and unformed lice pat this train. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: Toto je =?UTF-8?Q?digit=C3=A1ln=C4=9B?= =?ISO-8859-1?Q?_podepsan=E1?= =?UTF-8?Q?_=C4=8D=C3=A1st?= =?ISO-8859-1?Q?_zpr=E1vy?= Url : http://lists.freebsd.org/pipermail/freebsd-bluetooth/attachments/20090223/6b44cf5a/attachment.pgp From maksim.yevmenkin at gmail.com Mon Feb 23 17:47:02 2009 From: maksim.yevmenkin at gmail.com (Maksim Yevmenkin) Date: Mon Feb 23 17:47:07 2009 Subject: obexapp outgoing problem In-Reply-To: <1235427294.1166.0.camel@hood.oook.cz> References: <1235324110.44220.1.camel@hood.oook.cz> <1235422984.72242.2.camel@hood.oook.cz> <1235427294.1166.0.camel@hood.oook.cz> Message-ID: 2009/2/23 Pav Lucistnik : > Maksim Yevmenkin p??e v po 23. 02. 2009 v 13:42 -0800: >> 2009/2/23 Pav Lucistnik : >> > Maksim Yevmenkin p??e v po 23. 02. 2009 v 10:49 -0800: >> >> Hi Pav, >> >> >> >> > I'm having troubles sending files to phone over obexapp, similar to >> >> > >> >> > http://www.freebsd.org/cgi/query-pr.cgi?pr=128297 >> >> > >> >> > except this time it's on 7-STABLE and the messages goes about ubt bulk >> >> > transfer having SHORT_XFER error first and then TIMEOUT. >> >> > >> >> > The box panics inside UHCI code, or just hangs. >> >> > >> >> > What can I do to help it? >> >> >> >> is that a new behavior? or was it always like that? since you have >> >> mentioned ng_ubt(4), i assume you are using usb1 (and not HPS's usb2) >> >> stack, right? the only big change that went into ng_ubt(4) (long time >> >> ago) is support for isoc. transfers. however, this change was not >> >> mfc'd, and you said you are running 7-stable, so this can not be it. >> >> >> >> if it was working before then i would try to revert back to the time >> >> when it was working, then incrementally updating trying to pinpoint >> >> time frame when it stopped working. once you know the time frame look >> >> closely for commits that could have affected it. >> > >> > It's 7-STABLE so OLDUSB. I don't know if it's new behaviour, this is >> > first time I tried sending files over Bluetooth to the phone, instead of >> > mailing them. >> > >> > PS: other way (phone -> PC) using obexapp -s works flawlessly. >> >> ok, could you please try the following patch. its cut-and-paste so you >> may need redo it manually (its simple enough). >> >> diff -u10 ng_ubt.c.orig ng_ubt.c >> --- ng_ubt.c.orig 2007-07-12 19:19:51.000000000 -0700 >> +++ ng_ubt.c 2009-02-23 13:39:32.000000000 -0800 >> @@ -1378,21 +1378,21 @@ >> >> m_copydata(m, 0, m->m_pkthdr.len, sc->sc_bulk_out_buffer); >> >> /* Initialize a bulk-out USB transfer and then schedule it */ >> usbd_setup_xfer( >> sc->sc_bulk_out_xfer, >> sc->sc_bulk_out_pipe, >> (usbd_private_handle) sc->sc_node, >> sc->sc_bulk_out_buffer, >> m->m_pkthdr.len, >> - USBD_NO_COPY, >> + USBD_FORCE_SHORT_XFER | USBD_NO_COPY, >> USBD_DEFAULT_TIMEOUT, /* XXX */ >> ubt_bulk_out_complete); >> >> NG_NODE_REF(sc->sc_node); >> >> status = usbd_transfer(sc->sc_bulk_out_xfer); >> if (status != USBD_NORMAL_COMPLETION && status != USBD_IN_PROGRESS) { >> NG_UBT_ERR( >> "%s: %s - Could not start bulk-out transfer. %s (%d)\n", >> __func__, device_get_nameunit(sc->sc_dev), >> usbd_errstr(status), > > No change, now I get bulk-out transfer error SHORT_XFER twice and hang. bummer :( i will try to reproduce it locally in a couple of days or so. this looks like something usb related, imo. thanks, max From mad at madpilot.net Thu Feb 26 09:05:23 2009 From: mad at madpilot.net (Guido Falsi) Date: Thu Feb 26 09:05:36 2009 Subject: ports using sdp when mpeg4ip is installed In-Reply-To: <200902191517.n1JFHjqI092809@lurza.secnetix.de> References: <1234991336.235532.1915.nullmailer@galant.ukfsn.org> <200902191517.n1JFHjqI092809@lurza.secnetix.de> Message-ID: <20090226170521.GE75587@megatron.madpilot.net> On Thu, Feb 19, 2009 at 04:17:45PM +0100, Oliver Fromme wrote: > Iain Hibbert wrote: > > Guido Falsi wrote: > > > I second this idea and it sure will solve the includes problem. > > > > > > It will not solve the problem with libsdp.so though. > > > > would it make sense to merge the sdp functions into libbluetooth? > > IIRC with BlueZ only one library is required.. > > Either that, or rename it to libbtsdp. I filed a followup to PR ports/131778 with a fix which works here. I'm hardcoding paths though, which I do not like too much. If someone has a better solution please let me know! Obviously if and when libsdp will be renamed or merged into libbluetooth I will patch the port to take advantage of this. Just let me know and I will try to fix is ASAP. -- Guido Falsi From mad at madpilot.net Thu Feb 26 11:37:50 2009 From: mad at madpilot.net (Guido Falsi) Date: Thu Feb 26 11:38:07 2009 Subject: ports using sdp when mpeg4ip is installed In-Reply-To: <200902191517.n1JFHjqI092809@lurza.secnetix.de> References: <1234991336.235532.1915.nullmailer@galant.ukfsn.org> <200902191517.n1JFHjqI092809@lurza.secnetix.de> Message-ID: <20090226170521.GE75587@megatron.madpilot.net> On Thu, Feb 19, 2009 at 04:17:45PM +0100, Oliver Fromme wrote: > Iain Hibbert wrote: > > Guido Falsi wrote: > > > I second this idea and it sure will solve the includes problem. > > > > > > It will not solve the problem with libsdp.so though. > > > > would it make sense to merge the sdp functions into libbluetooth? > > IIRC with BlueZ only one library is required.. > > Either that, or rename it to libbtsdp. I filed a followup to PR ports/131778 with a fix which works here. I'm hardcoding paths though, which I do not like too much. If someone has a better solution please let me know! Obviously if and when libsdp will be renamed or merged into libbluetooth I will patch the port to take advantage of this. Just let me know and I will try to fix is ASAP. -- Guido Falsi _______________________________________________ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscribe@freebsd.org" From mad at madpilot.net Thu Feb 26 11:38:20 2009 From: mad at madpilot.net (Guido Falsi) Date: Thu Feb 26 11:38:33 2009 Subject: ports using sdp when mpeg4ip is installed In-Reply-To: <200902191517.n1JFHjqI092809@lurza.secnetix.de> References: <1234991336.235532.1915.nullmailer@galant.ukfsn.org> <200902191517.n1JFHjqI092809@lurza.secnetix.de> Message-ID: <20090226170521.GE75587@megatron.madpilot.net> On Thu, Feb 19, 2009 at 04:17:45PM +0100, Oliver Fromme wrote: > Iain Hibbert wrote: > > Guido Falsi wrote: > > > I second this idea and it sure will solve the includes problem. > > > > > > It will not solve the problem with libsdp.so though. > > > > would it make sense to merge the sdp functions into libbluetooth? > > IIRC with BlueZ only one library is required.. > > Either that, or rename it to libbtsdp. I filed a followup to PR ports/131778 with a fix which works here. I'm hardcoding paths though, which I do not like too much. If someone has a better solution please let me know! Obviously if and when libsdp will be renamed or merged into libbluetooth I will patch the port to take advantage of this. Just let me know and I will try to fix is ASAP. -- Guido Falsi _______________________________________________ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscribe@freebsd.org"