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