From: Stefan Mischke <survivor@uni-paderborn.de>
To: Marcel Holtmann <marcel@holtmann.org>
Cc: BlueZ Mailing List <bluez-devel@lists.sourceforge.net>
Subject: Re: [Bluez-devel] L2CAP: One failing connection hurts others?
Date: Tue, 14 Sep 2004 21:37:20 +0200 [thread overview]
Message-ID: <41474870.3020204@uni-paderborn.de> (raw)
In-Reply-To: <1095189878.5695.201.camel@pegasus>
Marcel Holtmann schrieb:
>before I start looking at the dump, include the output of hciconfig -a.
>
>
I forgot to mention that the hcidump was taken at the connecting client,
but that's obvious.
Ok, here are the hciconfig -a of all three devices:
00:02:72:B1:1D:6C is a listening server (master).
00:02:72:B1:1D:62 is also a listening server (master).
00:02:72:B1:59:46 is the connecting client (slave).
hci0: Type: USB
BD Address: 00:02:72:B1:59:46 ACL MTU: 192:8 SCO MTU: 64:8
UP RUNNING PSCAN ISCAN
RX bytes:403338 acl:11683 sco:0 events:15307 errors:0
TX bytes:222599 acl:7967 sco:0 commands:4111 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: 'BlueZ (0)'
Class: 0x000100
Service Classes: Unspecified
Device Class: Computer, Uncategorized
HCI Ver: 1.1 (0x1) HCI Rev: 0x20d LMP Ver: 1.1 (0x1) LMP Subver:
0x20d
Manufacturer: Cambridge Silicon Radio (10)
hci0: Type: USB
BD Address: 00:02:72:B1:1D:6C ACL MTU: 192:8 SCO MTU: 64:8
UP RUNNING PSCAN ISCAN
RX bytes:604827 acl:18955 sco:0 events:25430 errors:0
TX bytes:683933 acl:18133 sco:0 commands:2396 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: 'BlueZ (0)'
Class: 0x000100
Service Classes: Unspecified
Device Class: Computer, Uncategorized
HCI Ver: 1.1 (0x1) HCI Rev: 0x20d LMP Ver: 1.1 (0x1) LMP Subver:
0x20d
Manufacturer: Cambridge Silicon Radio (10)
hci0: Type: USB
BD Address: 00:02:72:B1:1D:62 ACL MTU: 192:8 SCO MTU: 64:8
UP RUNNING PSCAN ISCAN
RX bytes:344077 acl:15137 sco:0 events:11370 errors:0
TX bytes:395720 acl:10616 sco:0 commands:241 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: 'BlueZ (0)'
Class: 0x000100
Service Classes: Unspecified
Device Class: Computer, Uncategorized
HCI Ver: 1.1 (0x1) HCI Rev: 0x20d LMP Ver: 1.1 (0x1) LMP Subver:
0x20d
Manufacturer: Cambridge Silicon Radio (10)
>Are you sure that both of your listining servers are set for switching
>the role to master after connection? Remember that the connecting device
>is master in the first place.
>
>
>
Yes, I'm aware of that, but I don't know if this is a problem. It looks
like this at the client:
Connections:
< ACL 00:02:72:B1:1D:62 handle 0 state 5 lm MASTER
Connections:
< ACL 00:02:72:B1:1D:62 handle 44 state 1 lm SLAVE
Connections:
< ACL 00:02:72:B1:1D:62 handle 0 state 5 lm MASTER
Connections:
< ACL 00:02:72:B1:1D:62 handle 48 state 1 lm SLAVE
Connections:
< ACL 00:02:72:B1:1D:62 handle 0 state 5 lm MASTER
Connections:
< ACL 00:02:72:B1:1D:62 handle 47 state 1 lm SLAVE
Connections:
< ACL 00:02:72:B1:1D:6C handle 0 state 5 lm MASTER
Connections:
< ACL 00:02:72:B1:1D:6C handle 41 state 1 lm SLAVE
Connections:
< ACL 00:02:72:B1:1D:62 handle 0 state 5 lm MASTER
Connections:
< ACL 00:02:72:B1:1D:62 handle 46 state 1 lm SLAVE
Connections:
< ACL 00:02:72:B1:1D:6C handle 0 state 5 lm MASTER
Connections:
< ACL 00:02:72:B1:1D:6C handle 42 state 1 lm SLAVE
Connections:
< ACL 00:02:72:B1:1D:62 handle 0 state 5 lm MASTER
Connections:
< ACL 00:02:72:B1:1D:62 handle 48 state 1 lm SLAVE
Connections:
< ACL 00:02:72:B1:1D:62 handle 0 state 5 lm MASTER
Connections:
< ACL 00:02:72:B1:1D:62 handle 47 state 1 lm SLAVE
...
Regards
Stefan
next prev parent reply other threads:[~2004-09-14 19:37 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-09-14 15:20 [Bluez-devel] L2CAP: One failing connection hurts others? Stefan Mischke
2004-09-14 18:34 ` Marcel Holtmann
2004-09-14 19:11 ` Stefan Mischke
2004-09-14 19:24 ` Marcel Holtmann
2004-09-14 19:37 ` Stefan Mischke [this message]
2004-09-14 19:49 ` Marcel Holtmann
2004-09-14 20:10 ` Stefan Mischke
2004-09-14 21:12 ` Marcel Holtmann
2004-09-14 23:37 ` Stefan Mischke
2004-09-15 7:46 ` Marcel Holtmann
2004-09-15 14:00 ` Stefan Mischke
2004-09-15 21:09 ` Marcel Holtmann
2004-09-15 22:26 ` Stefan Mischke
2004-09-16 10:30 ` Stefan Mischke
2004-09-16 10:34 ` Marcel Holtmann
2004-09-16 10:39 ` Stefan Mischke
2004-09-16 11:00 ` Marcel Holtmann
2004-09-16 11:10 ` Stefan Mischke
2004-09-16 16:41 ` Stefan Mischke
2004-09-15 20:37 ` Stefan Mischke
2004-09-15 21:06 ` Marcel Holtmann
2004-09-15 22:13 ` Stefan Mischke
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=41474870.3020204@uni-paderborn.de \
--to=survivor@uni-paderborn.de \
--cc=bluez-devel@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.