On 4/14/2011 12:48 AM, Simon Horman wrote:
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.
Once it gets to this state it's stuck until I restart perdition.
Shouldn't it "start over" the next time and work?
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.
Everything about this is odd and in an environment that has not been
modified for quite some time. The previous version of perdition used was
1.17 and it connects to Panda IMAP (based on UW Imap) through a nis
lookup to get the appropriate hostname for the user.
Are you by any chance using SSL to connect to the
real-server?
Perhaps there is a problem with how perdition sets up SSL.
The real server connection is not through ssl, just a plain unencrypted
connection which I direct over port 1143 to the real server.
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.
This is my test environment I was doing a shakeout on first so it's no
problem to monitor it and tweak it. Any particular options to tcpdump
you would find useful? Do you just want to see the traffic from the
proxy (perdition) machine to the real host or all of it? Let me know
what would be helpful so I can make the most out of the capture.
thanks,
David
--
David Severance
Central Computing Services
Office of Information Technology
(949) 824-7552
sev(a)uci.edu