No reply from invoking method about dbus-java HOT 16 CLOSED

ok, I'll close this ticket now, as the main cause for this issue has been resolved in my eyes.

from dbus-java.

I think your interface definition is not valid.
From my experience with bluez ble implementation (see: bluez-dbus), I guess it should be:

void Join(DBusPath app_defined_root, byte[] uuid);

Also be sure that the objectPath and dbusName are valid and available (e.g. using d-feet).

from dbus-java.

Thank you for your quick response.

I used d-feet and checked whether the objectPath and dbusName is correct and that seems fine.

I can see the Join method with d-feet:
Join(Object Path app, Array of [Byte] uuid) -> ()

I've changed the interfaces as suggested by you above, and use as DBusPath the object path of my application object. In the end I am still unlucky.
Is there some way to get more debug information or a better guess on what is goring wrong?

Best regards
valli

from dbus-java.

Could you please show your Network1 interface class?

from dbus-java.

I'v used the documentation provided here:
https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/doc/mesh-api.txt

`package org.bluez.mesh;

import org.freedesktop.dbus.DBusPath;
import org.freedesktop.dbus.annotations.MethodError;
import org.freedesktop.dbus.annotations.MethodNoReply;
import org.freedesktop.dbus.interfaces.DBusInterface;
import java.util.List;
import org.freedesktop.dbus.types.UInt64;

public interface Network1 extends DBusInterface {

void Join(DBusPath app_defined_root, byte[] uuid);

void Cancel();

AttachTuple Attach(DBusPath app_defined_root, UInt64 token);

void Leave(UInt64 token);

UInt64 CreateNetwork(DBusInterface app_root, byte[] uuid);

UInt64 ImportLocalNode(String json_data);

}`

from dbus-java.

I've played around with the mesh stuff, but I don't get it to work.
I use the latest git version of it, because it seems that the mesh part got a lot of updates in the past few month after release of 5.50.

But when I call "Join" the daemon hangs. Debugging output of mesh daemon is more than useless.
After the "Join" call the registered dbus name is disappearing and the daemon can only be stopped using kill -9.

For me it looks like the whole mesh stuff is pretty buggy.
As I don't have a clou how to work with this mesh stuff, I would suggest that you first try to use the meshctl commandline tool provided by bluez.
If you get this running (I don't), it may help to find what's wrong with dbus-java or your code.

from dbus-java.

Hi,
thanks for your reply. I observed exactly the same behavior concerning the daemon going to stuck mode. I will try to contact some of the mesh developers to get some help on their side.

:)

from dbus-java.

Hi hypfvieh,

I did not have that much progress. I found out that my ObjectManager interface was not published correctly, therefore the meshd could not look-up the required interfaces on the bus as explained in the doc under Mesh Application Hierachy.

What I am curious about is the uint8 type which is mentioned on the Element1 interface for the Index property. Is it sufficient to map this to a Byte or would this require a new UInt8 implementation?

Best regards
valli

from dbus-java.

uint8 is not a valid DBus type.
The DBus specs only mention uint8 once and that's for the SIGNATURE type (see: https://dbus.freedesktop.org/doc/dbus-specification.html#container-types).

A java byte is indeed something different, as it has a different range.
While uint8 is 0..255, java byte is -127..128.
So maybe it is the wrong type...

Anyways, as the uint8 type has no specific encoding literal (like "s" for String) on the DBus interface, bluez-mesh will have to something compatible like "y" which would be a byte in java or use something different like "n" or "q".

I'm pretty busy atm so I don't have the time to investigate what is really used by bluez-mesh, so you may have a look yourself.

from dbus-java.

Hi,

I checked the spec above and saw that the
fixed, basic | BYTE | 121 (ASCII 'y') | 8-bit unsigned integer which is anyway mapped to a byte

I progressed with my test code up to the point where the meshd crashes due to malloc error (on invoking Join).
Just to be sure that it is no meshd issue I got a python sample up and running which does the same Network1.Join code with the same data. I verified that using dbus-monitor --system. The output of using python and java code looks the same. The outcome is quite different, on python side the meshd it continues, using java it is aborted with an error on malloc.

Using TRACE logging I traced the following lines on sending side:

14:55:17,475 DEBUG [DBus Sender Thread-1] o.f.d.MessageWriter: <= MethodCall(0,6) { Path=>/org/bluez/mesh, Interface=>org.bluez.mesh.Network1, Member=>Join, Destination=>org.bluez.mesh, Signature=>oay } { /at/valli/9c791e887acb42e595abab75cb74d774, [-100, 121, 30, -120, 122, -53, 66, -27, -107, -85, -85, 117, -53, 116, -41, 116] }
14:55:17,475 DEBUG [DBus Sender Thread-1] o.f.d.MessageWriter: Writing all 40 buffers simultaneously to Unix Socket
14:55:17,475 TRACE [DBus Sender Thread-1] o.f.d.MessageWriter: ([66, 1, 0, 1]):000000	42 01 00 01                                            B...              

14:55:17,475 TRACE [DBus Sender Thread-1] o.f.d.MessageWriter: ([0, 0, 0, 68]):000000	00 00 00 44                                            ...D              

14:55:17,475 TRACE [DBus Sender Thread-1] o.f.d.MessageWriter: ([0, 0, 0, 6]):000000	00 00 00 06                                            ....              

14:55:17,475 TRACE [DBus Sender Thread-1] o.f.d.MessageWriter: ([0, 0, 0, 105]):000000	00 00 00 69                                            ...i              

14:55:17,475 TRACE [DBus Sender Thread-1] o.f.d.MessageWriter: ([1]):000000	01                                                     .                 

14:55:17,475 TRACE [DBus Sender Thread-1] o.f.d.MessageWriter: ([1, 111, 0]):000000	01 6f 00                                               .o.               

14:55:17,475 TRACE [DBus Sender Thread-1] o.f.d.MessageWriter: ([0, 0, 0, 15]):000000	00 00 00 0f                                            ....              

14:55:17,475 TRACE [DBus Sender Thread-1] o.f.d.MessageWriter: ([47, 111, 114, 103, 47, 98, 108, 117, 101, 122, 47, 109, 101, 115, 104]):000000	2f 6f 72 67 2f 62 6c 75 65 7a 2f 6d 65 73 68           /org/bluez/mesh   

14:55:17,475 TRACE [DBus Sender Thread-1] o.f.d.MessageWriter: ([0]):000000	00                                                     .                 

14:55:17,475 TRACE [DBus Sender Thread-1] o.f.d.MessageWriter: ([6]):000000	06                                                     .                 

14:55:17,476 TRACE [DBus Sender Thread-1] o.f.d.MessageWriter: ([1, 115, 0]):000000	01 73 00                                               .s.               

14:55:17,476 TRACE [DBus Sender Thread-1] o.f.d.MessageWriter: ([0, 0, 0, 14]):000000	00 00 00 0e                                            ....              

14:55:17,476 TRACE [DBus Sender Thread-1] o.f.d.MessageWriter: ([111, 114, 103, 46, 98, 108, 117, 101, 122, 46, 109, 101, 115, 104]):000000	6f 72 67 2e 62 6c 75 65 7a 2e 6d 65 73 68              org.bluez.mesh    

14:55:17,476 TRACE [DBus Sender Thread-1] o.f.d.MessageWriter: ([0]):000000	00                                                     .                 

14:55:17,476 TRACE [DBus Sender Thread-1] o.f.d.MessageWriter: ([0]):000000	00                                                     .                 

14:55:17,476 TRACE [DBus Sender Thread-1] o.f.d.MessageWriter: ([2]):000000	02                                                     .                 

14:55:17,476 TRACE [DBus Sender Thread-1] o.f.d.MessageWriter: ([1, 115, 0]):000000	01 73 00                                               .s.               

14:55:17,476 TRACE [DBus Sender Thread-1] o.f.d.MessageWriter: ([0, 0, 0, 23]):000000	00 00 00 17                                            ...�              

14:55:17,476 TRACE [DBus Sender Thread-1] o.f.d.MessageWriter: ([111, 114, 103, 46, 98, 108, 117, 101, 122, 46, 109, 101, 115, 104, 46, 78, 101, 116, 119, 111, 114, 107, 49]):000000	6f 72 67 2e 62 6c 75 65 7a 2e 6d 65 73 68 2e 4e 65 74  org.bluez.mesh.Net
000012	77 6f 72 6b 31                                         work1             

14:55:17,476 TRACE [DBus Sender Thread-1] o.f.d.MessageWriter: ([0]):000000	00                                                     .                 

14:55:17,476 TRACE [DBus Sender Thread-1] o.f.d.MessageWriter: ([3]):000000	03                                                     .                 

14:55:17,476 TRACE [DBus Sender Thread-1] o.f.d.MessageWriter: ([1, 115, 0]):000000	01 73 00                                               .s.               

14:55:17,476 TRACE [DBus Sender Thread-1] o.f.d.MessageWriter: ([0, 0, 0, 4]):000000	00 00 00 04                                            ....              

14:55:17,476 TRACE [DBus Sender Thread-1] o.f.d.MessageWriter: ([74, 111, 105, 110]):000000	4a 6f 69 6e                                            Join              

14:55:17,476 TRACE [DBus Sender Thread-1] o.f.d.MessageWriter: ([0]):000000	00                                                     .                 

14:55:17,476 TRACE [DBus Sender Thread-1] o.f.d.MessageWriter: ([0, 0, 0]):000000	00 00 00                                               ...               

14:55:17,476 TRACE [DBus Sender Thread-1] o.f.d.MessageWriter: ([8]):000000	08                                                     .                 

14:55:17,476 TRACE [DBus Sender Thread-1] o.f.d.MessageWriter: ([1, 103, 0]):000000	01 67 00                                               .g.               

14:55:17,476 TRACE [DBus Sender Thread-1] o.f.d.MessageWriter: ([3, 111, 97, 121, 0]):000000	03 6f 61 79 00                                         .oay.             

14:55:17,476 TRACE [DBus Sender Thread-1] o.f.d.MessageWriter: ([0, 0, 0, 0, 0, 0, 0]):000000	00 00 00 00 00 00 00                                   .......           

14:55:17,476 TRACE [DBus Sender Thread-1] o.f.d.MessageWriter: ([0, 0, 0, 42]):000000	00 00 00 2a                                            ...*              

14:55:17,476 TRACE [DBus Sender Thread-1] o.f.d.MessageWriter: ([47, 97, 116, 47, 118, 97, 108, 108, 105, 47, 57, 99, 55, 57, 49, 101, 56, 56, 55, 97, 99, 98, 52, 50, 101, 53, 57, 53, 97, 98, 97, 98, 55, 53, 99, 98, 55, 52, 100, 55, 55, 52]):000000	2f 61 74 2f 76 61 6c 6c 69 2f 39 63 37 39 31 65 38 38  /at/valli/9c791e88
000012	37 61 63 62 34 32 65 35 39 35 61 62 61 62 37 35 63 62  7acb42e595abab75cb
000024	37 34 64 37 37 34                                      74d774            

14:55:17,476 TRACE [DBus Sender Thread-1] o.f.d.MessageWriter: ([0]):000000	00                                                     .                 

14:55:17,476 TRACE [DBus Sender Thread-1] o.f.d.MessageWriter: ([0]):000000	00                                                     .                 

14:55:17,476 TRACE [DBus Sender Thread-1] o.f.d.MessageWriter: ([0, 0, 0, 16]):000000	00 00 00 10                                            ....              

14:55:17,476 TRACE [DBus Sender Thread-1] o.f.d.MessageWriter: ([-100, 121, 30, -120, 122, -53, 66, -27, -107, -85, -85, 117, -53, 116, -41, 116]):000000	9c 79 1e 88 7a cb 42 e5 95 ab ab 75 cb 74 d7 74        .y�.z.B....u.t.t  

14:55:17,476 TRACE [DBus Sender Thread-1] o.f.d.MessageWriter: (null):
14:55:17,476 TRACE [DBus Sender Thread-1] o.f.d.MessageWriter: (null):
14:55:17,476 TRACE [DBus Sender Thread-1] o.f.d.MessageWriter: (null):
14:55:17,476 TRACE [DBus Sender Thread-1] o.f.d.MessageWriter: (null):

On meshd side I added some debug output and I can see that a message with the following header and body size (in bytes) is received.

header: 2130706448
body: 1140850688

That would be more than 1 gb body and more than 2 gb header ... that's very odd ... and explains why the daemon crashes on memory allocation.

I am using a debian Jessie installation, is there some incompatibiliy with that quite old os version and the Java library?

from dbus-java.

I don't think it has something to do with the debian version.
On my machine it also fails (Ubuntu 16.04 using lastest GIT snapshots of bluez and ELL).

For me it looks like the problem already appears in the ELL-Library not in bluez.
It's likely an integer overflow caused by the parser of the dbus message.

I tried to call 'cancel' on the Network1 interface to ensure the issue is not caused by the parameters provided to Join (quick side note: you passing in a UUID as byte-array which is to large, UUID class generated 36 byte uuids, while Join only wants 16 bytes).

Calling cancel without anything to cancel should result in an exception (see: mesh.c, line ~610).
But when calling cancel the daemon stucks like using join.

I then turned on Dbus-Debugging in mesh (using -b parameter, which is not explained in help output but you'll find it when looking at main.c).
I re-tried my test, but did not even see that the message is getting far enough to get logged by bluez-mesh.

So for me it looks like the problem is caused in the ELL-library.

ELL differs between two variants of DBus messages. Message which uses GVariant (16 byte header) and the non-GVariant (12 byte header, used by dbus-java).

As dbus-java is working fine with other services (like bluez itself or network-manager), I can only guess that your python script is doing something else than dbus-java.

Does it send GVariant messages?
Can you provide your sample code?

from dbus-java.

Hi,

Hi,

looks like tricky one so far. Thank you for helping so far. I used the python sample code located here
https://github.com/SilvairGit/bluetooth-meshd-example

Best regards
valli

from dbus-java.

Ok, I think a got a bit further on this one...

After thinking about the large header/body size you reported, I was pretty sure that this is some integer overflow.

But after debugging a bit further, it seems to be an issue with the endianess of the used messages.
It seems like ELL expects litte-endian (at least on my machine), while dbus-java is using big-endian.
That means byte order is different and so a small number in big-endian will be large in litte-endian.

After changing the (sadly hardcoded) big-endian to little-endian in dbus-java, it seems to work (more debug output from mesh).

I'll take a look if we can get rid of the hardcoded big-endian crap ...

Anyways I would expect ELL to except both endianesses and convert between them, because the endianess used on a message is signaled by the first byte of the header (capital B for BIG, lower L for little).
dbus-java should already be able to handle that, but the created messages are always big-endian atm.

from dbus-java.

Hi David,

I just did a bit of digging concerning endianess and ell. It seems that ell uses a pre-processor instruction to define the dbus endianess, based on the native byte order of the system. So on runtime it supports only one version of endianess. Sadly that check is done about 100 lines after the memory is allocated and debug message would be printed then.

I assume based on that information the java library code should be changed to use native byte order as well. It seems that Java even supports to determine that. See https://stackoverflow.com/questions/9431526/find-endianness-of-system-in-java

What do you think about that?

Best regards
valli

from dbus-java.

I just pushed some changes.

Endianness is now automatically chosen based on used system/architecture, but it is also possible to use a specific endianness by using DBusConnection.setEndianness(byte) before calling DBusConnection.getConnection/newConnection.

from dbus-java.

Hi,

this definitely improved the situation. Communication works now on bus-level. I have to do some further investigation on how to properly interact with the mesh daemon, but that's another topic.

Thank you for your support so far.

from dbus-java.