Description of problem: Since upgrading to Fedora 18 beta, I've been unable to connect to our local Communicator server with pidgin. The connection fails with a "Read Error". The pidgin Debug Window shows the following: (15:22:36) account: Connecting to account user,user. (15:22:36) connection: Connecting. gc = 0x29e7ae0 (15:22:36) dnssrv: querying SRV record for company.com: _sipinternaltls._tcp.company.com (15:22:36) dnssrv: found 1 SRV entries (15:22:36) dnsquery: Performing DNS lookup for ocspool.company.com (15:22:36) dns: Wait for DNS child 6044 failed: No child processes (15:22:36) dns: Created new DNS child 6200, there are now 1 children. (15:22:36) dns: Successfully sent DNS request to child 6200 (15:22:36) dns: Got response for 'ocspool.company.com' (15:22:36) dnsquery: IP resolved for ocspool.company.com (15:22:36) proxy: Attempting connection to 123.456.78.90 (15:22:36) proxy: Connecting to ocspool.company.com:5061 with no proxy (15:22:36) proxy: Connection in progress (15:22:36) proxy: Connecting to ocspool.company.com:5061. (15:22:36) proxy: Connected to ocspool.company.com:5061. (15:22:36) nss: subject=CN=ocspool.company.com,OU=IT,O=Company,L=City,ST=State,C=US issuer=OU=Equifax Secure Certificate Authority,O=Equifax,C=US (15:22:36) nss: partial certificate chain (15:22:36) certificate/x509/tls_cached: Starting verify for ocspool.company.com (15:22:36) certificate/x509/tls_cached: Checking for cached cert... (15:22:36) certificate/x509/tls_cached: ...Found cached cert (15:22:36) nss/x509: Loading certificate from /home/user/.purple/certificates/x509/tls_peers/ocspool.company.com (15:22:36) certificate/x509/tls_cached: Peer cert matched cached (15:22:36) nss/x509: Exporting certificate to /home/user/.purple/certificates/x509/tls_peers/ocspool.company.com (15:22:36) util: Writing file /home/user/.purple/certificates/x509/tls_peers/ocspool.company.com (15:22:37) certificate: Successfully verified certificate for ocspool.company.com (15:22:37) stun: using server (15:22:37) stun: using server (15:22:37) stun: using server (15:22:37) stun: using server (15:22:37) stun: using server (15:22:37) connection: Connection error on 0x29e7ae0 (reason: 0 description: Read error) (15:22:37) account: Disconnecting account user,user (0x1406d60) (15:22:37) connection: Disconnecting connection 0x29e7ae0 (15:22:37) GLib: g_hash_table_destroy: assertion `hash_table != NULL' failed (15:22:37) connection: Destroying connection 0x29e7ae0 Under Fedora 17 I had no such issue, and I'm using the same account profile under pidgin. Version-Release number of selected component (if applicable): pidgin-sipe-1.14.0-1.fc18.x86_64 purple-sipe-1.14.0-1.fc18.x86_64 pidgin-2.10.6-4.fc18.x86_64 (this issue also existed under: pidgin-sipe-1.13.3-1.fc18.x86_64 purple-sipe-1.13.3-1.fc18.x86_64 I just never got around to reporting it in a timely fashion.) How reproducible: always Steps to Reproduce: 1.Try to connect to a Communicator Server under Fedora 18 2. 3. Actual results: connection failure Expected results: connection success Additional info:
Please try from a shell: $ export NSS_SSL_CBC_RANDOM_IV=0 $ pidgin Does it work after that? See also SIPE FAQ: <https://sourceforge.net/apps/mediawiki/sipe/index.php?title=FAQ>
Yes, setting that environmental variable fixes it, and I can connect. Based off of the SF link, it is surprising that fixed it, as it worked fine in Fedora 17 (as F17 also had the affected version of NSS).
That means that a) you are connecting to one of the OCS/Lync servers that hasn't been upgrade to the latest Microsoft SSL code [e.g. I can connect to my Office365 test account with NSS_SSL_CBC_RANDOM_IV=1] b) the backward compatibility patch for NSS in F15/F16/F17 was obviously dropped for F18. Closing as duplicate to the original NSS bug. *** This bug has been marked as a duplicate of bug 770682 ***
Hi, I have the same issue, but setting NSS_SSL_CBC_RANDOM_IV dont fix it :-( pidgin.x86_64 - 2.10.7-2.fc18 pidgin-sipe.x86_64 - 1.15.1-1.fc18 nss.x86_64 - 3.14.3-1.fc18 purple-sipe.x86_64 - 1.15.1-1.fc18 Any idea ?