From owner-freebsd-bluetooth@FreeBSD.ORG Wed Apr 22 05:34:01 2015 Return-Path: Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3CD21C22 for ; Wed, 22 Apr 2015 05:34:01 +0000 (UTC) Received: from mail-ob0-x22e.google.com (mail-ob0-x22e.google.com [IPv6:2607:f8b0:4003:c01::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 067BB1FA2 for ; Wed, 22 Apr 2015 05:34:01 +0000 (UTC) Received: by obcux3 with SMTP id ux3so57548156obc.2 for ; Tue, 21 Apr 2015 22:34:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=/KJIY+of28gagZRDYgTER0Hz2gAJU/xbp9RREy9lz9U=; b=bJFyL95ZZG55OebF27SE4qCMThvDfirZIc+69uLTN64jeznW9mcE6Y7C0HeB0UI94D pDc9WxCDL+TEy6i5+UPVBG5LeuCfLNXSoLKSxeA9kLltUskCoajk9mZOBjLRrVBSuLUq tzs03f3gA9WQ5V1RdVI/2Nnbw5+Ix/xKhTdYqam21P6nGy8F+mYEesuTr3P4oBfkbfOC mQaly12iyE4gPm8iIzEjLgaDzFSiOB495UBTgsZqjUPJOCJkSUYlRv8hMI0cIEwMsd8u 3f3yw2O9aXNxRIM3pPyt6HUzqobtQvK+NtcBbTDSIh1frotOzkOvZIGDWsFK4NzsFGo1 IrPQ== MIME-Version: 1.0 X-Received: by 10.202.183.214 with SMTP id h205mr20762658oif.87.1429680840223; Tue, 21 Apr 2015 22:34:00 -0700 (PDT) Received: by 10.202.177.85 with HTTP; Tue, 21 Apr 2015 22:34:00 -0700 (PDT) Date: Tue, 21 Apr 2015 22:34:00 -0700 Message-ID: Subject: question about bthidd client.c From: Waitman Gobble To: "freebsd-bluetooth@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2015 05:34:01 -0000 I notice that if bthidd is running, and bluetooth is not active, or the configured host is out of range, the client_rescan() function generates new vkbd devices every 20 seconds or so. I believe this will eventually lock up the machine. ie, Apr 21 21:59:38 rpidev bthidd[521]: Opening outbound session for 00:1b:dc:06:94:d3 (new_device=0, reconnect_initiate=0) Apr 21 21:59:38 rpidev kernel: kbd2 at vkbd14137 Apr 21 21:59:38 rpidev bthidd[521]: Could not open control channel to 00:1b:dc:06:94:d3. No route to host (65) Apr 21 21:59:58 rpidev bthidd[521]: Opening outbound session for 00:1b:dc:06:94:d3 (new_device=0, reconnect_initiate=0) Apr 21 21:59:58 rpidev kernel: kbd2 at vkbd14138 Apr 21 21:59:58 rpidev bthidd[521]: Could not open control channel to 00:1b:dc:06:94:d3. No route to host (65) Apr 21 22:00:18 rpidev bthidd[521]: Opening outbound session for 00:1b:dc:06:94:d3 (new_device=0, reconnect_initiate=0) Apr 21 22:00:18 rpidev kernel: kbd2 at vkbd14139 Apr 21 22:00:18 rpidev bthidd[521]: Could not open control channel to 00:1b:dc:06:94:d3. No route to host (65) Apr 21 22:00:18 rpidev bthidd[521]: Got signal 15, total number of signals 1 # dmesg ... kbd2 at vkbd14118 kbd2 at vkbd14119 kbd2 at vkbd14120 kbd2 at vkbd14121 kbd2 at vkbd14122 kbd2 at vkbd14123 kbd2 at vkbd14124 kbd2 at vkbd14125 kbd2 at vkbd14126 kbd2 at vkbd14127 kbd2 at vkbd14128 kbd2 at vkbd14129 kbd2 at vkbd14130 kbd2 at vkbd14131 kbd2 at vkbd14132 kbd2 at vkbd14133 kbd2 at vkbd14134 kbd2 at vkbd14135 kbd2 at vkbd14136 kbd2 at vkbd14137 kbd2 at vkbd14138 kbd2 at vkbd14139 # ls /dev/vkbdctl141* /dev/vkbdctl141 /dev/vkbdctl14104 /dev/vkbdctl1411 /dev/vkbdctl14115 /dev/vkbdctl14120 /dev/vkbdctl14126 /dev/vkbdctl14131 /dev/vkbdctl14137 /dev/vkbdctl1417 /dev/vkbdctl1410 /dev/vkbdctl14105 /dev/vkbdctl14110 /dev/vkbdctl14116 /dev/vkbdctl14121 /dev/vkbdctl14127 /dev/vkbdctl14132 /dev/vkbdctl14138 /dev/vkbdctl1418 /dev/vkbdctl14100 /dev/vkbdctl14106 /dev/vkbdctl14111 /dev/vkbdctl14117 /dev/vkbdctl14122 /dev/vkbdctl14128 /dev/vkbdctl14133 /dev/vkbdctl14139 /dev/vkbdctl1419 /dev/vkbdctl14101 /dev/vkbdctl14107 /dev/vkbdctl14112 /dev/vkbdctl14118 /dev/vkbdctl14123 /dev/vkbdctl14129 /dev/vkbdctl14134 /dev/vkbdctl1414 /dev/vkbdctl14102 /dev/vkbdctl14108 /dev/vkbdctl14113 /dev/vkbdctl14119 /dev/vkbdctl14124 /dev/vkbdctl1413 /dev/vkbdctl14135 /dev/vkbdctl1415 /dev/vkbdctl14103 /dev/vkbdctl14109 /dev/vkbdctl14114 /dev/vkbdctl1412 /dev/vkbdctl14125 /dev/vkbdctl14130 /dev/vkbdctl14136 /dev/vkbdctl1416 Can we put a connect test in client_rescan before creating a new device? I believe psm 1 needs to be available anyhow. /usr/src/usr.sbin/bluetooth/bthidd/client.c int32_t client_rescan(bthid_server_p srv) { static hid_device_p d; bthid_session_p s; assert(srv != NULL); if (connect_in_progress) return (0); /* another connect is still pending */ /* check if we can connect to host on psm 1 */ int testsock; struct sockaddr_l2cap l2addr; testsock = socket(AF_BLUETOOTH, SOCK_SEQPACKET, BLUETOOTH_PROTO_L2CAP); l2addr.l2cap_len = sizeof(l2addr); l2addr.l2cap_family = AF_BLUETOOTH; memcpy(&l2addr.l2cap_bdaddr, &s->bdaddr, sizeof(l2addr.l2cap_bdaddr)); l2addr.l2cap_psm = htole16(0x1); if (bind(testsock, (struct sockaddr *) &l2addr, sizeof(l2addr)) < 0) { syslog(LOG_ERR, "Could not connect to host. " \ "%s (%d)", strerror(errno), errno); return (-1); } d = get_next_hid_device(d); /* create vkbd, etc */ ... Or maybe there's a better way? Thank you, -- Waitman Gobble Los Altos California USA 510-830-7975 From owner-freebsd-bluetooth@FreeBSD.ORG Wed Apr 22 17:45:06 2015 Return-Path: Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 63757ADC for ; Wed, 22 Apr 2015 17:45:06 +0000 (UTC) Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2EBFC1E8F for ; Wed, 22 Apr 2015 17:45:06 +0000 (UTC) Received: by igblo3 with SMTP id lo3so3106540igb.0 for ; Wed, 22 Apr 2015 10:45:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=jmXUTELpqnAbZ6YBhktZzQ4T/vj9OoK4oj9/L2AaEMY=; b=tJfUHd7MSKrUFhHtxzc3lne/UZGaPw/TK0j+ww7X3fk1Sr+qHwVtNU5bs4f5OQfcaA L5dfIA4inQXsfqL7PoeZxRjZsgA1D2xAbDoNrxiEjZiJ442QNqwEBwoXZo+J17DCRz48 8NZs+iaZoE3wTyYrSy6Eeq1s3XxKto568lEr7U1G5BWa+i4YNFQi9EVCfV+fGN0PtjUg ylv8wAg5fJ3Fpzg7XoEWp6/QKJE6YDRBslkzryiGmUJxxqjNkg9jJ9+06VGc07MgzRkJ ITTSMVT4F+ESP52uwRctc4/HcnJQZzRMteYf11WeqEW59CmdkxloowaWhtjmrs55j/El pdKQ== MIME-Version: 1.0 X-Received: by 10.43.63.76 with SMTP id xd12mr11346815icb.11.1429724705515; Wed, 22 Apr 2015 10:45:05 -0700 (PDT) Received: by 10.36.66.17 with HTTP; Wed, 22 Apr 2015 10:45:05 -0700 (PDT) In-Reply-To: References: Date: Wed, 22 Apr 2015 10:45:05 -0700 Message-ID: Subject: Re: question about bthidd client.c From: Maksim Yevmenkin To: Waitman Gobble Cc: "freebsd-bluetooth@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2015 17:45:06 -0000 On Tue, Apr 21, 2015 at 10:34 PM, Waitman Gobble wrote: > > I notice that if bthidd is running, and bluetooth is not active, or > the configured host is out of range, the client_rescan() function > generates new vkbd devices every 20 seconds or so. I believe this will > eventually lock up the machine. > may be... usually devices will reconnect, i.e. reconnect_initiate would be 1. however, this is a known problem. for whatever reason "cloned" devices are not completely going away when closed. similar problem exists with other "cloned" devices. its not bthidd or bluetooth code specific. thanks max From owner-freebsd-bluetooth@FreeBSD.ORG Wed Apr 22 17:57:26 2015 Return-Path: Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E6BBFD4B for ; Wed, 22 Apr 2015 17:57:26 +0000 (UTC) Received: from mail-ob0-x230.google.com (mail-ob0-x230.google.com [IPv6:2607:f8b0:4003:c01::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AD1801FB5 for ; Wed, 22 Apr 2015 17:57:26 +0000 (UTC) Received: by oblw8 with SMTP id w8so177100086obl.0 for ; Wed, 22 Apr 2015 10:57:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=9BHwIVXGRdrHp9vVzgqyeaPrwrmWi7lkWq5JuNJ35MU=; b=ef96fXSf1xt3h1ep6Yd9TPUJsekwf0brlcxNL9dXfLvMHTxeyKUQ1eSl9JEg38CXxQ iJETda4bGJEliWDsRsdwRQNI2LteZLFU1h3UGrdd0wgBZ0wF5/ba8rlBQBw2GrYRRNfw 6nWGTD6MKYSmgR93pCNgtgLlr7pEJPck0endkou+aE4y3mjj6Smcj893DEH1laOpCMf5 KP5wiaXndHm/i4TkxYA6PXeKAwgxoZmOlbD+3qTlJWW6NHJhVwtd5A5JsPhFDP/FU4da CZlNBc32qbMUuI3HuAAPAlanT8N81jrJ/cjcf8WP/HmewgviOaF1C2EDYneuReeW/z1E QzIg== MIME-Version: 1.0 X-Received: by 10.202.183.214 with SMTP id h205mr23247857oif.87.1429725445472; Wed, 22 Apr 2015 10:57:25 -0700 (PDT) Received: by 10.202.177.85 with HTTP; Wed, 22 Apr 2015 10:57:25 -0700 (PDT) In-Reply-To: References: Date: Wed, 22 Apr 2015 10:57:25 -0700 Message-ID: Subject: Re: question about bthidd client.c From: Waitman Gobble To: Maksim Yevmenkin Cc: "freebsd-bluetooth@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2015 17:57:27 -0000 On Wed, Apr 22, 2015 at 10:45 AM, Maksim Yevmenkin wrote: > On Tue, Apr 21, 2015 at 10:34 PM, Waitman Gobble wrote: >> >> I notice that if bthidd is running, and bluetooth is not active, or >> the configured host is out of range, the client_rescan() function >> generates new vkbd devices every 20 seconds or so. I believe this will >> eventually lock up the machine. >> > > may be... usually devices will reconnect, i.e. reconnect_initiate > would be 1. however, this is a known problem. for whatever reason > "cloned" devices are not completely going away when closed. similar > problem exists with other "cloned" devices. its not bthidd or > bluetooth code specific. > > thanks > max Thanks for the reply. Is there a better way to decide if a device is 'connectable'? It looks like a chicken-and-egg kind of problem, since the connect routine uses the established vkbd device. I am thinking that attempting to connect to the device on psm 1 is a way to verify that the host is connectable in the first place, before creating a new vkbd. Or, maybe the new vkbd can be destroyed on failure... but maybe this would cause other problems. I noticed this problem when I had the dongle unplugged, so there was no bluetooth available. But I had left bthidd set to start in rc.conf. Thank you, -- Waitman Gobble Los Altos California USA 510-830-7975 From owner-freebsd-bluetooth@FreeBSD.ORG Wed Apr 22 18:17:11 2015 Return-Path: Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E2C9E411 for ; Wed, 22 Apr 2015 18:17:11 +0000 (UTC) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id ACB3B1208 for ; Wed, 22 Apr 2015 18:17:11 +0000 (UTC) Received: by iecrt8 with SMTP id rt8so43894031iec.0 for ; Wed, 22 Apr 2015 11:17:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/fYueXMlLL+c8gPdd9V6OoD/FzlCuMPDsxgViN5/6fo=; b=jZb3S9qreW21pIrOh4oLT9nXg3d2wEYUF+bfDvPcW0ukrVcXrg3k8Rcwg/RL9UvhnG ipupjhlZuV0CpzUWtmsLs74zrTKFCRRvzZLuBTFv/n3p3FCfEjZP9lOXpDiEVId+uw6L o/8F5eXqSBCuOtA6ewC0EjTjN69zzLArK+ki3q0cfSe6bOfyUoRJPNDzz+GDZoZQn8oi d8TkcdnknSjmVujGKmd+ZNpbgNINzlr1NvO7gL6KCUm8MrtPHrjTSvoX+o3cK4/KUg0v qLJzbS/zYbq0x3yxg7vI4mp1SuvqjvX9dIM0O8Oqyk4EOfOE5I1YiKMjKq5wXSC4y4pj pH2Q== MIME-Version: 1.0 X-Received: by 10.50.66.230 with SMTP id i6mr6525665igt.22.1429726630911; Wed, 22 Apr 2015 11:17:10 -0700 (PDT) Received: by 10.36.66.17 with HTTP; Wed, 22 Apr 2015 11:17:10 -0700 (PDT) In-Reply-To: References: Date: Wed, 22 Apr 2015 11:17:10 -0700 Message-ID: Subject: Re: question about bthidd client.c From: Maksim Yevmenkin To: Waitman Gobble Cc: "freebsd-bluetooth@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2015 18:17:12 -0000 >>> I notice that if bthidd is running, and bluetooth is not active, or >>> the configured host is out of range, the client_rescan() function >>> generates new vkbd devices every 20 seconds or so. I believe this will >>> eventually lock up the machine. >>> >> >> may be... usually devices will reconnect, i.e. reconnect_initiate >> would be 1. however, this is a known problem. for whatever reason >> "cloned" devices are not completely going away when closed. similar >> problem exists with other "cloned" devices. its not bthidd or >> bluetooth code specific. > > Thanks for the reply. Is there a better way to decide if a device is > 'connectable'? It looks like a chicken-and-egg kind of problem, since device tells host who is supposed to initiate reconnect (in sdp attribute). normally, devices will initiate reconnect. host should not be required to constantly "poll". there is no easy way to know if device is "connectable". inquiry may tell you if device is in range but only if device is in "discoverable" mode. most devices will only go into discoverable mode during pairing. > the connect routine uses the established vkbd device. I am thinking > that attempting to connect to the device on psm 1 is a way to verify > that the host is connectable in the first place, before creating a new > vkbd. Or, maybe the new vkbd can be destroyed on failure... but maybe > this would cause other problems. there should not be any problem. cloned device is created on open() and should be destroyed on close(). thanks max From owner-freebsd-bluetooth@FreeBSD.ORG Wed Apr 22 18:26:21 2015 Return-Path: Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A871F4E5 for ; Wed, 22 Apr 2015 18:26:21 +0000 (UTC) Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 71ABA1301 for ; Wed, 22 Apr 2015 18:26:21 +0000 (UTC) Received: by iget9 with SMTP id t9so623098ige.1 for ; Wed, 22 Apr 2015 11:26:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vX8/P67RCyaFz1nxaBw5maiUcpBZLN7U3LVlaeSeeug=; b=rVTF/x0oWWTdXiIGYdi9e0gGkNKy9h6QTeyDqdyAfR2REAmcxkh27ar9yLQ0NoEvFi rlGYUD7485vBAdEpjA3vJ4+R+wE62vw/ZTs/V0s6G0rmqBmsSHyuCt3iEsrVF+Ku7k6W h241xUCdyvXaMX9Vdlq1VXLca4likLKt3nSYmeFGSZGllzel7B+mOrdbIsGSPx5S5sX/ Fxy3RpIo2AQrk2ZNmwRFpDI9gPuEiHwW8rbYHXeiOLEQ8D/KHKJ+mlGj7myAxopO4r85 SfdQXe7pIVbJNiP2yRKm+Mu7jm1VUyuUOOs7wVS5Sjz2XJwVRAGQpTzRib3z/0ZI33h2 x4Tg== MIME-Version: 1.0 X-Received: by 10.43.63.76 with SMTP id xd12mr11563592icb.11.1429727180895; Wed, 22 Apr 2015 11:26:20 -0700 (PDT) Received: by 10.36.66.17 with HTTP; Wed, 22 Apr 2015 11:26:20 -0700 (PDT) In-Reply-To: References: Date: Wed, 22 Apr 2015 11:26:20 -0700 Message-ID: Subject: Re: question about bthidd client.c From: Maksim Yevmenkin To: Waitman Gobble Cc: "freebsd-bluetooth@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2015 18:26:21 -0000 On Wed, Apr 22, 2015 at 11:17 AM, Maksim Yevmenkin wrote: >>>> I notice that if bthidd is running, and bluetooth is not active, or >>>> the configured host is out of range, the client_rescan() function >>>> generates new vkbd devices every 20 seconds or so. I believe this will >>>> eventually lock up the machine. >>>> >>> >>> may be... usually devices will reconnect, i.e. reconnect_initiate >>> would be 1. however, this is a known problem. for whatever reason >>> "cloned" devices are not completely going away when closed. similar >>> problem exists with other "cloned" devices. its not bthidd or >>> bluetooth code specific. >> >> Thanks for the reply. Is there a better way to decide if a device is >> 'connectable'? It looks like a chicken-and-egg kind of problem, since > > device tells host who is supposed to initiate reconnect (in sdp > attribute). normally, devices will initiate reconnect. host should not > be required to constantly "poll". there is no easy way to know if > device is "connectable". inquiry may tell you if device is in range > but only if device is in "discoverable" mode. most devices will only > go into discoverable mode during pairing. > >> the connect routine uses the established vkbd device. I am thinking >> that attempting to connect to the device on psm 1 is a way to verify >> that the host is connectable in the first place, before creating a new >> vkbd. Or, maybe the new vkbd can be destroyed on failure... but maybe >> this would cause other problems. > > there should not be any problem. cloned device is created on open() > and should be destroyed on close(). the simplest solution to this problem is to add a configuration parameter that specifies vkbd unit number for each entry. this way, the same device (i.e. keyboard) will always use the same vkbd. no more endless cloning. thanks, max From owner-freebsd-bluetooth@FreeBSD.ORG Wed Apr 22 18:28:30 2015 Return-Path: Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8E5A5535 for ; Wed, 22 Apr 2015 18:28:30 +0000 (UTC) Received: from mail-ob0-x22e.google.com (mail-ob0-x22e.google.com [IPv6:2607:f8b0:4003:c01::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 53259131C for ; Wed, 22 Apr 2015 18:28:30 +0000 (UTC) Received: by obcux3 with SMTP id ux3so72576215obc.2 for ; Wed, 22 Apr 2015 11:28:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=yAaxlAZHTb2rh6dujodl6lzdPxy/otPahd5eO+e26AY=; b=lznon0nJJyluSefjFHIDTkGmNVrzbtIE+1eZat7ZGyGMDkNPi2AaN+la8PWjqZ/hPm YB6jHDe0Xu0kCgS084MZgERVFoBb10yxKNOyKbur0AVhQmyoOlkehkh8mh2NCLlp9DfP JnZlo4+oLe/BGjkwxJN+Am+2Vn9FjBx9xT4dPCndvsr7T3KZrtsD5Xb4mT8EYcSVybnn og5hnA1Bb+REizTcvsSmkCWmpn5bTSQk02H57TwugH0DLLUd6DRN/cFpdLwbZyOo+2Aa 7r/QBNXz8K2291g7obztuwH2iB2DjverilgyMzVKQdRCLshsHtkMMxDac7HGPL28Y82c g9/Q== MIME-Version: 1.0 X-Received: by 10.182.115.167 with SMTP id jp7mr24983860obb.21.1429727309592; Wed, 22 Apr 2015 11:28:29 -0700 (PDT) Received: by 10.202.177.85 with HTTP; Wed, 22 Apr 2015 11:28:29 -0700 (PDT) In-Reply-To: References: Date: Wed, 22 Apr 2015 11:28:29 -0700 Message-ID: Subject: Re: question about bthidd client.c From: Waitman Gobble To: Maksim Yevmenkin Cc: "freebsd-bluetooth@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2015 18:28:30 -0000 On Wed, Apr 22, 2015 at 11:26 AM, Maksim Yevmenkin wrote: > On Wed, Apr 22, 2015 at 11:17 AM, Maksim Yevmenkin > wrote: >>>>> I notice that if bthidd is running, and bluetooth is not active, or >>>>> the configured host is out of range, the client_rescan() function >>>>> generates new vkbd devices every 20 seconds or so. I believe this will >>>>> eventually lock up the machine. >>>>> >>>> >>>> may be... usually devices will reconnect, i.e. reconnect_initiate >>>> would be 1. however, this is a known problem. for whatever reason >>>> "cloned" devices are not completely going away when closed. similar >>>> problem exists with other "cloned" devices. its not bthidd or >>>> bluetooth code specific. >>> >>> Thanks for the reply. Is there a better way to decide if a device is >>> 'connectable'? It looks like a chicken-and-egg kind of problem, since >> >> device tells host who is supposed to initiate reconnect (in sdp >> attribute). normally, devices will initiate reconnect. host should not >> be required to constantly "poll". there is no easy way to know if >> device is "connectable". inquiry may tell you if device is in range >> but only if device is in "discoverable" mode. most devices will only >> go into discoverable mode during pairing. >> >>> the connect routine uses the established vkbd device. I am thinking >>> that attempting to connect to the device on psm 1 is a way to verify >>> that the host is connectable in the first place, before creating a new >>> vkbd. Or, maybe the new vkbd can be destroyed on failure... but maybe >>> this would cause other problems. >> >> there should not be any problem. cloned device is created on open() >> and should be destroyed on close(). > > the simplest solution to this problem is to add a configuration > parameter that specifies vkbd unit number for each entry. this way, > the same device (i.e. keyboard) will always use the same vkbd. no more > endless cloning. > > thanks, > max Max, OK that sounds like the way to go. Thanks, -- Waitman Gobble Los Altos California USA 510-830-7975