SIPE not following the redirect for autodiscover

  • Tim

    Tim - 2014-03-14

    it tries to connect to which is correctly setup with a cname for but fails, tries to connect on port 80 which providers a redirect to but doesn't seem to follow that and EWS fails, no contacts are added, and the ones I add manually show up as offline.
    But, if I set the cname to, contacts that I add manually show the correct status, but contacts are not automatically added.

    I created the debug log, but did not want to attach it since I couldn't find the base64 field that we are supposed to remove when following the directions in the FAQ. Here is a portion of it though.

  • Stefan Becker

    Stefan Becker - 2014-03-14

    Sorry, but I fail to see any error on SIPE's or libpurple's part in your log. It shows:

    (10:08:47) dnsquery: Performing DNS lookup for
    (10:08:47) dnsquery: IP resolved for
    (10:08:47) proxy: Attempting connection to

    which reverse resolves to Those servers don't answer on ports 443, that's why the first attempt fails with:

    (10:08:46) proxy: Connecting to
    (10:08:46) proxy: Error connecting to (Connection refused.).
    (10:08:46) proxy: Connection attempt failed: Connection refused.

    The second attempt to port 80 remains unanswered for 60 seconds:

    (10:08:47) proxy: Connecting to
    (10:08:47) proxy: Connected to
    (10:08:47) sipe: sipe_http_transport_connected:
    (10:09:47) sipe: sipe_http_transport_drop: dropping connection '': timeout
    (10:09:47) sipe: sipe_http_transport_free: destroying connection ''

    When I compare it to debug log from another Office 365 account, that request on that connection should be answered with a HTTP/1.1 302 Moved Temporarily response, redirecting the request to the real autodiscover server for your domain.

    Please make sure that your Office 365 setup is correctly configured and that you have no network elements in the path to that prevent a correct connection, e.g. a blocker for unauthorized HTTP connections from your intranet to the internet.

    Last edit: Stefan Becker 2014-03-14
  • Stefan Becker

    Stefan Becker - 2014-03-30

    Another user reported the same problem in this thread [fc28ad9f].

    Using the data from the provided log I can confirm that the reason is not a HTTP connection blocker, because I get the same behaviour from my computer for your domain.

    After reading another M$ document I tried one of the things listed as "alternatives" for autodiscover and voilá:

    $ wget -S http://autodiscover.<SOMEDOMAIN>/Autodiscover/Autodiscover.xml
    --2014-03-30 21:44:24--  http://autodiscover.<SOMEDOMAIN>/Autodiscover/Autodiscover.xml
    Resolving autodiscover.<SOMEDOMAIN> (autodiscover.<SOMEDOMAIN>)...,,, ...
    Connecting to autodiscover.<SOMEDOMAIN> (autodiscover.<SOMEDOMAIN>)||:80... connected.
    HTTP request sent, awaiting response... 
      HTTP/1.1 302 Moved Temporarily
      Connection: close
      Cache-Control: no-cache
      Pragma: no-cache
    Location: [following]

    Tim: as your log is obfuscated, I can't verify if the same is true for your account. It would be nice if you could confirm this.

    I'll look into options how to implement this. I think I'll add the GET approach as an alternative if the POST method times out.



    Forums: fc28ad9f

  • Stefan Becker

    Stefan Becker - 2014-04-01

    I've added the new EWS autodiscover type in commit 04e87de.

    Tim & Sparhawk: I've provided a new Windows libsipe.dll in the development area. Please download and retry if this now works for you.

  • Sparhawk

    Sparhawk - 2014-04-01

    Hi, thanks for update.. I tryed it.. even reinstalled pidgin and sipe plugin etc.. but no change :( here is the log from new version of libsipe.dll.

    • Stefan Becker

      Stefan Becker - 2014-04-02

      The log shows that EWS autodiscover works and the buddy list is retrieved correctly. But your server rejects our request for buddy presence information with ms-diagnostics: 4001;reason="XML parse failure";source=.... The XML sent to the server is valid, I verified it with xmllint.

      Nothing I can do there.

      BTW: Please change your password. You didn't obfuscate the log file as described in the FAQ.

      • Sparhawk

        Sparhawk - 2014-04-02

        now it is solved.. all I needed to do was added new contact.. now I can see statuses as well.. great work... btw I cant see my pwd in that log.. I deleted it, so it will be ok :)

        • Stefan Becker

          Stefan Becker - 2014-04-02

          Yeah, that was one thing I was going to suggest: delete all your contacts and start the buddy list from fresh. AFAIR another user had problems with an incorrectly-to-UCS-migrated contact list too.

          Thanks for the feedback, one step closer to next release.

  • Tim

    Tim - 2014-04-01

    Thanks for checking into this!
    I replaced the dll with the file downloaded from the link you provided and restarted Pidgin. I have not had the time to watch logs, but so far it does seem to have fixed part of the problem.
    I can now see user status, and it even updated my contact photos.
    I'm still having to manually add users though. It isn't automatically updating the contact list or groups.


Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks