Michael Eager wrote:
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.
Now that you have done all that detective work, I wonder if MSS is the
problem after all. I just opened linkedin.com from this VM (my default
desktop) and it worked perfectly. So now I have to bring up the old
original list entry you made and see what you are doing differently from
what I'm doing, (which works).
I was able to bring up profiles, etc, so I assume it was working right.
--
Bill Davidsen <davidsen@xxxxxxx>
Obscure bug of 2004: BASH BUFFER OVERFLOW - if bash is being run by a
normal user and is setuid root, with the "vi" line edit mode selected,
and the character set is "big5," an off-by-one error occurs during
wildcard (glob) expansion.
--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
