From owner-freebsd-bluetooth@FreeBSD.ORG Sun May 17 10:21: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 3EDF3106564A for ; Sun, 17 May 2009 10:21:42 +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 EBFB18FC15 for ; Sun, 17 May 2009 10:21:41 +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 1M5dUu-00007E-UQ; Sun, 17 May 2009 10:21:37 +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 32722-06; Sun, 17 May 2009 11:21:36 +0100 (BST) Received: from [10.215.72.127] (helo=rya-online.net) by localhost.t-mobile.co.uk with smtp (Exim 4.50) id 1M5dUr-00006U-Vm; Sun, 17 May 2009 10:21:36 +0000 Received: (nullmailer pid 3549 invoked by uid 1000); Sun, 17 May 2009 10:20:49 -0000 Date: Sun, 17 May 2009 11:20:48 +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: <1242555649.223847.3574.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: Sun, 17 May 2009 10:21:42 -0000 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 owner-freebsd-bluetooth@FreeBSD.ORG Sun May 17 19:05:20 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 F3614106566C for ; Sun, 17 May 2009 19:05:19 +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 ABE458FC08 for ; Sun, 17 May 2009 19:05:19 +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 1M5lff-00038y-8m; Sun, 17 May 2009 19:05:15 +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 11884-04; Sun, 17 May 2009 20:05:14 +0100 (BST) Received: from [10.215.72.127] (helo=rya-online.net) by localhost.t-mobile.co.uk with smtp (Exim 4.50) id 1M5lfd-00038c-CV; Sun, 17 May 2009 19:05:14 +0000 Received: (nullmailer pid 23342 invoked by uid 1000); Sun, 17 May 2009 19:04:25 -0000 Date: Sun, 17 May 2009 20:04:25 +0100 (BST) To: Maksim Yevmenkin 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> User-Agent: Alpine 2.00 (NEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-Id: <1242587065.366534.1587.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: Sun, 17 May 2009 19:05:20 -0000 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 owner-freebsd-bluetooth@FreeBSD.ORG Mon May 18 16:01:56 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 D167D106566B for ; Mon, 18 May 2009 16:01:56 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from mail-px0-f106.google.com (mail-px0-f106.google.com [209.85.216.106]) by mx1.freebsd.org (Postfix) with ESMTP id A49FC8FC08 for ; Mon, 18 May 2009 16:01:56 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by pxi4 with SMTP id 4so2254049pxi.3 for ; Mon, 18 May 2009 09:01:56 -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=SOUi9n8QOqKijFKfY4NdYO6YP9dZEpz9gFmYQh8HrsA=; b=xp2T7xMn1zRo1dFld/EtB8QPwq+p2S6GTEj3I5ePHLrhb1z3rYiBJ2gU8/91r0wDFZ mnBwT4FYoR1HxPHMW2F5m4xP0BPKz+Ax3TedgY0fIA9TXst8JftIgn+7qFzxaIuGgMCj VLLuvmtP1PPXXJeW1P1z7Oxv6XBTdfYQdWXBo= 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=pDUQVGL2WvABToJsB4hxqMs5fLQy2vehEaCgkoh6pRuYahfWqT96v+TLHyOg8QgTd4 gW+R4blnjlfQahsQABI3ekDwDP2+RU3xklxeTWLpzxfRFzAPXc+aRv/B6OSb/CLUtSB6 ZsV7so7Ry2M7sqe5o3RcDxUwHYOe6J6Bq2ACg= MIME-Version: 1.0 Received: by 10.114.184.7 with SMTP id h7mr11587025waf.151.1242662515559; Mon, 18 May 2009 09:01:55 -0700 (PDT) In-Reply-To: <200905161507.34845.doconnor@gsoft.com.au> References: <200905141438.17380.doconnor@gsoft.com.au> <200905161507.34845.doconnor@gsoft.com.au> Date: Mon, 18 May 2009 09:01:55 -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: Mon, 18 May 2009 16:01:57 -0000 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 owner-freebsd-bluetooth@FreeBSD.ORG Mon May 18 16:26:35 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 A91701065673 for ; Mon, 18 May 2009 16:26:35 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from mail-pz0-f105.google.com (mail-pz0-f105.google.com [209.85.222.105]) by mx1.freebsd.org (Postfix) with ESMTP id 758408FC17 for ; Mon, 18 May 2009 16:26:35 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by pzk3 with SMTP id 3so2243742pzk.3 for ; Mon, 18 May 2009 09:26:35 -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=13MLmh6ZevMH6LWSbQ136V5QMKPJHw4XB+YMbaqwrrA=; b=uRjuuIKJyGRpqAA6sI71NGovQieoGxufzOGSQA+9uz1Mr9G81h1++dJo5S0rPjA266 WG2osgXrTfVxyG8kV9OEDYpbOB58RnK+r1ImbQkSY6LWl5eVwbaBvUDh+ZPygpDmUuuq jA4CZCYQ2WXgGFnLDttJznH3RrgULIc81INAM= 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=UJd5GqQ5dc+E/zgmkNpP1B5ThFvChBxNLs3TZ9elsilUsQQPI/0Mljr12NIOLeS5lT tVUzp8GxonRNEBtkhHvPNgahyJWxR0rWkntjDP9jR79PGMF4Qby5IE8NWCjt02j4k9lg ZMr9mhWw7f0u363Au1r7cmYj4OFc2fFQrious= MIME-Version: 1.0 Received: by 10.114.93.17 with SMTP id q17mr11884995wab.38.1242663995019; Mon, 18 May 2009 09:26:35 -0700 (PDT) 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> Date: Mon, 18 May 2009 09:26:34 -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: Mon, 18 May 2009 16:26:35 -0000 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 owner-freebsd-bluetooth@FreeBSD.ORG Mon May 18 20:32:12 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 93B1E10656C9 for ; Mon, 18 May 2009 20:32:12 +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 236C58FC27 for ; Mon, 18 May 2009 20:32:12 +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 1M69VK-0004OH-RU; Mon, 18 May 2009 20:32:10 +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 16468-10; Mon, 18 May 2009 21:32:10 +0100 (BST) Received: from [10.215.231.136] (helo=rya-online.net) by localhost.t-mobile.co.uk with smtp (Exim 4.50) id 1M69VC-0004Nu-9J; Mon, 18 May 2009 20:32:09 +0000 Received: (nullmailer pid 4726 invoked by uid 1000); Mon, 18 May 2009 20:31:18 -0000 Date: Mon, 18 May 2009 21:31:17 +0100 (BST) To: Maksim Yevmenkin 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> User-Agent: Alpine 2.00 (NEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-Id: <1242678678.137958.4773.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: Mon, 18 May 2009 20:32:17 -0000 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 owner-freebsd-bluetooth@FreeBSD.ORG Wed May 20 08:03:30 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 182C8106566C for ; Wed, 20 May 2009 08:03:30 +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 8B6F48FC28 for ; Wed, 20 May 2009 08:03:29 +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 n4K83Pvn009890 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 20 May 2009 17:33:27 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: Maksim Yevmenkin Date: Wed, 20 May 2009 17:33:24 +0930 User-Agent: KMail/1.9.10 References: <200905141438.17380.doconnor@gsoft.com.au> <200905161507.34845.doconnor@gsoft.com.au> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart7818447.9Fu3tigK2L"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200905201733.25859.doconnor@gsoft.com.au> X-Spam-Score: -3.509 () ALL_TRUSTED,AWL,BAYES_00 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: Wed, 20 May 2009 08:03:30 -0000 --nextPart7818447.9Fu3tigK2L Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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. =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 --nextPart7818447.9Fu3tigK2L 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) iD8DBQBKE7lN5ZPcIHs/zowRApJ7AJwJFgvzGUMTCLLndxwpNJHsD0toAQCeNCk6 Cf36zSk0DCqbA1sYOA2aE7Y= =0uac -----END PGP SIGNATURE----- --nextPart7818447.9Fu3tigK2L-- From owner-freebsd-bluetooth@FreeBSD.ORG Wed May 20 08:18:41 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 7A9ED106564A for ; Wed, 20 May 2009 08:18:41 +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 0A4B58FC0A for ; Wed, 20 May 2009 08:18:40 +0000 (UTC) (envelope-from plunky@rya-online.net) Received: from [127.0.0.1] (helo=localhost) by smtpbarns01 with esmtp (Exim 4.50) id 1M6h0W-0008Mq-9D; Wed, 20 May 2009 08:18:36 +0000 Received: from smtpbarns01 ([127.0.0.1]) by localhost (smtpbarns01 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31906-03; Wed, 20 May 2009 09:18:35 +0100 (BST) Received: from [10.216.196.109] (helo=rya-online.net) by smtpbarns01 with smtp (Exim 4.50) id 1M6h0T-0008Ml-9P; Wed, 20 May 2009 08:18:35 +0000 Received: (nullmailer pid 859 invoked by uid 1000); Wed, 20 May 2009 08:17:51 -0000 Date: Wed, 20 May 2009 09:17:51 +0100 (BST) To: Maksim Yevmenkin 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> User-Agent: Alpine 2.00 (NEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-Id: <1242807471.849053.801.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: Wed, 20 May 2009 08:18:41 -0000 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 owner-freebsd-bluetooth@FreeBSD.ORG Wed May 20 08:41:45 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 4C796106564A for ; Wed, 20 May 2009 08:41:45 +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 02B818FC15 for ; Wed, 20 May 2009 08:41:43 +0000 (UTC) (envelope-from plunky@rya-online.net) Received: from [127.0.0.1] (helo=localhost) by smtpbarns01 with esmtp (Exim 4.50) id 1M6hMt-0000AC-2x; Wed, 20 May 2009 08:41:43 +0000 Received: from smtpbarns01 ([127.0.0.1]) by localhost (smtpbarns01 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00596-01; Wed, 20 May 2009 09:41:42 +0100 (BST) Received: from [10.216.196.109] (helo=rya-online.net) by smtpbarns01 with smtp (Exim 4.50) id 1M6hMq-0000A8-D7; Wed, 20 May 2009 08:41:42 +0000 Received: (nullmailer pid 844 invoked by uid 1000); Wed, 20 May 2009 08:40:58 -0000 Date: Wed, 20 May 2009 09:40:58 +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> User-Agent: Alpine 2.00 (NEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-Id: <1242808858.879529.970.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: Wed, 20 May 2009 08:41:45 -0000 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 owner-freebsd-bluetooth@FreeBSD.ORG Fri May 22 07:23: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 B56FE1065672 for ; Fri, 22 May 2009 07:23:42 +0000 (UTC) (envelope-from freebsd-bluetooth@dino.sk) Received: from loki.netlab.sk (ns3.netlab.sk [84.245.65.11]) by mx1.freebsd.org (Postfix) with ESMTP id 3D9188FC12 for ; Fri, 22 May 2009 07:23:42 +0000 (UTC) (envelope-from freebsd-bluetooth@dino.sk) Received: from via.dino.sk (home.dino.sk [84.245.95.252]) (AUTH: PLAIN milan, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by loki.netlab.sk with esmtp; Fri, 22 May 2009 08:42:45 +0200 id 0002E03D.4A164965.00006247 From: Milan Obuch To: freebsd-bluetooth@freebsd.org Date: Fri, 22 May 2009 08:46:59 +0200 User-Agent: KMail/1.9.10 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200905220847.00259.freebsd-bluetooth@dino.sk> Subject: Bluetooth keyboard 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, 22 May 2009 07:23:43 -0000 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 owner-freebsd-bluetooth@FreeBSD.ORG Fri May 22 10:03:16 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 CA54F1065674 for ; Fri, 22 May 2009 10:03:16 +0000 (UTC) (envelope-from freebsd-bluetooth@dino.sk) Received: from loki.netlab.sk (ns3.netlab.sk [84.245.65.11]) by mx1.freebsd.org (Postfix) with ESMTP id 427B58FC08 for ; Fri, 22 May 2009 10:03:15 +0000 (UTC) (envelope-from freebsd-bluetooth@dino.sk) Received: from via.dino.sk (home.dino.sk [84.245.95.252]) (AUTH: PLAIN milan, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by loki.netlab.sk with esmtp; Fri, 22 May 2009 11:58:07 +0200 id 0002E036.4A16772F.00006EB6 From: Milan Obuch To: freebsd-bluetooth@freebsd.org Date: Fri, 22 May 2009 12:03:02 +0200 User-Agent: KMail/1.9.10 References: <200905220847.00259.freebsd-bluetooth@dino.sk> In-Reply-To: <200905220847.00259.freebsd-bluetooth@dino.sk> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200905221203.03590.freebsd-bluetooth@dino.sk> Subject: Re: Bluetooth keyboard 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, 22 May 2009 10:03:17 -0000 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