After upgrading Jive messenger to 2.3.0 beta 1 from 2.2.2, clients are unable to connect to server. Server login is there, but clients are not able to connect. Server log shows connection closed before session established. If I install version 2.2.2, then clients are able to connect. I am using Fedora core 3
Hey pradeep,
JM 2.3.0 checks that the provided server name is correct when a new session is established. If the server name is incorrect then the connection will be rejected. Make sure that the part after the @ (i.e. the domain or server name) matches the name of your server.
Regards,
– Gato
Gato,
I thought that we were going to allow any name for client connections, but enforce the correct name only for s2s connections?
-Matt
Hey Matt,
The only case the server does not check the TO attribute of the stream header is for external components since JEP-114 uses the TO attribute with another purpose. As far as I remember we agreed on checking the TO attribute both for c2s and s2s connections which is what we are doing now in the JM 2.3.0 branch. BTW, I just checked the XMPP spec and it says that we MUST check the TO attribute. Anyway, we can optionally disable the checking for c2s if this might be an issue for clients.
Regards,
– Gato
My clients are connected like user@serveripaddress
I have around 300 users, and all are able to connect without any problem with 2.2.2 version. After upgradation only this problem is there. If I downgrade to 2.2.2 again they are able to connect. The above rules out any hardware, OS, configuration issues.
Thank You
Prasad
We too have this problem - we have multiple sites all on various non-routable network addresses (192.168.x.0). Although I am in the process of setting up internal groupwide DNS so we can resolve intranet machine names correctly, the disparate nature of our bridges etc have required us to use fixed IP addressing up to now. As a result all our users have an IP address in their client as the server name, but JM 2.2.2 wouldn’'t allow me to use the IP address as the server name, and hence I used its internal unqualified name. All works fine, however:- upgrading to 2.3.1 causes exactly the problem described here.
For some of our remote users who do not have internal DNS available, it isn’‘t an option to change their client server from an IP address to a name, because the client then cannot locate the server! Hence we cannot update to a later JM. For those machines I suppose I could enable ‘‘hosts’’ file lookup, but I’‘ve already reconfigured all our clients once to move to JM from jabberd, I’'m a little reluctant to go down the path of reconfiguring all clients to use servers names AND installing additional local DNS tables on each machine so the client knows where to look!
An option to either allow the server name to be it’'s IP or to allow clients to connect without enforcing the TO would be perfect. Pretty please! 8)
An option to either allow the server name to be it’'s
IP or to allow clients to connect without enforcing
the TO would be perfect. Pretty please! 8)
I agree. This issue can be a stop against upgrading to 2.3.0 to us.
For some of our remote users who do not have internal
DNS available, it isn’'t an option to change their
client server from an IP address to a name, because
the client then cannot locate the server! Hence we
cannot update to a later JM. For those machines I
suppose I could enable ‘‘hosts’’ file lookup, but I’'ve
already reconfigured all our clients once to move to
JM from jabberd, I’'m a little reluctant to go down
the path of reconfiguring all clients to use servers
names AND installing additional local DNS tables on
each machine so the client knows where to look!
An option to either allow the server name to be it’'s
IP or to allow clients to connect without enforcing
the TO would be perfect. Pretty please! 8)
I don’'t know which clients are you using but some clients allow to specify the host and port to use to establish the connection. That means that you may specify the host to be the IP address of your server so the socket can be established and you may use the correct user JID (e.g. johndoe@myserver.com) of the user that is logging in. Will that work for you?
Regards,
– Gato
I don’'t know which clients are you using but some
clients allow to specify the host and port to use to
establish the connection. That means that you may
specify the host to be the IP address of your server
so the socket can be established and you may use the
correct user JID (e.g. johndoe@myserver.com) of the
user that is logging in. Will that work for you?
Just checked with Exodus. So we’'ll be fine with that. Just will have to go through all clients and change settings. I think there is something similar in Psi. But probably not every client will be able to do that.
Hi,
At would appear that our current client will allow connection via IP address so I’'ll test that out, thanks!
I’‘ve only got about 40 clients to re-configure - although some are relatively inaccessible - and it will take me a full day I expect. For someone with hundreds or thousands of clients it wouldn’'t really be a practical solution I suspect 8)
regards
Mike