powered by Jive Software

Phantom nick in MUC

I had a play around with his nick in a MUC … he changed his nick a few times. One of those nick changes didn’'t quite work right.

His real session nick changed, but the previous nick also stuck around. So he was appearing in the chat room twice. One with his first nick, which I call the phantom nick, and again with his new nick.

If I tried to /kick the phantom user, his actual users session was kicked out.

He logged off completely, but the phantom nick is still there.

Just on a lark, I tried changing my own nick to the phantom nick … I got a 409 conflict error and was kicked out of the chat room.

When I went back into the chat, I was the only one who showed up for me in the member list. Although there were other people in the room. When I left the chat and joined again, it showed everyone again … including the phantom nick.

Any suggestions on what might be wrong?

I’‘m sure that restarting the server will clear the problem … but it’'s kind of a pain now.

david

On a similar vein … I had a user login to a chat today … and then leave … and leave again … and leave again … it appears that he is leaving every 5 minutes (give or take a few seconds).

I closed that users connection and he left the room one more time … but no more after that.

I can’'t say what caused the problem … nothing appeared in the log files that looks likely.

david

FWIW: We considered renaming that chat room “Hotel California” because that user checked out … but he never really left.

This has been happening more and more … just about every day someone is in a chat room, and leaves, and leaves again, and leaves again, etc.

There is a regular interval between the leaving … usually 6 minutes.

If the user is local, then I can close their session to get it to stop … but if the user is connecting to the MUC from another server (like jabber.org), I can’'t get rid of the users constant leaving without restarting the wildfire server.

Anyone know what could be going wrong?

Thanks!

david

I’'m still having this problem … after upgrading to Openfire 3.3.0.

Now that I can see the members of a chat room, I see the person who is leaving" the chat every 5 minutes is still listed in the chat room’'s roster, but their role & affiliation are both set to “none”.

Any suggestions?

david

Hi,

Are your users coming from a different server or are they connecting to the local conference server?

Is this machine behind some sort of NAT device, which would have a timeout?

On the admin console, what do you have set for Group Chat -> Other settings -> Ide User Settings?

Is anything coming to any of the logs?

daryl

akrherz wrote:

Are your users coming from a different server or are they connecting to the local conference server?

I’‘m pretty sure it’'s different servers … jabber.org mostly, but I think it happened with Google too.

Is this machine behind some sort of NAT device, which would have a timeout?

No, direct connect.

On the admin console, what do you have set for Group Chat -> Other settings -> Ide User Settings?

Kick after 120 minutes.

Is anything coming to any of the logs?

Not that I can see. I haven’'t tried enabling debug logging.

david

Kick after 120 minutes.

That’'s your problem. Switch it to never and see what happens.

daryl

akrherz wrote:
Kick after 120 minutes.

That’'s your problem. Switch it to never and see what happens.

Can’‘t hurt … I’'ll give it a shot.

Doesn’'t seem logical though.

david

Hey guys,

I think I finally got to the bottom of this problem. The problem happens when an occupant is using uppercase letters in the nickname which under certain cases (e.g. kicking idle users) will generate the phantom users. The problematic cases are:

  1. Kicking idle users (as noted in this thread)

  2. Destroying a room will never alert those users that the room is gone

  3. Logging of room conversations will store messages of these users as sent by the room (and not the users)

Creating Jira issue and fixing this now.

Thanks,

– Gato

I created JM-1036 and JM-1037 and checked in the corresponding fixes. You can find them in the next nightly build (use it only if you are using Openfire 3.3.0).

Regards,

– Gato