Networking :: bluez-utils



The latest bluez-utils.uci should put symlinks for all the executables into /opt/bin which is in the path - could you check if this is so?

Even if the symlinks are in opt/bin (eg /opt/bin/hciconfig -> /opt/bluez-utils/sbin/hciconfig), it appears that scripts do not find them, at least in the script I tried. I do not know why this should be, but perhaps it could be fixed by putting a path statement at the start of the script?

Note also, you could put the bluetooth modules into /mydsl/modules to have them loaded automatically at boot if you use bluetooth all the time. The only drawback with this would be that the crc32 module needs to be loaded before the bnep module (if you use the bep module).

I have verified that the symlinks are in /opt/bin but when I execute:

sudo /op/bin/hcid
the response is:

sudo: /opt/bin/hcid: command not found

If I double click in emelfm over /opt/bin/hcid symlink the response is:

sh: line 1: ./hcid: no such file or directory
----end-of-output----

Now I delete this /opt/bin/hcid symlink and create a new one to /opt/bin/ from the /opt/bluez-utils/sbin/hcid and now this /opt/bin/hcid symlink works OK.

so I have verified that with all symlinks in /opt/bin occurs the same. Perhaps there is an error in the generation of the symlinks to /opt/bin.

Perhaps the key is the "line1: ./hcid" of the symlink, its lookink to a wrong place
Can you verified it?

I get the following when I load the latest extension:
Code Sample
$ ls -l /opt/bin/hcid
lrwxrwxrwx    1 root     root           34 Nov 23 09:47 /opt/bin/hcid -> /ramdisk/opt/bluez-utils/sbin/hcid

Maybe the problem is that it should read "/opt/bin/hcid -> /opt/bluez-utils/sbin/hcid".

Let me try with that and see if it makes a difference.

Quote (Juanito @ Nov. 23 2007,02:03)
I get the following when I load the latest extension:
Code Sample
$ ls -l /opt/bin/hcid
lrwxrwxrwx    1 root     root           34 Nov 23 09:47 /opt/bin/hcid -> /ramdisk/opt/bluez-utils/sbin/hcid

Maybe the problem is that it should read "/opt/bin/hcid -> /opt/bluez-utils/sbin/hcid".

Let me try with that and see if it makes a difference.

If you remember with the xorg extension, we had a similar problem with a similar symlink.  All the tests were done on frugal environments, where /ramdisk exists.  Our first traditional style hdd-install tester reported errors, which was fixed by changing the symlink as described.

Aaah - that would make sense. I created the symlinks by highlighting the whole lot in emelFM and clicking the "symlink" button, I guess I'll have to do it like this in future:
Code Sample
$ sudo ln -s /opt/my-app/bin/* /opt/bin

...but even allowing for that, a script to autostart a bt device wouldn't work for me either, I guess more trouble-shooting is required.

Edit (and here it is):
Code Sample
$ ls -l /opt/bin/hcid
lrwxrwxrwx    1 root     root           26 Nov 23 14:38 /opt/bin/hcid -> /opt/bluez-utils/sbin/hcid
$ cat /opt/mybt_test.sh
#!/bin/bash
#
hciconfig hci0 up
hcid restart
sdpd
#
# EOF

$ sudo /opt/mybt_test.sh
/opt/mybt_test.sh: line 3: hciconfig: command not found
/opt/mybt_test.sh: line 4: hcid: command not found
/opt/mybt_test.sh: line 5: sdpd: command not found

...but if I add a path statement:
Code Sample
$ cat /opt/mybt_test.sh
#!/bin/bash
#
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/X11R6/bin:/usr/local/sbin:/usr/local/bin:/usr/games:/opt/bin:.
#
hciconfig hci0 up
hcid restart
sdpd
#
# EOF

$ sudo /opt/mybt_test.sh
$ hciconfig
hci0:   Type: USB
       BD Address: 00:10:C6:56:F4:9F 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:300 acl:0 sco:0 commands:13 errors:0

- so it appears /opt/bin is not in the path as far as running scripts is concerned?

Next Page...
original here.