Re: [Bluez-devel] L2CAP: One failing connection hurts others?

[Stefan Mischke <survivor@uni-paderborn.de>]

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