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
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
389-devel@lists.fedoraproject.org