public inbox for linux-bluetooth@vger.kernel.org
 help / color / mirror / Atom feed
From: "Rolf E. Thorup" <rolft@daimi.au.dk>
To: Marcel Holtmann <marcel@holtmann.org>
Cc: BlueZ Mailing List <bluez-users@lists.sourceforge.net>
Subject: Re: [Bluez-users] SDP problems on embedded device
Date: Tue, 20 Jul 2004 19:10:47 +0200	[thread overview]
Message-ID: <40FD5217.3060705@daimi.au.dk> (raw)
In-Reply-To: <1090334863.4400.124.camel@pegasus>

Hi Marcel

[SNIP, some "hcidump -t -x" output]

>>
>>and here's the output from the Cerfcube:
>>
>>HCIDump - HCI packet analyzer ver 1.9
>>device: hci0 snap_len: 1028 filter: 0xffffffff
>>1090319478.496750 > HCI Event: Connect Request (0x04) plen 10
>>   74 05 B1 76 0C 00 00 01 00 01
>>1090319478.497886 < HCI Command: Accept Connection Request (0x01|0x0009) 
>>plen 7
>>   74 05 B1 76 0C 00 01
>>1090319478.512733 > HCI Event: Command Status (0x0f) plen 4
>>   00 01 09 04
>>1090319478.546741 > HCI Event: Connect Complete (0x03) plen 11
>>   00 29 00 74 05 B1 76 0C 00 01 00
>>1090319478.547821 < HCI Command: Write Link Policy Settings 
>>(0x02|0x000d) plen 4
>>   29 00 0F 00
>>1090319478.550769 > HCI Event: Page Scan Repetition Mode Change (0x20) 
>>plen 7
>>   74 05 B1 76 0C 00 01
>>1090319478.564746 > HCI Event: Command Complete (0x0e) plen 6
>>   01 0D 08 00 29 00
>>1090319478.565797 < HCI Command: Change Connection Packet Type 
>>(0x01|0x000f) plen 4
>>   29 00 18 CC
>>1090319478.584718 > HCI Event: Max Slots Change (0x1b) plen 3
>>   29 00 05
>>1090319478.588740 > HCI Event: Command Status (0x0f) plen 4
>>   00 01 0F 04
>>1090319478.592739 > HCI Event: Connection Packet Type Changed (0x1d) plen 5
>>   00 29 00 18 CC
>>1090319478.602746 > ACL data: handle 0x0029 flags 0x02 dlen 12
>>     L2CAP(s): Connect req: psm 1 scid 0x0040
>>1090319478.604041 < ACL data: handle 0x0029 flags 0x02 dlen 16
>>     L2CAP(s): Connect rsp: dcid 0x0040 scid 0x0040 result 0 status 0
>>1090319478.612733 > HCI Event: Number of Completed Packets (0x13) plen 5
>>   01 29 00 01 00
>>1090319478.618741 > ACL data: handle 0x0029 flags 0x02 dlen 12
>>     L2CAP(s): Config req: dcid 0x0040 flags 0x0000 clen 0
>>1090319478.619937 < ACL data: handle 0x0029 flags 0x02 dlen 14
>>     L2CAP(s): Config rsp: scid 0x0040 flags 0x0000 result 0 clen 0
>>1090319478.620053 < ACL data: handle 0x0029 flags 0x02 dlen 12
>>     L2CAP(s): Config req: dcid 0x0040 flags 0x0000 clen 0
> 
> 
> the problem is that this "Config req" request never reaches the other
> side. And because of that the laptop sides sends a "Disonn req" after
> some time.
> 
> 
>>1090319478.642724 > HCI Event: Number of Completed Packets (0x13) plen 5
>>   01 29 00 01 00
>>1090319517.746003 > ACL data: handle 0x0029 flags 0x02 dlen 12
>>     L2CAP(s): Disconn req: dcid 0x0040 scid 0x0040
>>1090319517.746236 < ACL data: handle 0x0029 flags 0x02 dlen 12
>>     L2CAP(s): Disconn rsp: dcid 0x0040 scid 0x0040
>>1090319517.768987 > HCI Event: Number of Completed Packets (0x13) plen 5
>>   01 29 00 01 00
>>1090319519.848575 > HCI Event: Disconn Complete (0x05) plen 4
>>   00 29 00 13
> 
> 
> Try using 2.4.19-mh14 and show us the output of "hciconfig -a" on your
> Cerfcube. Is the Cerfcube a big endian machine?

After compiling a new kernel and reflashing:

[root@xscale3 /root]# hciconfig -a
hci0:   Type: USB
         BD Address: 00:0A:94:00:20:2A ACL MTU: 192:8  SCO MTU: 64:8
         UP RUNNING PSCAN ISCAN
         RX bytes:99 acl:0 sco:0 events:13 errors:0
         TX bytes:296 acl:0 sco:0 commands:12 errors:0
         Features: 0xff 0xff 0x0f 0x00 0x00 0x00 0x00 0x00
         Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
         Link policy: RSWITCH HOLD SNIFF PARK
         Link mode: SLAVE ACCEPT
         Name: 'xscale3'
         Class: 0x000100
         Service Classes: Unspecified
         Device Class: Computer, Uncategorized
         HCI Ver: 1.1 (0x1) HCI Rev: 0x1d3 LMP Ver: 1.1 (0x1) LMP 
Subver: 0x1d3
         Manufacturer: Cambridge Silicon Radio (10)

With regards to endianess, good quiestion. After googling around I 
actually think it can be both. But I made a small program testing it and 
it said little endian.

Regards, Rolf

  reply	other threads:[~2004-07-20 17:10 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-07-19 19:38 [Bluez-users] SDP problems on embedded device Rolf E. Thorup
2004-07-19 20:53 ` Marcel Holtmann
2004-07-20 10:31   ` Rolf E. Thorup
2004-07-20 14:47     ` Marcel Holtmann
2004-07-20 17:10       ` Rolf E. Thorup [this message]
2004-07-20 17:43         ` Marcel Holtmann
2004-07-21  9:43           ` Rolf E. Thorup
2004-07-21 10:04             ` Marcel Holtmann
2004-07-21 10:56               ` Rolf E. Thorup
2004-07-21 12:18                 ` Marcel Holtmann
2004-07-21 12:30                   ` Rolf E. Thorup
2004-07-28 14:05                     ` Rolf E. Thorup
2004-07-28 18:57                       ` Marcel Holtmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=40FD5217.3060705@daimi.au.dk \
    --to=rolft@daimi.au.dk \
    --cc=bluez-users@lists.sourceforge.net \
    --cc=marcel@holtmann.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox