# dbus-send and bluez4: a ...

## salmonix

hi there, before loosing my usual quiet attitude I drop my problem to the public.

I want to connect an old Compaq Armada 1750 laptop to a PC. I can do it via an usb bluetooth adatpter for the laptop has no NIC.

Now, for I had no success with the bluez3 tools I have tried bluez ~4.39. After some time spent with transporting all the necessary things on pendrive to the laptop to emerge all seemed to work fine with Blueman. I had to use it because I could not find some friendly and fast way to achieve the goal. Meanwhile I had to update python and since then Blueman (a python gtk GUI) is away due to some problems with linking to pyGTK. (most perhaps)

Nevermind, said I, there is command line and let's figure out how to do it - at least I save some memory not using Blueman for this very simple task, and time to do all that manual transporting files to re-emerge.

Then I had to face the reality that 

1. keeping in line with the KISS principle bluez4 has NO sane command line interface but learn d-bus addressing instead.  Wonderful.

2. ok., then, I have figured out that there is an agent script in python that would do pairing, but the problem is that the script imports gobject that is in turn not accessible due to the PyGTK issue. (Nice, anyway, to see that a command line util depends on PyGTK)

3. Nevermind, said I, then roll yer own, and take a short tour, there is that dbus-send and some docs, use that.

http://wiki.bluez.org/wiki/HOWTO/NetworkConnections

has example of service activation from command line.

```
dbus-send --system --type=method_call --print-reply --dest=org.bluez/org/bluez org.bluez.Manager.ActivateService string:network
```

The problem is that the examples seem to be corrupt. I receive this message:

 *Quote:*   

> Must use org.mydomain.Interface.Method notation, no dot in "string:network"

 

This is the point where my thin knowledge faints. I beg  

anyone help me out with the proper syntax to try to go on with send-dbus?

(Workaround temporarily: shall I re-emerge old PyGTK to have it accessible again?)

Thanx!

(At least for reading it.)

----------

## salmonix

Perhaps this:

http://lists.freedesktop.org/archives/dbus/2005-June/002883.html

I see sadly this direction.   :Crying or Very sad: 

----------

## Rexilion

hmm :/

If you want to connect two computers together without wireless, I use a cross-cable. It's almost the same as a regular network cable, with just a small (yet important) modification. You can setup the computer you connect tot with a DHCP server and the computer that connects will automatically get a valid connection. This is all simplified by NetworkManager (it's called Shared with Other Computers). I suggest you try that, bluetooth support in Linux is still not quite 'reliable'.

----------

## salmonix

Yes, that would work if the Armada had a NIC. But it has not, only serial and I have an USB Bluetooth adapter.

And it worked - I mean Bluetooth.

----------

## dmpogo

Yes, user-level bluetooth is in rather sorrow state.  If you struggle with d-bus, you may want to install 

dev-util/d-feet.   I found it pretty useful to see what is actually happen with d-bus

----------

## dmpogo

 *salmonix wrote:*   

> Yes, that would work if the Armada had a NIC. But it has not, only serial and I have an USB Bluetooth adapter.
> 
> And it worked - I mean Bluetooth.

 

Actually, you can connect them via serial cable and SLIP protocol  :Smile: 

----------

## salmonix

The problem was a space:

dbus-send --system --type=method_call --print-reply --dest=org.bluez_/org/bluez org.bluez.Manager.ActivateService string:network

No I have at least a different error message:

 *Quote:*   

> Error org.freedesktop.DBus.Error.UnknownMethod: Method "ActivateService" with signature "s" on interface "org.bluez.Manager" doesn't exist

 

----------

## salmonix

 *dmpogo wrote:*   

> Yes, user-level bluetooth is in rather sorrow state.  If you struggle with d-bus, you may want to install 
> 
> dev-util/d-feet.   I found it pretty useful to see what is actually happen with d-bus

 

Agreed in every respect, to the level of GUI lib dependency of a command line tool.

The same with D-bus rather terrific syntax that reminds me iptables - but that has sense at least...

SLIP: the problem is this:

I should install packages to do that > back to manual transporting. Even after it is dead slow.

I may have to compile a new kernel (3 hours).

d-feet: problem is the same. gtk broken.

I have tried mdbus from http://git.freesmartphone.org/python-helpers but it also has some import error.

Yes, I know my choices...

----------

