This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 888074 - Pidgin-sipe unable to connect under Fedora 18
Pidgin-sipe unable to connect under Fedora 18
Status: CLOSED DUPLICATE of bug 770682
Product: Fedora
Classification: Fedora
Component: pidgin-sipe (Show other bugs)
18
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Stefan Becker
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-12-17 18:43 EST by Chad Feller
Modified: 2013-04-22 09:16 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-12-18 14:06:37 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Chad Feller 2012-12-17 18:43:02 EST
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@company.com,user@company.com.
(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@company.com,user@company.com (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:
Comment 1 Stefan Becker 2012-12-17 22:16:02 EST
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>
Comment 2 Chad Feller 2012-12-18 13:56:21 EST
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).
Comment 3 Stefan Becker 2012-12-18 14:06:37 EST
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 ***
Comment 4 Gilles 2013-04-22 09:16:55 EDT
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 ?

Note You need to log in before you can comment on or make changes to this bug.