> I'm using a Red Hat 5.1 system, upgraded to kernel 2.2.3 and ppp
> 2.3.5. When I try to grab a particular file off of the Internet,
> the transfer always stops at the 7% mark.
>
> Other files transfer without a problem, regardless of their size.
> I've tried retrieving the file (kernel-headers-2.0.36-3.i386rpm)
> from many sites and various times of day, but the result is
> always that progress stops cold at 7%. I've used Netscape, ftp,
> and ncftp, all with the same result.
I've run into this sort of problem as well. As far as I could tell,
here was what was happening:
1) The connection gets dropped for some reason, but there are still
sockets which are either still open or in a TIME_WAIT state. These
connections still send out a packet here and there trying to
compmletely close themselves down.
2) You re-establish the connection, and get a DIFFERENT ip address
dynamically assigned.
3) You start to ftp your large file
4) A few of those packets are sent across the connection with the
wrong "from" IP address, while this file transfer goes on.
5) After a couple of these packets with the wrong address, something
gets fed up and drops your connection. It takes pretty much the same
amount of time for this to happen every time, and so if you
immediately re-open your connection and start the FTP each time, you
get about the same length through the FTP and the connection drops.
I'm not entirely sure of the details of why this occurs or if my
diagnosis of what is going on is correct. However, I do have a
solution that I know solved my problem:
1) Configure your kernel to do firewalling: all you need is "Network
firewalls" and "IP: firewalling"
2) At boot time, set up a firewall to block all outgoing traffic
except through your loopback:
/sbin/ipchains -P output REJECT
/sbin/ipchains -A output -s 127.0.0.1 -j ACCEPT
3) In /etc/ppp/ip-up, enable outgoing packets from the assigned
address:
/sbin/ipchains -A output -s $4 -j ACCEPT
4) In /etc/ppp/ip-down, disable outgoing packets with the address
which is being closed down:
/sbin/ipchains -D output -s $4 -j ACCEPT
All this is probably not a half bad idea anyhow, since sending out
packets with the wrong "from" IP address is probably bad form anyhow.
> (In addition, normal file
> transfers are often choppy--lots of stalls.
>
> Under Win95, the file retrieves without a problem, and file
> transfers are not very choppy.
There are two things I would recommend for this:
1) Try setting an mtu and an mru. Try 1500 (which will not actually
have an effect if you use it as an mru setting) and 576. Often the
mtu that the client negotiates is 1524 or something like that (why, I
know not), and I ran into at least one instance where that ran me into
troubles. However, in reality I don't expect this to cure your
problem: I ran into troubles when I sent packets that were too large,
but your problem is in receiving packets.
2) Your modem settings may be too aggressive. Have windows create a
log file of the modem commands that it sends to initialize the modem,
and use those same commands to initialize the modem in your chat
script.
-Scott Berg
-
To unsubscribe from this list: send the line "unsubscribe linux-ppp" in
the body of a message to [EMAIL PROTECTED]
