0

I've got Ubuntu 12.04 TLS running on Virtual box, when I try and do wget it's taking about 10 seconds to connect to a server, although the download itself is quick.

If I run the same command in terminal on my laptop, it's instant.

:~$ time wget example.com/profile/avatar/USERID-640.jpg
--2014-02-26 09:52:58--  http://example.com/profile/avatar/USERID-640.jpg
Resolving example.com (example.com)... 54.230.2.117, 54.240.166.35, 54.230.0.66, ...
Connecting to example.com (example.com)|54.230.2.117|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 40145 (39K) [application/octet-stream]
Saving to: `USERID-640.jpg.7'

100%[===========================================================================>] 40,145      --.-K/s   in 0.04s   

2014-02-26 09:53:08 (898 KB/s) - `USERID-640.jpg.7' saved [40145/40145]


real    0m10.269s
user    0m0.000s
sys 0m0.004s

This is what the network settings look like:

Virtual box network settings

Summary of settings from image:

  • Attached to: Bridged Adapter
  • en0: Wi-Fi (AirPort)
  • Adapter Type: Paravirtualized Network (virtio-net)

I've also tried some other Adapter Types, it makes no difference

The file should download immediately, but when I try and check for files existences in PHP pages it's timing out the web server due to the slow page loads.

I'm using OS X mavericks, Virtual box 3.3.6

EDIT

Added /etc/resolv.conf as requested:

# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 192.168.0.1
search Home

EDIT

Just trying to access serverfault.com

  • time curl serverfault.com (real 0m10.516s)
  • time wget serverfault.com (real 0m10.607s)
  • time lynx -dump serverfault.com (real 0m30.709s)
16
  • Is 192.168.0.1 your DNS server? Do you see requests in the logs?
    – NickW
    Feb 26, 2014 at 10:47
  • 192.168.0.1 is the router, in my living room. Do you mean the logs on that?
    – Pete
    Feb 26, 2014 at 11:05
  • I guess not, something is interfering with the DNS resolution, I don't know if I can offer much else..
    – NickW
    Feb 26, 2014 at 11:09
  • What does that mean? Something's stopping wget from going straight out through the router?
    – Pete
    Feb 26, 2014 at 12:17
  • No, it means the DNS requests to 192.168.0.1 are somehow inhibited, how or why I couldn't say..
    – NickW
    Feb 26, 2014 at 12:19

2 Answers 2

1

I was experiencing the same issue. After some misguided troubleshooting, and finally some sound help, I've found the problem:

Check your /etc/network/interfaces file on your VM. You'll probably need to set the 'address' and 'netmask' for your host-only adapter, and your 'gateway' on your NAT adapter for your VM to be able to access the Internet (from your VM). Basically your network adapters don't appear to be configured correctly (and your Virtual Box config might be wrong also).

My VM was copied over from a different computer and I didn't have the correct network adapters setup in Virtual Box (not my VM, but virtual box itself for my host machine). I added an adapter for both VM adapters (NAT and Host-Only Network). After configuring my /etc/network/interfaces file, everything worked correctly; My VM/Browser responded immediately, and I was able to access the Internet from my VM.

You can find details on how to change those settings here:

https://askubuntu.com/questions/346838/how-do-i-configure-my-dns-settings-in-ubuntu-server

And more complete details on the /etc/network/interfaces file here:

http://www.cyberciti.biz/faq/setting-up-an-network-interfaces-file/

I set my VM's address to static, and added 'address', 'netmask' to my Host-Only adapter on my VM, and 'gateway' to my NAT adapter on my VM.

Check your Virtual Box -> Network settings (not the network settings for your virtual MACHINE, but the actual settings for the app). My adaptor is called 'vboxnet0'. Just make sure you run the ifdown and ifup commands for that interface (on your VM).

I believe the problem is that the VM tries to lookup the machine connecting to it (host) and has to time-out before it responds.

I hope this helps.

Here are my final /etc/network/interfaces settings:

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface (NAT)
auto eth0
iface eth0 inet dhcp
gateway 192.168.56.1

# Secondary network interface (Host Only)
auto eth1
iface eth1 inet static
address 192.168.56.101
netmask 255.255.255.0

FYI: My host machine is what I put in as the gateway.

1
  • I'm not using a host-only adapter, I'm using a bridged adapter
    – Pete
    Mar 7, 2014 at 22:07
0

You need to further decouple your tasks in order to pin-point where the problem is.

You said "it's taking about 10 seconds to connect to a server", so basically almost 99% of time of your wget command was spent on connecting to a server? You need to further break down that 10 seconds.

Is it spent on DNS resolving?

Try

dig serverfault.com

This is my result:

;; ANSWER SECTION:
serverfault.com.        35      IN      A       198.252.206.140

;; Query time: 38 msec
;; SERVER: 192.168.2.100#53(192.168.2.100)

I.e., the DNS resolving only took 38 msec, from my local DNS. If yours is taking much longer than that, please consider installing a local caching only DNS server, as I did. It's really simple, check out http://sfxpt.wordpress.com/2013/11/30/dnsmasq-installation-configuration-5/, and as a bonus, check out http://sfxpt.wordpress.com/2014/01/05/the-best-ad-blocking-method-in-a-package/,

If your DNS resolving is as fast as mine, then the problem is elsewhere, Try httping and post back what you've got.

httping - ping-like program for http-requests

All in all, you need to further decouple your tasks in order to pin-point where the problem is. E.g., How fast to get files from your local http server?

3
  • The response from dig was: Query time: 1097 msec - I don't fully understand what the problem is, I'd like to understand it before I try anything in that guide
    – Pete
    Mar 7, 2014 at 22:05
  • So your system spent 1 second doing DNS resolving, and 9 seconds on something else. You need to break down that 9 seconds. E.g., How fast to get files from your local http server?
    – xpt
    Mar 8, 2014 at 2:18
  • Using dig with default parameters is not accurate because it doesn't report timeouts and retries. Try "time" and disabling retries: time dig serverfault.com +retry=0 +tries=1 +time=1 @8.8.8.8
    – Colin M
    Apr 30, 2018 at 20:22

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .