Re: [Bluez-users] Re: PROBLEM: Apple powerbook, Apple BT keyboard, keyboard does not reconnect on reboot

[Matthew Grant <grantma@anathoth.gen.nz>]

[-- Attachment #1: Type: text/plain, Size: 4591 bytes --]

Hi Marcel,

My first ideas about the kernel realigning things are wrong, its actually the 
struct hidp_connlist_req definitions not matching.

Real reason for it is this, user-space thinks cnum field is 16 bit, kernel 
thinks it is 32 bit.  Bug only shows up in big-endian architectures as result
count is returned in top byte of what is received from the kernel, whereas on
i386 it is in the lowest where by fluke it works...

Mismatch in the kernel and user-space  header files:

in the kernel, net/bluetooth/hid/hdip.h: 

struct hidp_connlist_req {
        __u32  cnum;
        struct hidp_conninfo __user *ci;
};

in libbluetoth, include/bluetooth/hidp.h:

struct hidp_connlist_req {
        uint16_t cnum;
        struct hidp_conninfo *ci;
};

Which way should we go here?  We need to fix kernel or user-space, and I need your 
'official' touch before I post a patch in the Debian bug report I am going to submit.
The fix I prefer affects the user-space bluetooth include files.

My inclination is to convert user space from uint16_t 
to uint32_t for the cnum field as this will properly byte-align the following pointer
on a 4-byte boundary.  Some architectures throw exceptions on non-aligned pointer
dereferences and accesses, and this is why I suspect the kernel may have been changed.


Cheers,

Matthew Grant

PS: Following is here for reference.


Found what is wrong with hidd --show on powerpc.  

In function do_show(), main.c, hidd

The kernel is converting the size of the cnum record entry of struct
hidp_connlist_req from 2 bytes to 4, probably in an attempt to align the
pointer on a 4 byte boundary.  The program has not been compiled to take
account of this and thinks req.cnum is zero.... If this happens on Intel
it would not show up as the returned count would be written into the
first byte of the returned 4 byte integer...  I don't know what effect
this would be having on the programs stack, but more than 15 BT
connections could result in a buffer overflow.

Need to change cnum field of struct hidp_connlist_req to a uint32 to
stop this, and it should all start working...

gdb session output follows.

(gdb) run
The program being debugged has been started already.
Start it from the beginning? (y or n) y

Starting program: /usr/src/bluetooth/debug/bluez-utils-2.11/hidd/hidd
--show

Breakpoint 1, do_show (ctl=7) at main.c:364
364             printf("do_show(): req.cnum %d, req.ci 0x%x\n",
req.cnum, req.ci);
(gdb) n
361             req.cnum = 16;
(gdb) n
355     {
(gdb) n
362             req.ci   = ci;
(gdb) n
364             printf("do_show(): req.cnum %d, req.ci 0x%x\n",
req.cnum, req.ci);
(gdb) n
do_show(): req.cnum 16, req.ci 0x7fffedd0
365             if (ioctl(ctl, HIDPGETCONNLIST, &req) < 0) {
(gdb) x/8xb 0x7ffff730
0x7ffff730:     0x00    0x10    0xf7    0x70    0x7f    0xff    0xed   
0xd0
(gdb) n
371             printf("do_show(): req.cnum %d, req.ci 0x%x\n",
req.cnum, req.ci);
(gdb) x/8xb 0x7ffff730
0x7ffff730:     0x00    0x00    0x00    0x01    0x7f    0xff    0xee   
0x64
(gdb)

Cheers,

Matthew Grant


On Tue, 2004-11-09 at 08:53, Marcel Holtmann wrote:
> Hi Matthew,
> 
> > Just got debug going.  Going to put printks into hidp_get_connlist to
> > see what is happening.
> > 
> > Your comment on the big endian bug in the L2CAP you noticed below, and
> > some of the debug I have seen with the other BT problems make it look
> > like I am having endianess issues. 
> > 
> > I am going to print the kernel code tonight and read it through as it is
> > obvious I have to understand the stack if I am get things fixed - you
> > don't have access to an Apple machine to test things on.  In the past I
> > was a commercial router programmer, doing OSPF and IPX development.
> > 
> > Any good places to find protocol specs?  I especially need
> > specifications on the endianess of the incoming BT data so I can audit
> > and check the debug for that sort of thing.
> 
> everything is in the Bluetooth core and HID profile specification.
> 
> It must not be an endian problem, because other people with Apple
> machines are using HID. May you wanna try another compiler.
> 
> Regards
> 
> Marcel
> 
-- 
===============================================================================
Matthew Grant        /\  ^/\^   grantma@anathoth.gen.nz      /~~~~\
A Linux Network Guy /~~\^/~~\_/~~~~~\_______/~~~~~~~~~~\____/******\
===GPG KeyID: 2EE20270  FingerPrint: 8C2535E1A11DF3EA5EA19125BA4E790E2EE20270==


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]