android_get_control_socket fails....

[pavan savoy]

Hi,

 

 

I started the bluez hcid as root, after disabling the kernel feature that blocks creation of sockets [CONFIG_ANDROID_PARANOID_NETWORK] in the kernel,

 

Now If I start off hcid, I realise that the SDP server, isn't being initialised properly.

 

I get the error...

 

# hcid -f /etc/hcid.conf -d -n
hcid[681]: Bluetooth HCI daemon
hcid[681]: Enabling debug information
hcid[681]: Starting SDP server
hcid[681]: Adding rec : 0x3b628
hcid[681]: with handle : 0x1
hcid[681]: Adding rec : 0x3b788
hcid[681]: with handle : 0x0
hcid[681]: Service classes 0x00
hcid[681]: Unable to get the control socket for 'bluetooth'
hcid[681]: Server initialization failed

 

What is the reason ? where is android_get_control_socket defined, why do we need it ?

 

regards,

Pavan

[Nick Pelly]

This is some Android specific magic.

When two linux processes wish to communicate via a unix domain socket on a traditional linux distribution they often use /tmp. However on Android we got rid of /tmp for security and storage accountability reasons. Instead a mechanism was introduced for daemons to request a unix domain socket in /dev/socket than the init process creates on behalf of the daemon. The daemon just picks up the file descriptor from the environment.

See
/dev/socket
#define ANDROID_SOCKET_DIR
system/core/init/readme.txt keyword socket

The error you show here seems to indicate that hcid was unable to open the socket provided by init. Perhaps you did not use the socket syntax in your init.rc

Nick
Android Systems Engineer

[pavan savoy]

Yes, If I did a start hcid, it also created the required sockets, but on running from command line, it did not ..

/dev/socket/ didn't have a bluetooth entry.

 

Anyway, My problem is something like this,

 

I have an Obex Push server which is trying to register itself with SDP and cannot do so, because of some strange reason.

I suppose its something to do with permissions, so wanted to make sure, about it before digging into the reason...

 

regards,

Pavan

[Sidharth Malhotra]

Hi Nick,

I have been a silent observer of this group till now, but now I am
kinda stuck. I am able to run hciattach, hciconfig, hcitool, etc. but
while running hcid I get this error message:

"
bash-3.2# hcid
hcid[1155]: Bluetooth HCI daemon
hcid[1155]: Create and Bind socket
hcid[1155]: Can't open HCI socket: Operation not permitted (1)
hcid[1155]: Cant open HCI socket: Bad file number (9
"

Can you tell me how to avoid this? I can run hcid (start hcid) with
"bluetooth" user, but I guess since hcid is not running in root user
mode, I am facing this error. The relevant hcid entry in init.rc file
is:
service hcid /system/bin/logwrapper /system/bin/hcid -d -s -n -f
system/etc/hcid.conf
socket bluetooth stream 660 bluetooth bluetooth
socket dbus_bluetooth stream 660 bluetooth bluetooth
# init.rc does not yet support applying capabilities, so run as
root and
# let hcid drop uid to bluetooth with the right linux capabilities
group bluetooth net_bt_admin misc
user root
group bluetooth net_bt_admin misc
# disabled
oneshot

Still, when I do a ps, I cannot see hcid running.

Thanks,
Sidharth

> > Pavan- Hide quoted text -
>
> - Show quoted text -

[pavan savoy]

hciattach & hcid should be running as user "bluetooth" with both of them in group bluetooth & net_bt_admin.
If you are in development....
just remove the ANDROID_PARANOID_NETWORK option from your kernel.

regards,
Pavan

[Sidharth Malhotra]

Hi Pavan,

I am aware of this flag and have unset this to ensure that sockets can
be opened by hcid. But, I am still struggling with how to bring up
hcid.
By the way, can you share the init.rc file and the hcid source you are
running. It seems you also had certain problems earlier.

Since yesterday, I have been able to open the socket, but I am now
stuck on -

hcid[681]: Unable to get the control socket for 'bluetooth'

Were you able to resolve this one? I also saw that there is no
Bluetooth entry in /dev/socket. What to do now?

Thanks,
Sidharth

> > > - Show quoted text -- Hide quoted text -

[pavan savoy]

Hi,

Find the init.rc from the zoom2 product directory below.

http://git.omapzoom.org/?p=repo/android/vendor/ti/zoom2.git;a=blob;f=init.omapzoom2.rc;h=3434840e46a2694b5e42b77e027d6dd3c068989f;hb=HEAD

Recently I've added a new service by name hciattach_legacy which has the same definition as hciattach in init.rc, that's all.
And 1 more thing, hcid.conf path might have changed, and I've changed that in my local init.rc file.

Sockets as far as I know should be created in /data/misc/hcid/, I suppose [or somewhere there..]

[Sidharth Malhotra]

Hi Pavan

Thanks for the quick reply. I am essentially using this init.rc file
only, as fasr as hcid and hciattach go. That should help me for the
moment, right?
I did not understand how does adding another service hciattacth_legacy
help in running hcid? I'm sorry if I missed something.

I checked the /data/misc/hcid, and only the BD_ADDR of my device is
showing there. Any guess on how I can add the socket there? I just
need a way to get past that message:

hcid[681]: Unable to get the control socket for 'bluetooth'

The one that you also faced sometime back. :)

Thanks,
Sidharth

On Feb 3, 9:08 am, pavan savoy <pavan.sa...@gmail.com> wrote:
> Hi,
>

> Find the init.rc from the zoom2 product directory below.
>

> http://git.omapzoom.org/?p=repo/android/vendor/ti/zoom2.git;a=blob;f=...

[Nick Pelly]

Hi Sidharth,

I don't know exactly what is going wrong for you, but here are some ideas.

- The control sockets should be created by init for the hcid daemon in /dev/socket/bluetooth and /dev/socket/dbus_bluetooth. If they are not there then you have a problem.
- Your init.rc file looks ok.
- If you have the high speed uart drive in your kernel (/dev/ttyHS0 exists) then you don't need the hciattach_legacy entry in your board init.rc file. That entry was just there during the transition from low speed to high speed driver.

This one is important...
running hcid manually is _not_ the same as running it through the init.rc file. Those entries in the init.rc file like 'socket ....' tell init to create the /dev/socket entry AND to set some environment variables so that hcid can pick up a file descriptor to /dev/socket when it is run from init. You wont have a file descriptor to those control sockets if you try and run hcid manually.

That probably explains your error message, which is a red herring for the real problem.

To find the real issue you will want to run hcid via logwrapper in the init.rc file. logwrapper --help will explain. I think you may find the control socket is actually ok.

And are you running hciattach?

Nick

[Sidharth Malhotra]

Hi Nick,

Thanks for the detailed reply.

Yes, I am running hcid and hciattach manually. The problem is that all
the bluetooth modules (bluetooth.ko, l2cap.ko, etc.) are not present
as built-in modules. So, I need to do an insmod after the Android
image boots up on my device. Should I try using the built-in method
instead while I compile the kernel?

By the way, I had put my own log messages in hcid, and it seems that
token parsing was not happening fine. Now, I have solved that and hcid
is running as "bluetooth" user. I can also initiate pairing from
remote device now.

Thanks,
Sidharth

[Nick Pelly]

On Tue, Feb 3, 2009 at 12:18 AM, Sidharth Malhotra <sep...@gmail.com> wrote:

Hi Nick,

Thanks for the detailed reply.

Yes, I am running hcid and hciattach manually. The problem is that all
the bluetooth modules (bluetooth.ko, l2cap.ko, etc.) are not present
as built-in modules.

These should be compiled into the kernel, and are in the git android-msm-2.6.27 that we use both internally and publicly.
 

So, I need to do an insmod after the Android
image boots up on my device. Should I try using the built-in method
instead while I compile the kernel?

By the way, I had put my own log messages in hcid, and it seems that
token parsing was not happening fine. Now, I have solved that and hcid
is running as "bluetooth" user. I can also initiate pairing from
remote device now.

Glad it works :)

Nick
 

[pavan savoy]

Hey Nick,

Since you've brought it up.
I am working on OMAP which doesn't have the /dev/H* uart device node, so does that mean the bluedroid will try and call hciattach_legacy ?
Aren't things in bluedroid becoming too specific to msm ?

regards,
Pavan