15 Apr
2011
15 Apr
'11
8:29 a.m.
On Thu, Apr 14, 2011 at 03:25:59PM -0700, David Severance wrote:
Ok, we can eliminate SSL as a possible problem.
I think that traffic from perdition to the real server should be
sufficient. So far as tcpdump options go, it would be good to know
the packet length. But I think that is captured by default.
On 4/14/2011 12:48 AM, Simon Horman wrote:
Yes it should.
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.