#235 SIPE Adium plugin does not work with Lync server under Mavericks
When upgrading to Mavericka, the SIPE plugin stopped working ("Read error" when connecting). It sent one SIP message, after which the server responds 401, and another request is sent with auth info. After this, the server terminates the connection.
After some digging in log files and finally stepping through the code, I tracked it down to that this happens when the cyclic buffer wraps around, causing two socket sends instead of one for the request. It is possible that this is a server bug. I have only observed this problem on machines running Mavericks, maybe something was changed in the socket implementation?
Anyway, I tried increasing the buffer size so that the initial SIP requests fit, causing them to be sent one by one, and the problem went away.
Your analysis is unfortunately completely wrong.
You obviously choose to ignore the instructions and didn't read the FAQ before filing a bug.
Closing as duplicate of bug [#216].
Related
Bugs:
#216Hi,
On the contrary, I did read that bug report and the part in the FAQ where this related problem is taken up. The workaround suggested in the FAQ and bug #216 (disabling BEAST fix, running against the latest checkout of Adium and SIPE) did not solve the problem for me. I also tried to fiddle around with the kSSLSessionOptionSendOneByteRecord flag, as per your post in the thread, and I could not see that it helped me.
To me (admittedly quite new to how the protocol works) the problems seem a lot related: The BEAST mitigation splits up the request into chunks (reading here: http://www.educatedguesswork.org/2011/11/rizzoduong_beast_countermeasur.html), and this is also what you do on the application side (with the buffer).
I cannot argue that I missed may have missed the root cause (I only spent about 15-30 minutes trying to find the cause). It may be that my problem is somehow local to my account / server, I really can't say. Changing the buffer size did, however, fix my problem and I have been happily using Adium since then. Just thought I'd like to share that in the hope that it may have helped others.
Last edit: Rickard 2014-02-22
The only problem with your "tip" is that it doesn't do anything. The SIPE purple backend allocates a circular buffer for sending with a size of 0 and then for each new message calls `purple_circ_buffer_append(). To quote from the libpurple API documentation:
From that circular buffer the SIPE purple backend always tries to write as much as possible to the SSL connection. So if anything, you would need to make sure that libpurple, SSL or the TCP/IP socket would accept more data on a write attempt. Those parameters can't be changed by SIPE.
My best guess is that SSL BEAST mitigation is still active. To prove that they are really not active you'll need to
make sure you have disabled the SSL BEAST mitigation in the SIPE account settings. If you don't see the checkbox in the UI, you don't have SIPE 1.18.x or later, or your code is not compiled on Mac OS X 10.9.
make sure the SSL BEAST mitigation disable workaround is compiled into Adium. Run Adium in debug mode and if you don't see the message
cdsa: Explicitly disabling SSL BEAST mitigation...or if you see the messagecdsa: SSLSetSessionOption failed to disable SSL BEAST mitigation, then the workaround wasn't activated.verify with a tool like Wireshark or
ssldump -Adthat none of the sent messages is split into one 32 byte and one N byte TLS record, which is what the 1/n-1 record split looks like on the wire.Thanks you for your detailed response!
Sorry about taking up your time. It turned out I made a mistake when checking out the code for the SIPE plugin, I did another hg pull/update on Adium, and I accidentally reset the checkout to the default branch (which apparently does not have the BEAST mitigation disable code), meaning the breakpoint I set previously pointed somewhere else entirely. Your hint about looking for the log printout caught my mistake!