From info at lottery.co.uk Sun May 10 15:49:09 2009 From: info at lottery.co.uk (UK NATIONAL LOTTERY) Date: Sun May 10 15:49:20 2009 Subject: National Lottery: Your Email Won Message-ID: <20090510153215.C5DDD3C17E@hm1207.locaweb.com.br> United Kingdom National Lottery 101 Bovill Road, London SE23 1EL United Kingdom File #: EGS/2251256003/02 Congratulations, we are pleased to inform you of the result of the United Kingdom National Lottery Award Winners. Your email address have been randomly selected as a winner in the ongoing United Kingdom National Lottery Online program, the draw was held on 30th April, 2009 using a computerized balloting system of selection. The United Kingdom National Lottery is aimed and focused at global development and improvement of living standard across the world. Free £77 Million Pounds won including *four* Ten Million Pounds Winners and *fourteen* Millionaires plus thousands of other cash prizes. Winner from all over the world, India, France, Singapore, USA, United Kingdom, Spain, South America, Malaysia, Indonesia, South Africa, Belgium, Denmark, Ireland and many more. We wish to express our sincere apologies for the late notification, this free award online program is been conducted bi-quarterly. United Kingdom National Lottery Free Award draw was conducted at the Europe Issuing Centre, you were selected from an exclusive list of 1,000,000,000 e-mail addresses of internet users from the following categories; consumers, professionals and corporate bodies picked by an advanced automated random computer ballot search from the internet 'NO TICKETS OR DRAFTS WERE SOLD'. Your email address attached to Security File #: EGS/2251256003/02 with Serial number No: 002839 emerged as a winner of Six Hundred Thousand Pounds (£600.000.00 GBP), therefore you are eligible to file claim for your prize as one of our lucky winners for the payout of your total sum after a thorough verification that will be conducted by our various credible financial institutions. This online program is precisely aimed at enabling all internet users across the world benefit from the United Kingdom National Lottery, your email address falls within the First Category Winner as such your file has been designated to our European Centre, where the complete verification and payout will be conducted only if there are no exceptions during the claims process, to file your claim immediately please contact our International Programs Director Anderson Spencer with the following information: 1. Name in full----------------------------------------- 2. Phone/Fax------------------------------------------- 3. Occupation------------------------------------------ TO: Contact Person: Anderson Spencer European Payment Issuing Office Tel: +447024065192 (8am - 5pm GMT) Fax: +447092894160 Email: zonal.anderson-spencer@msn.com NOTE: In order to benefit from this program, you are advised in your own best interest to file your claim not later than 7days days from the date of this notification to avoid disqualification; anybody under the age of 18 is automatically disqualified. Please include this File #: EGS/2251256003/02 in every of your correspondence with our Foreign Service Director Anderson Spencer. IMPORTANT: Solemn confidentiality should be ensured until successful remittance of your prize to you to avoid undue taking of advantage, unwarranted claim and abuse of program, any breach of confidentiality on the part of the winner will result to automatic disqualification. Sincerely Yours, Mrs. Julie Van Hans, Executive Director. United Kingdom National Lottery. From doconnor at gsoft.com.au Thu May 14 05:35:11 2009 From: doconnor at gsoft.com.au (Daniel O'Connor) Date: Thu May 14 05:35:18 2009 Subject: btpand example Message-ID: <200905141438.17380.doconnor@gsoft.com.au> Hi, I just got btpand working with my phone (Samsung Omnia i900 - WinMo 6.1 based) and here's what I did.. On PDA: Programs -> Internet Sharing -> Connect sudo hccontrol -n ubt0hci write_authentication_enable 1 sudo ifconfig tap0 create mtu 600 sudo btpand -d me -s NAP -i tap0 -a pda [enter pin on PDA as per hcsecd.conf] sudo dhclient tap0 Note that unlike the NetBSD example '-d ubt0' or '-d ubt0hci' doesn't work as it reports unknown host. I have 'me' in /etc/bluetooth/hosts, but that is non-standard (and '-d local' doesn't work). Also, I found the MTU by trial and error, 600 works for me, 650 does not. I am guessing this is a bluetooth thing but I'm not sure.. If it is would it be possible for btpand to set the MTU? Please CC me as I'm not on the list, thanks. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 188 bytes Desc: This is a digitally signed message part. Url : http://lists.freebsd.org/pipermail/freebsd-bluetooth/attachments/20090514/9ad7a2ff/attachment.pgp From plunky at rya-online.net Thu May 14 08:32:47 2009 From: plunky at rya-online.net (Iain Hibbert) Date: Thu May 14 08:32:54 2009 Subject: btpand example In-Reply-To: <200905141438.17380.doconnor@gsoft.com.au> References: <200905141438.17380.doconnor@gsoft.com.au> Message-ID: <1242289912.789883.948.nullmailer@galant.ukfsn.org> On Thu, 14 May 2009, Daniel O'Connor wrote: > Also, I found the MTU by trial and error, 600 works for me, 650 does > not. I am guessing this is a bluetooth thing but I'm not sure.. If it > is would it be possible for btpand to set the MTU? Why did you think to change the MTU and what was the failure? btpand itself doesn't actually care about the interface MTU and I talk to a WinMo 6.0 system fine (from NetBSD) with default ethernet MTU of 1500. On the bluetooth side, the BNEP minimum MTU is 1691 but we won't send anything bigger than as we don't create any extension headers in client mode. Packets will be what came from the tap. regards, iain From doconnor at gsoft.com.au Thu May 14 09:50:52 2009 From: doconnor at gsoft.com.au (Daniel O'Connor) Date: Thu May 14 09:50:58 2009 Subject: btpand example In-Reply-To: <1242289912.789883.948.nullmailer@galant.ukfsn.org> References: <200905141438.17380.doconnor@gsoft.com.au> <1242289912.789883.948.nullmailer@galant.ukfsn.org> Message-ID: <200905141920.47717.doconnor@gsoft.com.au> On Thu, 14 May 2009, Iain Hibbert wrote: > On Thu, 14 May 2009, Daniel O'Connor wrote: > > Also, I found the MTU by trial and error, 600 works for me, 650 > > does not. I am guessing this is a bluetooth thing but I'm not > > sure.. If it is would it be possible for btpand to set the MTU? > > Why did you think to change the MTU and what was the failure? I found that pinging worked and I could connect to an SSH port but they SSH key exchange stalled so I guessed MTU and got lucky. > btpand itself doesn't actually care about the interface MTU and I > talk to a WinMo 6.0 system fine (from NetBSD) with default ethernet > MTU of 1500. OK. I later tried l2ping -s 1500 -a pda and it worked so I'm not sure what's going on. > On the bluetooth side, the BNEP minimum MTU is 1691 but we won't send > anything bigger than as we don't create any extension headers in > client mode. Packets will be what came from the tap. OK.. I wonder where the problem is :( I have done the same operation on the same hardware in Linux and it worked without MTU tweaks, however I haven't looked to see what MTU it used or anything. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 188 bytes Desc: This is a digitally signed message part. Url : http://lists.freebsd.org/pipermail/freebsd-bluetooth/attachments/20090514/5c2137ce/attachment.pgp From plunky at rya-online.net Thu May 14 09:51:48 2009 From: plunky at rya-online.net (Iain Hibbert) Date: Thu May 14 09:51:55 2009 Subject: libhci update In-Reply-To: References: <1240311202.361300.1366.nullmailer@galant.ukfsn.org> <1240352254.082638.416.nullmailer@galant.ukfsn.org> <1240386569.369073.696.nullmailer@galant.ukfsn.org> Message-ID: <1242294653.314348.1748.nullmailer@galant.ukfsn.org> On Wed, 22 Apr 2009, Maksim Yevmenkin wrote: > > I've got no more comments here > > thanks for the review. i committed it to -head. Hi Max, I'm in progress of translating for NetBSD and in bt_devinquiry() I see if (ii == NULL) { errno = EINVAL; return (-1); } but I think this test might be bogus? manpage implies that the caller provides a buffer but we allocate one.. /* Calculate inquire length in 1.28 second units */ to = (time_t) ((double) length / 1.28); if (to <= 0) cp->inquiry_length = 4; /* 5.12 seconds */ else if (to > 254) cp->inquiry_length = 255; /* 326.40 seconds */ else cp->inquiry_length = to + 1; 2.1 spec says 1.28 -> 61.44 seconds range is acceptable (0x01->0x30) Then, to avoid the floating point arithmetic, can use (to * 100 / 128) but would need to be range checked first. I'm inclined to use something like if (to == 0) to = 4; else if (to == 1) to = 2; else if (to > 61) to = 61; cp->inquiry_length = (uint8_t)(to * 100 / 128); also, I'm not sure that the timeout is handled right; the bt_devrecv() uses the complete timeout each time but the time endpoint might need to be calculated so that time-to-end can be used? Also I'm wondering what to do in the case bt_devrecv() does actually time out - what can it mean and should we [attempt to] cancel the inquiry? (actually the whole timeout thing is probably irrelevant for a properly functioning device :) iain From plunky at rya-online.net Thu May 14 11:04:52 2009 From: plunky at rya-online.net (Iain Hibbert) Date: Thu May 14 11:05:03 2009 Subject: btpand example In-Reply-To: <200905141920.47717.doconnor@gsoft.com.au> References: <200905141438.17380.doconnor@gsoft.com.au> <1242289912.789883.948.nullmailer@galant.ukfsn.org> <200905141920.47717.doconnor@gsoft.com.au> Message-ID: <1242299035.690452.893.nullmailer@galant.ukfsn.org> On Thu, 14 May 2009, Daniel O'Connor wrote: > On Thu, 14 May 2009, Iain Hibbert wrote: > > On Thu, 14 May 2009, Daniel O'Connor wrote: > > > Also, I found the MTU by trial and error, 600 works for me, 650 > > > does not. I am guessing this is a bluetooth thing but I'm not > > > sure.. If it is would it be possible for btpand to set the MTU? > > > > Why did you think to change the MTU and what was the failure? > > I found that pinging worked and I could connect to an SSH port but they > SSH key exchange stalled so I guessed MTU and got lucky. Hm, I do manage to use ssh successfully over a btpand/winmobile link.. > I later tried l2ping -s 1500 -a pda and it worked so I'm not sure what's > going on. probably better to try actual ping with larger packet sizes..? l2ping only tests the bluetooth link. If you also added a log_debug() to the end of bnep_send() to display the nw and pkt->len values you might see if lossage was happening at any particular packet size. There is already a check that the packet doesn't exceed the MTU of the link though. > I have done the same operation on the same hardware in Linux and it > worked without MTU tweaks, however I haven't looked to see what MTU it > used or anything. I do get a weird problem sometimes where incoming ethernet packet payload is rejected by tap for being oversized. I've never tracked it down but I'm blaming windows mobile for that because the ethernet packet probably originates there rather than at the other end of the GPRS link (I could be wrong) eg May 2 11:06:36 galant btpand[820]: bnep_recv: received long packet (type=0x02, proto=0x0800, len=1568) May 2 11:06:36 galant /netbsd: tap0: discarding oversize frame (len=1582) I find this will cause a HTTP transfer to stall but I think ssh recovers from the lost packet ok. iain From maksim.yevmenkin at gmail.com Thu May 14 16:26:20 2009 From: maksim.yevmenkin at gmail.com (Maksim Yevmenkin) Date: Thu May 14 16:26:27 2009 Subject: libhci update In-Reply-To: <1242294653.314348.1748.nullmailer@galant.ukfsn.org> References: <1240311202.361300.1366.nullmailer@galant.ukfsn.org> <1240352254.082638.416.nullmailer@galant.ukfsn.org> <1240386569.369073.696.nullmailer@galant.ukfsn.org> <1242294653.314348.1748.nullmailer@galant.ukfsn.org> Message-ID: Iain, >> thanks for the review. i committed it to -head. > > Hi Max, I'm in progress of translating for NetBSD and in bt_devinquiry() I > see > > if (ii == NULL) { > errno = EINVAL; > return (-1); > } > > but I think this test might be bogus? manpage implies that the caller > provides a buffer but we allocate one.. no, the test is correct. yes, we allocate buffer internally, but we need to return pointer to the buffer back to the caller. so, ii is basically ii is struct bt_devinquiry **. perhaps language in the man page is not clear enough? > /* Calculate inquire length in 1.28 second units */ > to = (time_t) ((double) length / 1.28); > > if (to <= 0) > cp->inquiry_length = 4; /* 5.12 seconds */ > else if (to > 254) > cp->inquiry_length = 255; /* 326.40 seconds */ > else > cp->inquiry_length = to + 1; > > 2.1 spec says 1.28 -> 61.44 seconds range is acceptable (0x01->0x30) > > Then, to avoid the floating point arithmetic, can use (to * 100 / 128) but > would need to be range checked first. I'm inclined to use something like > > if (to == 0) > to = 4; > else if (to == 1) > to = 2; > else if (to > 61) > to = 61; > > cp->inquiry_length = (uint8_t)(to * 100 / 128); i have no problem with it. > also, I'm not sure that the timeout is handled right; the bt_devrecv() > uses the complete timeout each time but the time endpoint might need to be > calculated so that time-to-end can be used? well, yes. bt_devrecv() was envisioned as "one-shot" call. the only case, imo, where it can restart internally with the same timeout is when select is interrupted by a signal. > Also I'm wondering what to do in the case bt_devrecv() does actually time > out - what can it mean and should we [attempt to] cancel the inquiry? ahh, but in case of bt_devinquiry() it probably does not matter that much because inquiry itself is limited by the "length" parameter. so we have to receive something back from the device. i was thinking to pass -1 as timeout to bt_devrecv() in this particular case, but decided not to do it (try harder to exit the bt_devinquiry()). > (actually the whole timeout thing is probably irrelevant for a properly > functioning device :) exactly :) thanks, max p.s. thanks for the sdp update. i will try and take a look when i get free minute. From maksim.yevmenkin at gmail.com Thu May 14 16:42:53 2009 From: maksim.yevmenkin at gmail.com (Maksim Yevmenkin) Date: Thu May 14 16:43:00 2009 Subject: libhci update In-Reply-To: References: <1240311202.361300.1366.nullmailer@galant.ukfsn.org> <1240352254.082638.416.nullmailer@galant.ukfsn.org> <1240386569.369073.696.nullmailer@galant.ukfsn.org> <1242294653.314348.1748.nullmailer@galant.ukfsn.org> Message-ID: On Thu, May 14, 2009 at 9:26 AM, Maksim Yevmenkin wrote: >> /* Calculate inquire length in 1.28 second units */ >> to = (time_t) ((double) length / 1.28); >> >> if (to <= 0) >> cp->inquiry_length = 4; /* 5.12 seconds */ >> else if (to > 254) >> cp->inquiry_length = 255; /* 326.40 seconds */ >> else >> cp->inquiry_length = to + 1; >> >> 2.1 spec says 1.28 -> 61.44 seconds range is acceptable (0x01->0x30) ok, do you like something like Index: hci.c =================================================================== --- hci.c (revision 191499) +++ hci.c (working copy) @@ -410,7 +410,6 @@ ng_hci_inquiry_response *ir; struct bt_devinquiry *i; int s, n; - time_t to; if (ii == NULL) { errno = EINVAL; @@ -452,17 +451,21 @@ cp->lap[1] = 0x8b; cp->lap[2] = 0x9e; - /* Calculate inquire length in 1.28 second units */ - to = (time_t) ((double) length / 1.28); - if (to <= 0) - cp->inquiry_length = 4; /* 5.12 seconds */ - else if (to > 254) - cp->inquiry_length = 255; /* 326.40 seconds */ - else - cp->inquiry_length = to + 1; + /* + * Calculate inquire length in 1.28 second units + * v2.x specification says that 1.28 -> 61.44 seconds + * range is acceptable + */ - to = (time_t)((double) cp->inquiry_length * 1.28) + 1; + if (length <= 0) + length = 5; + else if (length == 1) + length = 2; + else if (length > 61) + length = 61; + cp->inquiry_length = (uint8_t)((length * 100) / 128); + if (num_rsp <= 0 || num_rsp > 255) num_rsp = 8; cp->num_responses = (uint8_t) num_rsp; @@ -484,7 +487,7 @@ wait_for_more: - n = bt_devrecv(s, buf, sizeof(buf), to); + n = bt_devrecv(s, buf, sizeof(buf), length); if (n < 0) { free(i); bt_devclose(s); == thanks, max From plunky at rya-online.net Thu May 14 17:00:16 2009 From: plunky at rya-online.net (Iain Hibbert) Date: Thu May 14 17:00:22 2009 Subject: libhci update In-Reply-To: References: <1240311202.361300.1366.nullmailer@galant.ukfsn.org> <1240352254.082638.416.nullmailer@galant.ukfsn.org> <1240386569.369073.696.nullmailer@galant.ukfsn.org> <1242294653.314348.1748.nullmailer@galant.ukfsn.org> Message-ID: <1242320358.167446.9598.nullmailer@galant.ukfsn.org> On Thu, 14 May 2009, Maksim Yevmenkin wrote: > >> 2.1 spec says 1.28 -> 61.44 seconds range is acceptable (0x01->0x30) > > ok, do you like something like > > + if (length <= 0) > + length = 5; > + else if (length == 1) > + length = 2; > + else if (length > 61) > + length = 61; yes that is what I have too, except I've allowed 62 (as 61 gives 0x2f) iain From maksim.yevmenkin at gmail.com Thu May 14 17:05:32 2009 From: maksim.yevmenkin at gmail.com (Maksim Yevmenkin) Date: Thu May 14 17:05:38 2009 Subject: btpand example In-Reply-To: <200905141438.17380.doconnor@gsoft.com.au> References: <200905141438.17380.doconnor@gsoft.com.au> Message-ID: Daniel, > I just got btpand working with my phone (Samsung Omnia i900 - WinMo 6.1 > based) and here's what I did.. cool! thank for reporting. > Note that unlike the NetBSD example '-d ubt0' or '-d ubt0hci' doesn't > work as it reports unknown host. I have 'me' in /etc/bluetooth/hosts, > but that is non-standard (and '-d local' doesn't work). could you please try this patch? Index: btpand.c =================================================================== --- btpand.c (revision 192109) +++ btpand.c (working copy) @@ -101,7 +101,7 @@ break; case 'd': /* local address */ - if (!bt_aton(optarg, &local_bdaddr)) { + if (!bt_devaddr(optarg, &local_bdaddr)) { struct hostent *he; if ((he = bt_gethostbyname(optarg)) == NULL) === > Also, I found the MTU by trial and error, 600 works for me, 650 does > not. I am guessing this is a bluetooth thing but I'm not sure.. If it > is would it be possible for btpand to set the MTU? sure :) however, like Iain said, it would be interesting to see what is going on. any chance we could get both hcidump (created with -w option) and tcpdump? could it be something that has to do with tcp mss fixup? thanks, max From maksim.yevmenkin at gmail.com Thu May 14 17:11:35 2009 From: maksim.yevmenkin at gmail.com (Maksim Yevmenkin) Date: Thu May 14 17:11:42 2009 Subject: libhci update In-Reply-To: <1242320358.167446.9598.nullmailer@galant.ukfsn.org> References: <1240352254.082638.416.nullmailer@galant.ukfsn.org> <1240386569.369073.696.nullmailer@galant.ukfsn.org> <1242294653.314348.1748.nullmailer@galant.ukfsn.org> <1242320358.167446.9598.nullmailer@galant.ukfsn.org> Message-ID: On Thu, May 14, 2009 at 9:59 AM, Iain Hibbert wrote: > On Thu, 14 May 2009, Maksim Yevmenkin wrote: > >> >> 2.1 spec says 1.28 -> 61.44 seconds range is acceptable (0x01->0x30) >> >> ok, do you like something like >> >> + if (length <= 0) >> + length = 5; >> + else if (length == 1) >> + length = 2; >> + else if (length > 61) >> + length = 61; > > yes that is what I have too, except I've allowed 62 (as 61 gives 0x2f) cool. its in :) == Author: emax Date: Thu May 14 17:10:19 2009 New Revision: 192113 URL: http://svn.freebsd.org/changeset/base/192113 Log: Avoid floating point arithmetic while calculating iquiry length. Submitted by: Iain Hibbert < plunky -at- rya-online -dot- net > MFC after: 1 week Modified: head/lib/libbluetooth/hci.c Modified: head/lib/libbluetooth/hci.c == thanks, max From plunky at rya-online.net Thu May 14 17:38:04 2009 From: plunky at rya-online.net (Iain Hibbert) Date: Thu May 14 17:38:10 2009 Subject: libhci update In-Reply-To: References: <1240311202.361300.1366.nullmailer@galant.ukfsn.org> <1240352254.082638.416.nullmailer@galant.ukfsn.org> <1240386569.369073.696.nullmailer@galant.ukfsn.org> <1242294653.314348.1748.nullmailer@galant.ukfsn.org> Message-ID: <1242322384.832849.4269.nullmailer@galant.ukfsn.org> On Thu, 14 May 2009, Maksim Yevmenkin wrote: > Iain, > > >> thanks for the review. i committed it to -head. > > > > Hi Max, I'm in progress of translating for NetBSD and in bt_devinquiry() I > > see > > > > if (ii == NULL) { > > errno = EINVAL; > > return (-1); > > } > > > > but I think this test might be bogus? manpage implies that the caller > > provides a buffer but we allocate one.. > > no, the test is correct. yes, we allocate buffer internally, but we > need to return pointer to the buffer back to the caller. so, ii is > basically ii is struct bt_devinquiry **. perhaps language in the man > page is not clear enough? Ah yes, my bad. I haven't properly looked at the manpage yet (I saw a spelling mistake earlier but I didn't note it :), will examine it in detail later. I'm trying to think of another function that does similar to copy the language from, perhaps asprintf()? btw do you know what devinfo->role_switch_info might contain? I have link_policy_info which presumably contains the following flags /* Link policy settings */ #define HCI_LINK_POLICY_DISABLE_ALL_LM_MODES 0x0000 #define HCI_LINK_POLICY_ENABLE_ROLE_SWITCH 0x0001 /* Master/Slave switch */ #define HCI_LINK_POLICY_ENABLE_HOLD_MODE 0x0002 #define HCI_LINK_POLICY_ENABLE_SNIFF_MODE 0x0004 #define HCI_LINK_POLICY_ENABLE_PARK_MODE 0x0008 /* 0x0010 - 0x8000 - reserved for future use */ but I'm not sure what to put in role_switch_info? (for now, 0 :) > > also, I'm not sure that the timeout is handled right; the bt_devrecv() > > uses the complete timeout each time but the time endpoint might need to be > > calculated so that time-to-end can be used? > > well, yes. bt_devrecv() was envisioned as "one-shot" call. the only > case, imo, where it can restart internally with the same timeout is > when select is interrupted by a signal. I think the timeout should probably act the same way as in bt_devreq(), but I thought there could be close calls at the end because of the integer arithmetic. > > Also I'm wondering what to do in the case bt_devrecv() does actually time > > out - what can it mean and should we [attempt to] cancel the inquiry? > > ahh, but in case of bt_devinquiry() it probably does not matter that > much because inquiry itself is limited by the "length" parameter. so > we have to receive something back from the device. i was thinking to > pass -1 as timeout to bt_devrecv() in this particular case, but > decided not to do it (try harder to exit the bt_devinquiry()). mm, -1 is tempting but I think its better to error timeout even if the device is left in a weird state. At least the user won't be left waiting.. I'll continue to work on it because a successful exit must wait until the device has exited inquiry mode. (I noticed that you can't do things like get-remote-name when still in inquiry mode, at least on some devices) iain From maksim.yevmenkin at gmail.com Thu May 14 18:40:59 2009 From: maksim.yevmenkin at gmail.com (Maksim Yevmenkin) Date: Thu May 14 18:41:06 2009 Subject: libhci update In-Reply-To: <1242322384.832849.4269.nullmailer@galant.ukfsn.org> References: <1240311202.361300.1366.nullmailer@galant.ukfsn.org> <1240352254.082638.416.nullmailer@galant.ukfsn.org> <1240386569.369073.696.nullmailer@galant.ukfsn.org> <1242294653.314348.1748.nullmailer@galant.ukfsn.org> <1242322384.832849.4269.nullmailer@galant.ukfsn.org> Message-ID: On Thu, May 14, 2009 at 10:33 AM, Iain Hibbert wrote: [...] >> > but I think this test might be bogus? manpage implies that the caller >> > provides a buffer but we allocate one.. >> >> no, the test is correct. yes, we allocate buffer internally, but we >> need to return pointer to the buffer back to the caller. so, ii is >> basically ii is struct bt_devinquiry **. perhaps language in the man >> page is not clear enough? > > Ah yes, my bad. I haven't properly looked at the manpage yet (I saw a > spelling mistake earlier but I didn't note it :), will examine it in > detail later. I'm trying to think of another function that does similar to > copy the language from, perhaps asprintf()? yeah, may be. please feel free to correct my english :) > btw do you know what devinfo->role_switch_info might contain? I have > link_policy_info which presumably contains the following flags that is for 'forceful' role switch when we are accepting connection. basically always try to become master on any connection (or not). [...] >> > also, I'm not sure that the timeout is handled right; the bt_devrecv() >> > uses the complete timeout each time but the time endpoint might need to be >> > calculated so that time-to-end can be used? >> >> well, yes. bt_devrecv() was envisioned as "one-shot" call. the only >> case, imo, where it can restart internally with the same timeout is >> when select is interrupted by a signal. > > I think the timeout should probably act the same way as in bt_devreq(), > but I thought there could be close calls at the end because of the integer > arithmetic. sorry, are we talking about bt_devrecv() in isolation, or about bt_devinquiry() usage of bt_devrecv(). in other words, are you saying we should fix bt_devinquiry() and make sure that is decreases timeout with every call to bt_devrecv()? >> > Also I'm wondering what to do in the case bt_devrecv() does actually time >> > out - what can it mean and should we [attempt to] cancel the inquiry? >> >> ahh, but in case of bt_devinquiry() it probably does not matter that >> much because inquiry itself is limited by the "length" parameter. so >> we have to receive something back from the device. i was thinking to >> pass -1 as timeout to bt_devrecv() in this particular case, but >> decided not to do it (try harder to exit the bt_devinquiry()). > > mm, -1 is tempting but I think its better to error timeout even if the > device is left in a weird state. At least the user won't be left waiting.. my thoughts exactly :) > I'll continue to work on it because a successful exit must wait until the > device has exited inquiry mode. (I noticed that you can't do things like > get-remote-name when still in inquiry mode, at least on some devices) yes, inquiry is weird (from baseband point of view) procedure. device basically has to blast on the range of frequencies and wait for someone to respond. technically, nothing prevents device from doing other rf activity, but some devices choose not to do it. thanks, max From plunky at rya-online.net Thu May 14 19:23:38 2009 From: plunky at rya-online.net (Iain Hibbert) Date: Thu May 14 19:23:44 2009 Subject: libhci update In-Reply-To: References: <1240311202.361300.1366.nullmailer@galant.ukfsn.org> <1240352254.082638.416.nullmailer@galant.ukfsn.org> <1240386569.369073.696.nullmailer@galant.ukfsn.org> <1242294653.314348.1748.nullmailer@galant.ukfsn.org> <1242322384.832849.4269.nullmailer@galant.ukfsn.org> Message-ID: <1242328962.345875.22296.nullmailer@galant.ukfsn.org> On Thu, 14 May 2009, Maksim Yevmenkin wrote: > that is for 'forceful' role switch when we are accepting connection. > basically always try to become master on any connection (or not). Mm, I didn't put that into netbsd (yet) so it can remain 0 for now, thanks. > >> > also, I'm not sure that the timeout is handled right; the bt_devrecv() > >> > uses the complete timeout each time but the time endpoint might need to be > >> > calculated so that time-to-end can be used? > >> > >> well, yes. bt_devrecv() was envisioned as "one-shot" call. the only > >> case, imo, where it can restart internally with the same timeout is > >> when select is interrupted by a signal. > > > > I think the timeout should probably act the same way as in bt_devreq(), > > but I thought there could be close calls at the end because of the integer > > arithmetic. > > sorry, are we talking about bt_devrecv() in isolation, or about > bt_devinquiry() usage of bt_devrecv(). > > in other words, are you saying we should fix bt_devinquiry() and make > sure that is decreases timeout with every call to bt_devrecv()? yes, sorry - what bt_devrecv() does in isolation is fine, it is bt_devinquiry() that should manage a cumulative target for timeout. (btw 'close call' in quote above is 'near miss' not 'close() call' :) > yes, inquiry is weird (from baseband point of view) procedure. device > basically has to blast on the range of frequencies and wait for > someone to respond. technically, nothing prevents device from doing > other rf activity, but some devices choose not to do it. I haven't looked but I think from skimming their list that latest linux code (not sure if in kernel or bluetoothd) sets the device into inquiry state and manages the connections to avoid errors in that situation. I thought about that for netbsd but didn't get far - it also would cover things like pausing encryption to make role switches and suchlike which was causing me a trouble when I tried to make a MASTER mode work. iain From plunky at rya-online.net Thu May 14 21:16:33 2009 From: plunky at rya-online.net (Iain Hibbert) Date: Thu May 14 21:16:41 2009 Subject: libhci update In-Reply-To: <1242328962.345875.22296.nullmailer@galant.ukfsn.org> References: <1240311202.361300.1366.nullmailer@galant.ukfsn.org> <1240352254.082638.416.nullmailer@galant.ukfsn.org> <1240386569.369073.696.nullmailer@galant.ukfsn.org> <1242294653.314348.1748.nullmailer@galant.ukfsn.org> <1242322384.832849.4269.nullmailer@galant.ukfsn.org> <1242328962.345875.22296.nullmailer@galant.ukfsn.org> Message-ID: <1242335731.252131.19040.nullmailer@galant.ukfsn.org> Hi Max, some more queries I'm not sure about.. --- hci.c.orig 2009-05-14 21:11:04.000000000 +0100 +++ hci.c 2009-05-14 21:26:57.000000000 +0100 @@ -118,7 +118,7 @@ bt_devsend(int s, uint16_t opcode, void h.length = 0; while (writev(s, iv, ivn) < 0) { - if (errno == EAGAIN || errno == EINTR) + if (errno == EINTR) continue; return (-1); @@ -163,12 +163,15 @@ bt_devrecv(int s, void *buf, size_t size } while ((n = read(s, buf, size)) < 0) { - if (errno == EAGAIN || errno == EINTR) + if (errno == EINTR) continue; return (-1); I think these two should not have EAGAIN because that can be returned if the socket is set to nonblocking and we should just pass it back to the caller rather than looping? } + if (n == 0) + return (0); + the read() in bt_devrecv() can return 0 for EOF at least. ok it shouldn't happen but do you think it would be proper to return it? (or call it an error? I dunno) @@ -273,10 +276,11 @@ bt_devreq(int s, struct bt_devreq *r, ti if (r->rlen >= n) { r->rlen = n; memcpy(r->rparam, cc + 1, r->rlen); } + /* else what? */ goto out; } break; @@ -290,10 +294,11 @@ bt_devreq(int s, struct bt_devreq *r, ti } else { if (r->rlen >= n) { r->rlen = n; memcpy(r->rparam, cs, r->rlen); } + /* else what? */ goto out; } } break; @@ -302,10 +307,11 @@ bt_devreq(int s, struct bt_devreq *r, ti if (e->event == r->event) { if (r->rlen >= n) { r->rlen = n; memcpy(r->rparam, e + 1, r->rlen); } + /* else what? */ these three locations in bt_devreq() I'm not sure what should happen if the provided buffer was not big enough. I suggest the following construct instead: if (r->rlen > n) r->rlen = n; if (r->rlen > 0) memcpy(r->rparam, ..., r->rlen); which gives them as much as they asked for and discards the rest, how would that look? Also, I'm thinking of the case where r->event=0 but a command_status is returned. If status != 0, an error is produced but if status == 0 then we should set rlen = 0 and return success? @@ -504,10 +510,16 @@ wait_for_more: case NG_HCI_EVENT_INQUIRY_RESULT: ir = (ng_hci_inquiry_response *)(ep + 1); for (n = 0; n < MIN(ep->num_responses, num_rsp); n ++) { I found while writing the inquiry routine in btconfig(8) that some devices don't filter repeat addresses properly (or maybe its that some devices continue to respond, I've seen that too). Perhaps its worth handling that case inside the bt_devinquiry() function by discarding dupes? @@ -551,11 +563,11 @@ bt_devinfo(struct bt_devinfo *di) return (-1); } s = bt_devopen(di->devname); if (s < 0) return (-1); I'm not sure if in FreeBSD you can connect() to a device that is not marked up, but in NetBSD you can't. In any case, there is information in the devinfo structure that is only available from activated devices so it may fail? This really relates to bt_devenum() as below, are we counting 'active' devices or 'all' devices, as you ignored errors? @@ -659,21 +671,24 @@ bt_devenum(bt_devenum_cb_t cb, void *arg } for (count = 0, i = 0; i < rp.num_names; i ++) { strlcpy(di.devname, rp.names[i].name, sizeof(di.devname)); if (bt_devinfo(&di) < 0) - continue; + continue; /* or maybe error? */ count ++; if (cb == NULL) 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; + continue; /* or maybe error? */ + I think the second one should cause an error return at least? Not sure about the first - in NetBSD I have the flags already so I've skipped inactive interfaces as below while (ioctl(s, SIOCNBTINFO, &btr) != -1) { if ((btr.btr_flags & BTF_UP) == 0) continue; count++; if (cb == NULL) continue; memset(&di, 0, sizeof(di)); strlcpy(di.devname, btr.btr_name, HCI_DEVNAME_SIZE); memset(&sa, 0, sizeof(sa)); sa.bt_len = sizeof(sa); sa.bt_family = AF_BLUETOOTH; bdaddr_copy(&sa.bt_bdaddr, &btr.btr_bdaddr); if (bt_devinfo(&di) == -1 || bind(s, (struct sockaddr *)&sa, sizeof(sa)) == -1 || connect(s, (struct sockaddr *)&sa, sizeof(sa)) == -1) { close(s); return -1; } if ((*cb)(s, &di, arg) != 0) break; } thats all for now :) iain From maksim.yevmenkin at gmail.com Fri May 15 17:21:25 2009 From: maksim.yevmenkin at gmail.com (Maksim Yevmenkin) Date: Fri May 15 17:21:35 2009 Subject: libhci update In-Reply-To: <1242335731.252131.19040.nullmailer@galant.ukfsn.org> References: <1240386569.369073.696.nullmailer@galant.ukfsn.org> <1242294653.314348.1748.nullmailer@galant.ukfsn.org> <1242322384.832849.4269.nullmailer@galant.ukfsn.org> <1242328962.345875.22296.nullmailer@galant.ukfsn.org> <1242335731.252131.19040.nullmailer@galant.ukfsn.org> Message-ID: On Thu, May 14, 2009 at 2:15 PM, Iain Hibbert wrote: > Hi Max, > some more queries I'm not sure about.. > > --- hci.c.orig 2009-05-14 21:11:04.000000000 +0100 > +++ hci.c 2009-05-14 21:26:57.000000000 +0100 > @@ -118,7 +118,7 @@ bt_devsend(int s, uint16_t opcode, void > h.length = 0; > > while (writev(s, iv, ivn) < 0) { > - if (errno == EAGAIN || errno == EINTR) > + if (errno == EINTR) > continue; > > return (-1); > @@ -163,12 +163,15 @@ bt_devrecv(int s, void *buf, size_t size > } > > while ((n = read(s, buf, size)) < 0) { > - if (errno == EAGAIN || errno == EINTR) > + if (errno == EINTR) > continue; > > return (-1); > > I think these two should not have EAGAIN because that can be returned if > the socket is set to nonblocking and we should just pass it back to the > caller rather than looping? i somewhat disagree. it is true that _internally_ libbluetooth does not set hci socket to the non-blocking mode. however, bt_devsend/recv() can be used with the hci socket that was created outside of libbluetooth. [....] > + if (n == 0) > + return (0); > + > > the read() in bt_devrecv() can return 0 for EOF at least. ok it shouldn't > happen but do you think it would be proper to return it? (or call it an > error? I dunno) can it really return 0? i mean specifically when reading from bluetooth socket not in general. in any case the existing code will return EIO, i.e. error. granted, it will try to parse data in buf, but it will always fail if n == 0. > @@ -273,10 +276,11 @@ bt_devreq(int s, struct bt_devreq *r, ti > > if (r->rlen >= n) { > r->rlen = n; > memcpy(r->rparam, cc + 1, r->rlen); > } > + /* else what? */ > > goto out; > } > break; > > @@ -290,10 +294,11 @@ bt_devreq(int s, struct bt_devreq *r, ti > } else { > if (r->rlen >= n) { > r->rlen = n; > memcpy(r->rparam, cs, r->rlen); > } > + /* else what? */ > > goto out; > } > } > break; > @@ -302,10 +307,11 @@ bt_devreq(int s, struct bt_devreq *r, ti > if (e->event == r->event) { > if (r->rlen >= n) { > r->rlen = n; > memcpy(r->rparam, e + 1, r->rlen); > } > + /* else what? */ > > these three locations in bt_devreq() I'm not sure what should happen if > the provided buffer was not big enough. I suggest the following construct > instead: > > if (r->rlen > n) > r->rlen = n; > > if (r->rlen > 0) > memcpy(r->rparam, ..., r->rlen); > > which gives them as much as they asked for and discards the rest, how > would that look? i did not really know what to do here. practically, this just should not happen. caller is expected to know how big return parameters are and pass appropriately sized buffer. if the caller really does not care about return parameters, then no buffer should be passed. returning something that is incomplete is a bit broken, imo. i actually wrote the code like you suggested, but then decided not to do it this way. cant remember why :) i also considered to return EMSGSIZE in this case, but then deiced not do to it either. again i cant recall the exact reason :) since this is a relatively minor issue, lets agree on something and move on. i could go either way. > Also, I'm thinking of the case where r->event=0 but a command_status is > returned. If status != 0, an error is produced but if status == 0 then we > should set rlen = 0 and return success? what is wrong with the existing code? it simply returns status code in the return parameters and let caller deal with it. why give special treatment to status == 0 code? as far as bt_devreq() is concern, request has completed, i.e. we send something to the device and we got something back. since caller gave us no specifics (i.e. r->event == 0), caller should deal with the return parameters. > @@ -504,10 +510,16 @@ wait_for_more: > > case NG_HCI_EVENT_INQUIRY_RESULT: > ir = (ng_hci_inquiry_response *)(ep + 1); > > for (n = 0; n < MIN(ep->num_responses, num_rsp); n ++) { > > I found while writing the inquiry routine in btconfig(8) that some devices > don't filter repeat addresses properly (or maybe its that some devices > continue to respond, I've seen that too). Perhaps its worth handling that > case inside the bt_devinquiry() function by discarding dupes? yes, i've seen that too. broadcom chips (at least in my case) have this behavior. how do you propose to detect the dupes? using bd_addr only? or match all/some parameters as well? i think it would be ok to remove dupes. > @@ -551,11 +563,11 @@ bt_devinfo(struct bt_devinfo *di) > return (-1); > } > > s = bt_devopen(di->devname); > if (s < 0) > return (-1); > > I'm not sure if in FreeBSD you can connect() to a device that is not > marked up, but in NetBSD you can't. In any case, there is information in > the devinfo structure that is only available from activated devices so it > may fail? in freebsd, you can. bind()/connect() just sets device name in socket's pcb. in fact, in freebsd, you can bind/connect() hci socket to anything :) > This really relates to bt_devenum() as below, are we counting 'active' > devices or 'all' devices, as you ignored errors? in freebsd, we return the list of netgraph nodes. that is, device may be present (node exists) but not 'up'. that is what 'state' parameter in devinfo structure is telling you. so, in freebsd, devenum() will return the list of all devices. > @@ -659,21 +671,24 @@ bt_devenum(bt_devenum_cb_t cb, void *arg > } > > for (count = 0, i = 0; i < rp.num_names; i ++) { > strlcpy(di.devname, rp.names[i].name, sizeof(di.devname)); > if (bt_devinfo(&di) < 0) > - continue; > + continue; /* or maybe error? */ > > count ++; > > if (cb == NULL) > 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; > + continue; /* or maybe error? */ > + > > I think the second one should cause an error return at least? Not sure > about the first - in NetBSD I have the flags already so I've skipped > inactive interfaces as below this is probably something that should be os/stack implementation specific. however, i'll try very hard to make devenum() interface behave similarly on different os's. perhaps there should be another parameter to devenum() that tells which devices it should enumerate? i.e. all or active? thanks, max From plunky at rya-online.net Fri May 15 20:50:38 2009 From: plunky at rya-online.net (Iain Hibbert) Date: Fri May 15 20:50:45 2009 Subject: libhci update In-Reply-To: References: <1240386569.369073.696.nullmailer@galant.ukfsn.org> <1242294653.314348.1748.nullmailer@galant.ukfsn.org> <1242322384.832849.4269.nullmailer@galant.ukfsn.org> <1242328962.345875.22296.nullmailer@galant.ukfsn.org> <1242335731.252131.19040.nullmailer@galant.ukfsn.org> Message-ID: <1242420574.009085.2429.nullmailer@galant.ukfsn.org> On Fri, 15 May 2009, Maksim Yevmenkin wrote: > On Thu, May 14, 2009 at 2:15 PM, Iain Hibbert wrote: > > Hi Max, > > some more queries I'm not sure about.. > > > > --- hci.c.orig 2009-05-14 21:11:04.000000000 +0100 > > +++ hci.c 2009-05-14 21:26:57.000000000 +0100 > > @@ -118,7 +118,7 @@ bt_devsend(int s, uint16_t opcode, void > > h.length = 0; > > > > while (writev(s, iv, ivn) < 0) { > > - if (errno == EAGAIN || errno == EINTR) > > + if (errno == EINTR) > > continue; > > > > return (-1); > > @@ -163,12 +163,15 @@ bt_devrecv(int s, void *buf, size_t size > > } > > > > while ((n = read(s, buf, size)) < 0) { > > - if (errno == EAGAIN || errno == EINTR) > > + if (errno == EINTR) > > continue; > > > > return (-1); > > > > I think these two should not have EAGAIN because that can be returned if > > the socket is set to nonblocking and we should just pass it back to the > > caller rather than looping? > > i somewhat disagree. it is true that _internally_ libbluetooth does > not set hci socket to the non-blocking mode. however, > bt_devsend/recv() can be used with the hci socket that was created > outside of libbluetooth. Yes, thats the case I meant - actually I see the manpage says it should be used with socket created by bt_devopen() but in the case where a socket has NBIO set, bt_devrecv() will end up crazyfast looping (==bad) rather than do poll/return as read() normally would if there is no data. > [....] > > > + if (n == 0) > > + return (0); > > + > > > > the read() in bt_devrecv() can return 0 for EOF at least. ok it shouldn't > > happen but do you think it would be proper to return it? (or call it an > > error? I dunno) > > can it really return 0? i mean specifically when reading from > bluetooth socket not in general. in any case the existing code will > return EIO, i.e. error. granted, it will try to parse data in buf, > but it will always fail if n == 0. Well I thought perhaps if a (eg) USB device was removed but it turns out on NetBSD that doesn't cause the socket to EOF, it will just error out on sending, perhaps I'm being too careful with the edge cases.. > > @@ -302,10 +307,11 @@ bt_devreq(int s, struct bt_devreq *r, ti > > if (e->event == r->event) { > > if (r->rlen >= n) { > > r->rlen = n; > > memcpy(r->rparam, e + 1, r->rlen); > > } > > + /* else what? */ > > > > these three locations in bt_devreq() I'm not sure what should happen if > > the provided buffer was not big enough. I suggest the following construct > > instead: > > > > if (r->rlen > n) > > r->rlen = n; > > > > if (r->rlen > 0) > > memcpy(r->rparam, ..., r->rlen); > > > > which gives them as much as they asked for and discards the rest, how > > would that look? > > i did not really know what to do here. practically, this just should > not happen. caller is expected to know how big return parameters are > and pass appropriately sized buffer. if the caller really does not > care about return parameters, then no buffer should be passed. > returning something that is incomplete is a bit broken, imo. i > actually wrote the code like you suggested, but then decided not to do > it this way. cant remember why :) i also considered to return EMSGSIZE > in this case, but then deiced not do to it either. again i cant recall > the exact reason :) > > since this is a relatively minor issue, lets agree on something and > move on. i could go either way. Well, there was a case of bad bluetooth device I saw mentioned once that gives the inquiry_rssi_result with the wrong packet size but I can't remember the details, perhaps you are right - in fact bt_devrecv() explicitly makes sure that you have the complete packet so perhaps this should just be the same. I think it should probably return an error (EIO) though? eg if (r->rlen >= n) { r->rlen = n; memcpy(r->rparam, ..., r->rlen); } else if (r->rlen > 0) { error = EIO; goto out; } > > Also, I'm thinking of the case where r->event=0 but a command_status is > > returned. If status != 0, an error is produced but if status == 0 then we > > should set rlen = 0 and return success? > > what is wrong with the existing code? it simply returns status code in > the return parameters and let caller deal with it. why give special > treatment to status == 0 code? as far as bt_devreq() is concern, > request has completed, i.e. we send something to the device and we > got something back. since caller gave us no specifics (i.e. r->event > == 0), caller should deal with the return parameters. No I think you right I was misreading that, too many nestings :) > > @@ -504,10 +510,16 @@ wait_for_more: > > > > case NG_HCI_EVENT_INQUIRY_RESULT: > > ir = (ng_hci_inquiry_response *)(ep + 1); > > > > for (n = 0; n < MIN(ep->num_responses, num_rsp); n ++) { > > > > I found while writing the inquiry routine in btconfig(8) that some devices > > don't filter repeat addresses properly (or maybe its that some devices > > continue to respond, I've seen that too). Perhaps its worth handling that > > case inside the bt_devinquiry() function by discarding dupes? > > yes, i've seen that too. broadcom chips (at least in my case) have > this behavior. how do you propose to detect the dupes? using bd_addr > only? or match all/some parameters as well? i think it would be ok to > remove dupes. No just check bdaddr as it should be the same device. I've come up with the following function to add results to the list.. to be called with whichever data is present in relevant response and it overwrites the earlier entry in case anything changed. static void bt__devresult(struct bt_devinquiry *ii, int *count, bdaddr_t *ba, uint8_t psrm, uint8_t pspm, uint8_t *cl, uint16_t co, int8_t rssi, uint8_t *data) { int n; for (n = 0; n < *count; n++) if (bdaddr_same(&ii[n].bdaddr, ba)) break; bdaddr_copy(&ii[n].bdaddr, ba); if (cl != NULL) memcpy(ii[n].dev_class, cl, HCI_CLASS_SIZE); ii[n].pscan_rep_mode = psrm; ii[n].pscan_period_mode = pspm; ii[n].clock_offset = le16toh(co); ii[n].rssi = rssi; if (data != NULL) memcpy(ii[n].data, data, 240); if (n == *count) (*count)++; } (I don't really like massive arglists but its better than duplicating the code three times for inquiry_result, rssi_result and extended_result) > > @@ -551,11 +563,11 @@ bt_devinfo(struct bt_devinfo *di) > > return (-1); > > } > > > > s = bt_devopen(di->devname); > > if (s < 0) > > return (-1); > > > > I'm not sure if in FreeBSD you can connect() to a device that is not > > marked up, but in NetBSD you can't. In any case, there is information in > > the devinfo structure that is only available from activated devices so it > > may fail? > > in freebsd, you can. bind()/connect() just sets device name in > socket's pcb. in fact, in freebsd, you can bind/connect() hci socket > to anything :) yeah I let bind do any address since if it doesn't exist then you won't get any messages but connect seemed wrong to connect to nothing. sendto() also fails if the destination is unknown.. I presume that for inactive devices things like features, bdaddr and buffer_size results will just be nil? > > This really relates to bt_devenum() as below, are we counting 'active' > > devices or 'all' devices, as you ignored errors? > > in freebsd, we return the list of netgraph nodes. that is, device may > be present (node exists) but not 'up'. that is what 'state' parameter > in devinfo structure is telling you. so, in freebsd, devenum() will > return the list of all devices. Mm, I've fixed bt_devinfo() so it will work for inactive devices, will think about the devenum some more. What is the 'state' parameter containing is it just 0 = down, 1 = up or is there more? I think devenum should probably return all devs as caller can check the status but I'm not sure if its useful to have a socket connected to an empty device and know no details in the down case.. what happens if you send hci commands to a down device, nothing? iain From doconnor at gsoft.com.au Sat May 16 05:40:42 2009 From: doconnor at gsoft.com.au (Daniel O'Connor) Date: Sat May 16 05:40:49 2009 Subject: btpand example In-Reply-To: References: <200905141438.17380.doconnor@gsoft.com.au> Message-ID: <200905161507.34845.doconnor@gsoft.com.au> On Fri, 15 May 2009, Maksim Yevmenkin wrote: > Daniel, > > > I just got btpand working with my phone (Samsung Omnia i900 - WinMo > > 6.1 based) and here's what I did.. > > cool! thank for reporting. > > > Note that unlike the NetBSD example '-d ubt0' or '-d ubt0hci' > > doesn't work as it reports unknown host. I have 'me' in > > /etc/bluetooth/hosts, but that is non-standard (and '-d local' > > doesn't work). > > could you please try this patch? > Index: btpand.c > =================================================================== > --- btpand.c (revision 192109) > +++ btpand.c (working copy) > @@ -101,7 +101,7 @@ > break; > > case 'd': /* local address */ > - if (!bt_aton(optarg, &local_bdaddr)) { > + if (!bt_devaddr(optarg, &local_bdaddr)) { > struct hostent *he; > > if ((he = bt_gethostbyname(optarg)) > == NULL) > > === OK this works, thanks! btpand -d ubt0 -s NAP -i tap0 -a pda (and ubt0hci) > > Also, I found the MTU by trial and error, 600 works for me, 650 > > does not. I am guessing this is a bluetooth thing but I'm not > > sure.. If it is would it be possible for btpand to set the MTU? > > sure :) however, like Iain said, it would be interesting to see what > is going on. any chance we could get both hcidump (created with -w > option) and tcpdump? could it be something that has to do with tcp > mss fixup? Hmm, where do I get hcidump from? Also, I just tried it again and now I can set the MTU to 1500 and it works fine.. I have reset my phone in the mean time so maybe it was out of memory or something silly like that.. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 188 bytes Desc: This is a digitally signed message part. Url : http://lists.freebsd.org/pipermail/freebsd-bluetooth/attachments/20090516/548dd454/attachment.pgp From doconnor at gsoft.com.au Sat May 16 05:46:09 2009 From: doconnor at gsoft.com.au (Daniel O'Connor) Date: Sat May 16 05:46:15 2009 Subject: btpand example In-Reply-To: <1242299035.690452.893.nullmailer@galant.ukfsn.org> References: <200905141438.17380.doconnor@gsoft.com.au> <200905141920.47717.doconnor@gsoft.com.au> <1242299035.690452.893.nullmailer@galant.ukfsn.org> Message-ID: <200905161513.43690.doconnor@gsoft.com.au> On Thu, 14 May 2009, Iain Hibbert wrote: > > I found that pinging worked and I could connect to an SSH port but > > they SSH key exchange stalled so I guessed MTU and got lucky. > > Hm, I do manage to use ssh successfully over a btpand/winmobile > link.. > > > I later tried l2ping -s 1500 -a pda and it worked so I'm not sure > > what's going on. > > probably better to try actual ping with larger packet sizes..? > l2ping only tests the bluetooth link. Sorry, I missed a step before, I did try ICMP pings when trying to work it out. 600 was the largest I found (650 was too large) > If you also added a log_debug() to the end of bnep_send() to display > the nw and pkt->len values you might see if lossage was happening at > any particular packet size. There is already a check that the packet > doesn't exceed the MTU of the link though. I can't reproduce the problem now.. Perhaps my phone was out of RAM or something. > > I have done the same operation on the same hardware in Linux and it > > worked without MTU tweaks, however I haven't looked to see what MTU > > it used or anything. > > I do get a weird problem sometimes where incoming ethernet packet > payload is rejected by tap for being oversized. I've never tracked it > down but I'm blaming windows mobile for that because the ethernet > packet probably originates there rather than at the other end of the > GPRS link (I could be wrong) > > eg > > May 2 11:06:36 galant btpand[820]: bnep_recv: received long packet > (type=0x02, proto=0x0800, len=1568) May 2 11:06:36 galant /netbsd: > tap0: discarding oversize frame (len=1582) I haven't seen that [yet] but I've barely used it. > I find this will cause a HTTP transfer to stall but I think ssh > recovers from the lost packet ok. OK. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 188 bytes Desc: This is a digitally signed message part. Url : http://lists.freebsd.org/pipermail/freebsd-bluetooth/attachments/20090516/991dc1ee/attachment.pgp From plunky at rya-online.net Sun May 17 10:21:42 2009 From: plunky at rya-online.net (Iain Hibbert) Date: Sun May 17 10:21:49 2009 Subject: libhci update In-Reply-To: References: <1240386569.369073.696.nullmailer@galant.ukfsn.org> <1242294653.314348.1748.nullmailer@galant.ukfsn.org> <1242322384.832849.4269.nullmailer@galant.ukfsn.org> <1242328962.345875.22296.nullmailer@galant.ukfsn.org> <1242335731.252131.19040.nullmailer@galant.ukfsn.org> Message-ID: <1242555649.223847.3574.nullmailer@galant.ukfsn.org> Hi Max, more queries - in bt_devany_cb() you should perhaps make sure that the device is an enabled one? - I'm thinking that bt_devopen() should have an options argument, in order to pre-set any options such as TIMESTAMP, DIRECTION etc (even NBIO) which will get around the differences in API for that (BlueZ had a weird thing with not supporting SOL_SOCKET, SO_TIMESTAMP even though Linux does I don't know if they fixed it yet) - in bt_devinquiry() we accept (dev == NULL) to mean any device, should that happen in bt_devopen() too? - along this line I wonder if it is possible open a promiscuous socket (eg as used by hcidump) instead of any particular device? (could be dev==NULL I guess, or a PROMISCUOUS option?) I'm not sure how Linux works but on NetBSD you must explicitly bind to 00:00:00:00:00:00 to get that behaviour (IIRC FreeBSD gives it to you by default but I was paranoid :) regards, iain From plunky at rya-online.net Sun May 17 19:05:20 2009 From: plunky at rya-online.net (Iain Hibbert) Date: Sun May 17 19:05:27 2009 Subject: libhci update In-Reply-To: <1242322384.832849.4269.nullmailer@galant.ukfsn.org> References: <1240311202.361300.1366.nullmailer@galant.ukfsn.org> <1240352254.082638.416.nullmailer@galant.ukfsn.org> <1240386569.369073.696.nullmailer@galant.ukfsn.org> <1242294653.314348.1748.nullmailer@galant.ukfsn.org> <1242322384.832849.4269.nullmailer@galant.ukfsn.org> Message-ID: <1242587065.366534.1587.nullmailer@galant.ukfsn.org> On Thu, 14 May 2009, Iain Hibbert wrote: > Ah yes, my bad. I haven't properly looked at the manpage yet (I saw a > spelling mistake earlier but I didn't note it :), found it, iain --- bluetooth.3 22 Apr 2009 15:50:03 -0000 1.10 +++ bluetooth.3 17 May 2009 19:03:34 -0000 @@ -272,7 +272,7 @@ .Pp The .Fn bt_devinfo -function populates prodivded +function populates provided .Vt bt_devinfo structure with the information about given Bluetooth device. The caller is expected to pass Bluetooth device name in the From maksim.yevmenkin at gmail.com Mon May 18 16:01:57 2009 From: maksim.yevmenkin at gmail.com (Maksim Yevmenkin) Date: Mon May 18 16:02:03 2009 Subject: btpand example In-Reply-To: <200905161507.34845.doconnor@gsoft.com.au> References: <200905141438.17380.doconnor@gsoft.com.au> <200905161507.34845.doconnor@gsoft.com.au> Message-ID: On Fri, May 15, 2009 at 10:37 PM, Daniel O'Connor wrote: > On Fri, 15 May 2009, Maksim Yevmenkin wrote: >> Daniel, >> >> > I just got btpand working with my phone (Samsung Omnia i900 - WinMo >> > 6.1 based) and here's what I did.. >> >> cool! thank for reporting. >> >> > Note that unlike the NetBSD example '-d ubt0' or '-d ubt0hci' >> > doesn't work as it reports unknown host. I have 'me' in >> > /etc/bluetooth/hosts, but that is non-standard (and '-d local' >> > doesn't work). >> >> could you please try this patch? [...] > OK this works, thanks! > btpand -d ubt0 -s NAP -i tap0 -a pda > > (and ubt0hci) great! thanks! i've committed it. >> > Also, I found the MTU by trial and error, 600 works for me, 650 >> > does not. I am guessing this is a bluetooth thing but I'm not >> > sure.. If it is would it be possible for btpand to set the MTU? >> >> sure :) however, like Iain said, it would be interesting to see what >> is going on. any chance we could get both hcidump (created with -w >> option) and tcpdump? could it be something that has to do with tcp >> mss fixup? > > Hmm, where do I get hcidump from? from ports comm/hcidump > Also, I just tried it again and now I can set the MTU to 1500 and it > works fine.. > > I have reset my phone in the mean time so maybe it was out of memory or > something silly like that.. hmm... interesting... if/when it happens again could you please get both hci and tcp dumps? thanks, max From maksim.yevmenkin at gmail.com Mon May 18 16:26:35 2009 From: maksim.yevmenkin at gmail.com (Maksim Yevmenkin) Date: Mon May 18 16:26:42 2009 Subject: libhci update In-Reply-To: <1242420574.009085.2429.nullmailer@galant.ukfsn.org> References: <1242294653.314348.1748.nullmailer@galant.ukfsn.org> <1242322384.832849.4269.nullmailer@galant.ukfsn.org> <1242328962.345875.22296.nullmailer@galant.ukfsn.org> <1242335731.252131.19040.nullmailer@galant.ukfsn.org> <1242420574.009085.2429.nullmailer@galant.ukfsn.org> Message-ID: Hi Iain, [...] >> > I think these two should not have EAGAIN because that can be returned if >> > the socket is set to nonblocking and we should just pass it back to the >> > caller rather than looping? >> >> i somewhat disagree. it is true that _internally_ libbluetooth does >> not set hci socket to the non-blocking mode. however, >> bt_devsend/recv() can be used with the hci socket that was created >> outside of libbluetooth. > > Yes, thats the case I meant - actually I see the manpage says it should be > used with socket created by bt_devopen() but in the case where a socket > has NBIO set, bt_devrecv() will end up crazyfast looping (==bad) rather > than do poll/return as read() normally would if there is no data. oh, i see. you are right. we need to remove EAGAIN completely from everywhere in libbluetooth and only check for EINTR. i already have done it in my local tree. [...] >> > @@ -302,10 +307,11 @@ bt_devreq(int s, struct bt_devreq *r, ti >> > if (e->event == r->event) { >> > if (r->rlen >= n) { >> > r->rlen = n; >> > memcpy(r->rparam, e + 1, r->rlen); >> > } >> > + /* else what? */ >> > >> > these three locations in bt_devreq() I'm not sure what should happen if >> > the provided buffer was not big enough. I suggest the following construct >> > instead: >> > >> > if (r->rlen > n) >> > r->rlen = n; >> > >> > if (r->rlen > 0) >> > memcpy(r->rparam, ..., r->rlen); >> > >> > which gives them as much as they asked for and discards the rest, how >> > would that look? >> >> i did not really know what to do here. practically, this just should >> not happen. caller is expected to know how big return parameters are >> and pass appropriately sized buffer. if the caller really does not >> care about return parameters, then no buffer should be passed. >> returning something that is incomplete is a bit broken, imo. i >> actually wrote the code like you suggested, but then decided not to do >> it this way. cant remember why :) i also considered to return EMSGSIZE >> in this case, but then deiced not do to it either. again i cant recall >> the exact reason :) >> >> since this is a relatively minor issue, lets agree on something and >> move on. i could go either way. > > Well, there was a case of bad bluetooth device I saw mentioned once that > gives the inquiry_rssi_result with the wrong packet size but I can't > remember the details, perhaps you are right - in fact bt_devrecv() > explicitly makes sure that you have the complete packet so perhaps this > should just be the same. I think it should probably return an error (EIO) > though? eg > > if (r->rlen >= n) { > r->rlen = n; > memcpy(r->rparam, ..., r->rlen); > } else if (r->rlen > 0) { > error = EIO; > goto out; > } i would prefer EMSGSIZE, i.e. what i've done here locally is == if (r->rlen >= n) { r->rlen = n; memcpy(r->rparam, e + 1, r->rlen); - } + } else if (r->rlen > 0) + error = EMSGSIZE; goto out; == [...] >> > case NG_HCI_EVENT_INQUIRY_RESULT: >> > ir = (ng_hci_inquiry_response *)(ep + 1); >> > >> > for (n = 0; n < MIN(ep->num_responses, num_rsp); n ++) { >> > >> > I found while writing the inquiry routine in btconfig(8) that some devices >> > don't filter repeat addresses properly (or maybe its that some devices >> > continue to respond, I've seen that too). Perhaps its worth handling that >> > case inside the bt_devinquiry() function by discarding dupes? >> >> yes, i've seen that too. broadcom chips (at least in my case) have >> this behavior. how do you propose to detect the dupes? using bd_addr >> only? or match all/some parameters as well? i think it would be ok to >> remove dupes. > > No just check bdaddr as it should be the same device. I've come up with > the following function to add results to the list.. to be called with > whichever data is present in relevant response and it overwrites the > earlier entry in case anything changed. right, lets suppress the dupes in inquiry results. lets only match bd_addr and do not match any other parameters. >> > @@ -551,11 +563,11 @@ bt_devinfo(struct bt_devinfo *di) >> > return (-1); >> > } >> > >> > s = bt_devopen(di->devname); >> > if (s < 0) >> > return (-1); >> > >> > I'm not sure if in FreeBSD you can connect() to a device that is not >> > marked up, but in NetBSD you can't. In any case, there is information in >> > the devinfo structure that is only available from activated devices so it >> > may fail? >> >> in freebsd, you can. bind()/connect() just sets device name in >> socket's pcb. in fact, in freebsd, you can bind/connect() hci socket >> to anything :) > > yeah I let bind do any address since if it doesn't exist then you won't > get any messages but connect seemed wrong to connect to nothing. sendto() > also fails if the destination is unknown.. > > I presume that for inactive devices things like features, bdaddr and > buffer_size results will just be nil? depends what state node is in. there might be some residual data left, however, this really should not happen unless someone is messing with the nodes by hand (basically disconnect netgraph hooks) or intentionally misconfigured the system. in any case, state parameter should be checked first before accessing anything else. i'm guessing we need to define bluetooth device states independent of implementation. in freebsd we have connected, initialized and ready = connected+ready states. connected means that device hook is connected (i.e. device is present). initialized means that we run initialization sequence (get bd_addr, features, etc.). >> > This really relates to bt_devenum() as below, are we counting 'active' >> > devices or 'all' devices, as you ignored errors? >> >> in freebsd, we return the list of netgraph nodes. that is, device may >> be present (node exists) but not 'up'. that is what 'state' parameter >> in devinfo structure is telling you. so, in freebsd, devenum() will >> return the list of all devices. > > Mm, I've fixed bt_devinfo() so it will work for inactive devices, will > think about the devenum some more. What is the 'state' parameter > containing is it just 0 = down, 1 = up or is there more? > > I think devenum should probably return all devs as caller can check the > status but I'm not sure if its useful to have a socket connected to an > empty device and know no details in the down case.. what happens if you > send hci commands to a down device, nothing? like i said, we have connected and initialized states. as long as device is in the 'connected' state we will should a response from it. from your other email. > - in bt_devany_cb() you should perhaps make sure that the device is an > enabled one? what does 'enabled' means? > - I'm thinking that bt_devopen() should have an options argument, in order > to pre-set any options such as TIMESTAMP, DIRECTION etc (even NBIO) > which will get around the differences in API for that (BlueZ had a weird > thing with not supporting SOL_SOCKET, SO_TIMESTAMP even though Linux > does I don't know if they fixed it yet) maybe bt_dev{get,set}opts() ? > - in bt_devinquiry() we accept (dev == NULL) to mean any device, should > that happen in bt_devopen() too? we could. > - along this line I wonder if it is possible open a promiscuous socket > (eg as used by hcidump) instead of any particular device? (could be > dev==NULL I guess, or a PROMISCUOUS option?) I'm not sure how Linux > works but on NetBSD you must explicitly bind to 00:00:00:00:00:00 to > get that behaviour (IIRC FreeBSD gives it to you by default but I was > paranoid :) right, in freebsd we just don't bind socket to anything and use filter to enable all event/packets/etc. this is how we get promiscuous socket. perhaps bt_devopen(NULL) should mean create non-bound socket? thanks, max From plunky at rya-online.net Mon May 18 20:32:17 2009 From: plunky at rya-online.net (Iain Hibbert) Date: Mon May 18 20:32:24 2009 Subject: libhci update In-Reply-To: References: <1242294653.314348.1748.nullmailer@galant.ukfsn.org> <1242322384.832849.4269.nullmailer@galant.ukfsn.org> <1242328962.345875.22296.nullmailer@galant.ukfsn.org> <1242335731.252131.19040.nullmailer@galant.ukfsn.org> <1242420574.009085.2429.nullmailer@galant.ukfsn.org> Message-ID: <1242678678.137958.4773.nullmailer@galant.ukfsn.org> On Mon, 18 May 2009, Maksim Yevmenkin wrote: > in any case, state parameter should be checked first before accessing > anything else. i'm guessing we need to define bluetooth device states > independent of implementation. in freebsd we have connected, initialized > and ready = connected+ready states. connected means that device hook is > connected (i.e. device is present). initialized means that we run > initialization sequence (get bd_addr, features, etc.). Mm, I have a bunch of device flags for this situation. I followed the example of a network interface where it must be enabled to work so you can turn it off and save power (for PCMCIA at least it does that, in USB I don't know if there is a way to turn off the power) #define BTF_UP (1<<0) /* unit is up */ #define BTF_RUNNING (1<<1) /* unit is running */ #define BTF_INIT_BDADDR (1<<5) /* waiting for bdaddr */ #define BTF_INIT_BUFFER_SIZE (1<<6) /* waiting for buffer size */ #define BTF_INIT_FEATURES (1<<7) /* waiting for features */ #define BTF_POWER_UP_NOOP (1<<8) /* should wait for No-op on power up */ #define BTF_INIT_COMMANDS (1<<9) /* waiting for supported commands */ #define BTF_INIT (BTF_INIT_BDADDR \ | BTF_INIT_BUFFER_SIZE \ | BTF_INIT_FEATURES \ | BTF_INIT_COMMANDS) but that can be easily converted to other values (btw BlueZ/Linux seems to provide UP/INIT/RUNNING flags) > > Mm, I've fixed bt_devinfo() so it will work for inactive devices, will > > think about the devenum some more. I fixed that now, it just does the best it can - if the device is not enabled you get an unbound socket (but since sending stuff wouldn't work anyway it probably doesn't matter for now :) > > - in bt_devany_cb() you should perhaps make sure that the device is an > > enabled one? > > what does 'enabled' means? I guess it should wait until it finds a 'connected' device then. Otherwise if there are N devices but the first has just been plugged in, such an inquiry may fail. (its one of those edge cases :) { if ((di->state & BTF_UP)) { memcpy(arg, di->devname, HCI_DEVNAME_SIZE); return 1; } return 0; } > > - I'm thinking that bt_devopen() should have an options argument, in order > > to pre-set any options such as TIMESTAMP, DIRECTION etc (even NBIO) > > which will get around the differences in API for that (BlueZ had a weird > > thing with not supporting SOL_SOCKET, SO_TIMESTAMP even though Linux > > does I don't know if they fixed it yet) > > maybe bt_dev{get,set}opts() ? Well, I think a flags/options arg is simpler (very rare would anybody want to change the options during the lifetime of a socket?) Actually, I thought about this some more and found another problem in that bt_devrecv() does not have any way to extract the control messages. > > - in bt_devinquiry() we accept (dev == NULL) to mean any device, should > > that happen in bt_devopen() too? > > we could. > > > - along this line I wonder if it is possible open a promiscuous socket > > (eg as used by hcidump) instead of any particular device? (could be > > dev==NULL I guess, or a PROMISCUOUS option?) I'm not sure how Linux > > works but on NetBSD you must explicitly bind to 00:00:00:00:00:00 to > > get that behaviour (IIRC FreeBSD gives it to you by default but I was > > paranoid :) > > right, in freebsd we just don't bind socket to anything and use filter > to enable all event/packets/etc. this is how we get promiscuous > socket. The thing I didn't like about that is that you might get messages that you think came from your bound device but in fact they came from some other.. > perhaps bt_devopen(NULL) should mean create non-bound socket? Hmm, need to think about it some - again, bt_devrecv() does not have any way to retreive the socket address, so it would need to be declared that the descriptor bt_devopen() returns is a socket handle and using sendto/recvfrom/sendmsg/recvmsg etc is ok in that case. That means that a system that uses a device node instead of a socket for HCI cannot use the API. Perhaps not a problem? I prefer bt_devopen(NULL) to mean 'receive messages from all devices' rather than 'find first device' though.. iain From doconnor at gsoft.com.au Wed May 20 08:03:30 2009 From: doconnor at gsoft.com.au (Daniel O'Connor) Date: Wed May 20 08:03:37 2009 Subject: btpand example In-Reply-To: References: <200905141438.17380.doconnor@gsoft.com.au> <200905161507.34845.doconnor@gsoft.com.au> Message-ID: <200905201733.25859.doconnor@gsoft.com.au> On Tue, 19 May 2009, Maksim Yevmenkin wrote: > > OK this works, thanks! > > btpand -d ubt0 -s NAP -i tap0 -a pda > > > > (and ubt0hci) > > great! thanks! i've committed it. Thanks. > > Hmm, where do I get hcidump from? > > from ports comm/hcidump Ahah, it's installed now! > > I have reset my phone in the mean time so maybe it was out of > > memory or something silly like that.. > > hmm... interesting... if/when it happens again could you please get > both hci and tcp dumps? Sure. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 188 bytes Desc: This is a digitally signed message part. Url : http://lists.freebsd.org/pipermail/freebsd-bluetooth/attachments/20090520/3747324e/attachment.pgp From plunky at rya-online.net Wed May 20 08:18:41 2009 From: plunky at rya-online.net (Iain Hibbert) Date: Wed May 20 08:18:48 2009 Subject: libhci update In-Reply-To: <1242587065.366534.1587.nullmailer@galant.ukfsn.org> References: <1240311202.361300.1366.nullmailer@galant.ukfsn.org> <1240352254.082638.416.nullmailer@galant.ukfsn.org> <1240386569.369073.696.nullmailer@galant.ukfsn.org> <1242294653.314348.1748.nullmailer@galant.ukfsn.org> <1242322384.832849.4269.nullmailer@galant.ukfsn.org> <1242587065.366534.1587.nullmailer@galant.ukfsn.org> Message-ID: <1242807471.849053.801.nullmailer@galant.ukfsn.org> On Sun, 17 May 2009, Iain Hibbert wrote: > On Thu, 14 May 2009, Iain Hibbert wrote: > > > Ah yes, my bad. I haven't properly looked at the manpage yet (I saw a > > spelling mistake earlier but I didn't note it :), > > found it, actually, more :) iain Index: bluetooth.3 =================================================================== RCS file: /home/ncvs/src/lib/libbluetooth/bluetooth.3,v retrieving revision 1.10 diff -u -r1.10 bluetooth.3 --- bluetooth.3 22 Apr 2009 15:50:03 -0000 1.10 +++ bluetooth.3 20 May 2009 08:17:03 -0000 @@ -115,13 +115,13 @@ .Ft void .Fn bt_devfilter_pkt_set "struct bt_devfilter *filter" "uint8_t type" .Ft void -.Fn bt_devfilter_pkt_clt "struct bt_devfilter *filter" "uint8_t type" +.Fn bt_devfilter_pkt_clr "struct bt_devfilter *filter" "uint8_t type" .Ft int .Fn bt_devfilter_pkt_tst "struct bt_devfilter const *filter" "uint8_t type" .Ft void .Fn bt_devfilter_evt_set "struct bt_devfilter *filter" "uint8_t event" .Ft void -.Fn bt_devfilter_evt_clt "struct bt_devfilter *filter" "uint8_t event" +.Fn bt_devfilter_evt_clr "struct bt_devfilter *filter" "uint8_t event" .Ft int .Fn bt_devfilter_evt_tst "struct bt_devfilter const *filter" "uint8_t event" .Ft int @@ -272,7 +272,7 @@ .Pp The .Fn bt_devinfo -function populates prodivded +function populates provided .Vt bt_devinfo structure with the information about given Bluetooth device. The caller is expected to pass Bluetooth device name in the @@ -383,7 +383,7 @@ .Xr bt_devopen 3 . The .Fa opcode -parameter is exppected to be in the host byte order. +parameter is expected to be in the host byte order. The .Fa param and From plunky at rya-online.net Wed May 20 08:41:45 2009 From: plunky at rya-online.net (Iain Hibbert) Date: Wed May 20 08:41:51 2009 Subject: libhci update In-Reply-To: References: <1240386569.369073.696.nullmailer@galant.ukfsn.org> <1242294653.314348.1748.nullmailer@galant.ukfsn.org> <1242322384.832849.4269.nullmailer@galant.ukfsn.org> <1242328962.345875.22296.nullmailer@galant.ukfsn.org> <1242335731.252131.19040.nullmailer@galant.ukfsn.org> Message-ID: <1242808858.879529.970.nullmailer@galant.ukfsn.org> On Fri, 15 May 2009, Maksim Yevmenkin wrote: > however, bt_devsend/recv() can be used with the hci socket that was > created outside of libbluetooth. If this is to be the case (and I like it) then I think bt_devopen() should be documented to return a normal socket handle and have the caller call close() directly rather than bt_devclose() which adds nothing. also, on bt_devsend() can it return ssize_t number of bytes written? (I can't think a reason to want it, but it seems wasteful to discard :) and, going back a bit.. On Sat, Feb 14, 2009 at 1:52 AM, Iain Hibbert wrote: > (size and name could be passed in devinfo?) In the end, I'm not sure I actually like passing the name in the devinfo structure.. means every caller must do a copy rather than just passing it. I think bt_devinfo(name, di) would be better? iain From freebsd-bluetooth at dino.sk Fri May 22 07:23:43 2009 From: freebsd-bluetooth at dino.sk (Milan Obuch) Date: Fri May 22 07:23:49 2009 Subject: Bluetooth keyboard Message-ID: <200905220847.00259.freebsd-bluetooth@dino.sk> Hi, I bought recently a Logitech Cordless MediaBoard Pro keyboard (see page at http://www.logitech.com/index.cfm/gaming/playstation_3/keyboards/devices/3616&cl=za,en for details). Using 8.0, googled a bit and (for summary) did the following: kldload vkbd (I already have ng_ubt loaded via /loader.conf) Now I turned keyboard on and with hccontrol -n ubt0hci inquiry I found my bluetooth address to be 00:07:61:e6:bb:79. Next with bthidcontrol -a 00:07:61:e6:bb:79 query >> /etc/bluetooth/bthidd.conf I put device definition into config file for bthidd. For hcsecd I added following definition into /etc/bluetooth/hcsecd.conf: device {bdaddr 00:07:61:e6:bb:79; name "Logitech Bluetooth Keyboard"; key nokey; pin "9680"; } Configuration ended with bluetooth host definition in /etc/bluetooth/hosts, adding line: btkeyboard 00:07:61:e6:bb:79 Now I started daemons with /etc/rc.d/bthidd start /etc/rc.d/hcsecd start As I tested the keyboard already with Windows on the same machine, it was paired already, so I just need wait a bit until I got kbd2 at vkbd0 on console/in syslog and it works now, both keyboard and touchpad. Now I added hcsecd_enable="YES" bthidd_enable="YES" into /etc/rc.conf to start on reboot and that's it. When I turn on bluetooth module on my machine and bluetooth keyboard, it works. And now two small bugs. There is some resource leakage I think, I am getting more entries logged on console like this: kbd2 at vkbd0 kbd2 at vkbd1 kbd2 at vkbd2 kbd2 at vkbd3 kbd2 at vkbd4 This occures when I turn keyboard off and later on again. I have no other bluetooth keyboard here, so I think somehow link got broken and after re-connect new instance got created, but system should note it's the same device (uses the same address) and reuse the first one... Second, I am getting repeatedly logged in syslog Got short message (1 bytes) on Interrupt channel from 00:07:61:e6:bb:79 Maybe it's just cosmetic, but it repeats too often for me. What I would like to be able, but do not know now, is using additional keys on this keyboard. It was designed for PlayStation3, the kayes are on top left, labelled Menu, <<, >/||, >> and BD-DVD menu. I appended device definition to this message, maybe someone could decipher it and recommend something to try... Thank for work on bluetooth stack, hopefully my summary could be usefull for someone else, even if it turns out to be really simple... Regards, Milan /etc/bluetooth/bthidd.conf device { bdaddr 00:07:61:e6:bb:79; control_psm 0x11; interrupt_psm 0x13; reconnect_initiate true; battery_power false; normally_connectable false; hid_descriptor { 0x05 0x01 0x09 0x02 0xa1 0x01 0x85 0x02 0x09 0x01 0xa1 0x00 0x05 0x09 0x19 0x01 0x29 0x08 0x15 0x00 0x25 0x01 0x75 0x01 0x95 0x08 0x81 0x02 0x05 0x01 0x09 0x30 0x09 0x31 0x16 0x01 0xf8 0x26 0xff 0x07 0x75 0x0c 0x95 0x02 0x81 0x06 0x09 0x38 0x15 0x81 0x25 0x7f 0x75 0x08 0x95 0x01 0x81 0x06 0x05 0x0c 0x0a 0x38 0x02 0x81 0x06 0x05 0x09 0x19 0x09 0x29 0x10 0x15 0x00 0x25 0x01 0x95 0x08 0x75 0x01 0x81 0x02 0xc0 0xc0 0x05 0x01 0x09 0x06 0xa1 0x01 0x85 0x01 0x75 0x01 0x95 0x08 0x05 0x07 0x19 0xe0 0x29 0xe7 0x15 0x00 0x25 0x01 0x81 0x02 0x95 0x01 0x75 0x08 0x81 0x03 0x95 0x01 0x75 0x08 0x91 0x03 0x95 0x06 0x75 0x08 0x15 0x00 0x26 0xff 0x00 0x05 0x07 0x19 0x00 0x29 0xff 0x81 0x00 0xc0 0x05 0x0c 0x09 0x01 0xa1 0x01 0x85 0x03 0x75 0x10 0x95 0x02 0x15 0x01 0x26 0xff 0x02 0x19 0x01 0x2a 0xff 0x02 0x81 0x60 0xc0 0x05 0x0c 0x09 0x01 0xa1 0x01 0x85 0xac 0x05 0x01 0x09 0x06 0xa1 0x02 0x05 0x06 0x09 0x20 0x15 0x00 0x25 0xff 0x75 0x08 0x95 0x01 0x81 0x02 0xc0 0xc0 0x05 0x01 0x09 0x80 0xa1 0x01 0x85 0x04 0x15 0x00 0x25 0x01 0x75 0x01 0x95 0x01 0x09 0x82 0x81 0x02 0x95 0x01 0x75 0x07 0x81 0x03 0xc0 0x05 0x0c 0x09 0x01 0xa1 0x01 0x85 0xad 0x05 0x01 0x09 0x06 0xa1 0x02 0x06 0x00 0xff 0x25 0x01 0x75 0x01 0x95 0x02 0x0a 0x03 0xfe 0x0a 0x04 0xfe 0x81 0x02 0x95 0x06 0x81 0x03 0xc0 0xc0 0x05 0x0c 0x09 0x01 0xa1 0x01 0x85 0xff 0x05 0x06 0x15 0x00 0x25 0x02 0x95 0x01 0x75 0x02 0x19 0x24 0x29 0x26 0x81 0x40 0x75 0x06 0x81 0x01 0xc0 0x06 0x00 0xff 0x09 0x01 0xa1 0x01 0x85 0x10 0x75 0x08 0x95 0x06 0x15 0x00 0x26 0xff 0x00 0x09 0x01 0x81 0x00 0x09 0x01 0x91 0x00 0xc0 }; } From freebsd-bluetooth at dino.sk Fri May 22 10:03:17 2009 From: freebsd-bluetooth at dino.sk (Milan Obuch) Date: Fri May 22 10:03:24 2009 Subject: Bluetooth keyboard In-Reply-To: <200905220847.00259.freebsd-bluetooth@dino.sk> References: <200905220847.00259.freebsd-bluetooth@dino.sk> Message-ID: <200905221203.03590.freebsd-bluetooth@dino.sk> On Friday 22 May 2009 08:46:59 Milan Obuch wrote: > Hi, > I bought recently a Logitech Cordless MediaBoard Pro keyboard > [ snip ] Small addendum: After a while I decided to test it on 7-STABLE (three weeks old), and it works. I added ng_ubt_load=YES into /boot/loader.conf, then I added hcsecd_enable="YES" bthidd_enable="YES" into /etc/rc.conf. Files in /etc/bluetooth directory or their relevant parts I transferred (see original mail for details) and after boot it works. Some more observations. It looks like this keyboard goes into sleep mode when not used, When awaken, short message is logged often, when powered off, then on again, similar situation occurs, and additional vkbd instance is created. In syslog, control connection close and accepted new control and interrupt connection from my keyboard is recorded. Regards, Milan From plunky at rya-online.net Mon May 25 12:48:07 2009 From: plunky at rya-online.net (Iain Hibbert) Date: Mon May 25 12:48:14 2009 Subject: FBSD bt gammu In-Reply-To: <45283323@srv.sem.ipt.ru> References: <20070816105005.GA24403@harmless.hu> <20070817113053.GA61263@harmless.hu> <20070818133634.GA1448@harmless.hu> <20070902193327.15488.qmail@stuge.se> <45283323@srv.sem.ipt.ru> Message-ID: <1243255626.298740.6650.nullmailer@galant.ukfsn.org> On Thu, 6 Sep 2007, Boris Samorodov wrote: > On Wed, 5 Sep 2007 09:56:26 -0700 Maksim Yevmenkin wrote: > > > please modify cmake scripts so it can properly detect bluetooth on freebsd > > Michal incorporated all FreeBSD patches to svn version. All bluetooth > functions except channel searching (switched off for FreeBSD) should > work fine. > > Those who are interested may test it and give a feedback. > Those who are interested may look into channel searching problem and > produce patches. ;-) Hi Boris, This was some time ago but I have just rewritten the FBSD support in gammu to be generic BSD support and implemented channel searching using the new device access (already in FreeBSD) and service discovery (which Max is working on porting) routines. I wonder if you can validate that my work doesn't cause any regressions on FreeBSD? The attached patch adds cmake/FindBSDBluetooth.cmake libgammu/device/bluetoth/blue_bsd.c libgammu/device/bluetoth/blue_bsd.h and converts the build to use those files instead of the 'fbsd' versions, which can be removed, and the cmake framework will enable the channel searching if the new API is present. I'm not quite ready to commit the bt_dev stuff into NetBSD but will push this upstream after we have all caught up. I'm not sure if it will be worth putting the patches into ports or not, will leave that up to you. iain -------------- next part -------------- diff -Nru orig/gammu-1.24.0/CMakeLists.txt gammu-1.24.0/CMakeLists.txt --- orig/gammu-1.24.0/CMakeLists.txt 2009-04-15 14:39:54.000000000 +0100 +++ gammu-1.24.0/CMakeLists.txt 2009-05-25 13:04:36.000000000 +0100 @@ -270,12 +270,12 @@ set(BLUETOOTH_SEARCH TRUE) message(STATUS "Using BlueZ stack") endif (BLUEZ_FOUND) - find_package (FBSDBluetooth) - if (FBSD_BLUE_FOUND) + find_package (BSDBluetooth) + if (BSD_BLUE_FOUND) set(BLUETOOTH_FOUND ON) - set(BLUETOOTH_SEARCH FALSE) - message(STATUS "Using FreeBSD Bluetooth stack") - endif (FBSD_BLUE_FOUND) + check_library_exists(bluetooth sdp_service_search_attribute "" BLUETOOTH_SEARCH) + message(STATUS "Using BSD Bluetooth stack") + endif (BSD_BLUE_FOUND) find_package (OSXBluetooth) if (OSX_BLUE_FOUND) set(BLUETOOTH_FOUND ON) @@ -360,11 +360,11 @@ endif (NOT "${BLUEZ_LIBRARIES}" STREQUAL "") endif (BLUEZ_FOUND) -if (FBSD_BLUE_FOUND) - if (NOT "${FBSD_BLUE_LIBRARIES}" STREQUAL "") - set (GAMMU_LIBS "${GAMMU_LIBS} -l${FBSD_BLUE_LIBRARIES}") - endif (NOT "${FBSD_BLUE_LIBRARIES}" STREQUAL "") -endif (FBSD_BLUE_FOUND) +if (BSD_BLUE_FOUND) + if (NOT "${BSD_BLUE_LIBRARIES}" STREQUAL "") + set (GAMMU_LIBS "${GAMMU_LIBS} -l${BSD_BLUE_LIBRARIES}") + endif (NOT "${BSD_BLUE_LIBRARIES}" STREQUAL "") +endif (BSD_BLUE_FOUND) if (ICONV_FOUND) if (NOT "${ICONV_LIBRARIES}" STREQUAL "") diff -Nru orig/gammu-1.24.0/cmake/FindBSDBluetooth.cmake gammu-1.24.0/cmake/FindBSDBluetooth.cmake --- orig/gammu-1.24.0/cmake/FindBSDBluetooth.cmake 1970-01-01 01:00:00.000000000 +0100 +++ gammu-1.24.0/cmake/FindBSDBluetooth.cmake 2009-05-22 09:48:26.000000000 +0100 @@ -0,0 +1,35 @@ +# - Finds Bluetooth library on BSD +# This module defines +# BSD_BLUE_INCLUDE_DIR, where to find bluetooth.h +# BSD_BLUE_LIBRARIES, the libraries needed to use BSD Bluetooth. +# BSD_BLUE_FOUND, If false, do not try to use BSD Bluetooth. +# +# Copyright (c) 2007, Michal Cihar, +# +# vim: expandtab sw=4 ts=4 sts=4: + +if (NOT DEFINED BSD_BLUE_FOUND) + if (NOT CROSS_MINGW) + find_path(BSD_BLUE_INCLUDE_DIR NAMES bluetooth.h + PATHS + /usr/include + /usr/local/include + ) + + find_library(BSD_BLUE_LIBRARIES NAMES bluetooth + PATHS + /usr/lib + /usr/local/lib + ) + + if(BSD_BLUE_INCLUDE_DIR AND BSD_BLUE_LIBRARIES) + set(BSD_BLUE_FOUND TRUE CACHE INTERNAL "BSD Bluetooth found") + message(STATUS "Found BSD Bluetooth: ${BSD_BLUE_INCLUDE_DIR}, ${BSD_BLUE_LIBRARIES}") + else(BSD_BLUE_INCLUDE_DIR AND BSD_BLUE_LIBRARIES) + set(BSD_BLUE_FOUND FALSE CACHE INTERNAL "BSD Bluetooth found") + message(STATUS "BSD Bluetooth not found.") + endif(BSD_BLUE_INCLUDE_DIR AND BSD_BLUE_LIBRARIES) + + mark_as_advanced(BSD_BLUE_INCLUDE_DIR BSD_BLUE_LIBRARIES) + endif (NOT CROSS_MINGW) +endif (NOT DEFINED BSD_BLUE_FOUND) diff -Nru orig/gammu-1.24.0/cmake/templates/gammu-config.h.cmake gammu-1.24.0/cmake/templates/gammu-config.h.cmake --- orig/gammu-1.24.0/cmake/templates/gammu-config.h.cmake 2009-03-17 15:01:11.000000000 +0000 +++ gammu-1.24.0/cmake/templates/gammu-config.h.cmake 2009-05-22 09:49:28.000000000 +0100 @@ -322,8 +322,8 @@ /* Do we have libusb-1.0 ? */ #cmakedefine LIBUSB_FOUND -/* Will be used FreeBSD Bluetooth stack ? */ -#cmakedefine FBSD_BLUE_FOUND +/* Will be used BSD Bluetooth stack ? */ +#cmakedefine BSD_BLUE_FOUND /* Will be used OSX Bluetooth stack ? */ #cmakedefine OSX_BLUE_FOUND diff -Nru orig/gammu-1.24.0/libgammu/CMakeLists.txt gammu-1.24.0/libgammu/CMakeLists.txt --- orig/gammu-1.24.0/libgammu/CMakeLists.txt 2009-03-18 09:16:38.000000000 +0000 +++ gammu-1.24.0/libgammu/CMakeLists.txt 2009-05-22 09:46:23.000000000 +0100 @@ -76,9 +76,9 @@ if (LIBUSB_FOUND) list (APPEND LIBRARY_SRC device/usb/usb.c) endif (LIBUSB_FOUND) -if (FBSD_BLUE_FOUND) - list (APPEND LIBRARY_SRC device/bluetoth/blue_fbsd.c) -endif (FBSD_BLUE_FOUND) +if (BSD_BLUE_FOUND) + list (APPEND LIBRARY_SRC device/bluetoth/blue_bsd.c) +endif (BSD_BLUE_FOUND) if (OSX_BLUE_FOUND) list (APPEND LIBRARY_SRC device/bluetoth/blue_osx.c) endif (OSX_BLUE_FOUND) @@ -126,10 +126,10 @@ include_directories (${LIBUSB_INCLUDE_DIR}) endif (LIBUSB_FOUND) -if (FBSD_BLUE_FOUND) - target_link_libraries (libGammu ${FBSD_BLUE_LIBRARIES}) - include_directories (${FBSD_BLUE_INCLUDE_DIR}) -endif (FBSD_BLUE_FOUND) +if (BSD_BLUE_FOUND) + target_link_libraries (libGammu ${BSD_BLUE_LIBRARIES}) + include_directories (${BSD_BLUE_INCLUDE_DIR}) +endif (BSD_BLUE_FOUND) if (OSX_BLUE_FOUND) target_link_libraries (libGammu ${OSX_BLUE_LIBS}) diff -Nru orig/gammu-1.24.0/libgammu/device/bluetoth/blue_bsd.c gammu-1.24.0/libgammu/device/bluetoth/blue_bsd.c --- orig/gammu-1.24.0/libgammu/device/bluetoth/blue_bsd.c 1970-01-01 01:00:00.000000000 +0100 +++ gammu-1.24.0/libgammu/device/bluetoth/blue_bsd.c 2009-05-25 13:37:40.000000000 +0100 @@ -0,0 +1,265 @@ +/*- + * Copyright (c) 2009 Iain Hibbert + * 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 ``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 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. + */ + +#include "../../gsmstate.h" + +#ifdef GSM_ENABLE_BLUETOOTHDEVICE +#ifdef BSD_BLUE_FOUND + +#include +#include + +#include +#include +#include +#include +#include +#include +#include +#include + +#include "../../gsmcomon.h" +#include "../devfunc.h" +#include "bluetoth.h" + +/* + * Handle FreeBSD compatibility + */ +#ifndef BTPROTO_RFCOMM +#define BTPROTO_RFCOMM BLUETOOTH_PROTO_RFCOMM +#define BDADDR_ANY NG_HCI_BDADDR_ANY +#define sockaddr_bt sockaddr_rfcomm +#define bt_len rfcomm_len +#define bt_family rfcomm_family +#define bt_channel rfcomm_channel +#define bt_bdaddr rfcomm_bdaddr +#endif + +static GSM_Error bluetooth_open(GSM_StateMachine *s, bdaddr_t *bdaddr, int channel) +{ + GSM_Device_BlueToothData *d = &s->Device.Data.BlueTooth; + struct sockaddr_bt sa; + int fd; + + memset(&sa, 0, sizeof(sa)); + sa.bt_len = sizeof(sa); + sa.bt_family = AF_BLUETOOTH; + + smprintf(s, "Connecting to RF channel %i\n", channel); + + fd = socket(PF_BLUETOOTH, SOCK_STREAM, BTPROTO_RFCOMM); + if (fd < 0) { + smprintf(s, "Can't create socket\n"); + return ERR_DEVICENODRIVER; + } + + bdaddr_copy(&sa.bt_bdaddr, BDADDR_ANY); + + if (bind(fd, (struct sockaddr *)&sa, sizeof(sa)) < 0) { + smprintf(s, "Can't bind socket: %s\n", strerror(errno)); + close(fd); + return ERR_DEVICEOPENERROR; + } + + sa.bt_channel = channel; + bdaddr_copy(&sa.bt_bdaddr, bdaddr); + + if (connect(fd, (struct sockaddr *)&sa, sizeof(sa)) < 0) { + smprintf(s, "Can't connect to %s: %s\n", bt_ntoa(bdaddr, NULL), strerror(errno)); + close(fd); + return ERR_DEVICEOPENERROR; + } + + d->hPhone = fd; + return ERR_NONE; +} + +GSM_Error bluetooth_connect(GSM_StateMachine *s, int port, char *device) +{ + bdaddr_t bdaddr; + struct hostent *he = NULL; + + if (!bt_aton(device, &bdaddr)) { + if ((he = bt_gethostbyname(device)) == NULL) { + smprintf(s, "%s: %s\n", device, hstrerror(h_errno)); + return ERR_UNKNOWN; + } + + bdaddr_copy(&bdaddr, (bdaddr_t *)he->h_addr); + } + + return bluetooth_open(s, &bdaddr, port); +} + +#ifdef BLUETOOTH_RF_SEARCHING + +static int bluetooth_channel(sdp_data_t *value) +{ + sdp_data_t pdl, seq; + uintmax_t channel; + + sdp_get_alt(value, value); /* strip any alt container */ + + while (sdp_get_seq(value, &pdl)) { + if (sdp_get_seq(&pdl, &seq) + && sdp_match_uuid16(&seq, SDP_UUID_PROTOCOL_L2CAP) + && sdp_get_seq(&pdl, &seq) + && sdp_match_uuid16(&seq, SDP_UUID_PROTOCOL_RFCOMM) + && sdp_get_uint(&seq, &channel) + && channel >= 1 && channel <= 30) + return channel; + } + + return -1; +} + +static char *bluetooth_service(sdp_data_t *value) +{ + char *str; + size_t len; + + if (!sdp_get_str(value, &str, &len)) + return NULL; + + return strndup(str, len); +} + +static GSM_Error bluetooth_search(GSM_StateMachine *s, bdaddr_t *bdaddr) +{ + sdp_data_t rec, rsp, ssp, value; + uint8_t buf[3]; + uint16_t attr; + sdp_session_t ss; + int ch, channel, sc, score; + char *sv; + + smprintf(s, "Searching for services on %s\n", bt_ntoa(bdaddr, NULL)); + + ss = sdp_open(NULL, bdaddr); + if (ss == NULL) { + smprintf(s, "SDP Connection failed: %s\n", strerror(errno)); + return ERR_TIMEOUT; + } + + ssp.next = buf; + ssp.end = buf + sizeof(buf); + sdp_put_uuid16(&ssp, SDP_UUID_PROTOCOL_RFCOMM); + ssp.end = ssp.next; + ssp.next = buf; + + if (!sdp_service_search_attribute(ss, &ssp, NULL, &rsp)) { + smprintf(s, "SDP Service Search Attribute failed: %s\n", strerror(errno)); + sdp_close(ss); + return ERR_UNKNOWN; + } + + channel = -1; + score = 0; + + while (sdp_get_seq(&rsp, &rec)) { + ch = -1; + sv = NULL; + + while (sdp_get_attr(&rec, &attr, &value)) { + switch (attr) { + case SDP_ATTR_PROTOCOL_DESCRIPTOR_LIST: + ch = bluetooth_channel(&value); + break; + + case SDP_ATTR_PRIMARY_LANGUAGE_BASE_ID + SDP_ATTR_SERVICE_NAME_OFFSET: + sv = bluetooth_service(&value); + break; + + default: + break; + } + } + + if (ch != -1) { + smprintf(s, " Channel %i", ch); + if (sv != NULL) { + sc = bluetooth_checkservicename(s, sv); + smprintf(s, " - \"%s\" (score=%d)", sv, sc); + if (sc > score) { + score = sc; + channel = ch; + } + } + smprintf(s, "\n"); + } + + free(sv); + } + + sdp_close(ss); + + if (channel == -1) { + smprintf(s, "No suitable service found!\n"); + return ERR_NOTSUPPORTED; + } + + return bluetooth_open(s, bdaddr, channel); +} + +GSM_Error bluetooth_findchannel(GSM_StateMachine *s) +{ + char *device = s->CurrentConfig->Device; + bdaddr_t bdaddr; + struct hostent *he; + struct bt_devinquiry *ii; + int n; + + if (bt_aton(device, &bdaddr)) + return bluetooth_search(s, &bdaddr); + + if ((he = bt_gethostbyname(device)) != NULL) + return bluetooth_search(s, (bdaddr_t *)he->h_addr); + + smprintf(s, "Device \"%s\" unknown. Starting inquiry..\n"); + + if ((n = bt_devinquiry(NULL, 10, 20, &ii)) == -1) { + smprintf(s, "Inquiry failed: %s\n", strerror(errno)); + return ERR_UNKNOWN; + } + + smprintf(s, "Found %d devices\n", n); + + while (n-- > 0) { + if (bluetooth_search(s, &ii->bdaddr) == ERR_NONE) + return ERR_NONE; + + ii++; + } + + return ERR_UNKNOWN; +} + +#endif +#endif +#endif + +/* How should editor hadle tabs in this file? Add editor commands here. + * vim: noexpandtab sw=8 ts=8 sts=8: + */ diff -Nru orig/gammu-1.24.0/libgammu/device/bluetoth/blue_bsd.h gammu-1.24.0/libgammu/device/bluetoth/blue_bsd.h --- orig/gammu-1.24.0/libgammu/device/bluetoth/blue_bsd.h 1970-01-01 01:00:00.000000000 +0100 +++ gammu-1.24.0/libgammu/device/bluetoth/blue_bsd.h 2009-05-25 13:35:44.000000000 +0100 @@ -0,0 +1 @@ +/* empty file */ diff -Nru orig/gammu-1.24.0/libgammu/device/bluetoth/bluetoth.c gammu-1.24.0/libgammu/device/bluetoth/bluetoth.c --- orig/gammu-1.24.0/libgammu/device/bluetoth/bluetoth.c 2009-02-12 14:19:01.000000000 +0000 +++ gammu-1.24.0/libgammu/device/bluetoth/bluetoth.c 2009-05-22 09:44:29.000000000 +0100 @@ -21,8 +21,8 @@ #ifdef BLUEZ_FOUND # include "bluez.h" #endif -#ifdef FBSD_BLUE_FOUND -# include "blue_fbsd.h" +#ifdef BSD_BLUE_FOUND +# include "blue_bsd.h" #endif #ifdef OSX_BLUE_FOUND # include "blue_osx.h"