[Fedora-directory-devel] Re: Fedora-directory-devel Digest, Vol 7, Issue 2

[Rob Crittenden]

Peter Djalaliev wrote:
> 
> 
>     I haven't done tracing in mod_nss for a very long time but it did work
>     early in the development of the module.
> 
>     I'm a little confused what you mean about Apache "debug" versus "normal"
>     mode. Are you referring to the -X flag? I use that frequently myself.
> 
>     What problem are you trying to solve?
> 
>     I believe the error -8174 is a bad database error. This shouldn't cause
>     a segfault. Are you seeing this when not doing debugging?
> 
>     Is it dropping a core file?
> 
>     thanks
> 
>     rob
> 
> 
> Rob,
> 
> Yes, by the debug mode and normal mode I mean using -X as opposed to not 
> using it.
> 
> Yes, I see the -8174 error w/ or w/o debugging, but Apache with mod_nss 
> was working ok in normal mode (w/o -X) despite of the -8174 error, so I 
> guess I just ignored it.  I'll rebuild my database I guess.
> 
> I don't find any core files in the 'bin' directory, where I run 'httpd 
> -X -k start -DSSL'.  Should I be looking for them elsewhere?
> 
> What I am doing in essence is that I am extending the TLS/SSL3 
> implementation in the NSS package to incorporate an extension (as 
> defined in RFC3546).  Then, I use this modified NSS in Firefox 1.5 and 
> Apache 2.0.54 w/ mod_nss to test my modifications to the TLS handshake.
> 
> Inside NSS, I am using the SSL_TRC macros for debugging.  It works fine 
> with Firefox, but I needed Apache to stay attached to the shell, so I 
> can see the SSL_TRC output.  Alternatively, I am trying to get NSS to 
> ouput the debugging information to the Apache log files, but this might 
> be more of a hack than the right way to do it.  Do you have any 
> alternative suggestions here?
> 
> So, just to confirm, you are using Apache 2 with mod_nss and the -X flag 
> and it works OK, right?
> 
> Thanks,
> Peter

I just re-tested this with an Apache 2.0.54 I had lying about and it 
works ok for me.

I built a fresh copy of NSPR 4.4.1, DBM 1.61 and NSS 3.11 (with TRACE) 
and was able to fire up the server with no problems:

% bin/httpd -X -k start
SSL: tracing set to 10
SSL: debugging set to 99
25854: SSL: grow buffer from 0 to 18432
25854: SSL: grow buffer from 0 to 18432
25854: SSL[156374648]: closing, rv=0 errno=-8190
SSL: tracing set to 10
SSL: debugging set to 99
25854: SSL: grow buffer from 0 to 18432
25854: SSL: grow buffer from 0 to 18432
25854: SSL: grow buffer from 0 to 18432
25854: SSL: grow buffer from 0 to 18432
25854: SSL[156279504]: handshake gathering, rv=-2
25854: SSL[156279504]: handshake blocked (need 2)
25854: SSL: grow buffer from 0 to 18432
25854: SSL3[156279504]: handle client_hello handshake
25854: SSL3[156279504]: server, lookup client session-id for 
0x0000000000000000ffff00000100a8c0
25854: SSL3[156279504]: begin send server_hello sequence
25854: SSL3[156279504]: send server_hello handshake
25854: SSL: grow buffer from 0 to 18432
25854: SSL3[156279504]: Set XXX Pending Cipher Suite to 0x0035
25854: SSL3[156279504]: send certificate handshake
25854: SSL3[156279504]: send server_hello_done handshake
25854: SSL3[156279504] SendRecord type: handshake  (22) bytes=1187
25854: SSL[156279504]: Send record (plain text) [Len: 1187]

[ snip ]

I'm not sure why I'm getting the -8190 (a bad data error I believe) but 
otherwise it seems to work fine.

I'd work on verifying/fixing your cert database first, that error is 
very suspicious, particularly since you say it works with all debugging 
disabled.

To get a core file be sure that your ulimit allows one. I typically do: 
ulimit -c unlimited.

rob
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3178 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/fedora-directory-devel/attachments/20060104/74982ec5/attachment.bin>