From owner-freebsd-bluetooth@FreeBSD.ORG Sun May 10 15:49:09 2009 Return-Path: Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4F7B9106566B for ; Sun, 10 May 2009 15:49:09 +0000 (UTC) (envelope-from info@lottery.co.uk) Received: from hm1707.locaweb.com.br (shared-2.locaweb.com.br [200.234.214.155]) by mx1.freebsd.org (Postfix) with ESMTP id D8AE98FC0C for ; Sun, 10 May 2009 15:49:08 +0000 (UTC) (envelope-from info@lottery.co.uk) Received: from hm1207.locaweb.com.br (hm1207.locaweb.com.br [200.234.200.152]) by hm1707.locaweb.com.br (Postfix) with ESMTP id D1592258440E5 for ; Sun, 10 May 2009 12:32:15 -0300 (BRT) Received: by hm1207.locaweb.com.br (Postfix, from userid 50714) id C5DDD3C17E; Sun, 10 May 2009 12:31:37 -0300 (BRT) X-Locaweb-ID: 63325679646D56794F69426F625445794D4463734948567A5A584A755957316C4F694232595735705957526C5932467A64484A76 To: freebsd-bluetooth@freebsd.org X-PHP-Script: www.vaniadecastro.com.br/zero.php for 196.3.182.250 From: UK NATIONAL LOTTERY MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit Message-Id: <20090510153215.C5DDD3C17E@hm1207.locaweb.com.br> Date: Sun, 10 May 2009 12:31:37 -0300 (BRT) Subject: National Lottery: Your Email Won X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: zonal.anderson-spencer@msn.com List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 May 2009 15:49:09 -0000 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 owner-freebsd-bluetooth@FreeBSD.ORG Thu May 14 05:35:11 2009 Return-Path: Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0D52D106564A for ; Thu, 14 May 2009 05:35:11 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id 774A28FC16 for ; Thu, 14 May 2009 05:35:09 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (inchoate.gsoft.com.au [203.31.81.30]) (authenticated bits=0) by cain.gsoft.com.au (8.13.8/8.13.8) with ESMTP id n4E58Jf3095397 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 14 May 2009 14:38:19 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-bluetooth@freebsd.org Date: Thu, 14 May 2009 14:38:16 +0930 User-Agent: KMail/1.9.10 MIME-Version: 1.0 Message-Id: <200905141438.17380.doconnor@gsoft.com.au> X-UID: 8459 Content-Type: multipart/signed; boundary="nextPart1267344.vNfn3FOOV7"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit X-Spam-Score: -3.498 () ALL_TRUSTED,AWL,BAYES_00 X-Scanned-By: MIMEDefang 2.63 on 203.31.81.10 Subject: btpand example X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2009 05:35:11 -0000 --nextPart1267344.vNfn3FOOV7 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi, I just got btpand working with my phone (Samsung Omnia i900 - WinMo 6.1=20 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=20 work as it reports unknown host. I have 'me' in /etc/bluetooth/hosts,=20 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=20 not. I am guessing this is a bluetooth thing but I'm not sure.. If it=20 is would it be possible for btpand to set the MTU? Please CC me as I'm not on the list, thanks. =2D-=20 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 --nextPart1267344.vNfn3FOOV7 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iD8DBQBKC6dB5ZPcIHs/zowRAlZyAJ9T8QRwHTVwqe6pXN5n821Sd8QaAwCdE3X5 yrefqMLJdoQFWffuZywomfU= =3eS1 -----END PGP SIGNATURE----- --nextPart1267344.vNfn3FOOV7-- From owner-freebsd-bluetooth@FreeBSD.ORG Thu May 14 08:32:47 2009 Return-Path: Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2B3CB1065689 for ; Thu, 14 May 2009 08:32:47 +0000 (UTC) (envelope-from plunky@rya-online.net) Received: from smtp02.one2one.net (smtp02.one2one.net [149.254.192.174]) by mx1.freebsd.org (Postfix) with ESMTP id E16558FC1A for ; Thu, 14 May 2009 08:32:46 +0000 (UTC) (envelope-from plunky@rya-online.net) Received: from [127.0.0.1] (helo=localhost) by localhost.t-mobile.co.uk with esmtp (Exim 4.50) id 1M4WMr-0006Wz-5Z; Thu, 14 May 2009 08:32:41 +0000 Received: from localhost.t-mobile.co.uk ([127.0.0.1]) by localhost (smtpbeckt01 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24593-07; Thu, 14 May 2009 09:32:40 +0100 (BST) Received: from [10.214.182.214] (helo=rya-online.net) by localhost.t-mobile.co.uk with smtp (Exim 4.50) id 1M4WMp-0006Wg-GG; Thu, 14 May 2009 08:32:40 +0000 Received: (nullmailer pid 857 invoked by uid 1000); Thu, 14 May 2009 08:31:52 -0000 Date: Thu, 14 May 2009 09:31:52 +0100 (BST) To: Daniel O'Connor In-Reply-To: <200905141438.17380.doconnor@gsoft.com.au> References: <200905141438.17380.doconnor@gsoft.com.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-Id: <1242289912.789883.948.nullmailer@galant.ukfsn.org> From: Iain Hibbert X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at example.com X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: plunky@rya-online.net X-SA-Exim-Scanned: No (on localhost.t-mobile.co.uk); SAEximRunCond expanded to false Cc: freebsd-bluetooth@freebsd.org Subject: Re: btpand example X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2009 08:32:47 -0000 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 owner-freebsd-bluetooth@FreeBSD.ORG Thu May 14 09:50:52 2009 Return-Path: Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 825ED1065676 for ; Thu, 14 May 2009 09:50:52 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id CF12F8FC16 for ; Thu, 14 May 2009 09:50:51 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (ppp121-45-46-151.lns10.adl2.internode.on.net [121.45.46.151]) (authenticated bits=0) by cain.gsoft.com.au (8.13.8/8.13.8) with ESMTP id n4E9on7Z005164 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 14 May 2009 19:20:49 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: Iain Hibbert Date: Thu, 14 May 2009 19:20:46 +0930 User-Agent: KMail/1.9.10 References: <200905141438.17380.doconnor@gsoft.com.au> <1242289912.789883.948.nullmailer@galant.ukfsn.org> In-Reply-To: <1242289912.789883.948.nullmailer@galant.ukfsn.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2851386.WXdrXRW9Ae"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200905141920.47717.doconnor@gsoft.com.au> X-Spam-Score: -2.387 () AWL,BAYES_00,RDNS_DYNAMIC X-Scanned-By: MIMEDefang 2.63 on 203.31.81.10 Cc: freebsd-bluetooth@freebsd.org Subject: Re: btpand example X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2009 09:50:52 -0000 --nextPart2851386.WXdrXRW9Ae Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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=20 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=20 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=20 worked without MTU tweaks, however I haven't looked to see what MTU it=20 used or anything. =2D-=20 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 --nextPart2851386.WXdrXRW9Ae Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iD8DBQBKC+l35ZPcIHs/zowRAqo2AJ0aHc9Wnzt55nuFAjDYge40Jm5hWQCfVxE+ AOk6lRb67XPNZY609+TGZtw= =A8/U -----END PGP SIGNATURE----- --nextPart2851386.WXdrXRW9Ae-- From owner-freebsd-bluetooth@FreeBSD.ORG Thu May 14 09:51:48 2009 Return-Path: Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3AFCB106564A for ; Thu, 14 May 2009 09:51:48 +0000 (UTC) (envelope-from plunky@rya-online.net) Received: from smtp02.one2one.net (smtp02.one2one.net [149.254.192.174]) by mx1.freebsd.org (Postfix) with ESMTP id C4A2D8FC16 for ; Thu, 14 May 2009 09:51:47 +0000 (UTC) (envelope-from plunky@rya-online.net) Received: from [127.0.0.1] (helo=localhost) by localhost.t-mobile.co.uk with esmtp (Exim 4.50) id 1M4XbL-000104-CW; Thu, 14 May 2009 09:51:43 +0000 Received: from localhost.t-mobile.co.uk ([127.0.0.1]) by localhost (smtpbeckt01 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03829-01; Thu, 14 May 2009 10:51:42 +0100 (BST) Received: from [10.214.182.214] (helo=rya-online.net) by localhost.t-mobile.co.uk with smtp (Exim 4.50) id 1M4XbI-0000zn-FZ; Thu, 14 May 2009 09:51:42 +0000 Received: (nullmailer pid 1567 invoked by uid 1000); Thu, 14 May 2009 09:50:53 -0000 Date: Thu, 14 May 2009 10:50:53 +0100 (BST) To: Maksim Yevmenkin 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> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-Id: <1242294653.314348.1748.nullmailer@galant.ukfsn.org> From: Iain Hibbert X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at example.com X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: plunky@rya-online.net X-SA-Exim-Scanned: No (on localhost.t-mobile.co.uk); SAEximRunCond expanded to false Cc: freebsd-bluetooth@freebsd.org Subject: Re: libhci update X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2009 09:51:48 -0000 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 owner-freebsd-bluetooth@FreeBSD.ORG Thu May 14 11:04:51 2009 Return-Path: Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C26F1106564A for ; Thu, 14 May 2009 11:04:51 +0000 (UTC) (envelope-from plunky@rya-online.net) Received: from smtp02.one2one.net (smtp02.one2one.net [149.254.192.174]) by mx1.freebsd.org (Postfix) with ESMTP id 5F1558FC19 for ; Thu, 14 May 2009 11:04:51 +0000 (UTC) (envelope-from plunky@rya-online.net) Received: from [127.0.0.1] (helo=localhost) by localhost.t-mobile.co.uk with esmtp (Exim 4.50) id 1M4Yk2-0003YR-AS; Thu, 14 May 2009 11:04:46 +0000 Received: from localhost.t-mobile.co.uk ([127.0.0.1]) by localhost (smtpbeckt01 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13579-03; Thu, 14 May 2009 12:04:45 +0100 (BST) Received: from [10.214.182.214] (helo=rya-online.net) by localhost.t-mobile.co.uk with smtp (Exim 4.50) id 1M4Yjz-0003YK-CZ; Thu, 14 May 2009 11:04:45 +0000 Received: (nullmailer pid 2159 invoked by uid 1000); Thu, 14 May 2009 11:03:55 -0000 Date: Thu, 14 May 2009 12:03:55 +0100 (BST) To: Daniel O'Connor 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> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-Id: <1242299035.690452.893.nullmailer@galant.ukfsn.org> From: Iain Hibbert X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at example.com X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: plunky@rya-online.net X-SA-Exim-Scanned: No (on localhost.t-mobile.co.uk); SAEximRunCond expanded to false Cc: freebsd-bluetooth@freebsd.org Subject: Re: btpand example X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2009 11:04:52 -0000 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 owner-freebsd-bluetooth@FreeBSD.ORG Thu May 14 16:26:19 2009 Return-Path: Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C71D01065673 for ; Thu, 14 May 2009 16:26:19 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.29]) by mx1.freebsd.org (Postfix) with ESMTP id 7A3E98FC2A for ; Thu, 14 May 2009 16:26:19 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by yw-out-2324.google.com with SMTP id 9so773943ywe.13 for ; Thu, 14 May 2009 09:26:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ca8WAlGo6Stj1n6frB3JmPJvKBapj6vhNKhikIm1azk=; b=ah3cuZVRPpe1vOfrb3zp9cQznQiewN3hYykUkmBE5/kWQg5xdHFAKFY1+3boiHDxUR 1wQ2RqU3uJlIZMF2bl5PwJ9wqxWBcu5iweGY0lUn6Z8JdeLOmKP8u8RyCVS/Qqew9yZf b0WFkrPfUeWjlAXYw0e4n+1hS9hEcM+dGyvlE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=flPAVPEKLZdGF0MfZOIpFLYJJuJXkSRQK5U7757uIok6LE/NvStW84Q8zn6H2CWIxp bnEYpctMcZ5eKhDrB9ui5aomSv6jjOhTlaQ93+NzzUDNsBLCpTqwrTRXinLClOjRuahT PaF3DUIi+/kFmNxOO+sRn3aU4XPpyv49QQ/gQ= MIME-Version: 1.0 Received: by 10.90.83.2 with SMTP id g2mr1911345agb.105.1242318378846; Thu, 14 May 2009 09:26:18 -0700 (PDT) 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> Date: Thu, 14 May 2009 09:26:18 -0700 Message-ID: From: Maksim Yevmenkin To: Iain Hibbert Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-bluetooth@freebsd.org Subject: Re: libhci update X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2009 16:26:20 -0000 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 owner-freebsd-bluetooth@FreeBSD.ORG Thu May 14 16:42:53 2009 Return-Path: Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4802F106564A for ; Thu, 14 May 2009 16:42:53 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.217.172]) by mx1.freebsd.org (Postfix) with ESMTP id EC1338FC19 for ; Thu, 14 May 2009 16:42:52 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by gxk20 with SMTP id 20so440279gxk.19 for ; Thu, 14 May 2009 09:42:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=DuEjXxZcnz3KWsWDI87EsNsEQyit0C0uZ31IhzDVm58=; b=cFO+qZyHF88aTkI4e1ppdKoJlBJ8mKNab9Dhk5hqlEjyQuM+JDO1NuWiswHWqdAz8r rZXtR/IMmAkuj5ArYq9w7SGI41SGXQFdYuAsAzu5X1czLY8AUg2hC/BUn3wfml9adhz7 B16Asivsm4QTwDR/o5MUd9a1JMLieG0UDZmro= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=nyBJkxde38/8ZIidfgV5e2VZk6+dUQIStArdO+uvGjKc4mm2ru91/BRjxKZ8z3749m WaAd02oUJ4L/84u0gNIRruALWlGflfU8x8bMCjfn9zsYfXN34LgEYx7Mp9bEcY+l6Nlc u4nSJjhrQIZjJysSFVRBCyQXeJCv9CMxJwbMY= MIME-Version: 1.0 Received: by 10.90.26.3 with SMTP id 3mr1960845agz.27.1242319372428; Thu, 14 May 2009 09:42:52 -0700 (PDT) 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> Date: Thu, 14 May 2009 09:42:52 -0700 Message-ID: From: Maksim Yevmenkin To: Iain Hibbert Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-bluetooth@freebsd.org Subject: Re: libhci update X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2009 16:42:53 -0000 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 owner-freebsd-bluetooth@FreeBSD.ORG Thu May 14 17:00:15 2009 Return-Path: Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C21D71065673 for ; Thu, 14 May 2009 17:00:15 +0000 (UTC) (envelope-from plunky@rya-online.net) Received: from smtp01.one2one.net (smtp01.one2one.net [149.254.200.196]) by mx1.freebsd.org (Postfix) with ESMTP id 6AD0A8FC12 for ; Thu, 14 May 2009 17:00:15 +0000 (UTC) (envelope-from plunky@rya-online.net) Received: from [127.0.0.1] (helo=localhost) by smtpbarns01 with esmtp (Exim 4.50) id 1M4eHy-00063f-No; Thu, 14 May 2009 17:00:10 +0000 Received: from smtpbarns01 ([127.0.0.1]) by localhost (smtpbarns01 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23123-01; Thu, 14 May 2009 18:00:10 +0100 (BST) Received: from [10.216.51.64] (helo=rya-online.net) by smtpbarns01 with smtp (Exim 4.50) id 1M4eHw-00063b-MA; Thu, 14 May 2009 17:00:10 +0000 Received: (nullmailer pid 13780 invoked by uid 1000); Thu, 14 May 2009 16:59:18 -0000 Date: Thu, 14 May 2009 17:59:18 +0100 (BST) To: Maksim Yevmenkin 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> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-Id: <1242320358.167446.9598.nullmailer@galant.ukfsn.org> From: Iain Hibbert X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at example.com X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: plunky@rya-online.net X-SA-Exim-Scanned: No (on smtpbarns01); SAEximRunCond expanded to false Cc: freebsd-bluetooth@freebsd.org Subject: Re: libhci update X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2009 17:00:16 -0000 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 owner-freebsd-bluetooth@FreeBSD.ORG Thu May 14 17:05:31 2009 Return-Path: Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B8B19106564A for ; Thu, 14 May 2009 17:05:31 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.29]) by mx1.freebsd.org (Postfix) with ESMTP id 720F78FC15 for ; Thu, 14 May 2009 17:05:31 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by yx-out-2324.google.com with SMTP id 8so786876yxb.13 for ; Thu, 14 May 2009 10:05:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=mSRm2THyYJCLMG8Q/96F6z2GGMBKyvDooqJq4qaE92k=; b=JDULlXwH5QQo1nwgoJnbatiX+HY1RzL4eT6QMjihlJEEHhHcZiKI1MBMZVprebkTLg 671A7eS5SEGyXWzlUzrg0rvZURPgiRwtehKhcahJXcNz3uju/86StqGjNEFgz7gNlknd guBHJzhEOri9O6LwBBF62dPMHPSFQebhIMbaM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=PPb1Jx3hogCT6XIozbXWHvh+ZL91wVmmwMmz01/0XcqAzWPUDOnT9yGsduefD9nBUf /4tFjC4SCwRtqI9zIIwt4DYwLktMVJ4OT+rNuGvqQLkDkpSQe0qh2gnxHtUEHYKhgG4q ndxd3lky16XQmFg9YCgAPgvsH1f8y2jlcoT6U= MIME-Version: 1.0 Received: by 10.90.106.3 with SMTP id e3mr1963143agc.54.1242320730482; Thu, 14 May 2009 10:05:30 -0700 (PDT) In-Reply-To: <200905141438.17380.doconnor@gsoft.com.au> References: <200905141438.17380.doconnor@gsoft.com.au> Date: Thu, 14 May 2009 10:05:30 -0700 Message-ID: From: Maksim Yevmenkin To: "Daniel O'Connor" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-bluetooth@freebsd.org Subject: Re: btpand example X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2009 17:05:32 -0000 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 owner-freebsd-bluetooth@FreeBSD.ORG Thu May 14 17:11:33 2009 Return-Path: Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D849C106567F for ; Thu, 14 May 2009 17:11:33 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.217.172]) by mx1.freebsd.org (Postfix) with ESMTP id 7CC838FC23 for ; Thu, 14 May 2009 17:11:33 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by gxk20 with SMTP id 20so474114gxk.19 for ; Thu, 14 May 2009 10:11:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=oHK0Wi+WmHc3XaHzaHovuwlez+uvhBXCg6Ff8ZzYj40=; b=iguN4RnGHgUtk2uuIByBJYB9JgN3TiHTYo+6mX48dglUZiPbTevMKxDxzdjo8V2ZJu tj71XfgbJvdcP/Cc5LDUd6cjBvJypZjmjKe/rIHaqIXVxIyBu7f2GOZsU6nnMcS33TjB hqXeuNCzDqvwj/jJslzEJJ1U6BnxxSTuqHITU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=mKWQFWvHKPkyun+ozeCd/4bsQaYtFjcSIpS451ibSvtVeSBbIaTOBFs+RK6kMX/rpH NFjaV9YeO8jHeH9PylOno50/uJ4lN64bfLBVUFOJzygeT6NpxM2ywekFwrtYNcrHNuzM N14WmV3a2m/g2uJfiAgmDYet0GohKUV7zROa8= MIME-Version: 1.0 Received: by 10.90.92.16 with SMTP id p16mr1117966agb.56.1242321092626; Thu, 14 May 2009 10:11:32 -0700 (PDT) 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> Date: Thu, 14 May 2009 10:11:32 -0700 Message-ID: From: Maksim Yevmenkin To: Iain Hibbert Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-bluetooth@freebsd.org Subject: Re: libhci update X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2009 17:11:35 -0000 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 owner-freebsd-bluetooth@FreeBSD.ORG Thu May 14 17:38:04 2009 Return-Path: Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E78E6106564A for ; Thu, 14 May 2009 17:38:03 +0000 (UTC) (envelope-from plunky@rya-online.net) Received: from smtp01.one2one.net (smtp01.one2one.net [149.254.200.196]) by mx1.freebsd.org (Postfix) with ESMTP id 78DAA8FC1C for ; Thu, 14 May 2009 17:38:03 +0000 (UTC) (envelope-from plunky@rya-online.net) Received: from [127.0.0.1] (helo=localhost) by smtpbarns01 with esmtp (Exim 4.50) id 1M4esc-0007V9-00; Thu, 14 May 2009 17:38:02 +0000 Received: from smtpbarns01 ([127.0.0.1]) by localhost (smtpbarns01 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28782-05; Thu, 14 May 2009 18:38:01 +0100 (BST) Received: from [10.216.51.64] (helo=rya-online.net) by smtpbarns01 with smtp (Exim 4.50) id 1M4eof-0007Dj-8e; Thu, 14 May 2009 17:34:00 +0000 Received: (nullmailer pid 11196 invoked by uid 1000); Thu, 14 May 2009 17:33:04 -0000 Date: Thu, 14 May 2009 18:33:04 +0100 (BST) To: Maksim Yevmenkin 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> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-Id: <1242322384.832849.4269.nullmailer@galant.ukfsn.org> From: Iain Hibbert X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at example.com X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: plunky@rya-online.net X-SA-Exim-Scanned: No (on smtpbarns01); SAEximRunCond expanded to false Cc: freebsd-bluetooth@freebsd.org Subject: Re: libhci update X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2009 17:38:04 -0000 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 owner-freebsd-bluetooth@FreeBSD.ORG Thu May 14 18:40:58 2009 Return-Path: Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C0902106568A for ; Thu, 14 May 2009 18:40:58 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.29]) by mx1.freebsd.org (Postfix) with ESMTP id 73E5B8FC1B for ; Thu, 14 May 2009 18:40:58 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by yx-out-2324.google.com with SMTP id 8so819263yxb.13 for ; Thu, 14 May 2009 11:40:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=p6vith9++b4OTl2ajCFOC8qoXsIPlSDHa8bOo+kw5vI=; b=kEVao2FXo6/1aGbWv5LLe5umn477p3CxPmjX/TZ70wfDDPikgdwSi8TnnSY0K9AhkD dChluuJLIjRgur8eafCvWMvpUxA2o+80ZiCEiW4wS88k4aavAKwM19LoPk69zii4vOwM F+SyfFI1hQ2VqAPgaj/imp/G0VmWmzPgA64DE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=hNkW9oIDZNiX+p6XFccQQ7S4b1NAK46F8+uJ9hm1mgxJ9pbDmXf0I20HP5w0IdTQXK Dt1pW37DbWMxljkczMYVzxESy4+UVX4Nzsv8oa2Jg+zeaozeAa3RRrNjee5I2P4v+TR1 yycCeVCQ+RGGCo2L6aRpHkHrFmqLqDV5sgnaY= MIME-Version: 1.0 Received: by 10.100.46.18 with SMTP id t18mr3476133ant.54.1242326457879; Thu, 14 May 2009 11:40:57 -0700 (PDT) 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> Date: Thu, 14 May 2009 11:40:57 -0700 Message-ID: From: Maksim Yevmenkin To: Iain Hibbert Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-bluetooth@freebsd.org Subject: Re: libhci update X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2009 18:40:59 -0000 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 owner-freebsd-bluetooth@FreeBSD.ORG Thu May 14 19:23:37 2009 Return-Path: Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C4ECA1065670 for ; Thu, 14 May 2009 19:23:37 +0000 (UTC) (envelope-from plunky@rya-online.net) Received: from smtp01.one2one.net (smtp01.one2one.net [149.254.200.196]) by mx1.freebsd.org (Postfix) with ESMTP id 5660B8FC0C for ; Thu, 14 May 2009 19:23:37 +0000 (UTC) (envelope-from plunky@rya-online.net) Received: from [127.0.0.1] (helo=localhost) by smtpbarns01 with esmtp (Exim 4.50) id 1M4gWl-0001Kg-2W; Thu, 14 May 2009 19:23:35 +0000 Received: from smtpbarns01 ([127.0.0.1]) by localhost (smtpbarns01 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04783-05; Thu, 14 May 2009 20:23:34 +0100 (BST) Received: from [10.216.51.64] (helo=rya-online.net) by smtpbarns01 with smtp (Exim 4.50) id 1M4gWh-0001Kb-U3; Thu, 14 May 2009 19:23:34 +0000 Received: (nullmailer pid 23880 invoked by uid 1000); Thu, 14 May 2009 19:22:42 -0000 Date: Thu, 14 May 2009 20:22:42 +0100 (BST) To: Maksim Yevmenkin 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> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-Id: <1242328962.345875.22296.nullmailer@galant.ukfsn.org> From: Iain Hibbert X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at example.com X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: plunky@rya-online.net X-SA-Exim-Scanned: No (on smtpbarns01); SAEximRunCond expanded to false Cc: freebsd-bluetooth@freebsd.org Subject: Re: libhci update X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2009 19:23:38 -0000 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 owner-freebsd-bluetooth@FreeBSD.ORG Thu May 14 21:16:33 2009 Return-Path: Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8799A106566B for ; Thu, 14 May 2009 21:16:33 +0000 (UTC) (envelope-from plunky@rya-online.net) Received: from smtp01.one2one.net (smtp01.one2one.net [149.254.200.196]) by mx1.freebsd.org (Postfix) with ESMTP id 189998FC17 for ; Thu, 14 May 2009 21:16:31 +0000 (UTC) (envelope-from plunky@rya-online.net) Received: from [127.0.0.1] (helo=localhost) by smtpbarns01 with esmtp (Exim 4.50) id 1M4iI1-0002MH-UC; Thu, 14 May 2009 21:16:30 +0000 Received: from smtpbarns01 ([127.0.0.1]) by localhost (smtpbarns01 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08902-01; Thu, 14 May 2009 22:16:29 +0100 (BST) Received: from [10.216.51.64] (helo=rya-online.net) by smtpbarns01 with smtp (Exim 4.50) id 1M4iHt-0002MB-5U; Thu, 14 May 2009 21:16:29 +0000 Received: (nullmailer pid 27348 invoked by uid 1000); Thu, 14 May 2009 21:15:31 -0000 Date: Thu, 14 May 2009 22:15:31 +0100 (BST) To: Maksim Yevmenkin 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> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-Id: <1242335731.252131.19040.nullmailer@galant.ukfsn.org> From: Iain Hibbert X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at example.com X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: plunky@rya-online.net X-SA-Exim-Scanned: No (on smtpbarns01); SAEximRunCond expanded to false Cc: freebsd-bluetooth@freebsd.org Subject: Re: libhci update X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2009 21:16:33 -0000 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 owner-freebsd-bluetooth@FreeBSD.ORG Fri May 15 17:21:25 2009 Return-Path: Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 07F941065676 for ; Fri, 15 May 2009 17:21:25 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.30]) by mx1.freebsd.org (Postfix) with ESMTP id A89BD8FC1B for ; Fri, 15 May 2009 17:21:24 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by yw-out-2324.google.com with SMTP id 9so1175963ywe.13 for ; Fri, 15 May 2009 10:21:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=oSkiGn1DRygFtfduAc8WRHYkY+TZAO1ducvic+Wfiig=; b=s9dnhr9FiPJn9la9XKLSRb9oFdLTX9ovX/q1teqmr3Tpre+t3K82/yoY2FfKrhSK1V cDQpBA837O4sdjHYtvzPK7776x7Rl1OKN7UbdqdOEXErF8Zp9xrpH4AfzpQL/gQOZAfS mxy8ZzMFJEKs+DubVgxIa0p42o326tOlcMQsc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=GRdvvJKf2D3eUlRnc51TGRY+T9nfeNyIU8/j3aCKGeVch2X94ZmmXkIaBbCpXMJLg4 TM70tJnJDTLirGkiAU6lk4SpEbPox8ss5dO2oWyUpLwpc1CequThmD8LWCh9Qxx7a7Gd FLvE4pCwnfjTxLfruoqXV0VMHkSnPs/6oq0o4= MIME-Version: 1.0 Received: by 10.90.97.18 with SMTP id u18mr2972201agb.104.1242408083801; Fri, 15 May 2009 10:21:23 -0700 (PDT) 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> Date: Fri, 15 May 2009 10:21:23 -0700 Message-ID: From: Maksim Yevmenkin To: Iain Hibbert Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-bluetooth@freebsd.org Subject: Re: libhci update X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2009 17:21:25 -0000 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 owner-freebsd-bluetooth@FreeBSD.ORG Fri May 15 20:50:37 2009 Return-Path: Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A5D8F1065675 for ; Fri, 15 May 2009 20:50:37 +0000 (UTC) (envelope-from plunky@rya-online.net) Received: from smtp01.one2one.net (smtp01.one2one.net [149.254.200.196]) by mx1.freebsd.org (Postfix) with ESMTP id 2EF048FC0C for ; Fri, 15 May 2009 20:50:31 +0000 (UTC) (envelope-from plunky@rya-online.net) Received: from [127.0.0.1] (helo=localhost) by smtpbarns01 with esmtp (Exim 4.50) id 1M54MM-0007p4-Ra; Fri, 15 May 2009 20:50:26 +0000 Received: from smtpbarns01 ([127.0.0.1]) by localhost (smtpbarns01 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29620-09; Fri, 15 May 2009 21:50:26 +0100 (BST) Received: from [10.217.175.146] (helo=rya-online.net) by smtpbarns01 with smtp (Exim 4.50) id 1M54MF-0007p0-Ui; Fri, 15 May 2009 20:50:26 +0000 Received: (nullmailer pid 6023 invoked by uid 1000); Fri, 15 May 2009 20:49:34 -0000 Date: Fri, 15 May 2009 21:49:33 +0100 (BST) To: Maksim Yevmenkin 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> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-Id: <1242420574.009085.2429.nullmailer@galant.ukfsn.org> From: Iain Hibbert X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at example.com X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: plunky@rya-online.net X-SA-Exim-Scanned: No (on smtpbarns01); SAEximRunCond expanded to false Cc: freebsd-bluetooth@freebsd.org Subject: Re: libhci update X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2009 20:50:38 -0000 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 owner-freebsd-bluetooth@FreeBSD.ORG Sat May 16 05:40:42 2009 Return-Path: Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A3C2D106566C for ; Sat, 16 May 2009 05:40:42 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id EFCBC8FC08 for ; Sat, 16 May 2009 05:40:41 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au ([120.17.171.60]) (authenticated bits=0) by cain.gsoft.com.au (8.13.8/8.13.8) with ESMTP id n4G5eY4m028727 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sat, 16 May 2009 15:10:37 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: Maksim Yevmenkin Date: Sat, 16 May 2009 15:07:27 +0930 User-Agent: KMail/1.9.10 References: <200905141438.17380.doconnor@gsoft.com.au> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart4455335.CAPo854NO8"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200905161507.34845.doconnor@gsoft.com.au> X-Spam-Score: -2.212 () BAYES_00,RDNS_NONE X-Scanned-By: MIMEDefang 2.63 on 203.31.81.10 Cc: freebsd-bluetooth@freebsd.org Subject: Re: btpand example X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 May 2009 05:40:42 -0000 --nextPart4455335.CAPo854NO8 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- 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 =3D bt_gethostbyname(optarg)) > =3D=3D NULL) > > =3D=3D=3D 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=20 works fine.. I have reset my phone in the mean time so maybe it was out of memory or=20 something silly like that.. =2D-=20 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 --nextPart4455335.CAPo854NO8 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iD8DBQBKDlEe5ZPcIHs/zowRArycAJ9Q28iHVSROH3v0jULtWfyZCr7/9QCffHtZ fgaTdiX9r4eyACN20LHH9Js= =/T/e -----END PGP SIGNATURE----- --nextPart4455335.CAPo854NO8-- From owner-freebsd-bluetooth@FreeBSD.ORG Sat May 16 05:46:09 2009 Return-Path: Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5FAD5106564A for ; Sat, 16 May 2009 05:46:09 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id AB2238FC1A for ; Sat, 16 May 2009 05:46:07 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au ([120.17.171.60]) (authenticated bits=0) by cain.gsoft.com.au (8.13.8/8.13.8) with ESMTP id n4G5k0JK028884 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sat, 16 May 2009 15:16:04 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: Iain Hibbert Date: Sat, 16 May 2009 15:13:42 +0930 User-Agent: KMail/1.9.10 References: <200905141438.17380.doconnor@gsoft.com.au> <200905141920.47717.doconnor@gsoft.com.au> <1242299035.690452.893.nullmailer@galant.ukfsn.org> In-Reply-To: <1242299035.690452.893.nullmailer@galant.ukfsn.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3212573.FqtHeI5am1"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200905161513.43690.doconnor@gsoft.com.au> X-Spam-Score: -2.212 () BAYES_00,RDNS_NONE X-Scanned-By: MIMEDefang 2.63 on 203.31.81.10 Cc: freebsd-bluetooth@freebsd.org Subject: Re: btpand example X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 May 2009 05:46:09 -0000 --nextPart3212573.FqtHeI5am1 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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..?=20 > l2ping only tests the bluetooth link. Sorry, I missed a step before, I did try ICMP pings when trying to work=20 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=20 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=3D0x02, proto=3D0x0800, len=3D1568) May 2 11:06:36 galant /netbsd: > tap0: discarding oversize frame (len=3D1582) 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. =2D-=20 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 --nextPart3212573.FqtHeI5am1 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iD8DBQBKDlKP5ZPcIHs/zowRAgufAKCN9GVE1UIIZHWdn4nn3/gK4uYNwwCgmg7v x7kbQ6ZjkgyOd/unFx7oNEc= =qt15 -----END PGP SIGNATURE----- --nextPart3212573.FqtHeI5am1--