Connecting three basix-bt-400m to one laptop master

[Jaya Kumar-5]

Hi,

I have 3 basix-400xm-bt that I'm trying to get bluetooth-ed
simultaneously to a laptop master. I can get any 2 of them working
simultaneously. But never 3 at the same time.

Basically, hcitool scan on the master never shows the 3rd gumstix. By
3rd, I mean the 3rd one to get turned on. hcitool scan on the 3rd
gumstix shows:

# hcitool inq
Inquiring ...
        00:80:37:2E:4C:DA       clock offset: 0x7ab4    class: 0x820116
        00:80:37:2E:4D:35       clock offset: 0x47e8    class: 0x820116
        00:15:E9:65:3B:C5       clock offset: 0x390a    class: 0x3e0100

and the master is 00:15:E9:65:3B:C5 so the 3rd gumstix can sort of see
the master. However a scan shows:

# hcitool scan
Scanning ...
        00:80:37:2E:4C:DA       Gumstix (0)
        00:15:E9:65:3B:C5       n/a
        00:80:37:2E:4D:35       Gumstix (0)

So it can see the other 2 gumstixes but can't name the master. Further:

# hcitool info 00:15:E9:65:3B:C5
Requesting information ...
Can't create connection: Input/output error
# hcitool name 00:15:E9:65:3B:C5
# echo $?
0
# hcitool cc 00:15:E9:65:3B:C5
Can't create connection: Input/output error

I'm stumped as to what's causing this and what to look at to solve it.
I'd really appreciate any suggestions.

Thanks,
jaya

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
gumstix-users mailing list
gumstix-users@...
https://lists.sourceforge.net/lists/listinfo/gumstix-users

[Brad Midgley-3]

Jaya

   hcitool con

will show you connections and include whether they are master or not.
Most hardware will not allow 3 scatternets which is why the 3rd
connection fails.

You need to make the laptop prefer to be master. in its
/etc/bluetooth/hcid.conf:

   lm accept,master;
   lp hold,sniff,park;

but the gumstix needs to allow itself to be slave (the default):

   lm accept;
   lp rswitch,hold,sniff,park;

Brad

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
gumstix-users mailing list
gumstix-users@...
https://lists.sourceforge.net/lists/listinfo/gumstix-users

[Jaya Kumar-5]

Hi Brad,

Thanks for your reply. I think I am using settings identical to your
description. Here's my config on my laptop and on each gumstix for
comparison:

laptop running ubuntu 6.10 edgy with d-link dbt-120 bluetooth dongle:
# cat /etc/bluetooth/hcid.conf
# Default settings for HCI devices
device {
        # Local device name
        #   %d - device id
        #   %h - host name
        name "%h-%d";

        # Local device class
        class 0x3e0100;

        # Default packet type
        #pkt_type DH1,DM1,HV1;

        # Inquiry and Page scan
        iscan enable; pscan enable;
        discovto 0;

        # Default link mode
        #   none   - no specific policy
        #   accept - always accept incoming connections
        #   master - become master on incoming connections,
        #            deny role switch on outgoing connections
        lm accept, master;

        # Default link policy
        #   none    - no specific policy
        #   rswitch - allow role switch
        #   hold    - allow hold mode
        #   sniff   - allow sniff mode
        #   park    - allow park mode
        lp hold,sniff,park;
}
-----------------------------------------------------------

and on each of the gumstix-s basix-bt-400m:

# cat /etc/bluetooth/hcid.conf
#
# HCI daemon configuration file.
#

# HCId options
options {
        # Automatically initialize new devices
        autoinit yes;

        # Security Manager mode
        #   none - Security manager disabled
        #   auto - Use local PIN for incoming connections
        #   user - Always ask user for a PIN
        #
        security auto;

        # Pairing mode
        #   none  - Pairing disabled
        #   multi - Allow pairing with already paired devices
        #   once  - Pair once and deny successive attempts
        pairing multi;

        # PIN helper
        pin_helper /etc/bluetooth/bluepin;

        # D-Bus PIN helper
        #dbus_pin_helper;
}

# Default settings for HCI devices
device {
        # Local device name
        #   %d - device id
        #   %h - host name
        name "Gumstix (%d)";

        # Local device class
        class 0x820116;

        # Default packet type
        #pkt_type DH1,DM1,HV1;

        # Inquiry and Page scan
        iscan enable; pscan enable;

        # Default link mode
        #   none   - no specific policy
        #   accept - always accept incoming connections
        #   master - become master on incoming connections,
        #            deny role switch on outgoing connections
        lm accept;

        # Default link policy
        #   none    - no specific policy
        #   rswitch - allow role switch
        #   hold    - allow hold mode
        #   sniff   - allow sniff mode
        #   park    - allow park mode
        lp rswitch,hold,sniff,park;

        # Authentication and Encryption (Security Mode 3)
        #auth enable;
        #encrypt enable;
}

So I think the configs match what you described.

Just to be verbose, here's the output from my tests. On the two
gumstix-s that boot first, I see:
# hciconfig -a
hci0:   Type: UART
        BD Address: 00:80:37:2E:46:22 ACL MTU: 339:11 SCO MTU: 93:14
        UP RUNNING PSCAN ISCAN
        RX bytes:15739 acl:193 sco:0 events:122 errors:0
        TX bytes:9755 acl:94 sco:0 commands:20 errors:0
        Features: 0xff 0xff 0x8f 0xfe 0x9b 0xf9 0x00 0x80
        Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
        Link policy: RSWITCH HOLD SNIFF PARK
        Link mode: SLAVE ACCEPT
        Name: 'Gumstix (0)'
        Class: 0x820116
        Service Classes: Networking
        Device Class: Computer, Palm
        HCI Ver: 2.0 (0x3) HCI Rev: 0x62b9 LMP Ver: 2.0 (0x3) LMP Subver: 0x62b9
        Manufacturer: Infineon Technologies AG (9)

# hcitool scan
Scanning ...
        00:80:37:2E:4C:DA       Gumstix (0)
        00:15:E9:65:3B:C5       my1-0
        00:80:37:2E:4D:35       Gumstix (0)

and similarly:

# hciconfig -a
hci0:   Type: UART
        BD Address: 00:80:37:2E:4D:35 ACL MTU: 339:11 SCO MTU: 93:14
        UP RUNNING PSCAN ISCAN
        RX bytes:12298 acl:148 sco:0 events:93 errors:0
        TX bytes:6072 acl:70 sco:0 commands:20 errors:0
        Features: 0xff 0xff 0x8f 0xfe 0x9b 0xf9 0x00 0x80
        Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
        Link policy: RSWITCH HOLD SNIFF PARK
        Link mode: SLAVE ACCEPT
        Name: 'Gumstix (0)'
        Class: 0x820116
        Service Classes: Networking
        Device Class: Computer, Palm
        HCI Ver: 2.0 (0x3) HCI Rev: 0x62b9 LMP Ver: 2.0 (0x3) LMP Subver: 0x62b9
        Manufacturer: Infineon Technologies AG (9)

# hcitool con
Connections:
        < ACL 00:15:E9:65:3B:C5 handle 256 state 1 lm MASTER

# hcitool scan
Scanning ...
        00:80:37:2E:4C:DA       Gumstix (0)
        00:15:E9:65:3B:C5       my1-0
        00:80:37:2E:46:22       Gumstix (0)

and on the laptop:
root@my1:~# hciconfig -a
hci0:   Type: USB
        BD Address: 00:15:E9:65:3B:C5 ACL MTU: 192:8 SCO MTU: 64:8
        UP RUNNING PSCAN ISCAN
        RX bytes:173127 acl:2732 sco:0 events:3381 errors:0
        TX bytes:476548 acl:3511 sco:0 commands:88 errors:0
        Features: 0xff 0xff 0x0f 0x00 0x00 0x00 0x00 0x00
        Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
        Link policy: HOLD SNIFF PARK
        Link mode: SLAVE ACCEPT
        Name: 'my1-0'
        Class: 0x3e0100
        Service Classes: Networking, Rendering, Capturing, Object
Transfer, Audio
        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)

root@my1:~# hcitool con
Connections:
        > ACL 00:80:37:2E:4D:35 handle 41 state 1 lm SLAVE
        > ACL 00:80:37:2E:46:22 handle 43 state 1 lm SLAVE

So everything is happy for the first 2 gumstix-s.

and on the gumstix that booted last, I see:
# hciconfig -a
hci0:   Type: UART
        BD Address: 00:80:37:2E:4C:DA ACL MTU: 339:11 SCO MTU: 93:14
        UP RUNNING PSCAN ISCAN
        RX bytes:426 acl:0 sco:0 events:19 errors:0
        TX bytes:352 acl:0 sco:0 commands:18 errors:0
        Features: 0xff 0xff 0x8f 0xfe 0x9b 0xf9 0x00 0x80
        Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
        Link policy: RSWITCH HOLD SNIFF PARK
        Link mode: SLAVE ACCEPT
        Name: 'Gumstix (0)'
        Class: 0x820116
        Service Classes: Networking
        Device Class: Computer, Palm
        HCI Ver: 2.0 (0x3) HCI Rev: 0x62b9 LMP Ver: 2.0 (0x3) LMP Subver: 0x62b9
        Manufacturer: Infineon Technologies AG (9)

# hcitool con
Connections:
# hcitool scan
Scanning ...
        00:15:E9:65:3B:C5       n/a
        00:80:37:2E:46:22       Gumstix (0)
        00:80:37:2E:4D:35       Gumstix (0)

So that one is not happy. Of course, if I change the boot order and
boot that one first, then it works fine. The laptop will then see:

# hcitool con
Connections:
        > ACL 00:80:37:2E:4D:35 handle 44 state 1 lm SLAVE
        > ACL 00:80:37:2E:4C:DA handle 41 state 1 lm SLAVE

So there doesn't appear to be any hardware issues. That also implies
that there aren't any positioning or radio related issues.

I'm confused as ever. It must be something in software since the boot
order is what determines which 2 gumstix-s work. Any ideas?

Thanks,
jaya

On Sat, May 17, 2008 at 10:35 AM, Brad Midgley <bmidgley@...> wrote:

> Jaya
>
>   hcitool con
>
> will show you connections and include whether they are master or not.
> Most hardware will not allow 3 scatternets which is why the 3rd
> connection fails.
>
> You need to make the laptop prefer to be master. in its
> /etc/bluetooth/hcid.conf:
>
>   lm accept,master;
>   lp hold,sniff,park;
>
> but the gumstix needs to allow itself to be slave (the default):
>
>   lm accept;
>   lp rswitch,hold,sniff,park;
>
> Brad
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> gumstix-users mailing list
> gumstix-users@...
> https://lists.sourceforge.net/lists/listinfo/gumstix-users
>

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
gumstix-users mailing list
gumstix-users@...
https://lists.sourceforge.net/lists/listinfo/gumstix-users

[Brad Midgley-3]

Jaya

Still sounds like scatterneting to me.

hcitool con, run on the laptop, should show MASTER for all its connections.

if you are running your own comms software, you could also request a
role switch programmatically.

anyway, hcidump -X -V will show what's going on. look for anything
about initiating connections and roles.

the one case where you can't guarantee a master role is if your laptop
connects to the gumstix and the gumstix refuses to change roles.

Brad

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
gumstix-users mailing list
gumstix-users@...
https://lists.sourceforge.net/lists/listinfo/gumstix-users

[Brad Midgley-3]

Jaya

You're also running pretty old stuff on that laptop. It looks like
you're doing everything else right. Things might work right on a newer
distro.

Brad

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
gumstix-users mailing list
gumstix-users@...
https://lists.sourceforge.net/lists/listinfo/gumstix-users

[EXT-McGhehey, Mark J]

Brad, Jaya,
  I have been having this very same issue for quite sometime.  For my
setup I use Gumstix Connex 400xm-bt motherboards (with pba31308 v1.01 BT
radios).  I have a piconet configured with one master and 6 slaves.  I
was using Gumstix's "buildroot" and bluez 2.24, but then moved to "OE",
so now I use Bluez 3.24.  This same problem occurs with both of these
environments.

  I have researched this quite abit and I have tried many different
"hcid" configurations.  My standard "hcid" configuration is exactly like
the one that Brad recommended.  BTW, I have posted a number of requests
for help on this forum and on the Bluez forums, but have not had anyone
respond until now.  So I am definitely grateful to have you helping out
Brad!

  So far the only conclusion that I have come to is that this has to do
with the "role switch" procedure not working properly.

  For example; for my setup I have the slave devices initiate the
connection with the piconet master device.  Once the connection is
established, a role switch should occur automatically (based upon the
configuration).  If, after the ACL connection is established, the slave
does not perform the role switch with the master, then it's "lm" state
remains as MASTER and then only two of the six slaves will ever achieve
an ACL connection with the piconet master device.

  The only way that I have been able to ensure a high degree of success
with getting all 6 slaves to connect properly is to montior the ACL
connections (via hcitool con) and to force a role switch in the cases
where it does not occur automatically.

  Thank you again, Brad, for helping out with this.  Can you please
provide me with greater details for "role switch" procedure?

Thanks!

Mark

-----Original Message-----
From: Brad Midgley [mailto:bmidgley@...]
Sent: Saturday, May 17, 2008 1:36 PM
To: General mailing list for gumstix users.
Subject: Re: [Gumstix-users] Connecting three basix-bt-400m to one
laptopmaster

Jaya

You're also running pretty old stuff on that laptop. It looks like
you're doing everything else right. Things might work right on a newer
distro.

Brad

------------------------------------------------------------------------
-
This SF.net email is sponsored by: Microsoft Defy all challenges.
Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
gumstix-users mailing list
gumstix-users@...
https://lists.sourceforge.net/lists/listinfo/gumstix-users

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
gumstix-users mailing list
gumstix-users@...
https://lists.sourceforge.net/lists/listinfo/gumstix-users

[Brad Midgley-3]

Mark

>  Thank you again, Brad, for helping out with this.  Can you please
> provide me with greater details for "role switch" procedure?

hcidump -X -V will show you what is happening with roles. It can reveal a lot.

it does sound like bugs somewhere.

You can programatically change roles. This is useful if you write the
code that makes bluez calls or if you want to hack the bluez services.

The other alternative is to change it with hcitool.

using hcid.conf is considered the sledgehammer approach since it
affects all traffic.

adding master to the link mode (lm) master is supposed to make the
device deny an immediate switch on outbound connections and try to
switch to master on new incoming connections. the remote side can
always deny the request.

removing rswitch from the link policy (lp) is supposed to make the
device deny requests from the remote side for us to switch roles
during the lifetime of the connection.

is this enough info to figure out where things go wrong? maybe
'rswitch' should be left in. for me I think I had a headset that would
later try to switch to master so I needed rswitch out.

--
Brad

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
gumstix-users mailing list
gumstix-users@...
https://lists.sourceforge.net/lists/listinfo/gumstix-users

[EXT-McGhehey, Mark J]

Brad,
  Thank you for your response.
   
  Just as you have prescibed, I have been using (lm) MASTER for the
piconet master device and (lp) RSWITCH for all devices in each
respective hcid.conf file.  The intent being to:
  a.) explicitly configure for a single device to assume the
      role of Master
  b.) permit a role switch to occur after the slave initiated
      connection has been established

  I have used hcidump and I observe that sometimes the Role Change hci
event is present and at other times it simply is not.

  For example, here's a hcidump snippet from a slave device where the
ACL connection and the role switch were both successful:

     root@gumstix_3> hcidump -X -V
     HCI sniffer - Bluetooth packet analyzer ver 1.40
     device: hci0 snap_len: 1028 filter: 0xffffffff

     < HCI Command: Create Connection (0x01|0x0005) plen 13
       bdaddr 00:80:37:2E:44:CC ptype 0xcc18 rswitch 0x01 clkoffset
0x0000
       Packet type: DM1 DM3 DM5 DH1 DH3 DH5
     > HCI Event: Command Status (0x0f) plen 4
       Create Connection (0x01|0x0005) status 0x00 ncmd 1
     > HCI Event: Role Change (0x12) plen 8
       status 0x00 bdaddr 00:80:37:2E:44:CC role 0x01
       Role: Slave
     > HCI Event: Connect Complete (0x03) plen 11
       status 0x00 handle 256 bdaddr 00:80:37:2E:44:CC type ACL encrypt
0x00
     > HCI Event: Max Slots Change (0x1b) plen 3
       handle 256 slots 5
     < ACL data: handle 256 flags 0x02 dlen 12
       L2CAP(s): Connect req: psm 15 scid 0x0040


  After cycling power on the piconet devices, here's a hcidump snippet
from the same device where, although the ACL connection was successful,
NO role change occurred:

     root@gumstix_3> hcidump -X -V
     HCI sniffer - Bluetooth packet analyzer ver 1.40
     device: hci0 snap_len: 1028 filter: 0xffffffff

     < HCI Command: Create Connection (0x01|0x0005) plen 13
       bdaddr 00:80:37:2E:44:CC ptype 0xcc18 rswitch 0x01 clkoffset
0x0000
       Packet type: DM1 DM3 DM5 DH1 DH3 DH5
     > HCI Event: Command Status (0x0f) plen 4
       Create Connection (0x01|0x0005) status 0x00 ncmd 1
     > HCI Event: Connect Complete (0x03) plen 11
       status 0x00 handle 256 bdaddr 00:80:37:2E:44:CC type ACL encrypt
0x00
     < ACL data: handle 256 flags 0x02 dlen 12
       L2CAP(s): Connect req: psm 15 scid 0x0040


  Given this unpredicatble behavior I have resorted to using hcitool
from with a dev-up script to force a role change, whenever necessary.


Mark
 
-----Original Message-----
From: Brad Midgley [mailto:bmidgley@...]
Sent: Monday, May 19, 2008 10:28 AM
To: General mailing list for gumstix users.
Subject: Re: [Gumstix-users] Connecting three basix-bt-400m to
onelaptopmaster

Mark

>  Thank you again, Brad, for helping out with this.  Can you please
> provide me with greater details for "role switch" procedure?

hcidump -X -V will show you what is happening with roles. It can reveal
a lot.

it does sound like bugs somewhere.

You can programatically change roles. This is useful if you write the
code that makes bluez calls or if you want to hack the bluez services.

The other alternative is to change it with hcitool.

using hcid.conf is considered the sledgehammer approach since it affects
all traffic.

adding master to the link mode (lm) master is supposed to make the
device deny an immediate switch on outbound connections and try to
switch to master on new incoming connections. the remote side can always
deny the request.

removing rswitch from the link policy (lp) is supposed to make the
device deny requests from the remote side for us to switch roles during
the lifetime of the connection.

is this enough info to figure out where things go wrong? maybe 'rswitch'

 should be left in. for me I think I had a headset that would later try
to switch to master so I needed rswitch out.

--
Brad

------------------------------------------------------------------------
-
This SF.net email is sponsored by: Microsoft Defy all challenges.
Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
gumstix-users mailing list
gumstix-users@...
https://lists.sourceforge.net/lists/listinfo/gumstix-users

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
gumstix-users mailing list
gumstix-users@...
https://lists.sourceforge.net/lists/listinfo/gumstix-users