register HID with SDP error

[Waitman Gobble]

On Mar 23, 2015 12:06 AM, "Iain Hibbert" <plunky at ogmig.net> wrote:
>
> On Sun, 22 Mar 2015, Waitman Gobble wrote:
>
> > >> btw .. if you use sdpcontrol(1) to query the local SDP server (see
-l)
> > >> then hcidump will not see anything of the interchange, since it does
not
> > >> go through the Bluetooth stack.
> > >
> > > absolutely correct
> >
> > I'm tracking down a client connection problem, maybe this is causing
> > the issue...
>
> I doubt that is causing anything, exactly
>
> > checking it out.
> >
> > https://gist.github.com/waitman/c51ea08ebb6a2898f33f
> >
> > client gives up and never opens PSM channel 17 or 19
>
> you didn't say what client it is, and why it should try to connect to HID?
> Not all will, of course.. It may be more pertinient that when it searches
> for L2CAP, it did not discover any services? Searching for L2CAP is a lazy
> way to enumerate services, as many devices failed to provide a proper
> browse group, but if a device is looking for HID then I would expect it to
> search for HID?

Yes, it may be lazy perhaps. However, I have noticed that when the l2cap
query results are returned (see my note about commenting out a line if code
to get a response sent back).. then it starts working as HID keyboard on
android phone, Windows installs a device driver and registers as keyboard,
and mac os x comes up with a message about unrecognized keyboard, and
closes both PSM connections. (i was faking an apple keyboard which is risky
when actually connecting to an apple computer i suppose. I need to work
that out)

without the reaoonse to the l2cap query, the virtual HID shows up on these
devices as a keyboard, and after pairing the connection is stopped before
ever opening psm channel 17 or 19

Thank you.

>
> > I did notice some clients request 0x1200 'pnp info' so I added
> > SDP_SERVICE_CLASS_PNP_DEVICE handler to sdpd to see what would happen.
> > The code is here -> https://github.com/waitman/sdpd/blob/master/pnp.c
> > But the configuration parameters should be set by the request, not
> > hardcoded into pnp.c (also hid.c should be fixed)
>
> The PNP Info can be useful, I use it for example (on NetBSD) to get the
> product and vendor IDs in order to match a specific driver for the Apple
> Magic Mouse, rather than the generic Bluetooth HID mouse driver.
>
> regards,
> iain
> _______________________________________________
> freebsd-bluetooth at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-bluetooth
> To unsubscribe, send any mail to "
freebsd-bluetooth-unsubscribe at freebsd.org"