2008/2/8, Norman Rasmussen [EMAIL PROTECTED]:
On Feb 5, 2008 7:14 PM, Dan Hulme [EMAIL PROTECTED] wrote:
SEND: iq type='set' id='1007'bind
xmlns='urn:ietf:params:xml:ns:xmpp-bind'resource[EMAIL
PROTECTED]/resource/bind/iq
Can you ask Coccinella to use a different resource? If you
No, this problem is not fixed yet. Changing the Coccinella id makes
no difference. With the latest build (svn557), the behavior has
changed slightly, however. Instead of returning an error, Coccinella
hangs and eventually times out. The server shows it has successfully
authorized but no
Dnia 2008-02-08, Pt o godzinie 09:51 +0200, Norman Rasmussen pisze:
Can you ask Coccinella to use a different resource? If you remove the
@ does it help? (I'm thinking that having an @ in the resource might
be confusing jabberd2)
I was worried about the capitalization more (and lack of
Tomasz Sterna pisze:
Dnia 2008-02-08, Pt o godzinie 09:51 +0200, Norman Rasmussen pisze:
Can you ask Coccinella to use a different resource? If you remove the
@ does it help? (I'm thinking that having an @ in the resource might
be confusing jabberd2)
I was worried about the capitalization
Dnia 2008-02-08, Pt o godzinie 12:51 +0100, Maciek Niedzielski pisze:
Hmm I may be wrong, but I think there is no case-folding in
resourceprep.
You're right. Resourceprep does not use Table B.2 mapping.
--
/\_./o__ Tomasz Sterna
(/^/(_^^' http://www.xiaoka.com/
._.(_.)_ im:[EMAIL
On Feb 5, 2008 7:14 PM, Dan Hulme [EMAIL PROTECTED] wrote:
SEND: iq type='set' id='1007'bind
xmlns='urn:ietf:params:xml:ns:xmpp-bind'resource[EMAIL PROTECTED]
/resource/bind/iq
Can you ask Coccinella to use a different resource? If you remove the @ does
it help? (I'm thinking that having an
Dan,
It seems your problem isn't related neither to SASL or ntlogon, nor to
TLS. It is the bind command problem that fails.
I'm not sure why it fails though but it may be StorageManager that
isn't running for your domain and which is responsible for binding
after successful authentication.
All of this information is nice to have, however, it all seems like it
would cause my logon to fail even when SASL is disabled. However, as
soon as I disable SASL (even on the client), I am able to connect. In
other words, without changing the server configuration at all, I can
connect if I tell
Hi,
Yeah, they both have plain only, forgot to mention that.
Then I don't really have a clue what's going on. I'm running other
server with SASL, TLS and ntlogon and everything rockrolls.
Do you have anything like in c2s.log:
Tue Feb 05 11:52:44 2008 [notice] [264] [XX.XX.XX.XX,
I'd be willing to consider a problem with my ntlogon configuration, if
it were not for the fact that ntlogon works fine as soon as I turn off
SASL.
Tue Feb 05 09:06:11 2008 [notice] ntlogon: user 'user', realm
'domain.com' logged in
Tue Feb 05 09:06:11 2008 [notice] [252] SASL authentication
I'm using plain auth (with and without ntlogon). I've tested with
Spark 2.5.8, Coccinella .96.4.1, and PSI 0.11. All have the same
problem, they hang or return an error when doing SASL. I'd like to
repeat for Thomas' sake that all three worked on the previous build
which used Cyrus SASL.
When using ntlogon, I cannot get SASL to work. Only when using TLS on
'old port', will it connect with encryption. Turning off encryption
works as well. I tested all this with a clean install and no changes
to the config files except the server name and realm. I did not
realize this before,
Is SASL=TLS? Because TLS works fine.
On Feb 4, 2008 10:57 AM, Adam Strzelecki [EMAIL PROTECTED] wrote:
I'm using plain auth (with and without ntlogon). I've tested with
Spark 2.5.8, Coccinella .96.4.1, and PSI 0.11. All have the same
problem, they hang or return an error when doing SASL.
Hi Dan,
When using ntlogon, I cannot get SASL to work. Only when using TLS on
'old port', will it connect with encryption. Turning off encryption
works as well. I tested all this with a clean install and no changes
to the config files except the server name and realm.
Did you enable only
Yeah, they both have plain only, forgot to mention that.
On Feb 4, 2008 3:22 PM, Adam Strzelecki [EMAIL PROTECTED] wrote:
Hi Dan,
When using ntlogon, I cannot get SASL to work. Only when using TLS on
'old port', will it connect with encryption. Turning off encryption
works as well. I
On Śr, 2008-01-30 at 15:55 -0800, Dan Hulme wrote:
I am using Spark primarily. However, it did not work on PSI or
Coccinella either.
Was that Psi recent enough? (0.11+)
Please see http://jabberd2.xiaoka.com/wiki/ClientCompatibility
--
/\_./o__ Tomasz Sterna
(/^/(_^^'
Oh, and all three work with SASL on the previous build (the one with
Cyrus SASL).
Then it must be still something wrong with GSASL, I'll try to test it.
You don't use DIGEST-MD5 together with NTLOGON auth module, do you?
Coz NTLOGON work only with PLAIN, as it cannot do any digest
On Cz, 2008-01-31 at 12:00 +0100, Adam Strzelecki wrote:
Then it must be still something wrong with GSASL, I'll try to test it.
Or with the client.
Most older ones have broken SASL implementations.
--
/\_./o__ Tomasz Sterna
(/^/(_^^' http://www.xiaoka.com/
._.(_.)_ im:[EMAIL PROTECTED]
I'm using plain auth (with and without ntlogon). I've tested with
Spark 2.5.8, Coccinella .96.4.1, and PSI 0.11. All have the same
problem, they hang or return an error when doing SASL. I'd like to
repeat for Thomas' sake that all three worked on the previous build
which used Cyrus SASL.
You
Hi Dan,
Finally it is me. Yup, I deserve a spanking for not reading the list,
especially those posts related to me. Sorry bout that.
I've moved to Mac platform and got slight mental and physical disorder
regarding Windows ;)
First of all, huge thanks for this patch regarding MIO_WSASYNC!
Thanks for all your work on this. Regarding gsasl, I currently am not
compiling myself because I had not converted my build environment to
use the latest build and the library versions that would be required
(i.e., gsasl vs cyrus and whatever else is different). I am using the
build found on
So, I don't know if the build on nanoant uses the patches, but I would
hope that it did. In any case, it appears that the encryption works
somewhat, but that the session cannot be started. Hopefully this
information helps.
Can you drop me a line what is your Jabber client?
Cheers,
--
Adam
I am using Spark primarily. However, it did not work on PSI or
Coccinella either.
Thanks,
Dan
On Jan 30, 2008 2:45 PM, Adam Strzelecki [EMAIL PROTECTED] wrote:
So, I don't know if the build on nanoant uses the patches, but I would
hope that it did. In any case, it appears that the
Oh, and all three work with SASL on the previous build (the one with
Cyrus SASL).
Dan
On Jan 30, 2008 3:55 PM, Dan Hulme [EMAIL PROTECTED] wrote:
I am using Spark primarily. However, it did not work on PSI or
Coccinella either.
Thanks,
Dan
On Jan 30, 2008 2:45 PM, Adam Strzelecki
On Śr, 2008-01-23 at 09:26 -0800, Dan Hulme wrote:
You might also mention that the win32 is broken on 2.1.21 (doesn't
compile).
Adam worked hard today and there is current, working win32 build
available.
The fixes are in SVN for the ones that wants to compile jabberd by
themselves.
--
Great, thanks for letting me know about this. Is there a fix for the
bug with socket closing?
On Jan 29, 2008 12:11 PM, Tomasz Sterna [EMAIL PROTECTED] wrote:
On Śr, 2008-01-23 at 09:26 -0800, Dan Hulme wrote:
You might also mention that the win32 is broken on 2.1.21 (doesn't
compile).
Never mind, I saw that it was checked in to the source. Thanks again, guys!
On Jan 29, 2008 2:44 PM, Dan Hulme [EMAIL PROTECTED] wrote:
Great, thanks for letting me know about this. Is there a fix for the
bug with socket closing?
On Jan 29, 2008 12:11 PM, Tomasz Sterna [EMAIL PROTECTED]
I installed the new build over my compiled version and I've run in to
two snags. First, the database between the two versions is not
compatible. I used the installed database and it worked fine. The
next problem is that SASL no longer seems to work. I don't know what
the problem is, but an
On Wt, 2008-01-29 at 15:24 -0800, Dan Hulme wrote:
I installed the new build over my compiled version and I've run in to
two snags. First, the database between the two versions is not
compatible. I used the installed database and it worked fine.
Well...
$ head tools/db-update.sqlite
--
--
When it installs, it installs libgsasl.dll. Is this what you mean?
-Dan
On Jan 29, 2008 4:25 PM, Tomasz Sterna [EMAIL PROTECTED] wrote:
On Wt, 2008-01-29 at 15:24 -0800, Dan Hulme wrote:
I installed the new build over my compiled version and I've run in to
two snags. First, the database
On Śr, 2008-01-23 at 16:14 -0800, Dan Hulme wrote:
Have tracked the problem down to this point:
Great! :-)
Many thanks for the information.
I contacted ONO and he will look into that.
--
/\_./o__ Tomasz Sterna
(/^/(_^^' http://www.xiaoka.com/
._.(_.)_ im:[EMAIL PROTECTED]
On Jan 24, 2008 2:14 AM, Dan Hulme [EMAIL PROTECTED] wrote:
This function appears to try to append the old closed socket to a
linked list of free sockets. When the new connection tries to use
this socket, it has trouble. Once the next connection connects,
however, it will not use that
I had forgotten, but this is the case. Here is confirmation:
http://msdn2.microsoft.com/en-us/library/ms740481(VS.85).aspx
An application should not rely on being able to reuse a socket after it has
been shut down.
In particular, a Windows Sockets provider is not required to support the use
Ok, after looking closer, it does not appear to reuse sockets at all,
but reuses the mio structure. The structure is pretty simple and was
not remembering the old file descriptor, so I just looked at how it
differed (after being used once) from a completely new one. What I
noticed was that the
Although that patch does seem to work, I'm completely sure it ever
frees the mio struct. Thus, I think the zeroing the event method is
better.
-Dan
On Jan 24, 2008 2:15 PM, Dan Hulme [EMAIL PROTECTED] wrote:
Ok, after looking closer, it does not appear to reuse sockets at all,
but reuses the
err, not completely sure
On Jan 24, 2008 3:01 PM, Dan Hulme [EMAIL PROTECTED] wrote:
Although that patch does seem to work, I'm completely sure it ever
frees the mio struct. Thus, I think the zeroing the event method is
better.
-Dan
On Jan 24, 2008 2:15 PM, Dan Hulme [EMAIL PROTECTED]
On Wt, 2008-01-22 at 15:12 -0800, Dan Hulme wrote:
I have run into a strange bug with the win32 version of jabberd2
(2.1.13).
after disconnecting with some clients, the next client to connect
hangs
after that, the next client works fine again [...]
Which MIO implementation are you using?
Whatever comes with the tree tagged jbberd-2.1.13. Which appears to
be most recently updated in build 340.
http://jabberd2.xiaoka.com/browser/tags/jabberd-2.1.13
-Dan
On Jan 23, 2008 3:05 AM, Tomasz Sterna [EMAIL PROTECTED] wrote:
On Wt, 2008-01-22 at 15:12 -0800, Dan Hulme wrote:
I have
On Śr, 2008-01-23 at 08:21 -0800, Dan Hulme wrote:
Whatever comes with the tree tagged jbberd-2.1.13. Which appears to
be most recently updated in build 340.
http://jabberd2.xiaoka.com/browser/tags/jabberd-2.1.13
There are four MIO implementations in
I see. Well, since I used the win32 build, I never had to do that. I
will see if the win32 build makes it obvious which it is using.
On Jan 23, 2008 8:36 AM, Tomasz Sterna [EMAIL PROTECTED] wrote:
On Śr, 2008-01-23 at 08:21 -0800, Dan Hulme wrote:
Whatever comes with the tree tagged
From Jabberd2.vcproj:
44:
PreprocessorDefinitions=SX_DEBUG;MIO_DEBUG;MIO_WSASYNC;WIN32;_DEBUG;_USRDLL;JABBERD2_EXPORTS;HAVE_CONFIG_H;_CRT_SECURE_NO_DEPRECATE;_CRT_NONSTDC_NO_DEPRECATE
122:
On Śr, 2008-01-23 at 08:48 -0800, Dan Hulme wrote:
Am I correct in assuming this means it uses wsasync?
I guess so.
That could mean, that there is a bug in wsasync implementation.
I will talk to Win32 build maintainer about.
--
/\_./o__ Tomasz Sterna
(/^/(_^^' http://www.xiaoka.com/
You might also mention that the win32 is broken on 2.1.21 (doesn't compile).
On Jan 23, 2008 9:16 AM, Tomasz Sterna [EMAIL PROTECTED] wrote:
On Śr, 2008-01-23 at 08:48 -0800, Dan Hulme wrote:
Am I correct in assuming this means it uses wsasync?
I guess so.
That could mean, that there is a
Have tracked the problem down to this point:
mio_wsasync.h: 68
static void _mio_free_fd(mio_t m, mio_priv_fd_t priv_fd)\
{ \
priv_fd-next_free = MIO(m)-next_free; \
I have run into a strange bug with the win32 version of jabberd2 (2.1.13).
after disconnecting with some clients, the next client to connect hangs
after that, the next client works fine again
after tracking down the behavior, I found that removing the following
line fixed the problem
sx/io.c:149
45 matches
Mail list logo
