From e6bb6d51c92e017179913dd98633c62f9e6a60d9 Mon Sep 17 00:00:00 2001 From: "Eric S. Raymond" Date: Sun, 1 Aug 1999 04:01:40 +0000 Subject: New iten on TCP/IP stalling problem. svn path=/trunk/; revision=2522 --- fetchmail-FAQ.html | 34 ++++++++++++++++++++++++++++++---- 1 file changed, 30 insertions(+), 4 deletions(-) diff --git a/fetchmail-FAQ.html b/fetchmail-FAQ.html index 5aaecd29..40a7475c 100644 --- a/fetchmail-FAQ.html +++ b/fetchmail-FAQ.html @@ -10,7 +10,7 @@
Back to Fetchmail Home Page To Site Map -$Date: 1999/07/31 21:41:50 $ +$Date: 1999/08/01 04:01:40 $

Frequently Asked Questions About Fetchmail

@@ -40,7 +40,6 @@ IP address?
G12. Is fetchmail Y2K-compliant?
-

Build-time problems:

B1. Lex bombs out while building the fetchmail lexer.
@@ -101,6 +100,8 @@ IP address?
R6. Fetchmail hangs when used with pppd.
R7. Fetchmail randomly dies with socket errors.
R8. Fetchmail running as root stopped working after an OS upgrade
+R9. Fetchmail is timing out after fetching certain +messages but before deleting them

Disappearing mail

@@ -1849,7 +1850,32 @@ option values that work:

In RH 6.0, the HOME value in the boot-time root environment changed from /root to / as the result of a change in init. Move your .fetchmailrc or use a -f option to explicitly point at the file. -(Oddly, a similar problem has been reported from Debian systems)

+(Oddly, a similar problem has been reported from Debian systems.)

+ +

+

R9. Fetchmail is timing out after fetching certain +messages but before deleting them

+ +There's a TCP/IP stalling problem under Redhat 6.0 (and possibly other +recent Linuxes) that can cause this symptom. Brian Boutel writes:

+ +

+TCP timestamps are turned on on my Linux boxes (I assume it's now the +default). This uses 12 extra bytes per segment. +When the tcp connection starts, the other end agrees a MSS of 1460, +and then fragments 1460 byte chunks into 1448 and 12, because +is is not allowing for the timestamp.

+ +Then, for reasons I can't explain, it waits a long time (typically 2 +minutes) after the ack is sent before sending the next (fragmented) +packet. Turning off tcp timestamps avoids the fragmentation and +restores normal behaviour. To do this, [execute]

+ +echo 0 > /proc/sys/net/ipv4/tcp_timestamps

+ +I'm still unclear about the details of why this is happening. At least +[now] I am now getting good performance and no queue blocking. +

D1. I think I've set up fetchmail correctly, but I'm not getting any mail.

@@ -2427,7 +2453,7 @@ inactivity timeout.

Back to Fetchmail Home Page To Site Map -$Date: 1999/07/31 21:41:50 $ +$Date: 1999/08/01 04:01:40 $

Eric S. Raymond <esr@snark.thyrsus.com>
-- cgit v1.2.3