On Wed, Apr 13, 2011 at 03:40:29PM -0700, David Severance wrote:
I've been having this once in a blue moon problem
with the latest
perdition 1.19-rc4 compiled on RHEL5 so I turned on debug and caught
this today. If I restart perdition then everything works until the next
blue moon.
Apr 13 10:29:33 proxyx perdition.imaps[22437]:
Connect:
128.200.62.206:2170->128.200.80.50:993
Apr 13 10:29:33 proxyx perdition.imaps[22437]: SSL connection using
AES256-SHA
Apr 13 10:29:33 proxyx perdition.imaps[22437]: SELF: "* OK
[CAPABILITY IMAP4 IMAP4REV1 LITERAL+] perdition ready on
proxyx.es.uci.edu 0002376b\r\n"
Apr 13 10:29:33 proxyx perdition.imaps[22437]: CLIENT: "2 login
\"jbrancal\" \"XXXXXX\"\r\n"
Apr 13 10:29:33 proxyx perdition.imaps[22437]: username_add_domain:
username_add_domain 0 1
Apr 13 10:29:33 proxyx perdition.imaps[22437]: username_add_domain:
username_add_domain 0 2
Apr 13 10:29:33 proxyx perdition.imaps[22437]:
vanessa_socket_daemon_setid: uid=99 euid=99 gid=99 egid=99
Apr 13 10:29:33 proxyx perdition.imaps[22437]: username_add_domain:
username_add_domain 0 4
Apr 13 10:29:33 proxyx perdition.imaps[22437]: REAL: ""
Apr 13 10:29:33 proxyx perdition.imaps[22437]: token_read:
token_fill_buffer
Apr 13 10:29:33 proxyx perdition.imaps[22437]: read_line: token_read
Apr 13 10:29:33 proxyx perdition.imaps[22437]: imap4_out_response:
read_line
Apr 13 10:29:33 proxyx perdition.imaps[22437]: imap4_out_setup:
imap4_out_response greeting
Apr 13 10:29:33 proxyx perdition.imaps[22437]: main:
protocol->out_setup -1
Apr 13 10:29:33 proxyx perdition.imaps[22437]: Fatal error negotiating
setup. Exiting child.
Not sure what to do next, any ideas?
Hi David,
that is rather curious.
It appears that when perdition connects to the real server
it is getting an empty read, which it regards as invalid.
My first instinct is to wonder if the real server really
is closing the connection or otherwise sending an invalid response.
But that doesn't seem particularly likely, so I too am scratching my head.
Are you by any chance using SSL to connect to the real-server?
Perhaps there is a problem with how perdition sets up SSL.
In any case, I wonder if a way forward would be to set up
a test environment, opening connections repeatedly until we
see the problem. Meanwhile using ssldump or tcpdump to see
what is happening on the wire. At least that would confirm
or refute my instinctive guess above.