Re: Fatal error negotiating setup

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.
______________________________________________
Perdition-users mailing list
[email protected]
http://lists.vergenet.net/listinfo/perdition-users