On December 4, 2012 at 4:43:53 AM PST, Ben Morrow wrote:
> So, it looks to me as though you have a firewall problem. You may be
> able to get more information by setting the kern.ipc.sodefunctlog sysctl
> to 1: this should make the kernel log to syslog (or wherever the OSX
> kernel logs go) when s
On December 5, 2012 2:07:14 AM PST, Ben Morrow wrote:
> At 1AM -0800 on 5/12/12 Erik A Johnson wrote:
>> FYI, the tcpdump I sent previously was with one of our
>> previously-discussed patches in place:
>>
>>if (!proxy->client_proxy && net_geterror
FYI, the tcpdump I sent previously was with one of our previously-discussed
patches in place:
if (!proxy->client_proxy && net_geterror(proxy->fd_ssl) == EBADF) {
I'm attaching that dump again (as tcpdump_output_witholdpatch_headeronly.txt),
as well as a dump without any of the patches
(tcp
At 10AM -0800 on 1/12/12 Erik A Johnson wrote:
>> Should the "#ifdef __APPLE__" remain? or would any of these tests be
>> appropriate for other platforms as well?
On 12/1/2012 at 11:07:36am PST, Ben Morrow wrote:
> I had a go at reproducing this on FreeBSD and fa
On Nov 29, 2012, at 7:42 AM, Erik A Johnson wrote:
>>>> No, the test to bug out doesn't work because net_geterror(proxy->fd_ssl)
>>>> returns 0 in the statement
>>>>
>>>> if (!proxy->client_proxy && net_geterror(proxy->
ted. So read() probably shouldn't be returning
> ENOTCONN anymore at this point, but instead ECONNRESET or ETIMEDOUT.
>
> See if the attached patch helps.
>
>
> On 29.11.2012, at 7.45, Erik A Johnson wrote:
>> Here's the log:
>>
>> Nov 28 21:28:11 macboo
> On 10.11.2012, at 12.44, Erik A Johnson wrote:
>> imap-login processes are hanging (using 100% of CPU) when connected from a
>> client that is partially blocked by a firewall. It appears that imap-login
>> is stuck in a loop trying to complete an ssl handshake. imap-login
Thanks, Timo. Nope, still an infinite loop. Anything I can try using gdb to
trace?
On Nov 22, 2012, at 10:52 PM, Timo Sirainen wrote:
> On 10.11.2012, at 12.44, Erik A Johnson wrote:
>
>> imap-login processes are hanging (using 100% of CPU) when connected from a
>&
imap-login processes are hanging (using 100% of CPU) when connected from a
client that is partially blocked by a firewall. It appears that imap-login is
stuck in a loop trying to complete an ssl handshake. imap-login is working
fine for other clients not blocked by the firewall (including loca