Bill Davidsen wrote:
Michael Eager wrote:
Hi --
When I try to open a page on LinkedIn in Firefox or
Konqueror, it takes forever to display. Often, the
session times out before the page is shown. I have
not noticed any other sites which have similar problems.
A Google search shows that a number of people have encountered
similar problems. There were conjectures that the problem
has to do with routers or network settings. There are a few
suggestions to reduce the TCP MTU size, and some people
claimed this fixed their problem. When I followed these
suggestions, it doesn't improve display of LinkedIn pages,
but it did screw up display of other sites.
On a Windows XP system running under VMware on the same
hardware, Firefox displays LinkedIn pages with no delay.
Since the network connection and router is the same,
it's not a problem with the physical hardware. Since
the same problem appears on both Firefox and Konqueror,
it's not a problem with the browser display engine.
Anyone have a suggestion how to eliminate this annoyance?
Thanks for the suggestion.
MTU sounds good, the usual "real cause" is some router not passing or
honoring the "can't fragment" ICMP. If you are running from a VM, behind
a tunnel, etc, etc, this might be your problem, and since there's a
simple solution it's worth a try.
Actually, the WinXP system running in the VM works OK; the
host Linux system is the one that fails. The VM is accessing
the NIC in promiscuous mode. The same routers should be in place
for both VM and host.
Look at the "mss M" section of the "man route" output, and it explains
this better. Using the route command you can set a route to the problem
site, via your default router, and only for that route use a smaller
MTU. So "mss 1400" would be part of the command line.
Tried host route:
# route -v add -host linkedin.com mss 1400 gw gateway dev eth0
# route -e
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
www.linkedin.co gateway 255.255.255.255 UGH 1400 0 0 eth0
172.16.160.0 * 255.255.255.0 U 0 0 0 vmnet1
192.168.20.0 * 255.255.255.0 U 0 0 0 eth0
192.168.238.0 * 255.255.255.0 U 0 0 0 vmnet8
link-local * 255.255.0.0 U 0 0 0 eth0
default gateway 0.0.0.0 UG 0 0 0 eth0
Also tried network route:
# route -v add -net 64.74.98.0 netmask 255.255.255.0 mss 1400 gw gateway dev eth0
# route -e
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
172.16.160.0 * 255.255.255.0 U 0 0 0 vmnet1
192.168.20.0 * 255.255.255.0 U 0 0 0 eth0
64.74.98.0 gateway 255.255.255.0 UG 1400 0 0 eth0
192.168.238.0 * 255.255.255.0 U 0 0 0 vmnet8
link-local * 255.255.0.0 U 0 0 0 eth0
default gateway 0.0.0.0 UG 0 0 0 eth0
Neither appear to make any difference. I also shrank MTU down to 1000
to see if that helped. Same result.
One interesting aspect is that some of the LinkedIn pages come up fast,
others hang. Firefox thinks it's waiting for www.linkedin.com. I could
run a sniffer to see if it really is accessing the IP address with the
reduced MTU.
--
Michael Eager eager@xxxxxxxxxxxx
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
