headers
Bill Stouder-Studenmund | 3 Sep 2007 07:36
Picon

Anyone see what's wrong with this trace?

I'm running a NetBSD 4.0 Beta 2 kernel, and seeing the following trace 
most times I try to fetch EMail from my ISP's popmail server: anyone know 
what's wrong?

22:10:23.235746 IP wsip-72-214-2-130.sd.sd.cox.net.63674 > pop.coxmail.com.pop3: S
3676123145:3676123145(0) win 32768 <mss 1460,nop,wscale 0,sackOK,nop,nop,nop,nop,timestamp 0 0>
22:10:23.314508 IP pop.coxmail.com.pop3 > wsip-72-214-2-130.sd.sd.cox.net.63674: S
197536:197536(0) ack 3676123146 win 24616 <nop,nop,timestamp 1001834778 0,nop,wscale
0,nop,nop,sackOK,mss 1460>
22:10:23.314766 IP wsip-72-214-2-130.sd.sd.cox.net.63674 > pop.coxmail.com.pop3: R
3676123146:3676123146(0) win 0

Fetchmail dumps the following when this happens:

fetchmail: connection to pop.coxmail.com:pop3 [68.99.120.2/110] failed: 
Interrupted system call.
POP3 connection to pop.coxmail.com failed: Interrupted system call
fetchmail: Query status=2 (SOCKET)

Occasionally it works. I don't yet have a trace for when that's happening.

Any thoughts?

Take care,

Bill
Permalink | Reply |
headers
Matthias Scheler | 3 Sep 2007 14:05
Picon
Favicon

Re: Anyone see what's wrong with this trace?

On Sun, Sep 02, 2007 at 10:36:50PM -0700, Bill Stouder-Studenmund wrote:
> Fetchmail dumps the following when this happens:
> 
> fetchmail: connection to pop.coxmail.com:pop3 [68.99.120.2/110] failed: 
> Interrupted system call.
> POP3 connection to pop.coxmail.com failed: Interrupted system call
> fetchmail: Query status=2 (SOCKET)
> 
> Occasionally it works. I don't yet have a trace for when that's happening.
> 
> Any thoughts?

Do you use "fetchmail -d <...>"? If you do can you try increasing the value?

	Kind regards

--

-- 
Matthias Scheler                                  http://zhadum.org.uk/
Permalink | Reply |
headers
Bill Stouder-Studenmund | 4 Sep 2007 01:28
Picon

Re: Anyone see what's wrong with this trace?

On Mon, Sep 03, 2007 at 01:05:56PM +0100, Matthias Scheler wrote:
> On Sun, Sep 02, 2007 at 10:36:50PM -0700, Bill Stouder-Studenmund wrote:
> > Fetchmail dumps the following when this happens:
> > 
> > fetchmail: connection to pop.coxmail.com:pop3 [68.99.120.2/110] failed: 
> > Interrupted system call.
> > POP3 connection to pop.coxmail.com failed: Interrupted system call
> > fetchmail: Query status=2 (SOCKET)
> > 
> > Occasionally it works. I don't yet have a trace for when that's happening.
> > 
> > Any thoughts?
> 
> Do you use "fetchmail -d <...>"? If you do can you try increasing the value?

Yes and no. I've seen this with fetchmail -d 180 and with it at the 
command line.

Any idea what's wrong? How would delaying more help? I'm starting to think 
I may know, but I'd like to hear your thoughts. :-)

Take care,

Bill
Permalink | Reply |
headers
Steven M. Bellovin | 4 Sep 2007 02:13

Re: Anyone see what's wrong with this trace?

On Mon, 3 Sep 2007 16:28:51 -0700
Bill Stouder-Studenmund <wrstuden <at> NetBSD.org> wrote:

> On Mon, Sep 03, 2007 at 01:05:56PM +0100, Matthias Scheler wrote:
> > On Sun, Sep 02, 2007 at 10:36:50PM -0700, Bill Stouder-Studenmund
> > wrote:
> > > Fetchmail dumps the following when this happens:
> > > 
> > > fetchmail: connection to pop.coxmail.com:pop3 [68.99.120.2/110]
> > > failed: Interrupted system call.
> > > POP3 connection to pop.coxmail.com failed: Interrupted system call
> > > fetchmail: Query status=2 (SOCKET)
> > > 
> > > Occasionally it works. I don't yet have a trace for when that's
> > > happening.
> > > 
> > > Any thoughts?
> > 
> > Do you use "fetchmail -d <...>"? If you do can you try increasing
> > the value?
> 
> Yes and no. I've seen this with fetchmail -d 180 and with it at the 
> command line.
> 
> Any idea what's wrong? How would delaying more help? I'm starting to
> think I may know, but I'd like to hear your thoughts. :-)
> 
With a large mailbox in mbox format, it can take a long time to copy;
you can also run into locking issues.  Also, were you on a slow link?
I've had problems that way, too.
(Continue reading)

Permalink | Reply |
headers
Bill Stouder-Studenmund | 4 Sep 2007 19:06
Picon

Re: Anyone see what's wrong with this trace?

On Mon, Sep 03, 2007 at 08:13:53PM -0400, Steven M. Bellovin wrote:
> On Mon, 3 Sep 2007 16:28:51 -0700
> Bill Stouder-Studenmund <wrstuden <at> NetBSD.org> wrote:
> 
> > On Mon, Sep 03, 2007 at 01:05:56PM +0100, Matthias Scheler wrote:
> > > Do you use "fetchmail -d <...>"? If you do can you try increasing
> > > the value?
> > 
> > Yes and no. I've seen this with fetchmail -d 180 and with it at the 
> > command line.
> > 
> > Any idea what's wrong? How would delaying more help? I'm starting to
> > think I may know, but I'd like to hear your thoughts. :-)
> > 
> With a large mailbox in mbox format, it can take a long time to copy;
> you can also run into locking issues.  Also, were you on a slow link?
> I've had problems that way, too.

I actually just switched to procmail into Maildir folders.

However this is all happening rapidly. We send a SYN, we get a SYN-ACK, we
reset the connection. Boom, boom, boom. The time stamps are
22:10:23.235746, 22:10:23.314508, and 22:10:23.314766.

Why are we rejecting the Syn-Ack of the connection we're starting? Or why 
are we rejecting the connection?

Take care,

Bill
(Continue reading)

Permalink | Reply |
headers
Steven M. Bellovin | 4 Sep 2007 19:15

Re: Anyone see what's wrong with this trace?

On Tue, 4 Sep 2007 10:06:18 -0700
Bill Stouder-Studenmund <wrstuden <at> netbsd.org> wrote:

> On Mon, Sep 03, 2007 at 08:13:53PM -0400, Steven M. Bellovin wrote:
> > On Mon, 3 Sep 2007 16:28:51 -0700
> > Bill Stouder-Studenmund <wrstuden <at> NetBSD.org> wrote:
> > 
> > > On Mon, Sep 03, 2007 at 01:05:56PM +0100, Matthias Scheler wrote:
> > > > Do you use "fetchmail -d <...>"? If you do can you try
> > > > increasing the value?
> > > 
> > > Yes and no. I've seen this with fetchmail -d 180 and with it at
> > > the command line.
> > > 
> > > Any idea what's wrong? How would delaying more help? I'm starting
> > > to think I may know, but I'd like to hear your thoughts. :-)
> > > 
> > With a large mailbox in mbox format, it can take a long time to
> > copy; you can also run into locking issues.  Also, were you on a
> > slow link? I've had problems that way, too.
> 
> I actually just switched to procmail into Maildir folders.

I was referring to the server side, not the client.
> 
> However this is all happening rapidly. We send a SYN, we get a
> SYN-ACK, we reset the connection. Boom, boom, boom. The time stamps
> are 22:10:23.235746, 22:10:23.314508, and 22:10:23.314766.
> 
> Why are we rejecting the Syn-Ack of the connection we're starting? Or
(Continue reading)

Permalink | Reply |
headers
Bill Stouder-Studenmund | 3 Sep 2007 08:43
Picon

Re: Anyone see what's wrong with this trace?

On Sun, Sep 02, 2007 at 10:36:50PM -0700, Bill Stouder-Studenmund wrote:
> I'm running a NetBSD 4.0 Beta 2 kernel, and seeing the following trace 
> most times I try to fetch EMail from my ISP's popmail server: anyone know 
> what's wrong?
> 
> 22:10:23.235746 IP wsip-72-214-2-130.sd.sd.cox.net.63674 > pop.coxmail.com.pop3: S
3676123145:3676123145(0) win 32768 <mss 1460,nop,wscale 0,sackOK,nop,nop,nop,nop,timestamp 0 0>
> 22:10:23.314508 IP pop.coxmail.com.pop3 > wsip-72-214-2-130.sd.sd.cox.net.63674: S
197536:197536(0) ack 3676123146 win 24616 <nop,nop,timestamp 1001834778 0,nop,wscale
0,nop,nop,sackOK,mss 1460>
> 22:10:23.314766 IP wsip-72-214-2-130.sd.sd.cox.net.63674 > pop.coxmail.com.pop3: R
3676123146:3676123146(0) win 0
> 

And here's one that didn't break:

23:30:27.208179 IP wsip-72-214-2-130.sd.sd.cox.net.63557 > pop.coxmail.com.pop3: S
2939205328:2939205328(0) win 32768 <mss 1460,nop,wscale 0,sackOK,nop,nop,nop,nop,timestamp 0 0>
23:30:27.285234 IP pop.coxmail.com.pop3 > wsip-72-214-2-130.sd.sd.cox.net.63557: S
3196401568:3196401568(0) ack 2939205329 win 24616 <nop,nop,timestamp 1002315192 0,nop,wscale
0,nop,nop,sackOK,mss 1460>
23:30:27.285395 IP wsip-72-214-2-130.sd.sd.cox.net.63557 > pop.coxmail.com.pop3: . ack 1 win 33580
<nop,nop,timestamp 0 1002315192>

I don't see much difference. ??

Take care,

Bill
(Continue reading)

Permalink | Reply |

Gmane