Re: IPMasq disturbing Fetchmail?
"Karl E. Jorgensen" wrote:
>
> On Fri, Mar 01, 2002 at 03:10:24PM +0100, joe user wrote:
> > Hello.
> >
> > Is it possible that IPMasq can disturb fetchmail?
> > The retrieving of messages always stalls when a message is between 2434- or
> > 2448 bytes in size.
I'm no expert on this, but is it possible you're have a problem with a
combination of short TCP FIN timeout and then some weird fragment
handling combination that occurs with this size transfer? It just
sounds like something to do with timeouts and fragmetns if you're fixing
it by reducing mtu. Somewhere else along the line the mtu is smaller so
you get fragmentation, presumably, and then when you get a certain size
fragment with a certain affect on time to live you time out. One thing
I'd try is setting TCP FIN timeout up a bit, but I don't know if doing
this alone without more engineering thought on the problem is a good
idea. Sounds like an interesting problem. I've been reading up on
IPChains/IPMasq and they recommend making sure you have the
always_defragment="1" if you can, a la:
echo "1" > /proc/sys/net/ipv4/ip_always_defrag
and that solves some of these fragment problems around the firewall
best. You have to have this compiled into the kernel, but it is by
default. If for some reason you can't do this you need to specify some
extra chain rules to handle the fragments. At any rate, it doesn't
sound to me like a fragment problem alone, but a combination. I've got
the command:
$gICPATH -M -S $TCPTIMEOUT $TCPFINTIMEOUT $UDPTIMEOUT
(where $gICPATH is a version of ipchains, for instance), to set
timeouts, so
you'd want to set TCPFINTIMOUT=$morethanbefore.
> >
> > I have a small home-network with two boxes running Woody.
> > One of them is acting 'router' using the 'ipmasq'-package.
> > The other one is my workstation and there is where I run fetchmail directly
> > against my ISP.
> >
> > If I try fetchmail on the router instead, it works fine and retrieves all
> > messages without stalling.
>
> I had a similar problem with my ISP - intermittently. Never got to the
> bottom of it. I suspect it had something to do with packet
> fragmentation, but I am at a loss. Calling the ISP turned out to be
> fruitless, as they are only willing to support windoze (odd: I'm told
> that many ISPs actually use linux themselves...)
>
> My symptoms were similar to yours. In addition, some web page graphics
> wouldn't load (as if big images couldn't load), and seti@home never
> managed to download work units. Got the first few K, then stopped.
>
> But I did find a workaround: lower the MTU on the ppp
> connection from the default 1500. In my case, lowering to 800 did the
> trick.
>
> Where to lower it depends on what you use for dialling up:
>
> For diald:
> add a line "mtu 800" to /etc/diald/diald.options.<your-provider-name>
> (diald doesn't like you to add it to the ppp config nor command line).
> Beware that diald likes to re-generate the /etc/diald/diald.options.*
> files (how *do* you turn that off anyway?), and undo changes in
> here.
>
> For ppp:
> add "mtu 800" to /etc/ppp/peers/<your-provider-name>
>
> > If this is a unknown behaviour, what can I do to get more information on
> > what is happening?
>
> Don't know. Pls post here if you find out more
>
> > I am not a netfilter guru so I don't have an idea on how to turn on
> > extensive logging on the router..
>
> Neither am I. The above worked for me, but I'm sure there is more to it.
>
> HTH
> --
> Karl E. Jørgensen
> karl@jorgensen.com
> www.karl.jorgensen.com
> ==== Today's fortune:
> if (argc > 1 && strcmp(argv[1], "-advice") == 0) {
> printf("Don't Panic!\n");
> exit(42);
> }
> -- Arnold Robbins in the LJ of February '95, describing RCS
>
> ------------------------------------------------------------------------
> Part 1.2Type: application/pgp-signature
--
http://www.eskimo.com/~xeno
xeno@eskimo.com
Physically I'm at: 5101 N. 45th St., Tacoma, WA, 98407-3717, U.S.A.
Reply to: