Good morning guys,

I’ve tried discussing this on IRC over the past couple of days, unfortunately my  net connection here is a little sketchy and I seem to drop off the channel before I get chance to discuss it properly with anyone.

At the moment I can only describe the symptoms I’ve been seeing and with any luck you’ll be able to help me debug and diagnose the root cause of the problem.

The problem seems to occur when performing an inquiry (periodic) when there are many devices present, when performing the same operations during quieter times in the office we don’t seem to see this issue, however, when staff here and in the neighbouring office turn up we start having problems.

Essentially it would seem that all other calls to the bluez dbus interfaces results in the following error:

“DBusException: org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.”

This is true for seemingly any calls I try to make, whether it be GetAddress(), DefaultAdapter(),GetRemoteServiceHandles() or seemingly even any of the operations invoked by obex-data-server.

Once I start to receive these errors, I kill my application and then try to relaunch it and I receive:

“ERROR:dbus.proxies:Introspect error on :1.0:/org/bluez: dbus.exceptions.DBusException: org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.”

Can anyone give me any idea as to whether this is normal behaviour? Or is this due to me doing something wrong with the Bluetooth stack? I’ve been testing this with BlueZ 3.36 on Kernel 2.6.25 and dbus 1.2 and I’m using the BlueZ 3.x API.

I’d really appreciate any and all suggestions on this guys, I’m open to any ideas J

Cheers.

Heston