At 2PM + on 6/12/12 Ben Morrow wrote:
>
> +if (connect(ret, &so.sa, &addrlen) >= 0)
> +i_panic("dummy connect to detect DEFUNCT socket succeeded");
> +if (errno == EOPNOTSUPP)
> +return -1;
Ack, forgot to close the new socket...
if (errno
At 9PM -0800 on 5/12/12 Erik A Johnson wrote:
> 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
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
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(proxy->fd_ssl) == EBADF) {
>
> I'm attaching that dump again (as
> tcpdump_output_witholdpatch_headero
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 12PM + on 4/12/12 Ben Morrow wrote:
>
> Well, it looks to me as though xnu/bsd/kern/uipc_socket.c:soreceive will
> indeed return ENOTCONN for a socket which was once successfully
> connected but has now been disconnected. This happens when the socket is
> in the DEFUNCT state, which is a s
At 2AM -0800 on 3/12/12 you (Erik A Johnson) wrote:
> 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
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 failed, but I don't believe
> we'v
At 10AM -0800 on 1/12/12 Erik A Johnson wrote:
>
> On November 29, 2012 at 2:39:51 PM PST, Timo Sirainen wrote:
> > Yes, that sounds like it would work better:
> >
> > if (!proxy->client && net_getpeername(proxy->fd_ssl, NULL, NULL) <
> > 0 && errno == ENOTCONN) {
>
> Using getpeername or net_
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->fd_ssl) == ENOTCONN) {
I was wrong here: the FIRST time, net_geterror retu
On 30.11.2012, at 0.12, Ben Morrow wrote:
>> This change isn't very reliable, since the previous call might not
>> have been read().. I wonder if something like would work:
>>
>> if (!proxy->client && read(proxy->fd_ssl, &err, 0) < 0 && errno == ENOTCONN)
>> {
>
> How about calling getpeername
At 10PM +0200 on 29/11/12 Timo Sirainen wrote:
> On 29.11.2012, at 17.42, 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->fd_ssl) == ENOTCONN) {
On 29.11.2012, at 17.42, 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->fd_ssl) == ENOTCONN) {
>
> However, errno is indeed ENOTCONN. Changing the test t
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->fd_ssl) == ENOTCONN) {
However, errno is indeed ENOTCONN. Changing the test to
if (!proxy->client_proxy &&
errno == ENOTCONN)
This is either OSX bug or OpenSSL bug.. Apparently what happens is:
1. Client sends SYN packet to Dovecot
2. Dovecot accept()s the connection (sends SYN-ACK) and goes into OpenSSL code
3. Client doesn't send ACK to Dovecot. Does it send RST or nothing or something
else? I don't know.
4. OSX notic
Here's the log:
Nov 28 21:28:11 macbookpro-e17d.home dovecot[54139]: master: Dovecot v2.1.10
starting up (core dumps disabled)
Nov 28 21:30:19 macbookpro-e17d.home dovecot[54141]: imap-login: Debug:
ssl_step()
Nov 28 21:30:19 macbookpro-e17d.home dovecot[54141]: imap-login: Debug:
ssl_handshake
Could you try with the attached patch, and with only the problematic
client running? What does it log (the beginning of the session until it
starts repeating the same lines)?
On Sat, 2012-11-24 at 00:16 -0800, Erik A Johnson wrote:
> Thanks, Timo. Nope, still an infinite loop. Anything I can try
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
>> client that is partially
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 is
> working fine for o
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
20 matches
Mail list logo
