# GXemul: Networking

Back to the index.

- Introduction
- Network across multiple hosts
- Direct-access example 1: udp_snoop

### Introduction:

GXemul's current networking layer supports two modes:

1. A NAT-like 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.

2. A direct-access layer, allowing external tools to read/write raw ethernet packages from/to the emulator.

NOTE: Both these modes have problems. 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.) Because of the obvious limitations with the NAT approach, I have also included support for direct packet access, but this is not designed for security or anything like that.

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`, Turbochannel Lance Ethernet, as used in DECstation 5000/200 ("3max")
- `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.

If you are impatient, and simply want to try out networking in GXemul, I would recommend trying out an ftp install of NetBSD/pmax.

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

### Direct-access example 1: 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                                ......
    	...