Firefox display of LinkedIn slow on Fedora 10
Bill Davidsen
davidsen at tmr.com
Wed Jul 29 12:32:45 UTC 2009
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 at tmr.com>
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.
More information about the users
mailing list