GXemul's current networking layer supports three modes:
IPv4 address: 10.0.0.1 Netmask: 255.0.0.0 Gateway / default route: 10.0.0.254 Nameserver: 10.0.0.254To the outside world, it will seem as if the host is doing all the networking, since the emulator is just a normal user process on the host.
NOTES:
The tap device support was contributed by Jason Thorpe.
The NAT-like layer is very "hackish" and was only meant as a proof-of-concept, to see if networking like this would work with e.g. NetBSD as a guest OS. (If you are interested in the technical details, and the reasons why NAT networking is implemented this way, you might want to read the networking section in the technical documentation.)
The UDP mode is used to connect multiple instances of GXemul in an easy way, but it provides no security of any kind.
Use the networking features at your own risk.
The emulated machine must have a NIC (network interface card). Not all machines have this. At the moment, the following NICs are more or less working:
It is not possible to simply attach any of the supported NICs into any of the supported emulated machines. Some machines, for example, have a specific NIC in them, others may have a PCI bus where a PCI NIC can be used. This is very much machine-dependent, and implemented on a case-by-case basis.
If you are impatient, and simply want to try out networking in GXemul, I would recommend trying out an ftp install of NetBSD/pmax.
The simplest way to emulate a real Ethernet network is using a tap device. In this mode, the emulator disables the simulated NAT and direct-access machinery and internally treats all emulated NICs as if they are on a single Ethernet switch. In this mode, packets destined for the guest's specific MAC address as well as Ethernet multicast and broadcast packets are send to the individual guest instances. Individual NIC emulations may also apply their own multicast filtering; multicast filtering is implemented for the DEC 21143 and Lance NICs.
The tap interface on the host can be thought of as an upstream link on the virtual Ethernet switch. In addition to providing a "port" for the host, the tap interface can be bridged to a physical Ethernet port on the host, allowing the guests to access the host's connected LAN.
Networking services such as DHCP and DNS must be provided either by the host or by the host's connected LAN.
Support for the tap device was developed on NetBSD, but should also work on FreeBSD, OpenBSD, and Linux hosts.
The easiest way to enable tap device networking is to use the -L command line option, e.g.:
gxemul -e 3max -L /dev/tap0 -d nbsd_pmax.img
Here is a simple example of how to enable it when using configuration files:
! Configuration file for
! virtual Ethernet switch networking
! using a tap device.
net(
tapdev("/dev/tap0")
)
machine(
name("guest machine")
type("dec")
subtype("5000/200")
! Add a disk, etc.
)
Before starting the emulator, you will need to create the tap interface on the host. Here is an example for NetBSD:
# ifconfig tap0 create up
If you wish to simply network the host and the guests together, then simply assign an IP address to the tap interface on the host:
# ifconfig tap0 10.0.0.254
You can now run a DHCP server on the host for the guests, or you can configure the guests manually.
If instead you would like to bridge to the host's connected LAN, Here is an example for NetBSD:
# ifconfig bridge0 create up # brconfig add tap0 add wm0
Although it is possible to have more than one machine per configuration file, I strongly recommend against it. Please use one configuration file for one emulated machine. Each configuration file must have a unique tap instance, and machines in separate configuration files must use bridged tap devices if they wish to communicate with each other as if on the same LAN.
(The section above is written by Jason Thorpe.)
The way to emulate a network of multiple emulated machines, whether they are actually running on the same physical host, or on multiple hosts, is to use configuration files, and the "direct-access" method of networking.
Although it is possible to have more than one machine per configuration file, I strongly recommend against it. Please use one configuration file for one emulated machine.
Here is a simple example:
! Configuration file for a
! "client" machine, netbooting
! of another machine.
net(
local_port(15000)
add_remote("localhost:15001")
)
machine(
name("client machine")
serial_nr(1) ! 10.0.0.1
type("sgi")
subtype("o2")
load("netbsd-GENERIC32_IP3x.gz")
)
|
! Configuration file for the
! "server" machine.
net(
local_port(15001)
add_remote("localhost:15000")
)
machine(
name("nfs server")
serial_nr(2) ! 10.0.0.2
type("dec")
subtype("3max")
disk("nbsd_pmax.img")
)
|
This example creates a network using the default settings (10.0.0.0/8), but it also uses the direct-access networking mode to allow the network to be connected to other emulator instances. local_port(15000) means that anything coming in to UDP port 15000 on the host is added to the network. All ethernet packets on the network are also sent out to all other connected machines (those added with add_remote()).
As you can see in the example, this is a configuration file for netbooting a NetBSD/sgimips diskless machine, with a NetBSD/pmax machine acting as the nfs server. Note that the nfs server has ports 15000 and 15001 reversed, compared to the client!
"localhost" can be changed to the Internet hostname of a remote machine, to run the simulation across a physical network.
NOTE: There is no error checking or security checking of any kind. All UDP packets arriving at the input port are added to the emulated ethernet. This is not very good of course; use this feature at your own risk.
The most basic example of how the simple direct-access system works is a small program in the experiments/ directory, udp_snoop, which simply dumps incoming UDP packets to the terminal, in hex and ASCII.
The easiest way to test the example is to download a NetBSD/pmax INSTALL kernel, and start the emulator with a configuration file looking something like this:
net(
add_remote("localhost:12300")
)
machine(
subtype(3max)
load("netbsd-INSTALL.gz")
)
In addition to the machine section, you can see that there is also a net() section. It defaults to emulating a 10.0.0.0/8 IPv4 NATed network, but there is also an additional "raw output", to UDP port 12300.
Now, do the following:
This should be enough to see broadcast messages from the guest OS which are not directed to the gateway. It might look like this:
$ ./udp_snoop 12300 ff ff ff ff ff ff 10 20 30 00 00 10 08 06 00 01 ....... 0....... 08 00 06 04 00 01 10 20 30 00 00 10 0a 00 00 02 ....... 0....... 00 00 00 00 00 00 0a 00 00 02 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 ............ 33 33 ff 00 00 10 10 20 30 00 00 10 86 dd 60 00 33..... 0.....`. 00 00 00 20 00 01 00 00 00 00 00 00 00 00 00 00 ... ............ 00 00 00 00 00 00 ff 02 00 00 00 00 00 00 00 00 ................ 00 01 ff 00 00 10 3a 00 01 00 05 02 00 00 83 00 ......:......... 80 83 00 00 00 00 ff 02 00 00 00 00 00 00 00 00 ................ 00 01 ff 00 00 10 ...... ...