XFCE Thinclient Internet Very Slow

Hello.

This is actually my first time posting on this forum, though I've used it in the past as a resource for troubleshooting, I can't seem to find anything similar to my issue this time.

I have FreeBSD 8.2 serving one Thinclient that I just setup. It's using PXE and boots to XFCE.

Everything is working as it should except trying to view websites is VERY slow. I've used Firefox3 and Opera with the same results. nslookup returns DNS in < 1 second. Links (from TTY) is able to load pages at normal speeds, and curl (also from TTY) can download large files at around 65KBps so my intuition tells me there's a problem from within XFCE that's causing the slowdown.

If someone can give me some clues as to where to start my investigation.

Thanks a million!
 
Didn't actually think to try that. lol.

I started firefox from an X11 login and got the same issue. Links again worked normally when executed from one of those pts-ish terminals that X11 automatically starts.
 
Just an update. It seems that the slowdown occurs during name resolution.

If i'm already navigating a website, the subsequent pages load just find. It seems that the slowdown occurs when newpages are trying to be resolved.
 
If DNS is the problem, it should be the same with links. See if the pages that are slow in Firefox have Flash on them. There was a recent problem with Flash and it did that, even with Flashblock installed. Fixed now, but I can't recall whether the fix was an update to Firefox, nspluginwrapper, linux-f10-flashplugin, one of the linux_base-f10 ports, or -STABLE.
 
Nope. No flash or anything. Simple websites like Craigslist will exhibit this behavior.

What's more interesting is this morning I created an SSH tunnel to that machine and used Firefox from another system and it works at normal speed!!

I'm definitely dumbfounded at this point.
 
X display driver? Is there a lag when dragging windows around? Disable compositing, maybe disable acceleration, depending on the type of card.
 
I can't imagine how that would be an issue. I've gone so far as to ssh in with remote forwarding and forwarded a Firefox session to my screen from the PXE-booted machine and it's just as slow. It always hangs when the bottom status bar says "looking up host," even though an nslookup of the same host will return an IP in < a second. If I then enter THAT IP address in Firefox the page loads within seconds.

P.S., same problem with Opera but NOT with Links? Haven't tried any other browsers.

This just doesn't make any sense. I almost want to say there's some implementation bug in some API or something.
 
It just seems odd that the graphic browsers have a problem but the text ones do not. Are the text ones running in a console or xterm? If you build links with X11 support and run it in graphics mode, is it slow?

Maybe the text/older browsers don't support IPv6, but Firefox and Opera are trying it?
 
wblock@ said:
Maybe the text/older browsers don't support IPv6, but Firefox and Opera are trying it?

I definitely think you're on to something!

I did a little experiment. Using Firefox, I navigated to the website hills.ccsf.edu. It's a nice, simple html-only website. Below is the excerpt from tcpdump.

Code:
1. [color="Red"]22:33:01[/color].800747 IP 172.20.1.73.32504 > 172.20.1.10.53: 48698+ A? hills.ccsf.edu. (32)
2. 22:33:01.855371 IP 172.20.1.10.53 > 172.20.1.73.32504: 48698 2/3/1 CNAME[|domain]
[B]3. 22:33:01.855666 IP 172.20.1.73.42735 > 172.20.1.10.53: 48699+ AAAA? hills.ccsf.edu. (32)
4. [color="red"]22:33:06[/color].972298 IP 172.20.1.73.42735 > 172.20.1.10.53: 48699+ AAAA? hills.ccsf.edu. (32)[/B][color="Gray"]
5. 22:33:11.495167 IP 172.20.1.73.47591 > 172.20.1.10.53: 1335+ A? sb-ssl.google.com. (35)
6.   22:33:11.555125 IP 172.20.1.10.53 > 172.20.1.73.47591: 1335 17/4/2 CNAME[|domain]
7.   22:33:11.555229 IP 172.20.1.73.65495 > 172.20.1.10.53: 1336+ AAAA? sb-ssl.google.com. (35)
8.   22:33:16.672539 IP 172.20.1.73.65495 > 172.20.1.10.53: 1336+ AAAA? sb-ssl.google.com. (35)
9.   22:33:17.470392 IP 172.20.1.73.32650 > 172.20.1.10.53: 48700+ A? [url]www.ccsf.edu[/url]. (30)
10.   22:33:17.524426 IP 172.20.1.10.53 > 172.20.1.73.32650: 48700 2/3/3 CNAME[|domain]
11.   [color="Red"]22:33:17[/color].524522 IP 172.20.1.73.32837 > 172.20.1.10.53: 48701+ AAAA? [url]www.ccsf.edu[/url]. (30)[/color]
Line 1 and 2 are standard A record (IP4) request/response for the server. Line 3 and 4, I believe, is the problem. Those appear to be IP6 record requests. This extra traffic takes 5 seconds to resolve. Then it looks like Firefox takes it upon itself to query a few more domains that are somehow related to the website I navigated to, also using AAAA records and taking more time in the process. The webpage doesn't display until line 11 executes, over 15 seconds from the start of the request. Bear in mind, this was a VERY simple webpage with no outside linking. Pages that include linked content compound this problem to the order of minutes to fully load!

Below is the SAME website loaded from Links:
Code:
22:33:[color="red"]37[/color].709673 IP 172.20.1.73.51373 > 172.20.1.10.53: 11617+ A? hills.ccsf.edu. (32)
22:33:[color="red"]37[/color].765376 IP 172.20.1.10.53 > 172.20.1.73.51373: 11617 2/3/3 CNAME[|domain]
...and that's IT! It resolves and loads almost instantly.

So it seems that Links, as the previous poster theorized, does not try to resolve IP6 whereas Firefox and Opera do. This is almost certainly where my problem is.

So now the next step....How do I stop the query from happening, or force it to timout immediately?

And THANK YOU again for everyone helping.
 
about:config did the trick for Firefox!

Short of rebuilding the kernel, I just setup ipfw to reject IP6 traffic outbound so Opera would work as well.

So my problem is solved! Curious why that was happening though. On my other machine (using a different ISP), it tries to resolve an AAAA record too but doesn't behave that way. I get the same tcpdump output, but it all happens much faster. From what I understand of the tcpdump output, neither the problem machine nor the working machine ever get an answer to the AAAA record request. Maybe the ISP's DNS server is to blame? I might try some of those free online DNS servers with the problem machine to test that.

Thanks again for all your help wblock@!
 
Back
Top