PANU currently broken?

PANU currently broken?

[James Le Cuirot]

Hi,

I've managed to serve my phone with NAP successfully but using PANU in
the other direction has not worked at all. No one I've spoken to has
any answers so I've done some digging. I've been using Blueman a little
but I worked out how to start the connection manually with dbus-send.
The first error I encountered was this. It appears after a short delay.

Error 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 seemed a little vague but after adding some debug messages to the
source, I figured out what the problem was. The D-Bus method signature
for org.bluez.Network.Connect says it's supposed to return a string. So
do the API docs. So why does it return NULL? I don't know much about
D-Bus but this doesn't seem right.

According to the docs, it's supposed to return the name of the newly
created interface such as bnep0. I outputted nc->dev to the log to
check that's what it actually was. Close. It gave me bnep%d.

In any case, I wasn't sure how to return a string to D-Bus so I got it
to return null with g_dbus_create_reply(msg, DBUS_TYPE_INVALID). This
fixed the error and the delay. Still no sign of bnep0 though.

Looking through the rest of the source, it seemed to me that nc->dev is
supposed to get changed from bnep%d to bnep0 at some point but this
isn't happening and I can't even see any code that resembles this
operation. If it's trying to do operations on an interface called
bnep%d then no wonder it's not working.

Having said that, I changed the setting in network.conf from bnep%d to
bnep0 and while it definitely did pick this up, it still wouldn't work.
I've seen "Connection refused (111)" a couple of times but I'm not sure
where that's coming from exactly.

Are my observations correct or am I missing something here? If I'm
right, why is it in such a broken state? I wouldn't expect a release to
have these kind of problems.

Regards,
James

Re: PANU currently broken?

[James Le Cuirot]

On Sun, 8 Mar 2009 23:22:15 +0000
James Le Cuirot <chewi@aura-online.co.uk> wrote:

> I've managed to serve my phone with NAP successfully but using PANU in
> the other direction has not worked at all.

I'm not necessarily asking for an immediate fix here but could someone
at least explain the situation? That might allow me to fix it myself.

James

Re: PANU currently broken?

[Luiz Augusto von Dentz]

Hi James,

On Thu, Mar 12, 2009 at 8:11 AM, James Le Cuirot
<chewi@aura-online.co.uk> wrote:
> On Sun, 8 Mar 2009 23:22:15 +0000
> James Le Cuirot <chewi@aura-online.co.uk> wrote:
>
>> I've managed to serve my phone with NAP successfully but using PANU in
>> the other direction has not worked at all.
>
> I'm not necessarily asking for an immediate fix here but could someone
> at least explain the situation? That might allow me to fix it myself.

I have a fix for it, the problem was that we use
g_io_channel_set_close_on_unref on BtIO code so we should maintain a
reference if we want to maintain the socket open.

Try this patch and see if it helps:
http://gitorious.org/projects/bluez/repos/vudentzs-clone/commits/adaf1c1d4f2c8764c3d5336759368a0e1dcb44c9

ps: we are still reviewing the code so it may have some bug left.


-- 
Luiz Augusto von Dentz
Engenheiro de Computação

Re: PANU currently broken?

[James Le Cuirot]

On Thu, 12 Mar 2009 11:23:40 -0300
Luiz Augusto von Dentz <luiz.dentz@gmail.com> wrote:

> On Thu, Mar 12, 2009 at 8:11 AM, James Le Cuirot
> <chewi@aura-online.co.uk> wrote:
> > On Sun, 8 Mar 2009 23:22:15 +0000
> > James Le Cuirot <chewi@aura-online.co.uk> wrote:
> >  
> >> I've managed to serve my phone with NAP successfully but using
> >> PANU in the other direction has not worked at all.  
> >
> > I'm not necessarily asking for an immediate fix here but could
> > someone at least explain the situation? That might allow me to fix
> > it myself.  
> 
> I have a fix for it, the problem was that we use
> g_io_channel_set_close_on_unref on BtIO code so we should maintain a
> reference if we want to maintain the socket open.
> 
> Try this patch and see if it helps:
> http://gitorious.org/projects/bluez/repos/vudentzs-clone/commits/adaf1c1d4f2c8764c3d5336759368a0e1dcb44c9
> 
> ps: we are still reviewing the code so it may have some bug left.

Thanks, Luiz.

I'm afraid it's still not working though. I tried the patch on its own
against 4.32 and also the latest from the for-upstream branch. I
generally get "bnep setup failed" as well as "Hangup or error on l2cap
server socket" in the log.

James