Chat event logs off users
Open implementation of the Lotus Sametime protocol
Brought to you by:
jhkrischel,
taliesein
Menu
▾
▴
#82 Chat event logs off users
Some users who open chat windows with me are logged
out/off the sametime server, it is consistent with
particular users. When I open windows with them I get a
message " 'user' has logged out" and their icon
momentarily disappears from the buddy list. It returns
after a few seconds.
This happened on 1.2.7 and 1.2.8.
Most users are straight Lotus Notes users with basic
SameTime.
Discussion
Anonymous
Logged In: YES
user_id=77326
This has been used fairly regularly against Lotus Sametime
Connect versions 2.0 and 3.0, you'll have to provide better
client and version information.
And wouldn't logging out be a bug on their end? If old
versions work, and a newer version disconnects on an
incoming message...
Logged In: YES
user_id=77326
related help forum discussion:
https://sourceforge.net/forum/forum.php?thread_id=1443720&forum_id=378953
Logged In: YES
user_id=1415197
Most users have Notes 5.0.10 with sametime. Other have a
stand alone version of Sametime @ V2.5.
I hear you on "a bug at their end" however Sametime is the
standard, and Meanwhile is the contender. All Sametimes seem
to work well together.
Logged In: YES
user_id=77326
can you get the debug output from when gaim when this
happens? It may give a clue as to what's happening in the
session while this happens, and may present the code that
the user disconnected with. Use
gaim -dto obtain this. Ionly need the portion leading up to the user logging off,
not the entire thing (as it can be quite large otherwise)
Logged In: YES
user_id=21785
Here's the debug output from gaim when this happens:
meanwhile: setting conversation (CN=Roderick
Thomas/OU=WashingtonDC/O=Pershing, (null)) state: pending
meanwhile: channel 0x00000006 state: waiting
meanwhile: channel 0x00000006 state: initializing
meanwhile: channel 0x00000006 state: waiting
meanwhile: channel 0x00000006 state: error (0x80000221)
meanwhile: setting conversation (CN=Roderick
Thomas/OU=WashingtonDC/O=Pershing, (null)) state: closed
accels: accel changed, scheduling save.
accels: accel changed, scheduling save.
accels: accel changed, scheduling save.
accels: accel changed, scheduling save.
accels: accel changed, scheduling save.
accels: accel changed, scheduling save.
Logged In: YES
user_id=21785
The user says that sametime freezes and he gets logged out
of sametime. (and I see him go away from the Buddy List). A
minute later he get logged back in, but can't type into any
of the windows he had open. Then a minute later he can type
into windows and everything is ok.
Logged In: YES
user_id=77326
ok, let's see if I can piece this all together...
the error code is 0x80000221, which means the server saw the
other client disconnect, and closed the channel on the
client's behalf. That would seem to indicate that the
problem isn't dependant on the server version, which will
make things much easier to debug.
I'm going to guess and say that something in the offering of
the encryption support is doing this: that meanwhile may be
mildly mangling the offer or accept of encryption in ways
that causes earlier clients to choke and drop their
connection, then reconnect (hence that hanging period
described). I must then postulate that later clients or
versions of the official toolkit can handle this mangling
and don't see it as an error, or silently correct it.
Backing up this idea is the fact that the problem appeared
between the 0.5 release onward. This was the first release
to offer the DH RC2 128 cipher for channel encryption.
So what I need to do then is find a way to duplicate the
problem on a server I have access to. I can get traces of
some official clients talking to the problematic versions,
and I can get some traces of meanwhile talking to the
problematic versions, and I can try to discern what's
different between the two.
A big hole in my theory is that I have a copy of STConnect
3.0, and I can't get this to happen with that version. I've
seen a report stating that a 3.0 user experienced this
problem, so I should have been able to replicate the
problem as well. That indicates that it may in fact be
related to the server version, and that's going to be very
hard to diagnose without access to an appropriately
versioned server.
Logged In: YES
user_id=21785
Initially I thought that it was working with 3.2 and not
with 3.0, but that seems to be incorrect. There was
confusion because the top of the about box says 3.0, but in
the list of files at the bottom, they're 3.2.0.x. So oddly
enough, we're seeing it crash for some people and not for
others, but they're all using the same exact version of the
Sametime client but are connecting to different servers.
So, we have server A and server B. User X and User Y.
User X is using server A and me and user Y are using server B.
I can initiate a conversation with user X.
User Y gets logged out when I initiate a conversation.
If I change to login to server A. I can't talk to anyone. It
logs me out:
meanwhile: setting conversation (CN=Gordon
Hawley/OU=WashingtonDC/O=Pershing, (null)) state: pending
meanwhile: channel 0x00000004 state: waiting
meanwhile: channel 0x00000004 state: initializing
meanwhile: channel 0x00000004 state: waiting
meanwhile: channel 0x00000004 state: error (0x80002005)
meanwhile: falling back on a plaintext conversation
meanwhile: channel 0x00000005 state: waiting
meanwhile: channel 0x00000005 state: initializing
meanwhile: channel 0x00000005 state: waiting
gaim-meanwhile: connection reset
account: Disconnecting account 0x8220080
connection: Disconnecting connection 0x8233a88
Logged In: YES
user_id=21785
Some more testing and I've verified that I work fine with
everyone logging into one particular server, but I have
problems with everyone logging into the other server. And I
can't use the other server at all. Is there anyway I can
find out what version of the sametime server are running?
Logged In: YES
user_id=77326
Wait, two different servers?
You might be using something that I've been looking for for
a while. You may actually have more than one community in
your Sametime deployment! If that's the case, this is very
exciting!
Can you get a logging output from when someone attempts to
IM you from the other server? If it is indeed a
two-community setup, then instead of the (null) after the
other user's ID, you should see another string. This will be
the community string, and it would probably be necessary to
use in order to correctly contact the other person.
It may turn out not to be separate communities after all,
but I can hope.
Logged In: YES
user_id=21785
Sorry. These must be the same community . You can seen in
some of the logs below, there is a (null) after the id. I
don't know too much about the setup here. I think there may
be different sametime servers at our different locations,
but there linked up somehow.
I still think the problem has something to do with the fact
that I can't even use one of our servers. I kicks me out
when I try to IM anyone:
meanwhile: setting conversation (CN=Gordon
Hawley/OU=WashingtonDC/O=Pershing, (null)) state: pending
meanwhile: channel 0x00000004 state: waiting
meanwhile: channel 0x00000004 state: initializing
meanwhile: channel 0x00000004 state: waiting
meanwhile: channel 0x00000004 state: error (0x80002005)
meanwhile: falling back on a plaintext conversation
meanwhile: channel 0x00000005 state: waiting
meanwhile: channel 0x00000005 state: initializing
meanwhile: channel 0x00000005 state: waiting
gaim-meanwhile: connection reset
account: Disconnecting account 0x8220080
connection: Disconnecting connection 0x8233a88
Logged In: YES
user_id=77326
sbender, for an outgoing conversation, that's what I'd
expect to see. An incoming conversation from a user on
another community is what would show as non-(null). It could
be that we're trying to address someone who requires a
non-(null) with a (null), which may be causing the logoff
problem (I'm not sure, really).
What you'd need to do is get someone to send you a message
(the channel ID should start with 0x8) and watch the
debugging output as they tried. Sorry for all the run-around
in this, but it's my only way to get at the problem, really.
Logged In: YES
user_id=21785
Here's log from an incomming chat from one of the people I
have this problem with.
meanwhile: channel 0x80000001 state: waiting
meanwhile: channel offered with encrypt policy 0x0000
meanwhile: channel offered cipher id 0x0000
meanwhile: channel 0x80000001 added cipher RC2/40 Cipher
meanwhile: channel offered cipher id 0x0001
meanwhile: channel 0x80000001 added cipher RC2/128 Cipher
meanwhile: setting conversation (CN=*
*/OU=EastBrunswick/O=Pershing, (null
)) state: pending
meanwhile: channel 0x80000001 selected cipher RC2/40 Cipher
meanwhile: channel 0x80000001 state: open
meanwhile: setting conversation (CN=Linda
Guo/OU=EastBrunswick/O=Pershing, (null
)) state: open
gaim-meanwhile: conversation features set to 0x0080
gaim-meanwhile: conversation features set to 0x0080
Logged In: YES
user_id=77326
oh well, there goes that theory. Thanks for doing that,
anyway. I guess it's back to being a version/protocol
incompatability or something. We'll get this thing figured
out eventually, I'm sure of it.