Hi,
On 11/20/2007 06:02:15 AM, Julian Krause wrote:
> Half the time SASL authentication will succeed
perfectly and work
> just
> fine. The other half the time, the auth message gets
sent twice
> causing the remote server (ejabberd in this case) to
crash and drop
> the connection. From some looking over the source code
there are 2
> ways in which the sasl_authenticate function are
called. Once from
> lm_sasl_authenticate and once from sasl_features_cb. It
also looks
> like there is a chance that they can be hit in just the
right order to
> cause both sasl_authenticate function calls to be run
as well.
Looking from the source, the only way I see this could
happen is
if lm_connection_authenticate() is called more than once (in
turn,
calling lm_sasl_authenticate() more than once).
The logic of this part of the code is the following:
* If the library user calls lm_connection_authenticate()
before
stream features are received, the library has to delay
SASL,
so lm_sasl_authenticate() doesn't call
sasl_authenticate(),
but instead just sets 'start_auth' to true (signalling
that
we're ready for SASL).
Afterwards, when stream features are received, we check
if
start_auth is set (which means SASL was delayed up to
this point),
and if so, start the SASL.
* If the stream features are received before the library
user
calls lm_connection_authenticate(),
lm_sasl_authenticate() is
not called, only 'features_received' is set.
Afterwards, when
the user calls lm_connection_authenticate(),
lm_sasl_authenticate()
will see that features_received is set, and call
sasl_authenticate().
In both scenarios, sasl_authenticate() is called exactly
once, if
lm_connection_authenticate() is called once.
However, by looking at the code, I found a different bug: if
features
are received *after* lm_connection_authenticate() the
callbacks are
installed twice.
> Has anyone else run into such an issue or have any
ideas of how to
> code around it? I am currently looking into adding some
small pauses
> into my code in order to see if that helps but I would
like to avoid
> that if at all possible.
I've worked on SASL code and didn't encounter such error,
but if we
could gather some more info on what happens, we should be
able to
fix it. It would be helpful if you could provide backtraces
for the
points at which sasl_authenticate() is called, so we can try
and detect
*why* it is called twice. You could run your application in
gdb,
attach breakpoint to sasl_authenticate() function, and each
time the
breakpoint is reached, just print out the backtrace.
I agree that adding delays in hoping to work around the
error isn't
the right way of "fixing" this.
Also, it would be cool if you could make a new bug report
about this
in the loudmouth issue tracker:
http://developer.imendio.com/issues/secure
/BrowseProject.jspa?id=10001
Regards,
Senko
_______________________________________________
Loudmouth mailing list
Loudmouth lists.imendio.com
h
ttp://lists.imendio.com/mailman/listinfo/loudmouth
|