Firefox display of LinkedIn slow on Fedora 10

[Bill Davidsen]

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.