Hello,
we've been using perdition as a pop3/pop3s/imap/imaps proxy for about
four years now, first with Debian Sarge package and now under Etch.
And throughout this time I've seen pop3s (and from the looks of it
the same happens with imaps) processes stuck in connect, like this:
---
16836 ? S 5:31 0 120 32179 2204 0.0 perdition.pop3s
28070 ? S 0:00 0 120 32311 1564 0.0 \_ perdition.pop3s: connect
7782 ? S 0:00 0 120 32311 1564 0.0 \_ perdition.pop3s: connect
24468 ? S 0:00 0 120 32311 1568 0.0 \_ perdition.pop3s: connect
14180 ? S 0:00 0 120 32311 1568 0.0 \_ perdition.pop3s: connect
13503 ? S 0:00 0 120 32311 1564 0.0 \_ perdition.pop3s: connect
---
They never die off, keep the connection open, there is no traffic and the
other end might be long gone. Last trace in the logs is always like this:
---
Feb 5 22:05:16 pp11 perdition[7782]: Connect: hi.mi.ts.u->203.216.5.113
---
It must be something related to the SSL'ness of these service, since I'm
not seeing this happening ever for imap/pop3. Alas a lot of people do use
TLS with those, so it's not a generic SSL issue. Maybe the master process
could kick a child handling connections in the head after "timeout"
seconds in connect state?
If more information is needed I can try to provide it, but note that with a
rate of roughly 35 pops per second I'm a bit weary to turn on
debugging. ^_-
This may or may not be related to another SSL related issue, which will
be for the sake of making searches in the archive more likely to find good
keywords in a separate mail.
Regards,
Christian
--
Christian Balzer Network/Systems Engineer NOC
chibi(a)gol.com Global OnLine Japan/Fusion Network Services
http://www.gol.com/
Hi List,
I've just searched the July 2010 Archives [1] for a problem with Mozilla
Thunderbird 3.1 and a TLS connection to Perdition, but
am still missing a solution.
After connecting to Perdition, Thunderbird 3.1 emits warnings like:
> Server "foo(a)bar.com" has disconnected.
> The server may have gone down or there may be a network problem.
Looking into the perdition logs reveals:
> perdition[9088]: Connect: 121.121.121.121->123.123.123.123
> perdition[9088]: Fatal error establishing TLS connection
The same when running perdition in debug mode:
> perdition[10304]: Connect: 121.121.121.121->123.123.123.123
> perdition[10304]: SELF: "* OK IMAP4 Ready 121.121.121.121 0001cd8b\r\n"
> perdition[10304]: CLIENT: "1 capability\r\n"
> perdition[10304]: SELF: "* CAPABILITY IMAP4 IMAP4REV1 STARTTLS\r\n"
> perdition[10304]: SELF: "1 OK CAPABILITY\r\n"
> perdition[10304]: CLIENT: "2 STARTTLS\r\n"
> perdition[10304]: SELF: "2 OK Begin TLS negotiation now\r\n"
> perdition[10304]: __perdition_ssl_connection: error:140D9115:SSL routines:SSL_GET_PREV_SESSION:session id context uninitialized
> perdition[10304]: __perdition_ssl_connection: SSL_accept
> perdition[10304]: __perdition_ssl_connection: no shared ciphers?
> perdition[10304]: perdition_ssl_server_connection: perdition_ssl_connection
> perdition[10304]: main: perdition_ssl_server_connection TLS
> perdition[10304]: Fatal error establishing TLS connection
I think the "no shared ciphers" is misleading here, it's the first
message that looks b0rked:
> perdition[10304]: __perdition_ssl_connection:
> error:140D9115:SSL routines:SSL_GET_PREV_SESSION:
> session id context uninitialized
This could be related to the SSL/TLS renegotiation [2] done by the
recent Mozilla stack because of CVE-2009-3555, as pointed to by Thierry
Hotelier some days ago [3].
There is another mail by Giorgio Paolucci [4] indicating a problem with
the ssl/tls session caching (which really matches the error message).
Too bad the proposed fix (patch?) did not end up in the mailing list
archive. Could someone (Georgio?) please re-post this patch inline so
others will find it without being subscribed?
After a quick search on openssl-users it looks like this can be fixed
using SSL_CTX_set_session_id_context.
Any news on this?
Thanks.
[1]
http://lists.vergenet.net/pipermail/perdition-users/2010-July/thread.html
[2] https://wiki.mozilla.org/Security:Renegotiation
[3]
http://lists.vergenet.net/pipermail/perdition-users/2010-July/002336.html
[4]
http://lists.vergenet.net/pipermail/perdition-users/2010-July/002341.html
Hi all,
I have pushed the following change to fix a regression.
# HG changeset patch
# User Simon Horman <horms(a)verge.net.au>
# Date 1280553826 -32400
# Node ID aeff92473a55f077295220c1ff5ea7eb0ba82e76
# Parent 2178a55280292c9822e0d1a5031ce23487eeee72
Fix build failure if pam libraries aren't installed
This is a regression between 1.19-rc2 and 1.19-rc3 caused
by the addition of --diasble-pam.
./configure --disable-pam is a work-around for this problem
Reported-by: Dominique Marant <Dominique.Marant(a)univ-lille1.fr>
Signed-off-by: Simon Horman <horms(a)verge.net.au>
diff -r 2178a5528029 -r aeff92473a55 configure.ac
--- a/configure.ac Fri Jul 30 16:02:17 2010 +0900
+++ b/configure.ac Sat Jul 31 14:23:46 2010 +0900
@@ -906,7 +906,7 @@
security/pam_appl.h,
true,
[
- pam=no
+ enable_pam=no
AC_MSG_WARN(
""
"**********************************************************************"
@@ -926,7 +926,7 @@
pam_authenticate,
true,
[
- pam=no
+ enable_pam=no
AC_MSG_WARN(
""
"**********************************************************************"
Hi,
if you have debug and/or quiet set in your configuration file instead of
on the cmd line they are ignore when updating the logger options at
start up.
--- a/perdition/perdition.old 2010-07-30 06:30:14.693804169 +0200
+++ b/perdition/perdition.c 2010-07-30 06:38:00.988554075 +0200
@@ -371,6 +371,11 @@
/*Parse options*/
options(argc, argv, OPT_FIRST_CALL);
+ /*Read config file*/
+ if(opt.config_file!=NULL){
+ config_file_to_opt(opt.config_file);
+ }
+
/* Initialise setting of proctitle */
init_set_proc_title(argc, argv, envp);
progname = strdup(get_progname(argv[0]));
@@ -386,11 +391,6 @@
vanessa_logger_change_max_priority(vanessa_logger_get(),
opt.quiet?LOG_ERR:LOG_INFO);
- /*Read config file*/
- if(opt.config_file!=NULL){
- config_file_to_opt(opt.config_file);
- }
-
/*Open the dbserver_get library, if we have a library*/
if(getserver_openlib(opt.map_library, opt.map_library_opt,
&handle, &dbserver_get, &dbserver_get2)<0){
greetings
JS
Hi,
Not really sure how to edit a man page using command line only, please
enlighten me and I can make the patch for it.
Also right now the --help text for --managesieve_capability isn't really
clear that you have to do "\"option\" \"value\"" to make it work.
greetings
JS
Hi,
There is an error adding the host name to the greeting message. I have
found the following:
With no_bind_banner and no_lookup = no problem
* OK [CAPABILITY IMAP4 IMAP4rev1 LITERAL+] perdition ready on mail 0002c797
With no_bind_banner, without no_lookup = no problem
* OK [CAPABILITY IMAP4 IMAP4rev1 LITERAL+] perdition ready on mail 0002c936
Without no_bind_banner, with no_lookup = problem
* OK [CAPABILITY IMAP4 IMAP4rev1 LITERAL+] perdition ready on
zÃÿ¿¤ÇA·@P·@P·ÐhÃÿ¿y 0 0002c7f5
greetings
JS
Hi,
Is there any other way to disable linking against PAM beside editing the
configure script and changing pam=yes into pam=no? Adding a
--disable-pam option would be great.
greetings
JS
Hello all,
I'm looking into a possible use of perdition here, but I'm seeing a
problem when I transmit certain characters, like CTRL-C, to perdition
configured for IMAP4.
It looks like it crashes for both the 1.19 RC2 and 1.18 versions, and it
appears the crash is actually inside libvanessa_logger.so.
For perdition-1.19rc2-1.1 and libvanessa_logger0-0.0.9-3.1:
*** glibc detected *** perdition: connect (
sanitized:36810->sanitized:5143): realloc(): invalid next size:
0x00000000081c76a0 ***
======= Backtrace: =========
/lib64/libc.so.6[0x3a406746b4]
/lib64/libc.so.6(realloc+0x102)[0x3a406751a2]
/usr/lib64/libvanessa_logger.so.0(vanessa_logger_str_dump+0xd2)[0x2b20cec8a742]
perdition: connect (
sanitized:36810->sanitized:5143)(token_read+0x23b)[0x40e71b]
perdition: connect (
sanitized:36810->sanitized:5143)(read_line+0x9a)[0x417e2a]
perdition: connect (
sanitized:36810->sanitized:5143)(imap4_in_get_auth+0x5a)[0x408d9a]
perdition: connect ( sanitized:36810->sanitized:5143)(main+0x855)[0x413e15]
/lib64/libc.so.6(__libc_start_main+0xf4)[0x3a4061d994]
perdition: connect ( sanitized:36810->sanitized:5143)[0x406509]
For version perdition-1.18-1.7 and libvanessa_logger0-0.0.8-18.2:
*** glibc detected *** perdition: connect: realloc(): invalid next size:
0x000000000100b330 ***
======= Backtrace: =========
/lib64/libc.so.6[0x3a406746b4]
/lib64/libc.so.6(realloc+0x102)[0x3a406751a2]
/usr/lib64/libvanessa_logger.so.0(vanessa_logger_str_dump+0xd2)[0x2b8240f6b742]
perdition: connect(token_read+0x23b)[0x4139fb]
perdition: connect(read_line+0x9a)[0x4130ba]
perdition: connect(imap4_in_get_pw+0x5a)[0x4074fa]
perdition: connect(main+0xb96)[0x40f866]
/lib64/libc.so.6(__libc_start_main+0xf4)[0x3a4061d994]
perdition: connect[0x405b19]
Has anyone seen this particular problem? Thanks!
--
Martin B. Smith
smithmb(a)ufl.edu - (352) 273-1374
CNS/Open Systems Group
University of Florida