Authentication Failing

[Raphael Simon]

I now know a lot more than I ever wanted about the internals of Loudmouth :P ... I'm working on an "evented" branch of the Loudmouth ruby binding which runs the GLib event loop in a separate thread than the Ruby thread (if you are curious: http://github.com/raphael/loudmouth-ruby/tree/evented). I've made good progress and I'm ready to start testing however the basic functional test fails (modified spec\base_spec.rb to use authenticate_and_block instead of just authenticate). Looking into it I see that Loudmouth never replies to the 'stream:features' message sent by ejabberd. Looking even closer shows that the 'stream:features' message is correctly received and parsed by loudmouth and that it pushes it to its messages queue. However that message never gets popped. Looking even closer shows that the 'prepare' function callback of the message queue GLib source only gets called once (for the initial 'stream:stream' message) when it should be called a second time to handle the 'stream:features' message.

At this point I'm not sure what to do, it seems that GLib doesn't deem it necessary to call the 'prepare' callback again on the message queue source. One hint is that both messages ('stream:stream' and 'stream:features') get pushed on the queue before the first one ('stream:stream') gets handled. I should probably also say that I've been doing this testing using the original loudmouth ruby binding, not my modified version so it's not something I did. Anyone ever saw something similar?

Thanks,

--
Raphael.

PS: All this research did yield something useful, the following patch should be applied to lm-message.c so logs reflect the correct message type (the 'error' and 'features' types are reversed compared to the enum in lm-message.h so the lookup function picks up the wrong one):

@@ -43,8 +45,8 @@ static struct TypeNames
     { LM_MESSAGE_TYPE_PRESENCE,        "presence"        },
     { LM_MESSAGE_TYPE_IQ,              "iq"              },
     { LM_MESSAGE_TYPE_STREAM,          "stream:stream"   },
-    { LM_MESSAGE_TYPE_STREAM_FEATURES, "stream:features" },
     { LM_MESSAGE_TYPE_STREAM_ERROR,    "stream:error"    },
+    { LM_MESSAGE_TYPE_STREAM_FEATURES, "stream:features" },
     { LM_MESSAGE_TYPE_AUTH,            "auth"            },
     { LM_MESSAGE_TYPE_CHALLENGE,       "challenge"       },
     { LM_MESSAGE_TYPE_RESPONSE,        "response"        },

[Raphael Simon]

OK I finally get it... what was happening is that the authentication call is made during the open connection callback and because I was using the blocking variant this meant that the callback was blocked. In turn this meant that the message queue source was blocked and thus GLib skipped it and didn't call 'prepare' or 'dispatch' on it.

I guess I don't see how the test as is can work. Using the non-blocking authenticate call results in the <op></op> message being sent before authentication is done, resulting in a 503. Using the blocking authentication results in the issue described above.

I had to move sending the message to the auth callback block and then move the checking of the answer in the message callback block. Now the test passes...

--
Raphael.