# GXemul: Networking

Back to the index.

- Introduction
- Virtual Ethernet switch using a tap device
- Network across multiple hosts
- UDP "Direct-access" example: udp_snoop

### Introduction:

GXemul's current networking layer supports three modes:

1. A virtual Ethernet switch built on top of a tap device.

2. A NAT-like emulation layer, which allows guest OSes to access the outside internet world (IPv4 only, so far). When only one machine is being emulated, the following default values apply to the guest OS:

       	IPv4 address:			10.0.0.1
       	Netmask:			255.0.0.0
       	Gateway / default route:	10.0.0.254
       	Nameserver:			10.0.0.254

   To 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.

3. A UDP mode, allowing external tools to read/write raw ethernet packages from/to the emulator via UDP.

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:

- `dec21143`, Digital's 21143 PCI NIC (known as `dc` in OpenBSD, or `tlp` in NetBSD)
- `ether`, the "fake" experimental ethernet device (documented here)
- `le`, Lance Ethernet, as used in DECstation 5000/200 ("3max") and the LUNA88K machines
- `mec`, the SGI O2's ethernet controller

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.

### Virtual Ethernet switch using a tap device:

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.)

### Network across multiple hosts:

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.

### UDP "Direct-access" example: udp_snoop:

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:

- Start the emulator with the configuration file, i.e. `gxemul @testconfig`.
- Start `udp_snoop 12300` in another terminal.
- Inside emulated NetBSD/pmax, type `ifconfig le0 10.0.0.1`.

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                                ......
    	...