Opened 17 years ago
Closed 16 years ago
#1247 closed defect (fixed)
ping doesn't work with NAT network interfaces
Reported by: | Bart | Owned by: | |
---|---|---|---|
Component: | network | Version: | VirtualBox 1.5.6 |
Keywords: | Cc: | ||
Guest type: | other | Host type: | other |
Description
Run a Windows XP guest on a Linux host, and configure the network interface as NAT. In the guest, run a ping command to a live host.
Expected: Windows guest reports that the host is alive.
Actual result: Windows guest reports that the request timed out.
Technical background: VirtualBox NAT translates the outgoing ICMP request in an UDP echo request (port 7). If the echo service is not enabled on this host (which is e.g. the case on OpenSolaris servers), that host will send back an ICMP error (destination unreachable). VirtualBox does not translate this ICMP error into an ICMP response for the guest. This can be easily verified by running Wireshark simultaneously on the guest OS and on the host OS.
Attachments (2)
Change History (9)
by , 17 years ago
Attachment: | host.snoop added |
---|
by , 17 years ago
Attachment: | guest.snoop added |
---|
comment:1 by , 17 years ago
comment:2 by , 17 years ago
Attributing this "bug" to QEMU doesn't isn't really accurate. It's slirp which has that what you call bug. Both VirtualBox and QEMU use slirp as their NAT engine, because it's so nicely portable.
The hinted solution however doesn't get us anywhere. I've read the relevant documentation up and down, and there is simply no way of receiving (leave alone sending, that would make the whole discussion redundant) ICMP messages from a process not running with root privileges. Which is something we resisted so far. So unless I'm completely wrong there (if I am please let me know), the suggestions are not implementable.
comment:3 by , 17 years ago
Do you know that it is possible to detect asynchronous errors (=ICMP errors) on connected UDP sockets from userspace ? See also Unix Network Programming: The Sockets Networking API (R. Stevens), pages 252-253.
comment:4 by , 17 years ago
I know. But this is getting way too indirect for my taste, especially as the "destination unreachable" ICMP is pretty unreliable outside your nice and cozy LAN. Another aspect is that the slirp code will get even more complicated, because it requires distinguishing between UDP initiated by guests or by guest ICMP.
Just to fake success for ICMP echo which doesn't always work either. So far I'm not thrilled to say the least.
comment:5 by , 17 years ago
Hi guys.
I read this information from VirtualBox Manual.
Probably this is not a but, just the way it works.
"By default, virtual network cards are set up to use network address translation, which is well suited to standard networking needs (accessing the Internet from programs running in the guest and providing network services for machines in a local intranet). In particular, if all you want is to browse the Web, download files and view e-mail inside the guest then the default configuration of the NAT network should be sufficient for you, and you can safely skip the rest of this section. Please note that the ping utility does not work over NAT, and that there are certain limitations when using Windows file sharing." Source: Page 58 from Innotek VirtualBox User Manual. Version 1.5.4. December 29 2007.
comment:6 by , 17 years ago
Component: | other → network |
---|
Yea, this bug came from the Qemu codebase.
This is because ICMP protocol, unlike TCP or UDP, has no "ports".
Technically it can be resolved, by doing NAT map, based on the "ICMP message number" rather than TCP/UDP port.
This way first stream may start with ICMP message #0, second stream may start with ICMP message #1000, and so on... so the NAT logic will have to remember map of all those things.
-Technologov