From owner-freebsd-bluetooth@FreeBSD.ORG Mon Mar 30 03:48:17 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 C92B4F99 for ; Mon, 30 Mar 2015 03:48:17 +0000 (UTC) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (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 4DFC3880 for ; Mon, 30 Mar 2015 03:48:17 +0000 (UTC) Received: by wiaa2 with SMTP id a2so108905486wia.0 for ; Sun, 29 Mar 2015 20:48:15 -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=3/g3mpUlyDEIPfzDkvlz1j3G39dSATQMLKhG4CCw/pA=; b=IYdG+jdRTFUm/VuuL5AT04c4ScDVcBCv1fyL0A9v/U+BgNtKlnUE9pTfWHcYEPw2Ek 4cSxuTkMEyBlBn3iN0WlZdvgvY/cdMJr8ShnNJZ8OHZuMnrjAG3nSrBZVU5oELH/I5vo AaoyG1J+8LuvNA2cgnca1FuhDX2gJuqfOKkX9ylmaIQ/VSfHsRWyjb/2NA26HQE1mJjP X7vbxhaJOF4W8Q0nqVWcX7MApCSt9kL2fdhCzOpUuk9k+W6KOhMyLR9h8MSCiMOf3ZdJ QTs+jRQzE8SAxRN5hvMhyfsONI8yRp36le8ri5sRtkLigMfKkPc97xM9FOHmQInJa3m6 QRVg== MIME-Version: 1.0 X-Received: by 10.180.77.40 with SMTP id p8mr17813199wiw.1.1427687295879; Sun, 29 Mar 2015 20:48:15 -0700 (PDT) Received: by 10.27.91.75 with HTTP; Sun, 29 Mar 2015 20:48:15 -0700 (PDT) In-Reply-To: References: <0AD7A2F7-37BE-4F6A-9FD6-F6C81B2CAF36@gmail.com> Date: Sun, 29 Mar 2015 20:48:15 -0700 Message-ID: Subject: Re: register HID with SDP error From: Waitman Gobble To: Maksim Yevmenkin Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-bluetooth@freebsd.org" , Iain Hibbert X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2015 03:48:17 -0000 On Wed, Mar 25, 2015 at 8:46 AM, Waitman Gobble wrote: > On Wed, Mar 25, 2015 at 8:16 AM, Maksim Yevmenkin > wrote: >> Hello, >> >> sorry for the delay... >> >>> Through trial and error I found that this code is preventing the >>> response to the 0x0100 (L2CAP) query. >>> >>> in sdpd/ssar.c around line 230 or so. >>> >>> if (memcmp(&uuid, &puuid, sizeof(uuid)) != 0 && >>> memcmp(&uuid, &uuid_public_browse_group, sizeof(uuid)) != 0) >>> continue; >> >> right. this is to match uuid from the request with the uuid of >> registered services, or, special case, uuid for public browse group >> that is expected to return everything that is public. >> >>> When I comment that code out then it responds to the request with the >>> list of registered and advertised services and my clients then >>> magically connect. >> >> well, that's plain just wrong. you completely disabled any filtering. >> basically request for any uuid will return everything. including >> things that client has not asked for. the correct way is to add a list >> of addition uuid's (such as l2cap uuid) to every profile that should >> be checked as well. when client makes request for l2cap uuid it >> effectively asking to give back everything that "runs over l2cap". >> >>> Can you please explain the purpose of that code so I can fully >>> understand what I'm commenting out of the provider lookup loop in >>> sdpd/ssar.c ? >> >> please read above. also please read SDP spec, particularly part that >> talks about Service Search Request and Service Search Attribute >> Request. >> >> thanks >> max > > Thanks Max, I appreciate your reply and helpful information. > I will experiment and see if I can get this right. > > -- > Waitman Gobble > Los Altos California USA > 510-830-7975 Hi, I'm not sure I'm getting it right.. in ssar.c, if the uuid query is L2CAP 0x0100 i set dol2capquery = 1; /* * Service Search Attribute Response format * * value16 - 2 bytes AttributeListByteCount (not incl.) * seq8 len16 - 3 bytes * attr list - 3+ bytes AttributeLists * [ attr list ] */ ptr = rsp + 3; while (ssplen > 0) { SDP_GET8(type, sspptr); ssplen --; switch (type) { case SDP_DATA_UUID16: if (ssplen < 2) return (SDP_ERROR_CODE_INVALID_REQUEST_SYNTAX); memcpy(&uuid, &uuid_base, sizeof(uuid)); uuid.b[2] = *sspptr ++; uuid.b[3] = *sspptr ++; if ((uuid.b[2]==1) && (uuid.b[3]==0)) //0x0100 { dol2capquery = 1; } ssplen -= 2; break; Then while iterating through provider list, if the uuid matches something with l2cap then it sends back the response with those records. I don't think this should be 'hardcoded' in this way, but at the moment I'm tinkering. for (provider = provider_get_first(); provider != NULL; provider = provider_get_next(provider)) { if (!provider_match_bdaddr(provider, &srv->req_sa.l2cap_bdaddr)) continue; memcpy(&puuid, &uuid_base, sizeof(puuid)); puuid.b[2] = provider->profile->uuid >> 8; puuid.b[3] = provider->profile->uuid; if (dol2capquery) { switch (provider->profile->uuid) { case 0x1124: /* HID */ case 0x1200: /* PNP */ break; default: continue; break; } } else { if (memcmp(&uuid, &puuid, sizeof(uuid)) != 0 && memcmp(&uuid, &uuid_public_browse_group, sizeof(uuid)) != 0) continue; } My client is still connecting to PSM channels, but I'm seeing syntax errors https://gist.github.com/waitman/811e4dde41bfefd32054 So I'm wondering if i'm supposed to send the whole record or maybe just matching aids... Also just in case someone reading mailing list messages needs a way to associate BDADDR with 'previously negotiated human identification numbers' instead of hard config-file pins, I added a "BRIG" mode to hcsecd. As an example, you might want 1000 clients to pair and you wish to associate the BDADDR with a phone number or some other number the people know exclusively and can remember. # printf "5108307975" > /tmp/brig.txt Then the person pairs using their phone number. The tmp file is removed by hcsecd after use. This isn't something you'd want to set up a long time before pairing. But, like the person doing the pairing is standing there and is ready to pair. Then you can build an index of BDADDR with human id's which can be used later when either continuous scanning of devices and/or pairing from a database. https://github.com/waitman/hcsecd Thank you, -- Waitman Gobble Los Altos California USA 510-830-7975