Re: [jdev] Bug in jabberd2 (2.1.13) on win32
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 remove the @ does it help? (I'm thinking that having an @ in the resource might be confusing jabberd2) Yes, that's possible. Enter a slash behind your JID in the Contact ID field, followed by your manual defined resource. (e.g. [EMAIL PROTECTED]/blabla) If no resource is defined this way, Coccinella simply generates a safe resource to not get troubles when connecting different Jabber clients to the same JID at the same computer and/or different computers. btw: is the issue in this thread already fixed? (just curious) -- Mvg, Sander Devrieze.
Re: [jdev] Bug in jabberd2 (2.1.13) on win32
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 connection is ever given to the client. -Dan On Wed, Feb 20, 2008 at 2:56 AM, Sander Devrieze [EMAIL PROTECTED] wrote: 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 remove the @ does it help? (I'm thinking that having an @ in the resource might be confusing jabberd2) Yes, that's possible. Enter a slash behind your JID in the Contact ID field, followed by your manual defined resource. (e.g. [EMAIL PROTECTED]/blabla) If no resource is defined this way, Coccinella simply generates a safe resource to not get troubles when connecting different Jabber clients to the same JID at the same computer and/or different computers. btw: is the issue in this thread already fixed? (just curious) -- Mvg, Sander Devrieze.
Re: [jdev] Bug in jabberd2 (2.1.13) on win32
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 resourceprep somewhere), but I just checked and resource [EMAIL PROTECTED] works on my local installation. It's Linux not win32 though. -- /\_./o__ Tomasz Sterna (/^/(_^^' http://www.xiaoka.com/ ._.(_.)_ im:[EMAIL PROTECTED]
Re: [jdev] Bug in jabberd2 (2.1.13) on win32
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 more (and lack of resourceprep somewhere), but I just checked and resource [EMAIL PROTECTED] works on my local installation. It's Linux not win32 though. Hmm I may be wrong, but I think there is no case-folding in resourceprep. -- Maciek xmpp:[EMAIL PROTECTED]
Re: [jdev] Bug in jabberd2 (2.1.13) on win32
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 PROTECTED]
Re: [jdev] Bug in jabberd2 (2.1.13) on win32
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 @ in the resource might be confusing jabberd2) -- - Norman Rasmussen - Email: [EMAIL PROTECTED] - Home page: http://norman.rasmussen.co.za/
Re: [jdev] Bug in jabberd2 (2.1.13) on win32
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.
Make sure SM is running and its sm.xml sm/id matches c2s/local/id of
c2s.xml, checkout you got same domain and your components are
connected to router:
c2s.log
Tue Feb 05 00:17:11 2008 [notice] [mydomain.com] configured;
realm=mydomain.com, registration disabled
Tue Feb 05 00:17:11 2008 [notice] connection to router established
sm.log
Tue Feb 05 00:17:19 2008 [notice] id: mydomain.com
Tue Feb 05 00:17:19 2008 [notice] connection to router established
Note that domain setting is setting used for ntlogon to indicate which
ADS domain (or computer) should be used as auth source.
SEND: iq type='set' id='1007'bind
xmlns='urn:ietf:params:xml:ns:xmpp-
bind'resource[EMAIL PROTECTED]/resource/bind/iq
RECV: stream:error
xmlns:stream='http://etherx.jabber.org/streams'internal-server-error
xmlns='urn:ietf:params:xml:ns:xmpp-streams'/text
xmlns='urn:ietf:params:xml:ns:xmpp-streams'internal server
error/text/stream:error/stream:stream
SEND: /stream:stream
@Tomasz: Do you have any clue what else may cause internal server
error? Would be nice if we could have more clear error reporting in
this case @ c2s.c:
/* route errors */
if(nad_find_attr(nad, 0, -1, error, NULL) = 0) {
log_debug(ZONE, routing error);
sx_error(sess-s, stream_err_INTERNAL_SERVER_ERROR,
internal server error);
sx_close(sess-s);
nad_free(nad);
return 0;
}
I think we could pass there some more meaningful error description to
the client? Like sm for this domain is not running or cannot connect
to sm.
Cheers,
--
Adam Strzelecki |: nanoant.com :|
Re: [jdev] Bug in jabberd2 (2.1.13) on win32
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 the client not to use encryption. Doesn't this
basically mean my ntlogon etc. is configured correctly?
On Feb 6, 2008 3:55 AM, Adam Strzelecki [EMAIL PROTECTED] wrote:
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.
Make sure SM is running and its sm.xml sm/id matches c2s/local/id of
c2s.xml, checkout you got same domain and your components are
connected to router:
c2s.log
Tue Feb 05 00:17:11 2008 [notice] [mydomain.com] configured;
realm=mydomain.com, registration disabled
Tue Feb 05 00:17:11 2008 [notice] connection to router established
sm.log
Tue Feb 05 00:17:19 2008 [notice] id: mydomain.com
Tue Feb 05 00:17:19 2008 [notice] connection to router established
Note that domain setting is setting used for ntlogon to indicate which
ADS domain (or computer) should be used as auth source.
SEND: iq type='set' id='1007'bind
xmlns='urn:ietf:params:xml:ns:xmpp-
bind'resource[EMAIL PROTECTED]/resource/bind/iq
RECV: stream:error
xmlns:stream='http://etherx.jabber.org/streams'internal-server-error
xmlns='urn:ietf:params:xml:ns:xmpp-streams'/text
xmlns='urn:ietf:params:xml:ns:xmpp-streams'internal server
error/text/stream:error/stream:stream
SEND: /stream:stream
@Tomasz: Do you have any clue what else may cause internal server
error? Would be nice if we could have more clear error reporting in
this case @ c2s.c:
/* route errors */
if(nad_find_attr(nad, 0, -1, error, NULL) = 0) {
log_debug(ZONE, routing error);
sx_error(sess-s, stream_err_INTERNAL_SERVER_ERROR,
internal server error);
sx_close(sess-s);
nad_free(nad);
return 0;
}
I think we could pass there some more meaningful error description to
the client? Like sm for this domain is not running or cannot connect
to sm.
Cheers,
--
Adam Strzelecki |: nanoant.com :|
Re: [jdev] Bug in jabberd2 (2.1.13) on win32
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, port=61371] connect Tue Feb 05 11:52:48 2008 [notice] ntlogon: user 'ono', realm 'mydomain.com' logged in Tue Feb 05 11:52:48 2008 [notice] [264] SASL authentication succeeded: mechanism=PLAIN; [EMAIL PROTECTED], TLS negotiated Tue Feb 05 11:52:48 2008 [notice] [264] bound: [EMAIL PROTECTED]/macono If not, what is the last message for your connection in the logs and which's missing. Maybe your ntlogon (realm) is invalid, and auth fails? It must be your ADS domain or hostname. Cheers, -- Adam Strzelecki |: nanoant.com :|
Re: [jdev] Bug in jabberd2 (2.1.13) on win32
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 succeeded: mechanism=PLAIN; [EMAIL PROTECTED] Tue Feb 05 09:06:11 2008 [notice] [252] bound: [EMAIL PROTECTED]/[EMAIL PROTECTED] Tue Feb 05 09:06:11 2008 [notice] [252] [192.168.4.66, port=2837] disconnect [EMAIL PROTECTED]/[EMAIL PROTECTED], packets: 1 At this point I am not using TLS with SASL. TLS on a separate port works. For now, I am just trying to get SASL to work without TLS. As you can see, the authentication is working, however, the client is disconnected immediately after. Here is Coccinella's log: SEND: ?xml version='1.0' encoding='UTF-8'?stream:stream xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' xml:lang='en' to='chatter.domain.com' version='1.0' RECV: ?xml version='1.0'?stream:stream xmlns:stream='http://etherx.jabber.org/streams' xmlns='jabber:client' from='chatter.domain.com' version='1.0' id='5zwasdfly7hlpvgcmb1wasf1231sdf86iqq8cuwd' RECV: stream:features xmlns:stream='http://etherx.jabber.org/streams'mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'mechanismPLAIN/mechanism/mechanismsauth xmlns='http://jabber.org/features/iq-auth'//stream:features SEND: auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl' mechanism='PLAIN'dG9asdfAaWVtLWNvbXAafdasr12ALmNvbQB0b255ZQBmYXRmYXRmYXQ=/auth RECV: success xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/ SEND: stream:stream xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' to='chatter.domain.com' xml:lang='en' version='1.0' RECV: ?xml version='1.0'?stream:stream xmlns:stream='http://etherx.jabber.org/streams' xmlns='jabber:client' from='chatter.domain.com' version='1.0' id='112312bd7ntk7ybes7d2rxmfzvojktsadfasrx0c' RECV: stream:features xmlns:stream='http://etherx.jabber.org/streams'bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'required//bindunbind xmlns='urn:ietf:params:xml:ns:xmpp-bind'/session xmlns='urn:ietf:params:xml:ns:xmpp-session'//stream:features SEND: iq type='set' id='1007'bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'resource[EMAIL PROTECTED]/resource/bind/iq RECV: stream:error xmlns:stream='http://etherx.jabber.org/streams'internal-server-error xmlns='urn:ietf:params:xml:ns:xmpp-streams'/text xmlns='urn:ietf:params:xml:ns:xmpp-streams'internal server error/text/stream:error/stream:stream SEND: /stream:stream On Feb 5, 2008 2:57 AM, Adam Strzelecki [EMAIL PROTECTED] wrote: 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, port=61371] connect Tue Feb 05 11:52:48 2008 [notice] ntlogon: user 'ono', realm 'mydomain.com' logged in Tue Feb 05 11:52:48 2008 [notice] [264] SASL authentication succeeded: mechanism=PLAIN; [EMAIL PROTECTED], TLS negotiated Tue Feb 05 11:52:48 2008 [notice] [264] bound: [EMAIL PROTECTED]/macono If not, what is the last message for your connection in the logs and which's missing. Maybe your ntlogon (realm) is invalid, and auth fails? It must be your ADS domain or hostname. Cheers, -- Adam Strzelecki |: nanoant.com :|
Re: [jdev] Bug in jabberd2 (2.1.13) on win32
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. I've tested Adium 1.2.1, Spark 2.5.8, PSI 0.11 and all of them seems to work without a problem with new builds both TLS and non-TLS work, both PLAIN and DIGEST-MD5 work too. Please check (diff) your config XML files with new dist.xml files. There may be sections to upgrade in sm.xml, c2s.xml, router.xml. Your config may fail just because of some missing configuration or module. Also to have working TLS you need to have valid PEM and enable it at: c2s.xml id register-enable=true pemfile='server.pem'YOURDOMAIN/id Cheers, -- Adam Strzelecki |: nanoant.com :|
Re: [jdev] Bug in jabberd2 (2.1.13) on win32
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, but the problems only occur with ntlogon. However, in the old version (2.13), SASL and ntlogon worked fine. On Feb 4, 2008 11:38 AM, Dan Hulme [EMAIL PROTECTED] wrote: 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. I'd like to repeat for Thomas' sake that all three worked on the previous build which used Cyrus SASL. I've tested Adium 1.2.1, Spark 2.5.8, PSI 0.11 and all of them seems to work without a problem with new builds both TLS and non-TLS work, both PLAIN and DIGEST-MD5 work too. Please check (diff) your config XML files with new dist.xml files. There may be sections to upgrade in sm.xml, c2s.xml, router.xml. Your config may fail just because of some missing configuration or module. Also to have working TLS you need to have valid PEM and enable it at: c2s.xml id register-enable=true pemfile='server.pem'YOURDOMAIN/id Cheers, -- Adam Strzelecki |: nanoant.com :|
Re: [jdev] Bug in jabberd2 (2.1.13) on win32
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. I'd like to repeat for Thomas' sake that all three worked on the previous build which used Cyrus SASL. I've tested Adium 1.2.1, Spark 2.5.8, PSI 0.11 and all of them seems to work without a problem with new builds both TLS and non-TLS work, both PLAIN and DIGEST-MD5 work too. Please check (diff) your config XML files with new dist.xml files. There may be sections to upgrade in sm.xml, c2s.xml, router.xml. Your config may fail just because of some missing configuration or module. Also to have working TLS you need to have valid PEM and enable it at: c2s.xml id register-enable=true pemfile='server.pem'YOURDOMAIN/id Cheers, -- Adam Strzelecki |: nanoant.com :|
Re: [jdev] Bug in jabberd2 (2.1.13) on win32
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 PLAIN in c2s.xml for NTLOGON? Coz NTLOGON as mentioned ealier can work only with PLAIN auth. authreg-mechanism-traditional sasl must have only plain/ inside. (Rest should be commented out for NTLOGON) Regards, -- Adam Strzelecki |: nanoant.com :|
Re: [jdev] Bug in jabberd2 (2.1.13) on win32
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 tested all this with a clean install and no changes to the config files except the server name and realm. Did you enable only PLAIN in c2s.xml for NTLOGON? Coz NTLOGON as mentioned ealier can work only with PLAIN auth. authreg-mechanism-traditional sasl must have only plain/ inside. (Rest should be commented out for NTLOGON) Regards, -- Adam Strzelecki |: nanoant.com :|
Re: [jdev] Bug in jabberd2 (2.1.13) on win32
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 (/^/(_^^' http://www.xiaoka.com/ ._.(_.)_ im:[EMAIL PROTECTED]
Re: [jdev] Bug in jabberd2 (2.1.13) on win32
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 authentication with Windows API. Currently I'm using PLAIN+TLS+NTLOGON at my company and it works just fine with Adium and Miranda. So, it must have something to do with DIGIEST-MD5 or other auth methods. Do you have any XML logs where the connection stucks with server? Regards, -- Adam Strzelecki |: nanoant.com :|
Re: [jdev] Bug in jabberd2 (2.1.13) on win32
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]
Re: [jdev] Bug in jabberd2 (2.1.13) on win32
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 say you are using TLS...have you tried SASL? Here is a Coccinella log of it failing: -- ?xml version='1.0' encoding='UTF-8'?stream:stream xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' xml:lang='en' to='chatter.example.com' version='1.0'?xml version='1.0'?stream:stream xmlns:stream='http://etherx.jabber.org/streams' xmlns='jabber:client' from='chatter.example.com' version='1.0' id='8pagx0e4s4hanl8fnsr3ou05bnhrvapuhgd0uu50'stream:features xmlns:stream='http://etherx.jabber.org/streams'mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'mechanismPLAIN/mechanism/mechanismsauth xmlns='http://jabber.org/features/iq-auth'//stream:featuresauth xmlns='urn:ietf:params:xml:ns:xmpp-sasl' mechanism='PLAIN'ZGFuaFBjaGE0LmllbWSnLmNvcQBKYW5oAE9CRVNFWA==/authsuccess xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/stream:stream xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' to='chatter.example.com' xml:lang='en' version='1.0'?xml version='1.0'?stream:stream xmlns:stream='http://etherx.jabber.org/streams' xmlns='jabber:client' from='chatter.example.com' version='1.0' id='kncfraylp37okkurdzou43ns0gouuj44g1b5v52i' stream:features xmlns:stream='http://etherx.jabber.org/streams'bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'required//bindunbind xmlns='urn:ietf:params:xml:ns:xmpp-bind'/session xmlns='urn:ietf:params:xml:ns:xmpp-session'//stream:featuresiq type='set' id='1038'bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'resource[EMAIL PROTECTED]/resource/bind/iqstream:error xmlns:stream='http://etherx.jabber.org/streams'internal-server-error xmlns='urn:ietf:params:xml:ns:xmpp-streams'/text xmlns='urn:ietf:params:xml:ns:xmpp-streams'internal server error/text/stream:error/stream:stream/stream:stream -- Here is a PSI log of it failing: -- ?xml version=1.0? stream:stream xmlns:stream=http://etherx.jabber.org/streams; version=1.0 xmlns=jabber:client to=chatter.example.com xml:lang=en xmlns:xml=http://www.w3.org/XML/1998/namespace; ?xml version='1.0'?stream:stream xmlns:stream='http://etherx.jabber.org/streams' xmlns='jabber:client' from='chatter.example.com' version='1.0' id='x9f8vk6mqnietkkd0u1qn2yy3sacgegfn0sp5jd3' stream:features mechanisms xmlns=urn:ietf:params:xml:ns:xmpp-sasl mechanismPLAIN/mechanism /mechanisms auth xmlns=http://jabber.org/features/iq-auth/ register xmlns=http://jabber.org/features/iq-register/ /stream:features auth xmlns=urn:ietf:params:xml:ns:xmpp-sasl mechanism=PLAIN AHRvanllAbZhdGchdGZhdA==/auth success xmlns=urn:ietf:params:xml:ns:xmpp-sasl/ ?xml version=1.0? stream:stream xmlns:stream=http://etherx.jabber.org/streams; version=1.0 xmlns=jabber:client to=chatter.example.com xml:lang=en xmlns:xml=http://www.w3.org/XML/1998/namespace; ?xml version='1.0'?stream:stream xmlns:stream='http://etherx.jabber.org/streams' xmlns='jabber:client' from='chatter.example.com' version='1.0' id='oweh5z1u573c5x4k9hq73fpittrpvze7en1qwncw' stream:features bind xmlns=urn:ietf:params:xml:ns:xmpp-bind required/ /bind unbind xmlns=urn:ietf:params:xml:ns:xmpp-bind/ session xmlns=urn:ietf:params:xml:ns:xmpp-session/ /stream:features iq type=set id=bind_1 bind xmlns=urn:ietf:params:xml:ns:xmpp-bind resourceclient-resource/resource /bind /iq -- (When PSI fails, it causes a popup that says details: disconnected) -Dan On Jan 31, 2008 5:25 AM, Tomasz Sterna [EMAIL PROTECTED] wrote: 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]
Re: [jdev] Bug in jabberd2 (2.1.13) on win32
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! 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 Yup this is something I found missing in the SVN, added it looking at the db-setup.sqlite differences from times of my last commit and todays. It won't hurt if you run it twice, it will report errors on fields that are already updated in the database. The next problem is that SASL no longer seems to work. I don't know what the problem is, but an 'internal server error' is being returned to the client. Any idea what this could be? Logging in with no encryption works. When logging in with SASL the c2s server log shows I have authenticated, but the session manager shows nothing. When it installs, it installs libgsasl.dll. Is this what you mean? This is major change in comparison to previous win32 builds, we use now GSASL also for win32. I did one try to port GSASL to win32 last year, but I've surrendered. Once Tomasz deprecated Cyrus SASL for good, I did try once again yesterday. This time I found the reason it wasn't working, it was using /dev/random and having minor problems in other functions. Also those Vortex builds for win32 have the same problems... and simply don't work, reporting stupid error GSASL_MECHANISM_CALLED_TOO_MANY_TIMES, while the problem was gc_nonce function that was returning 3 == GSASL_MECHANISM_CALLED_TOO_MANY_TIMES, but the error was out of gsasl scope (different library). So, do you use, DIGEST-MD5? Do you build libgsasl it yourself? If yes, do you use the patches for libgsasl I've posted on my site at: http://www.nanoant.com/projects/jabberd2-win32#download Because without them especially without patch file, libgsasl will compile on win32, but simply won't work, as it is trying use /dev/ random, and etc. But then if you use my patch, then it must be again some other problem with libgsasl I haven't encountered yet. Please post me details about the auth method you're using, and maybe try disabling DIGEST-MD5 for user auth, and try PLAIN - Cheers, -- Adam Strzelecki |: nanoant.com :|
Re: [jdev] Bug in jabberd2 (2.1.13) on win32
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 nanoant. I am already using plain instead of digest-md5. The authentication, according to the logs, is working. However, no session ever shows up in the sm.log, and the client just hangs while connecting. As soon as I switch sasl off in the client, I can connect normally. 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. Thanks, Dan On Jan 30, 2008 2:15 AM, Adam Strzelecki [EMAIL PROTECTED] wrote: 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! 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 Yup this is something I found missing in the SVN, added it looking at the db-setup.sqlite differences from times of my last commit and todays. It won't hurt if you run it twice, it will report errors on fields that are already updated in the database. The next problem is that SASL no longer seems to work. I don't know what the problem is, but an 'internal server error' is being returned to the client. Any idea what this could be? Logging in with no encryption works. When logging in with SASL the c2s server log shows I have authenticated, but the session manager shows nothing. When it installs, it installs libgsasl.dll. Is this what you mean? This is major change in comparison to previous win32 builds, we use now GSASL also for win32. I did one try to port GSASL to win32 last year, but I've surrendered. Once Tomasz deprecated Cyrus SASL for good, I did try once again yesterday. This time I found the reason it wasn't working, it was using /dev/random and having minor problems in other functions. Also those Vortex builds for win32 have the same problems... and simply don't work, reporting stupid error GSASL_MECHANISM_CALLED_TOO_MANY_TIMES, while the problem was gc_nonce function that was returning 3 == GSASL_MECHANISM_CALLED_TOO_MANY_TIMES, but the error was out of gsasl scope (different library). So, do you use, DIGEST-MD5? Do you build libgsasl it yourself? If yes, do you use the patches for libgsasl I've posted on my site at: http://www.nanoant.com/projects/jabberd2-win32#download Because without them especially without patch file, libgsasl will compile on win32, but simply won't work, as it is trying use /dev/ random, and etc. But then if you use my patch, then it must be again some other problem with libgsasl I haven't encountered yet. Please post me details about the auth method you're using, and maybe try disabling DIGEST-MD5 for user auth, and try PLAIN - Cheers, -- Adam Strzelecki |: nanoant.com :|
Re: [jdev] Bug in jabberd2 (2.1.13) on win32
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 Strzelecki |: nanoant.com :|
Re: [jdev] Bug in jabberd2 (2.1.13) on win32
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 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 Strzelecki |: nanoant.com :|
Re: [jdev] Bug in jabberd2 (2.1.13) on win32
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 [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 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 Strzelecki |: nanoant.com :|
Re: [jdev] Bug in jabberd2 (2.1.13) on win32
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. -- /\_./o__ Tomasz Sterna (/^/(_^^' http://www.xiaoka.com/ ._.(_.)_ im:[EMAIL PROTECTED]
Re: [jdev] Bug in jabberd2 (2.1.13) on win32
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). 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. -- /\_./o__ Tomasz Sterna (/^/(_^^' http://www.xiaoka.com/ ._.(_.)_ im:[EMAIL PROTECTED]
Re: [jdev] Bug in jabberd2 (2.1.13) on win32
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] 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). 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. -- /\_./o__ Tomasz Sterna (/^/(_^^' http://www.xiaoka.com/ ._.(_.)_ im:[EMAIL PROTECTED]
Re: [jdev] Bug in jabberd2 (2.1.13) on win32
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 'internal server error' is being returned to the client. Any idea what this could be? Logging in with no encryption works. When logging in with SASL the c2s server log shows I have authenticated, but the session manager shows nothing. Thanks, Dan On Jan 29, 2008 2:51 PM, Dan Hulme [EMAIL PROTECTED] wrote: 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] 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). 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. -- /\_./o__ Tomasz Sterna (/^/(_^^' http://www.xiaoka.com/ ._.(_.)_ im:[EMAIL PROTECTED]
Re: [jdev] Bug in jabberd2 (2.1.13) on win32
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 -- -- This updates jabberd2 sqlite databases created prior to 2.1.19. -- -- sqlite3 jabberd2.db db-setup.sqlite -- ;-) The next problem is that SASL no longer seems to work. I don't know what the problem is, but an 'internal server error' is being returned to the client. Any idea what this could be? Logging in with no encryption works. When logging in with SASL the c2s server log shows I have authenticated, but the session manager shows nothing. Do you have gsasl library installed? -- /\_./o__ Tomasz Sterna (/^/(_^^' http://www.xiaoka.com/ ._.(_.)_ im:[EMAIL PROTECTED]
Re: [jdev] Bug in jabberd2 (2.1.13) on win32
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 between the two versions is not compatible. I used the installed database and it worked fine. Well... $ head tools/db-update.sqlite -- -- This updates jabberd2 sqlite databases created prior to 2.1.19. -- -- sqlite3 jabberd2.db db-setup.sqlite -- ;-) The next problem is that SASL no longer seems to work. I don't know what the problem is, but an 'internal server error' is being returned to the client. Any idea what this could be? Logging in with no encryption works. When logging in with SASL the c2s server log shows I have authenticated, but the session manager shows nothing. Do you have gsasl library installed? -- /\_./o__ Tomasz Sterna (/^/(_^^' http://www.xiaoka.com/ ._.(_.)_ im:[EMAIL PROTECTED]
Re: [jdev] Bug in jabberd2 (2.1.13) on win32
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]
Re: [jdev] Bug in jabberd2 (2.1.13) on win32
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 socket as it is still in use, so it will work. Not sure why the socket that is being appended is broken, but if this function is not called (at mio_impl.h: 267), the program works fine. It may not be reusing sockets, but everything else works. In my experience win32 does weird things with closed sockets: if you close a listening socket, it doesn't actually go away until all connected clients do too. It sounds like this is similar, and that perhaps for win32 you shouldn't be trying to pool sockets. -- - Norman Rasmussen - Email: [EMAIL PROTECTED] - Home page: http://norman.rasmussen.co.za/
Re: [jdev] Bug in jabberd2 (2.1.13) on win32
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 of 'connect' on a socket that has been shut down. So the win32 implementation should not be pooling sockets, I guess. -Dan On Jan 24, 2008 12:51 AM, Norman Rasmussen [EMAIL PROTECTED] wrote: 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 socket as it is still in use, so it will work. Not sure why the socket that is being appended is broken, but if this function is not called (at mio_impl.h: 267), the program works fine. It may not be reusing sockets, but everything else works. In my experience win32 does weird things with closed sockets: if you close a listening socket, it doesn't actually go away until all connected clients do too. It sounds like this is similar, and that perhaps for win32 you shouldn't be trying to pool sockets. -- - Norman Rasmussen - Email: [EMAIL PROTECTED] - Home page: http://norman.rasmussen.co.za/
Re: [jdev] Bug in jabberd2 (2.1.13) on win32
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 revent and event fields were not being reset
on freeing it for reuse. I zeroed them (it seems only the event must
be cleared):
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; \
priv_fd-mio_fd.fd = 0; \
priv_fd-revent = 0; \
priv_fd-event = 0; \
MIO(m)-next_free = priv_fd;\
} \
And the bug goes away. Since the socket is available for reuse, it
doesn't make sense to remember the old event flags. This may mean that
an event may arrive that doesn't get handled, of course, but if it
*is* to be handled, the mio struct should not be marked as available
until the event is handled.
In this vein, I have provided a patch which does nothing when
_mio_free_fd is called, but frees it when the FD_CLOSE is received.
It's attached. It basically replaces mio_free_fd with a dummy
function and moves the functionality to another function.
-Dan
On Jan 24, 2008 11:25 AM, Dan Hulme [EMAIL PROTECTED] wrote:
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 of
'connect' on a socket that has been shut down.
So the win32 implementation should not be pooling sockets, I guess.
-Dan
On Jan 24, 2008 12:51 AM, Norman Rasmussen [EMAIL PROTECTED] wrote:
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 socket as it is still in use, so it will
work. Not sure why the socket that is being appended is broken, but
if this function is not called (at mio_impl.h: 267), the program works
fine. It may not be reusing sockets, but everything else works.
In my experience win32 does weird things with closed sockets: if you close a
listening socket, it doesn't actually go away until all connected clients do
too. It sounds like this is similar, and that perhaps for win32 you
shouldn't be trying to pool sockets.
--
- Norman Rasmussen
- Email: [EMAIL PROTECTED]
- Home page: http://norman.rasmussen.co.za/
mio_wsasync.h.diff
Description: Binary data
Re: [jdev] Bug in jabberd2 (2.1.13) on win32
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 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 revent and event fields were not being reset
on freeing it for reuse. I zeroed them (it seems only the event must
be cleared):
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; \
priv_fd-mio_fd.fd = 0; \
priv_fd-revent = 0; \
priv_fd-event = 0; \
MIO(m)-next_free = priv_fd;\
} \
And the bug goes away. Since the socket is available for reuse, it
doesn't make sense to remember the old event flags. This may mean that
an event may arrive that doesn't get handled, of course, but if it
*is* to be handled, the mio struct should not be marked as available
until the event is handled.
In this vein, I have provided a patch which does nothing when
_mio_free_fd is called, but frees it when the FD_CLOSE is received.
It's attached. It basically replaces mio_free_fd with a dummy
function and moves the functionality to another function.
-Dan
On Jan 24, 2008 11:25 AM, Dan Hulme [EMAIL PROTECTED] wrote:
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 of
'connect' on a socket that has been shut down.
So the win32 implementation should not be pooling sockets, I guess.
-Dan
On Jan 24, 2008 12:51 AM, Norman Rasmussen [EMAIL PROTECTED] wrote:
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 socket as it is still in use, so it will
work. Not sure why the socket that is being appended is broken, but
if this function is not called (at mio_impl.h: 267), the program works
fine. It may not be reusing sockets, but everything else works.
In my experience win32 does weird things with closed sockets: if you
close a
listening socket, it doesn't actually go away until all connected clients
do
too. It sounds like this is similar, and that perhaps for win32 you
shouldn't be trying to pool sockets.
--
- Norman Rasmussen
- Email: [EMAIL PROTECTED]
- Home page: http://norman.rasmussen.co.za/
Re: [jdev] Bug in jabberd2 (2.1.13) on win32
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] wrote:
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 revent and event fields were not being reset
on freeing it for reuse. I zeroed them (it seems only the event must
be cleared):
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; \
priv_fd-mio_fd.fd = 0; \
priv_fd-revent = 0; \
priv_fd-event = 0; \
MIO(m)-next_free = priv_fd;\
} \
And the bug goes away. Since the socket is available for reuse, it
doesn't make sense to remember the old event flags. This may mean that
an event may arrive that doesn't get handled, of course, but if it
*is* to be handled, the mio struct should not be marked as available
until the event is handled.
In this vein, I have provided a patch which does nothing when
_mio_free_fd is called, but frees it when the FD_CLOSE is received.
It's attached. It basically replaces mio_free_fd with a dummy
function and moves the functionality to another function.
-Dan
On Jan 24, 2008 11:25 AM, Dan Hulme [EMAIL PROTECTED] wrote:
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 of
'connect' on a socket that has been shut down.
So the win32 implementation should not be pooling sockets, I guess.
-Dan
On Jan 24, 2008 12:51 AM, Norman Rasmussen [EMAIL PROTECTED] wrote:
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 socket as it is still in use, so it will
work. Not sure why the socket that is being appended is broken, but
if this function is not called (at mio_impl.h: 267), the program works
fine. It may not be reusing sockets, but everything else works.
In my experience win32 does weird things with closed sockets: if you
close a
listening socket, it doesn't actually go away until all connected
clients do
too. It sounds like this is similar, and that perhaps for win32 you
shouldn't be trying to pool sockets.
--
- Norman Rasmussen
- Email: [EMAIL PROTECTED]
- Home page: http://norman.rasmussen.co.za/
Re: [jdev] Bug in jabberd2 (2.1.13) on win32
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? -- /\_./o__ Tomasz Sterna (/^/(_^^' http://www.xiaoka.com/ ._.(_.)_ im:[EMAIL PROTECTED]
Re: [jdev] Bug in jabberd2 (2.1.13) on win32
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 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? -- /\_./o__ Tomasz Sterna (/^/(_^^' http://www.xiaoka.com/ ._.(_.)_ im:[EMAIL PROTECTED]
Re: [jdev] Bug in jabberd2 (2.1.13) on win32
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 http://jabberd2.xiaoka.com/browser/tags/jabberd-2.1.13/mio: select, poll, epoll, wsasync. Which one did you choose during ./configure? -- /\_./o__ Tomasz Sterna (/^/(_^^' http://www.xiaoka.com/ ._.(_.)_ im:[EMAIL PROTECTED]
Re: [jdev] Bug in jabberd2 (2.1.13) on win32
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 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 http://jabberd2.xiaoka.com/browser/tags/jabberd-2.1.13/mio: select, poll, epoll, wsasync. Which one did you choose during ./configure? -- /\_./o__ Tomasz Sterna (/^/(_^^' http://www.xiaoka.com/ ._.(_.)_ im:[EMAIL PROTECTED]
Re: [jdev] Bug in jabberd2 (2.1.13) on win32
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: PreprocessorDefinitions=MIO_WSASYNC;WIN32;NDEBUG;_USRDLL;JABBERD2_EXPORTS;HAVE_CONFIG_H;_CRT_SECURE_NO_DEPRECATE;_CRT_NONSTDC_NO_DEPRECATE Am I correct in assuming this means it uses wsasync? -Dan On Jan 23, 2008 8:40 AM, Dan Hulme [EMAIL PROTECTED] wrote: 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 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 http://jabberd2.xiaoka.com/browser/tags/jabberd-2.1.13/mio: select, poll, epoll, wsasync. Which one did you choose during ./configure? -- /\_./o__ Tomasz Sterna (/^/(_^^' http://www.xiaoka.com/ ._.(_.)_ im:[EMAIL PROTECTED]
Re: [jdev] Bug in jabberd2 (2.1.13) on win32
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/ ._.(_.)_ im:[EMAIL PROTECTED]
Re: [jdev] Bug in jabberd2 (2.1.13) on win32
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 bug in wsasync implementation. I will talk to Win32 build maintainer about. -- /\_./o__ Tomasz Sterna (/^/(_^^' http://www.xiaoka.com/ ._.(_.)_ im:[EMAIL PROTECTED]
Re: [jdev] Bug in jabberd2 (2.1.13) on win32
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; \
priv_fd-mio_fd.fd = 0; \
MIO(m)-next_free = priv_fd;\
} \
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 socket as it is still in use, so it will
work. Not sure why the socket that is being appended is broken, but
if this function is not called (at mio_impl.h: 267), the program works
fine. It may not be reusing sockets, but everything else works.
Hope this helps.
-Dan
On Jan 23, 2008 9:26 AM, Dan Hulme [EMAIL PROTECTED] wrote:
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 bug in wsasync implementation.
I will talk to Win32 build maintainer about.
--
/\_./o__ Tomasz Sterna
(/^/(_^^' http://www.xiaoka.com/
._.(_.)_ im:[EMAIL PROTECTED]
[jdev] Bug in jabberd2 (2.1.13) on win32
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 s-want_write = 1; when a stream closes, and this is set, it seems to hang the next connection A similar bug is caused at error.c:85 s-want_write = 1; When a client is disconnected because of a bad stream/packet, this occurs, and disconnects the client. But, the next client cannot connect again. Some clients, such as PSI, do not cause this problem when disconnecting. It appears to be because they do not send a final /stream:stream tag before disconnecting. To duplicate the bug, connect to a win32 jabberd2 server with cocinella. Disconnect. Try to connect again. The second connection will hang and eventually fail. Try to connect again, and it will work again. If you telnet to the server in this state, it will not respond to anything you send it. Initially, I used the provided win32 build (336) on nanoant.com. This fails suitably for the test. Next, I tried building 2.1.21 on win32. The build doesn't work without some fixes to the code. Once I got it working, it had the same problem. Currently, I am using 2.1.13 on win32. I have built it myself and it works almost without changing anything. It has the bug, as well. My line numbers above refer to this version. I don't pretend to understand everything that's going on in the code. However, I have tried with sasl on, sasl off, plainttext, etc., and no options seem to change this problem. So it seems a fairly basic problem in jabberd2, and probably not related to plugins. Does deactivating want_write prevent the session close information from being sent or recorded? I don't know, but everything seems to work correctly even with that line commented. I'm unsure of what to try next in order to correctly fix the problem. Perhaps the developers can take this and run with it. I'm guessing that it has trouble writing to a closed session or something like that. -Dan
