Need help resolving browser STALLING... When using any http browser
(Netscape, etc) on LINUX (Red Hat 7.1). Our System is able to resolve
a url, starts pulling in data to the browser and then stalls out with
a partial page download. This Linux box is behind a firewall with a
private address, and two dns server entries. This similar setup is
replicated on a Windows-2k machine without any stalls.

Hi Martin,


    The problem you are facing could be due to a number of reasons.

    A common solution is to download the latest version of the
browser. But in your case, since you say that any http browser stalls,
its unlikely, but worth a try. If you're using Netscape 4.72,
upgrading to the latest version should solve your problem.

    Alternatively, try using -vj with pppd when dialing. This should
most probably solve your problem.

    If even that doesn't work, then try changing the value of MTU. MTU
value should typically be 1500 for a network connection. Try 1400 and
come descending to 1000. You could also try changing the MRU, MSS &
TTL values.

    If after this, it doesn't work, I'll need more specific data.
Like...the browser(s) you have a problem with. Whether this problem
happens only to certain webpages. If so, which ones? Whether this
problem happens only sometimes for the same webpage. I need all
possible info. Please post it as a clarification.

    If I have provided a solution to you and you are satisfied, then
so am I :-)

Have a good day.

Cheers,
aditya2k


Search Terms
page load stalls linux
page download stalls linux
page load stalling linux
page download stalls redhat

---

Clarification of Answer by aditya2k-ga on 13 Jun 2002 12:02 PDT

It's nice to see you solved your problem with the DIY method (Do It
Yourself) :-)

Just a small comment. In future, when you rate a researcher's answer,
please rate the answer based on the content and not the final
solution. I don't know if this makes sense. A 3-star rating, though
not bad, isn't good either. Google checks the ratings periodically
(quality control), and its the ratings they see, not the comments.
They drop researchers if the ratings are poor. However, 3 isn't a
droppable rating. In the end, you're happy, therefore, so am I.

Have a good day :-)

I made an alternative decision to replace my NIC card and "magically"
my problem went away. So the MTU adjustment may have been a close
call. I replaced with a more established vendor's NIC card from a
no-namer. I did not explicitly change an MTU setting to fix the
problem currently.

I think this answer and other comments all added nice value to me !
The 3 star rating is indicative of a different approach I took to
resolve, and the suggestion may have been correct and worked, but I
did not validate. The version of Netscrape (pun intended) was not an
issue in my case.

Thanks and this is a GREAT service!

Martin

Have you tried rebooting the machine?  Sometimes Netscape does funky
things like this, at least on both my Mac and my husband's PC.  We
didn't experience it on our Slackware or Mandrake boxes, but then
again we didn't use them nearly as much as the other ones.

In any event, a reboot on the MacOS/Win9x machines would clear it up,
and it's a problem that seems to be unique to Netscape in particular. 
It is also random, with pages sometimes working and sometimes not. 
Does it happen with Opera?

Hello Martin,

I also run Redhat 7.1 with IP Masquerading and had a similar problem,
but only on my internal boxes (not on the firewall).  Setting the MTU
to a lower value on the internal machines than on the firewall fixed
the problem.

My understaning of the problem goes something like this:

In order to do NAT, the kernel has to add some data to the packet
headers.  This increases the size of the packets by a few bytes. 
Assume that both the firewall's and internal machine's MTUs are set to
1500.  This guarantees fragmentation of packets coming from the the
internal machine--1500 bytes + what the kernel adds for NAT exceeds
the MTU of the firewall, so the kernel has to break each packet into
two smaller packets.

That's all well and good except that some people won't let fragmented
packets through for security reasons.  The remote server should send
an ICMP message back saying that you need to lower your MTU, but some
administrators unnecessarily block all ICMP messages, preventing the
necessary communication.

The easiest way to test for the problem is to temporarily set the MTU
down by issuing a command similar to

# /sbin/ifconfig ppp0 mtu 1000

You'll need to replace ppp0 with your interface name, and replace 1000
with whatever MTU you would like to try.  Note that this will only
change the MTU until that interface is taken down.  If you want to
make it stick, you'll need to add a line like

MTU=1000

to the appropriate file under /etc/sysconfig/network-scripts/
NB: There was a bug in the network scripts that prevented the above
line from having any effect.  They probably fixed it in the updates,
but I'm not sure.  My solution was to add the appropriate ifconfig
command to /etc/rc.d/rc.local.  That will cause the MTU to be changed
at boot, but not if the network goes down and comes back up between
boots.

You might find the following thread from the Seawolf mailing list
interesting (the link is to the first message in the thread):
https://listman.redhat.com/pipermail/seawolf-list/2001-November/014496.html

Hope this helps,
bikerman