Appbrowser questions

[aeios]

Why is the appbrowser so horrendously slow sometimes? I'm running TC in livecd mode on virtualbox. It doesn't seem that it's timing out it's just committing so heavily it's interfering with the user experience. After I noticed this I am running a packet sniffer on the host and it doesn't seem to really be emitting any packets in that time frame. Host lookups seem to be the culprit as 'sudo ping' (why can't you ping as a local user again?) to google.com gets nowhere fast.

[curaga]

You could use a mirror near you - ibiblio can be slow sometimes.

[aeios]

You could use a mirror near you - ibiblio can be slow sometimes.

It shouldn't be slow though, after toying with it more I am having horrid nameserver lookup times. What's even weirder is that TC isn't caching names it has already looked up. If I ping ibiblio by IP my round trip time is taking twice as long as another guest machine, but if I try to ping by DNS name I end up spending about 40-50 seconds doing a name lookup. This makes using the appbrowser dreadful because it does three DNS lookups to download one package (One to connect, One to get the package's .info, One to download). So generally it takes about 5 minutes just to download a 16kb package. Additionally I can't alter resolv.conf because it's locked as part of the live cd image.

[roberts]

Everything in CORE is in ram and therefore you just need permisison.
sudo vi /etc/resolv.conf

[tobiaus]

not to split hairs but when you say appbrowser is slow, you're referring actually to wget, which is used to do the downloading, right?

only that wget is pretty standard and (as others suggested) is not always the culprit itself.

[MikeLockmoore]

I'm having this slow wget behavior in my TC 2.0 installation.  It takes 5 seconds to wget google.com's main page.  My AppBrowser is also very slow, of course.  I have not seen a definitive cause or fix for this in the TC forums.  It seems others are having similar problems in other versions of Linux, but I don't think most of those people are using a busybox version of wget.  

One possible cause seems to be the DNS resolution process getting tripped up by a change in some key library, and/or inproper handling of IPv6-based DNS requests (at least in those other versions of Linux).  One suggestion that worked for some is adding the line 'options single-request' to /etc/resolv.conf file.  I tried this, but it does not help before reboot, and after reboot my /etc/resolv.conf file reverted back to the way it was (even though I tried to save it in .filetool.lst.)

Any ideas on why DNS and/or wget is so slow for me?  I did not notice this problem back in the TC 1.3 days (maybe not in 1.4.3 either, but I did not use that version very long).  Thanks for any suggestions.

p.s. Another possible clue:  I tried to substitute the IP of google's main website into the command line of wget like this:

 wget http://64.233.233.2/

And I get back:
wget: cannot connect to remote host (127.0.0.1): Connection refused

 

UPDATE: I have a fix!    At least for me.  I'll post it below.
--
Mike Lockmoore

[MikeLockmoore]

I dug around a bit more in various Linux discussion boards and found a very interesting bug report in Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=459756.  Therein, the infamous glibc maintainer Ulrich  Drepper basically ignored a bunch of solid evidence that changes in the DNS lookup in glibc to better support mixed IPv6 and IPv4 networks very commonly lead to dropped DNS replies, so there are many delays or outright DNS failures.  Ulrich also said the ISPs should fix buggy DNS servers and the rest of the world's apps should be recoded to request the host lookup the propper way.   Ulrich also seemed to ignore the a particularly cognizant observation that the poor DNS behavior started when glibc was changed to send essentially simultaneous IPv6 and IPv4 type DNS lookup requests out of the same originating IP port.  Appearantly, earlier versions either did the lookup requests sequentially (e.g. maybe IPv4 first, then if no reply, IPv6; or vice-versa), or at least from differing originating ports. 

On the same thread, several user config level work-arounds were suggested which basically suggested running a DNS caching process locally.  But some people posted that their problems sometimes cleared up upon rebooting a router or firewall.  Since my /etc/resolv.conf file had a line:

    ...
    nameserver 192.168.{... the rest of my WAP/router's local IP addr ...}

I thought it may not be forwarding DNS requests and/or replies very well, so I logged into my WAP/router's admin page, found the DNS number provided by my ISP, then edited my /etc/resolv.conf file to now point to the ISP's DNS server address:

    ...
    nameserver {my ISP-issued DNS IP address}

After this, AppBrowser and wget started working lightning quick again! 

However, it was not so simple to have it permanently fixed.  I realize now that my /etc/resolv.conf is getting modified upon reboot by a script I wrote for my wireless network setup.  /opt/bootlocal.sh is modified to start my script /opt/wireless_start.sh.  And wireless_start.sh invokes udhcpc, which rewrites /etc/resolv.conf.  So I added another two lines to my wireless_start.sh to copy the wanted content (which I saved in a file named /opt/etc_resolv.conf) over the "bad" /etc/resolv.conf.  The lines added to my wireless_start.sh script are (or these could probably be added to bootlocal.sh):

    sleep 7
    sudo cp -f /opt/etc_resolv.conf /etc/resolv.conf

The long sleep makes sure udhcpc is done mucking with /etc/resolv.conf, since it is running in the background, in parallel with the rest of the wireless_start.sh script.  Not pretty, but it works! 

If anyone here knows a more elegant way to do this, or at least how to prevent udhcpc rewriting the /etc/resolv.conf file, I'd appreciate hearing it.

Or if there is not a better way, maybe I should write this up as a Tips and Tricks post?
--
ML

[curaga]

If anyone here knows a more elegant way to do this, or at least how to prevent udhcpc rewriting the /etc/resolv.conf file, I'd appreciate hearing it.

udhcpc forwards commands to a script, see /usr/share/udhcpc/default.script.

[MikeLockmoore]

Thanks for that tip, curaga.  I tried to hack the script so it would only put my specific DNS into the /etc/resolv.conf file, and while the resolv.conf was getting set like I expected, the wireless LAN link was totally inoperable.    Maybe there is something subtle in that script I just broke, but I'm not sure yet.  For now, I've reverted to my crude sleep + cp method.  Maybe later I can come up with a mod to udhcpc/default.script that will work.
--
ML

[jpeters]

I think somethings wrong, and the nameserver should be the DNS address.  Puppy uses udhcpc, and /etc/resolve lists the correct nameserver with wireless (& it's on a network).  I'd try this out with TC, but it has problems connecting to my 802.11A.     

[jpeters]

Finally got a wireless connection, and indeed /etc/resolv.conf has the correct nameserver:

Code: [Select]

search hsd1.ca.comcast.net.
nameserver 68.87.76.xxx
nameserver 68.87.78.xxx