Anyone see what's wrong with this trace?

[Bill Stouder-Studenmund]

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

[Bill Stouder-Studenmund]

Post by Bill Stouder-Studenmund
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

[Matthias Scheler]

Post by Bill Stouder-Studenmund
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

[Bill Stouder-Studenmund]

Post by Matthias Scheler

Post by Bill Stouder-Studenmund
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

[Steven M. Bellovin]

On Mon, 3 Sep 2007 16:28:51 -0700

Post by Bill Stouder-Studenmund

Post by Matthias Scheler

Post by Bill Stouder-Studenmund
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.


--Steve Bellovin, http://www.cs.columbia.edu/~smb

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Bill Stouder-Studenmund]

Post by Steven M. Bellovin
On Mon, 3 Sep 2007 16:28:51 -0700

Post by Bill Stouder-Studenmund

Post by Matthias Scheler
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

[Steven M. Bellovin]

On Tue, 4 Sep 2007 10:06:18 -0700

Post by Bill Stouder-Studenmund

Post by Steven M. Bellovin
On Mon, 3 Sep 2007 16:28:51 -0700

Post by Bill Stouder-Studenmund

Post by Matthias Scheler
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.

Post by Bill Stouder-Studenmund
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?

Hmm...


--Steve Bellovin, http://www.cs.columbia.edu/~smb

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de