3.0 Beta still has presence problem

Hi all,

I’‘ve been running 2.6.2 with LDAP Auth and LDAP Groups for a while and have been seeing the presence problems discussed in other threads. I updated to 3.0 today in the hopes that this might have been fixed. No such luck. I’‘m not sure what to post to help resolve the problem, but I seem to be able to reproduce the problem at the moment with one specific user. I’'ve done an LDAP dump of the problematic user and compared it to a working user and there are no apparent differences. (One thing to note since its mentioned in another thread…both users have a comma in the CN, but one works fine and the other does not.)

Let me describe what I am seeing specifically…

Using 3 accounts. My own, the user that does not work, and the user that does work. I log into Wildfire (all users running Spark 1.1.4.) Working user logs in and I see the roster change. Broken user logs in and I do NOT see the roster change. If I log into the admin GUI, I see all three of us online. I ask broken user to log off and then back on. While off, the admin GUI shows her off, when she logs back in, the GUI shows her online. Spark shows nothing. I bring up the Smack Debug Window and have her do the same thing. No presence packets received by my client. I do the same thing with the working user and all works as expected, GUI, Spark roster, and debug window all show the updates.

I then turned on debug in the Log View in the admin GUI. Had the broken user log off and log on, and then the working user do the same. Log for each is identical (besides the user specific stuff obviously.) Wildfire sees the change to offline, then shows the LDAP auth process and then ends with the “context created…” line. Not helpful at all.

Finally…if both the working and non-working users are online and I go offline and then online, I now see both of them. Also, the non-working user sees my status change just fine. Its very odd and frustrating.

I’'d be happy to do some more extensive testing/logging/information sharing if someone would be so kind as to point me in the right direction. This presence problem is preventing me from taking Wildfire from an IT test to a production deployment.

Thank you.

-Andy

One more interesting observation.

In the Web GUI if I go to Users/Groups and click on the non-working user, it shows “None” for “Groups:”. However, if I then click Group Summary and then the one group I have defined, the non-working account is listed as expected.

Seeing this, I checked all the other accounts I have created, and idetified several accounts with the same situation. I just called each person and did my testing and they are all seeing the problem. (As described in my previous post.)

I then started looking closely at the accounts, both through LDAP and Users and Computers and noticed that all the accounts with this problem have a comma in the name and all the ones that work fine do not. (As was posted in another thread a while back.) I then changed one of the problem accounts to remove the comma, which updated the “cn” and the “name” attributes in the LDAP record for the user and the problem went away. This is for sure a bug in the code and easily reproducable.

I don’'t see anything in the LDAP configuration that references cn or name specifically except so Im not sure what part of the auth/login process pulls one or both of the attributes and breaks.

Im happy to help in anyway I can, just let me know. Unfortunatly, I can not remove the comma for the 600 or so user accounts this affects, so I’'m hoping a fix can be found on the server side.

Thank you…