BT module in Slackware

chekkizhar

How to enable bluetooth in slackware?

marc

linustorvalds wrote:

How to enable bluetooth in slackware?

Install bluez and bluez-utils

modprobe bluetooth

/etc/init.d/bluetooth start (or service bluetooth start)

hcitool scan

There you go.

You could as well have a look at installing gnome-bluetooth or bluedevil (for kde)

Regards

mfillpot

if you performed a full installation then the bluetooth libraries and applications are installed, you will only need to start the service by running (as root) "sh /etc/rc.d/rc.bluetooth" and if you want the service to start on boot you need to set /etc/rc.d/rc.bluetooth to be executable. The blueman gui configuration tool is also installed in a full slackware installation for simplified configuration.

chekkizhar

I installed Slackware almost with default settings. Is there any way to find out whether the installation is full one?

When i tried "sh /etc/rc/d/rc/bluetooth" i got "Usage: { start|stop|restart}
I append start with that command. Simply the terminal promt came without any success/failed messge

when I tried "/etc/rc/d/rc/bluetooth" alone, I got "Permission Denied". But, I ran as root only.

With gui, If i click bluetooth manager, its saying, "Bluez deamon is not running,blueman manager can not continue"


"/etc/rc.d/rc.bluetooth executable?" No, when I checked the mode, there was no execute permission for anyone.

Then I changed the permissions. Now, its working. Thank you very much.

I tried so many forums and tried a lot. But, mathew, the word you told about, "executable" solved my problem. But, not for start on boot , even for manual start also, it should be executable, I think. you are GREAT

thank you marc , since bluetooth installed already with distro, I finished with simple mode changing. thanks man:laugh:

chekkizhar

thank you marc , since bluetooth installed already with distro, I finished with simple mode changing. thanks man

chekkizhar

I hope, I almost know who is the 2012 Linux Guru?. any guess mathew ? :-)

and why there is no default permission to execute "/etc/rc.d/rc.bluetooth", even for root ? what reason ?

marc

linustorvalds wrote:

I hope, I almost know who is the 2012 Linux Guru?. any guess mathew ? :-)

and why there is no default permission to execute "/etc/rc.d/rc.bluetooth", even for root ? what reason ?

That looks like a bug.

If you feel up to it, check the Slackware bugtracker and submit a bug report if it's not already there.

Regards

PS: in *nix like permission system execute bit is not for "root" rather than for the owner, group or everybody else

chekkizhar

"If you feel up to it, check the Slackware bugtracker and submit a bug report if it's not already there."

ok

" "in *nix like permission system execute bit is not for "root" rather than for the owner, group or everybody else"
ya, its user-group-others.
thanks man :-)

mfillpot

I am hoping that someone else gets ultimate guru this year, we have plenty of very knowledgeable and active people on the site that can easily take that title next year. Rather than focusing on the title, I try more to built an active community on the site with knowledgeable and helpful people. Marc and Eric Layton are my two top hopefuls for the top spot next year.

Sorry, the correct command that you were to run on /etc/rc.d/rc.bluetooth was "/etc/rc.d/rc.bluetooth start", I guess I forgot to type a single word.

The starting permissions of the files in /etc/rc.d were set by you in the initial installation, when it asked what services you want it changed each of the chosen files to executable, so you did not select to use the bluetooth service when you installed. That can be changed at any time in the terminal by tunning pkgtool, which will allow you to change most of the options that were chosen when you installed slackware.

The way the slackware init system works is that, in most cases when a service setup script in /etc/rc.d is set to executable it will be launched by the system when it is booted. You must remember that slackware does not really use any defaults, most things that will effect you are chosen when you install the OS, in this case you skipped through the step about choosing which services to use.

mfillpot

marc wrote:

linustorvalds wrote:

I hope, I almost know who is the 2012 Linux Guru?. any guess mathew ? :-)

and why there is no default permission to execute "/etc/rc.d/rc.bluetooth", even for root ? what reason ?

That looks like a bug.

If you feel up to it, check the Slackware bugtracker and submit a bug report if it's not already there.

Regards

PS: in *nix like permission system execute bit is not for "root" rather than for the owner, group or everybody else

As explained in my other post, not setting the script as executable by default is a feature, not a bug, the user forgot to choose to enable the Bluetooth service when it was installed. Plus, Slackware does not have a bug-tracker it only has Pat..lol

You will find that the lack of assumptions and the different organization by the development team in Slackware defy what other distros do. These differences are considered strengths by many of their users, but tend to confused people who come from more user-friendly distros

chekkizhar

" Rather than focusing on the title, I try more to built an active community on the site with knowledgeable and helpful people."

Great :-)

" Marc and Eric Layton are my two top hopefuls for the top spot next year. "

we are also waiting. I feel like waiting for my school results

" Sorry, the correct command that you were to run on /etc/rc.d/rc.bluetooth was "/etc/rc.d/rc.bluetooth start", I guess I forgot to type a single word. "

No problem. It happens to everyone



"you did not select to use the bluetooth service when you installed"

may be. Next time, I will be more alert during installation.



" slackware does not really use any defaults, most things that will effect you are chosen when you install the OS "

thats why more people are afraid to use this beast. For the same reason, I want to use this lovely OS :-)

thank you matt.

marc

mfillpot wrote:

The starting permissions of the files in /etc/rc.d were set by you in the initial installation, when it asked what services you want it changed each of the chosen files to executable, so you did not select to use the bluetooth service when you installed. That can be changed at any time in the terminal by tunning pkgtool, which will allow you to change most of the options that were chosen when you installed slackware.

I don't think that's usefull. At all.

It could sound correct from a security point of view but... it's not as you could always just

sh /what/ever/script

And you'd still be able to run the script.

Therefore, removing the executable possibility from a script that is there for, well, be executed looks like nonsense to me.

Regards

mfillpot

The installed system scripts work that way because there are scripts in rc.local and rc.M stating to check the specific system scripts for executable rights prior to launching them. People cannot just drop executable scripts into the folder and expect them to work, they must first add the correct initialization scripts to the correct files. I consider this a better method than what is used by distros that use the SystemV init method in which any executable script that is placed into a runlevel folder is executed without any further modifications.

marc

mfillpot wrote:

The installed system scripts work that way because there are scripts in rc.local and rc.M stating to check the specific system scripts for executable rights prior to launching them. People cannot just drop executable scripts into the folder and expect them to work, they must first add the correct initialization scripts to the correct files. I consider this a better method than what is used by distros that use the SystemV init method in which any executable script that is placed into a runlevel folder is executed without any further modifications.

Regular users do not have access to those folders

Anyway, I rather use Archlinux aproach with a line in rc.conf containing which scripts to run at startup

Using this you avoid the "problem" you were mentioning and selection of what to run or not is a matter of editing a text file. Ya know, KISS philosofy.

Regards

mfillpot

The other benefit we get from that method is the ability to simply start, stop and restart a service for testing or loading of new configuration files without setting the service to launch on boot. I recommend checking out some of the script files to see what they can do to make life easier.

As for the arch method, I am still trying to get used to all of the components of arch, it has some benefits but the dependency resolution still drives me crazy.

chekkizhar

from you people, strong healthy technical discussion, I learnt/learning a lot. I am really enjoying this site like anything

marc

mfillpot wrote:

The other benefit we get from that method is the ability to simply start, stop and restart a service for testing or loading of new configuration files without setting the service to launch on boot. I recommend checking out some of the script files to see what they can do to make life easier.

That's the thing, you can do just the same with the Arch method.

The thing is that you achieve the same with both aproaches but I find the arch one much more human friendly than Slackware's.

Regards

atreyu

mfillpot wrote:

The installed system scripts work that way because there are scripts in rc.local and rc.M stating to check the specific system scripts for executable rights prior to launching them. People cannot just drop executable scripts into the folder and expect them to work, they must first add the correct initialization scripts to the correct files. I consider this a better method than what is used by distros that use the SystemV init method in which any executable script that is placed into a runlevel folder is executed without any further modifications.

At least with Fedora/RH-based Linux, system initscripts will not be run by the system unless the proper symlinks have been generated for them for the specific runlevels in which they are supposed to run. These runlevels are defined at the top of each initscript ( e.g., "# chkconfig: - 85 15" ). So you can drop an executable script in /etc/init.d/ but it won't run until you:

a) put the proper "chkconfig" entry at the top of the script
b) run a command to create the symlinks, e.g. "chkconfig --add myService" , or create them manually

marc

atreyu wrote:

mfillpot wrote:

At least with Fedora/RH-based Linux, system initscripts will not be run by the system unless the proper symlinks have been generated for them for the specific runlevels in which they are supposed to run. These runlevels are defined at the top of each initscript ( e.g., "# chkconfig: - 85 15" ). So you can drop an executable script in /etc/init.d/ but it won't run until you:

a) put the proper "chkconfig" entry at the top of the script
b) run a command to create the symlinks, e.g. "chkconfig --add myService" , or create them manually

In fact, this is how is defined in the standard

Regards

chekkizhar

Hi, after some long time, I hardly need to open this thread again. I am facing problem with my blueman-manager. Actually, I re-installed Slackware due to some KDE problems and for past 2-3 months am trying to use the BT service. I strongly doubt that, the same problem may be a reason for my home wireless router is not getting listed in wicd.

In my system, I need to move same physical button for BT as well as for wireless network.

I can able to do the above both in Windows. So, in that way, there is no problem with actual device inside the system

So, I want to get the BT to work and possibly try with wlan issue.

This is what I am getting , when I ran "blueman-manager" from terminal,
########################################################################################################################
bash-4.1$ blueman-manager
Loading configuration plugins
_________
<module> (/usr/lib/python2.6/site-packages/blueman/main/Config.py:20)
Skipping plugin Gconf
No module named gconf
Using file config backend
_________
Load (/usr/lib/python2.6/site-packages/blueman/main/PluginManager.py:68)

_________
Load (/usr/lib/python2.6/site-packages/blueman/main/PluginManager.py:68)
Unable to load plugin module PulseAudioProfile
PulseAudio applet plugin not loaded, nothing to do here
_________
__load_plugin (/usr/lib/python2.6/site-packages/blueman/main/PluginManager.py:142)
loading <class 'blueman.plugins.manager.Services.Services'>
blueman-manager version 1.22 starting
_________
on_bluez_name_owner_changed (/usr/bin/blueman-manager:110)
org.bluez owner changed to :1.25
Using file config backend
_________
SetAdapter (/usr/lib/python2.6/site-packages/blueman/gui/DeviceList.py:301)
None
Traceback (most recent call last):
File "/usr/lib/python2.6/site-packages/dbus/connection.py", line 586, in msg_reply_handler
reply_handler(*message.get_args_list(**get_args_opts))
File "/usr/bin/blueman-manager", line 162, in on_bluez_name_owner_changed
self.List = ManagerDeviceList(adapter=self.Config.props.last_adapter, inst=self)
File "/usr/lib/python2.6/site-packages/blueman/gui/manager/ManagerDeviceList.py", line 71, in __init__
DeviceList.__init__(self, adapter, data)
File "/usr/lib/python2.6/site-packages/blueman/gui/DeviceList.py", line 122, in __init__
self.SetAdapter(adapter)
File "/usr/lib/python2.6/site-packages/blueman/gui/DeviceList.py", line 332, in SetAdapter
except dbus.DBusServiceUnknownError:
AttributeError: 'module' object has no attribute 'DBusServiceUnknownError'
^CTraceback (most recent call last):
File "/usr/bin/blueman-manager", line 301, in <module>
Blueman()
File "/usr/bin/blueman-manager", line 188, in __init__
gtk.main()
KeyboardInterrupt
_________
save (/usr/lib/python2.6/site-packages/blueman/plugins/config/File.py:117)
Saving config
Exception AttributeError: "'NoneType' object has no attribute 'Bus'" in <bound method File.__del__ of <File object at 0x84d198c (blueman+plugins+ConfigPlugin+ConfigPlugin at 0x82c4f30)>> ignored
########################################################################################################################
Thanks,

mfillpot

Have you checked the proc directory to locate the files that controls your bluetooth and wifi radios? One you find those files and figure out the commands you can script the system to enable both on boot.

As for the errors, I would be best to focus on both of those after the radios are activated.

chekkizhar

thanks Mathew. I expected your reply.

Can you please help me out to find out those two in /proc dir. I can not able to find anything related to radios in that dir.

in iomem file I can not able to find any word "radio" or bluetooth"
I can not understand and not fully aware of the error it is saying about , "Dbus"...

mfillpot

Sorry the trigger files are not in /proc, they are in sys. You can locate them by using "find /sys/ -name state" , this will output the state files (on/off) for all devices on your system, generally your wireless will be listed with 80211 such as "/sys/devices/pci0000:00/0000:00:1c.2/0000:04:00.0/ieee80211/phy0/rfkill0/state" and something similar will be listed for the bluetooth most likely citing the protocol.

chekkizhar

thats ok and here is the output,
################################################################################################################
/sys/devices/virtual/video_output/acpi_video0/state
/sys/devices/LNXSYSTM:00/device:00/PNP0A08:00/device:0c/PNP0C09:00/VPC2004:00/rfkill/rfkill0/state
/sys/devices/LNXSYSTM:00/device:00/PNP0A08:00/device:0c/PNP0C09:00/VPC2004:00/rfkill/rfkill1/state
/sys/devices/LNXSYSTM:00/device:00/PNP0A08:00/device:0c/PNP0C09:00/VPC2004:00/rfkill/rfkill3/state
/sys/devices/pci0000:00/0000:00:02.0/graphics/fb0/state
/sys/devices/pci0000:00/0000:00:1c.2/0000:04:00.0/ieee80211/phy0/rfkill2/state
/sys/devices/pci0000:00/0000:00:1f.2/host2/scsi_host/host2/state
/sys/devices/pci0000:00/0000:00:1f.2/host2/target2:0:0/2:0:0:0/state
/sys/devices/pci0000:00/0000:00:1f.2/host3/scsi_host/host3/state
/sys/devices/pci0000:00/0000:00:1f.2/host3/target3:0:0/3:0:0:0/state
/sys/devices/pci0000:00/0000:00:1f.2/host4/scsi_host/host4/state
/sys/devices/pci0000:00/0000:00:1f.2/host5/scsi_host/host5/state
/sys/devices/pci0000:00/0000:00:1f.2/host6/scsi_host/host6/state
/sys/power/state
################################################################################################################
and I guess, the one we need is,
/sys/devices/pci0000:00/0000:00:1c.2/0000:04:00.0/ieee80211/phy0/rfkill2/state. then, what I need to do ?

Thanks a lot matt

mfillpot

Now we have something to work with and can see that rfkill is enabled for multiple devices.

You can cat /sys/devices/pci0000:00/0000:00:1c.2/0000:04:00.0/ieee80211/phy0/rfkill2/stat to see if the wifi radio is on.

But with rfkill it becomes easier, use "rfkill list" to see the states of each available device which may include your bluetooth adapter, once you figure out the names for each you can type "rfkill unblock {device}" to turn a radio on and "rfkill block {device}" to turn a radio off.

After you test and confirm the rfkill command you can add a script into your rc.d scripts to start each radio on boot.

chekkizhar

thanks Matthew. BT is still has problem. But, as of now, my goal is to use/access my wifi connection, and that is done by enabling the things using "rfkill".