Bug 8008

I am having similar problems.  It occurs not only in Netscape, but in lynx, ftp,
and telnet as well.  It seems to be more common when a large burst of data comes
in, ie. a long web page.  Like this bug report, I am also seeing a large number
of frame errors in ifconfig.  I installed the ppp and initscripts upgrades from
the errata page but this didn't help.  Nothing strange in /var/log/messages, but
I do notice that software compression is enabled:

Feb  5 15:21:53 localhost kernel: PPP BSD Compression module registered
Feb  5 15:21:53 localhost kernel: PPP Deflate Compression module registered

For what it's worth, I figured out how to turn off the software compression, but
it didn't fix my problem.

I am also having the same problem. Have tried upgrading ppp and turning off
compression. By turning off compression the connect stays up slightly longer I
believe. No problem with the hardware as it works fine under windows. I have
also found that I can restart the transfer and that it will work fine for a
while again than stall.


I was wondering whether it could be a bug on the ppp server end in MS NT
implimentation of PPP protocol.

My ISP is running SunOS 5.5.1, so it can't just be an NT problem.  My modem
and ISP work fine under Win95 also.  I'm using an external modem, so I tried
switching COM ports, but got the same symptoms on both (ttyS0 and ttyS1).

My connection seems much better by turning off vj header compression in pppd by
adding the option novj. Not sure why this should be the case ? Unless the
sending in is compressing the header incorrectly. I suspect that windows PPP
does not use any software compression of any type, that is why it works........

Harry

Yes, that seems to be working!  The novj option seems to have fixed it.  I've
been going to sites that usually make it stall, and no freeze ups yet. I'm still
seeing frame errors in ifconfig, but I don't know if that is worth worrying
about.  Thanks for your help!

This is odd.  Could I ask which ISPs you are all using?

I dial into Rocky Mountain Internet, v.90 pool.

I also dial into an Cisco AS/5200 that I administrate.  The modems are v.90
Mincom modems.  I can probably provide you a lot of debugging info.  If you
want.   -Tim Teller

I'm using FYI Networks(fyi.net), a small Pittsburgh ISP.  Like I said they are
running SunOS 5.5.1.  Since I added the novj to my PPP options I haven't had any
more problems.

I am using two ISP's and get the same behavior on both.  First the connection
starts off fine, but soon it starts to slow down and stall. One of the ISP seems
to take longer to slowdown and stall, after using novj. Although it still always
stalls after a few web page downloads. Restarting the connection results in
stalling immediately, unless I restart computer.  Also starting one connection
running it untill it stalls and then starting the other connection causes the
second to immediately start to stall. I am using a ELSA MicroLink 56K external
modem, which is a ISDN device?

I have a similar problem; the overall connection is fine, but individual TCP
transfers (like FTPing large files or downloading a large POP3 mailbox) stall
after a few dozen kilobytes. I'm using a 56K modem with Concentric.net as ISP.
Nothing yet has helped; I have tried -vj, asyncmap 0, mru 552, and a variety of
other recommended solutions. Through this, I have discovered what appears to be
a bug in the (kernel portion) ppp.c driver: if you attempt to set the MRU less
than the default of 1500, it sets it to the default. I believe what's intended
is that it fixes it up if you set it less than the *minimum*, which is 128. I am
working on rebuilding the kernel with this driver fix to see whether it helps my
problem.

Oh, to reproduce the bug I found, enable 'mru 552' and 'kdebug 7' in pppd, then
examine the log output in /var/log/messages. Despite requesting mru 552, it will
report 'ppp_ioctl: set mru to 5dc' (0x5dc = 1500).

I can't tell for certain, but I suspect that 1500 is too large a packet size for
my dialup connection. It probably results in worse throughput for other users as
well, although not necessarily as dramatic as a total freeze. MRU 552 is much
more appropriate for a fast modem.

On further looking, it's possible that the MRU thing is not a bug... at this
point I'm not sure. It may be that the ppp driver doesn't care if the MRU is
less than its default. Still, it seems suspicious to me, so it may be worth
checking out.

Okay, I managed to fix my own problems, for now at least. Turning off VJ header
compression in ppp is one way. (This didn't work for me before; I was using the
"-vj" syntax suggested in the pppd options file, which didn't work, but "novj"
seems to do it.)

The root cause is (as I understand it) an incompatibility with TCP timestamps
(from RFC 1323) and VJ header compression (from RFC 1144). Basically, you have a
choice: disable VJ or disable timestamps. You can do the former with pppd
options; to turn off TCP timestamps instead, use sysctl to deselect the kernel's
runtime tcp_timestamps option. I don't know whether you also need to turn off
tcp_window_scaling or tcp_sack (two more RFC 1323 options) as well. You may want
to try both approaches (novj and no tcp_timestamps) to see which one gives you
better throughput.

My connection is currently running much better. This may explain why.

There were bugs in several vendors handling of vj+timestamp combos, and some
obscure Linux cases too. All seem to have been fixed over time.

If not re-open