39154 - SSL connections for nntp and imap are broken.

Status: VERIFIED FIXED

(MailNews Core :: Networking, defect, P2)

Description

[Scott MacGregor]

This problem has been around for at least 2 weeks, we just haven't crystalized
it into a bug yet.

I started looking at this and it appears that we pass the correct port and host
into the networking layer. necko is in turn creating a ssl socket correctly. I'm
finding myself getting in here:
nsSSLSocketProvider::NewSocket and successfully returning a socket.

However, nothing happens after this point. PSM never comes up to ask me to
choose a certificate to use.

We have this problem regardless of the mail protocol being used.

Comment 1

[Doug Turner (:dougt)]

can you try putting breakpoints on:

nsSSLIOLayerConnect
nsSSLIOLayerRead
nsSSLIOLayerWrite

Comment 2

[Scott MacGregor]

Thanks for the tip doug. We do reach the connect phase. And the first time a
read occurrs, amount = 2048 but the PR_Recv calls returns a -1 and we fall out.

PRInt32 result = PR_Recv(fd, buf, amount, 0, PR_INTERVAL_MIN);

Comment 3

[Doug Turner (:dougt)]

what is the PR_GetError()?  Is it PR_IO_TIMEOUT_ERROR?  If it is, you are still 
good and will be placed in the select q.

Comment 4

[Scott MacGregor]

you are right doug. It's just the timeout. Unfortunately nothing happens after

that read. We don't get called back into read, write or close....

Comment 5

[Doug Turner (:dougt)]

ssl connections are working for http(s).  How are you creating the socket?  The 
same way http does?  Maybe we should get together today or tomorrow for some 
debuggin fun?

Comment 6

[Scott MacGregor]

sure let's look at it after tomorrow night (post feature deadline).

Comment 7

[leger]

Putting on [nsbeta2+][6/01] radar.  This work must be done by 06/01 or we may 
pull this for PR2.

Comment 8

[leger]

Due to slip in schedule, moving this bug from [6/01] to [Will be minus on 6/15] 
for fix deadline.

Comment 9

[Scott MacGregor]

Leaving as a present for dougt when he gets back. (I hope it's before 6/15!!!).
I've traced this through several times and we open the SSL socket and block
waiting for data from cartman. No data ever arrives.

I think it works for http because once the socket is open http posts data...we
are waiting for the server to send back certificate request information in the
imap /  news case?? Or am I just blowing smoke.

In any case, the connection never gets a response so it never propogates up to
mailnews that we have a connection.

Comment 10

[Stuart Parmenter]

the original imaps bug was marked dogfood+, so i'm nominating this for dogfood. 
This needs to get fixed ASAP.  I am unable to use mail with our product.  I
don't think doug is going to be back for another 3 weeks at least.

Comment 11

[Phil Peterson]

[dogfood+]

Comment 12

[Karen Huang]

*** Bug 42383 has been marked as a duplicate of this bug. ***

Comment 13

[Karen Huang]

Change QA Contact to me.

Comment 14

[leger]

Removing [Will be minus on 6/15]....[dogfood+] indication trumps here :-)

Comment 15

[Karen Huang]

This bug blocked bug 25670, without this bug's fix. Cannot use IMAP for SSL and 
Secnews at all!

Comment 16

[Karen Huang]

From Beta 2 criteria, Secure News is P3. So suggest won't hold beta 2 for that.
But there is no Beta2 definition for IMAP SSL....

Comment 17

[Stuart Parmenter]

IMAP SSL is dogfood+ so it should be P0

Comment 18

[Doug Turner (:dougt)]

Reassigning all https/cartman/security bugs to valeski.  He will be finding new 
owner(s).  This shift is so that I can focus on embedding issues.  If the new 
owner has questions that can not be resovled, I may be able to lend a (quick) 
hand.

over to valeski....

Comment 19

[Scott MacGregor]

Hi Terry, this dogfood bug had been assigned to dougt whose out for a couple
more weeks I think. Do you think you might be able to shed some light on what
could be going on here?


It looks like cartman is creating the SSL connection to the imap or nntp server
(at least from the psm-glue point of view it looks that way). But then nothing
happens after the connect phase. We never get called back with any data to read
from the socket.Before this broke, cartman used to bring up the certificate
manager so you could pick the certificate you wanted to use for authentication
and then the connection was made and all was good. We don't even see the
certificate manager anymore.

Comment 20

[Judson Valeski]

please note that once doug does get back his ssl responsibilities will be nil as 
he's going to be 100% embedding.

Comment 21

[Stuart Parmenter]

adding javi to cc list... he thought this was a bug in cartman that was causing
a deadlock on the socket.

Comment 22

[Mike]

M16 has been out for a while now, these bugs target milestones need to be 
updated.

Comment 23

[leger]

Putting on [nsbeta2-][dogfood-] per PDT beta2 review today.

Some folks such as mscott, gagan and pavlov need to pow-wow on this.

Comment 24

[Scott MacGregor]

I thought this was because of a bug in cartman and had nothing to do with us...hmmm

Comment 25

[Phil Peterson]

Ok, if this is a cartman bug, I'm reassigning to ddrinan for triage

Comment 26

[Stuart Parmenter]

sigh.  i don't care whos bug this is.  it has to be fixed.

Comment 27

[Stuart Parmenter]

Would someone please tell me *why* this was marked nsbeta2- and dogfood-.

Javi had thought he had a fix, but the fix doesn't help

I have been debugging it this weekend and am stuck... I need some info from the
cartman team.  I will contact them tomorrow.

This is (still) blocking me from using our product.

Comment 28

[Jim Roskind]

This feature long ago fell off the "in feature list" as far as Netscape was 
concerned for Nav 6.  Pav did a great job of getting it in (on a bet as I recall 
;-) ) in the past, but that was really outside of Netscapes critical needs for a 
beta2 (let alone an RTM).

When the bug triage managers saw this bug last week, they re-evaled it to a pure  
minus (beta2 and dogfood).

It would be nice if the mozilla community submitted a patch for this... but 
inside Netscape we are more than overcommited with existing planned features for  
beta2 (and RTM).  

I hope that explanation makes more sense. Sorry this discussion was not added 
when the change was made.

Jim

Comment 29

[Stuart Parmenter]

reassigning

Comment 30

[Stuart Parmenter]

Attachment: patch to fix described problem

Comment 31

[Stuart Parmenter]

I have made a patch to fix this problem.  Please reconsider for dogfood+.

Comment 32

[Javier Delgadillo]

Probably wanna ifdef DEBUG that at least one printf in your diffs.

Comment 33

[Stuart Parmenter]

Attachment: new patch. fixes news. removes printfs.

Comment 34

[Jay Patel [:jay]]

Putting on [dogfood-] radar.  Not critical to everyday use.  Please land it as 
soon as we branch.

Comment 35

[cls]

Actually, this critical for everyday use for some of us.  Maybe the branch will
occur by time I get back from vacation.

Not sure if this a problem with the patch or moz imap in general but I appear to
only be able to connect to one imap account at a time.  Both of my accounts
connect to the same imap server which hosts several virtual domains.

Comment 36

[Stuart Parmenter]

phil approved it.  fix checked in.

Comment 37

[Karen Huang]

Verified on WinNT 07-19-11-M17: it's working for IMAP on WinNT platform.
Verified on Linux 07-19-10-M17: it's working for IMAP on Linux platform.
Verified on WinNT 07-19-11-M17: it's working for NNTP on WinNT platform.
Verified on Linux 07-19-11-M17: it's working for NNTP on Linux platform.
But, for Mac 07-19-12-M17 commercial build: still need to wait for bug 45935 fix 
in order to verify on Mac platform.

Comment 38

[Karen Huang]

After confirmed with John (junruh), the Secure Connction (SSL) is actually 
connecting, bug 45935 actually is the Security certificate problem. I am removing 
bug 45935 for this bug's dependence and marking this bug as verified.