You are reading it now, and it is available from wherever you are reading it :-) but its canonical location is https://www.liminix.org/doc/

Liminix source code is held in git, and hosted at https://gti.telent.net/dan/liminix, with a mirror at https://github.com/telent/liminix. You can clone from either of those repos. For more on this, see Contributing.

There is an IRC channel #liminix registered on the OFTC network, which is a good place to ask if you want a quick answer about how to use Liminix or are looking at a new port. Be mindful that other participants may be in different timezones than your own, so do not expect an immediate answer.

Three Liminix mailing lists are available: all are quite low volume. To subscribe to any of these lists, send an email to listname+subscribe@liminix.org. You can write anything you want in the subject and message body: only the destination address is important.

The mailing lists are managed with Mlmmj and archived with MHonArc.

Liminix is dedicated to providing a harassment-free experience for everyone. We do not tolerate harassment of participants in any form.

The Liminix Code of Conduct applies to all Liminix spaces, including the IRC channel, mailing lists, and any other forums, both online and off. Anyone who violates the code of conduct may be sanctioned or expelled from these spaces at the discretion of the project leadership.

You will need a reasonably powerful computer running Nix. Target devices for Liminix are unlikely to have the CPU power and disk space to be able to build it in situ, so the build process is based around "cross-compilation" from another computer. The build machine can be any reasonably powerful desktop/laptop/server PC running NixOS. Standalone Nixpkgs installations on other Linux distributions - or on MacOS, or even in a Docker container - also ought to work but are untested.

You can try out Liminix without even having a router to play with. Clone the Liminix git repository and change into its directory

Now build Liminix

In this command liminix-config points to the desired software configuration (e.g. services, users, filesystem, secrets) and device describes the hardware (or emulated hardware) to run it on. outputs.default tells Liminix that we want the default image output for flashing to the device: for the Qemu "hardware" it’s an alias for outputs.vmbuild, which creates a directory containing a root filesystem image and a kernel.

Now you can try it:

This starts the Qemu emulator with a bunch of useful options, to run the Liminix configuration you just built. It connects the emulated device’s serial console and the QEMU monitor to stdin/stdout.

You should now see Linux boot messages and after a few seconds be presented with a root shell prompt. You can run commands to look at the filesystem, see what processes are running, view log messages (in :file:/run/log/current), etc. To kill the emulator, press ^P (Control P) then c to enter the "QEMU Monitor", then type quit at the (qemu) prompt.

To see that it’s running network services we need to connect to its emulated network. Start the machine again, if you had stopped it, and open up a second terminal on your build machine. We’re going to run another virtual machine attached to the virtual network, which will request an IP address from our Liminix system and give you a shell you can run ssh from.

We use System Rescue in tty mode (no graphical output) for this example, but if you have some other favourite Linux Live CD ISO - or, for that matter, any other OS image that QEMU can boot - adjust the command to suit.

Download the System Rescue ISO:

and run it

System Rescue displays a boot menu at which you should select the "serial console" option, then after a few moments it boots to a root prompt. You can now try things out:

Congratulations! You have installed your first Liminix system - albeit it has no practical use and it’s not even real. The next step is to try running it on hardware.

For the next example, we’re going to install onto an actual hardware device. These steps have been tested using a GL.iNet GL-MT300A, which has been chosen for the purpose because it’s cheap and easy to unbrick if necessary.

You may want to read and inwardly digest the section on Serial connections when you start working with Liminix on real hardware. You won’t need serial access for this example, assuming it works, but it allows you to see the boot monitor and kernel messages, and to login directly to the device if for some reason it doesn’t bring its network up.

Now we can build Liminix. Although we could use the same example configuration as we did for Qemu, you might not want to plug a DHCP server into your working LAN because it will compete with the real DHCP service. So we’re going to use a different configuration with a DHCP client: this is examples/hello-from-mt300.nix

It’s instructive to compare the two configurations:

You’ll see a new boot.tftp stanza which you can ignore, services.dns has been removed, and the static IP address allocation has been replaced by a dhcp.client service.

This time in result/ you will see a bunch of files. Most of them you can ignore for the moment, but result/firmware.bin is the firmware image you can flash.

The third example examples/demo.nix is a fully-functional home "WiFi router" - although you will have to edit it a bit before it will actually work for you. Copy examples/demo.nix to my-router.nix (or other name of your choice) and open it in your favourite text editor. Everywhere that the text EDIT appears is either a place you probably want to change or a place you almost certainly need to change.

There’s a lot going on in this configuration:

Build it using the same method as the previous example

and then you can flash it to the device.

Footnotes

To speak to U-Boot on your device you’ll usually need a serial connection to it. This typically involves opening the box, locating the serial header pins (TX, RX and GND) and connecting a USB TTL converter to them.

The Rolls Royce of USB/UART cables is the FTDI cable, but there are cheaper alternatives based on the PL2303 and CP2102 chipsets - or you could even get creative and use the UART GPIO pins on a Raspberry Pi. Whatever you do, make sure that the voltages are compatible: if your device is 3.3V (this is typical but not universal), you don’t want to be sending it 5v or (even worse) 12v.

Run a terminal emulator such as Minicom on the computer at other end of the link. 115200 8N1 is the typical speed.

When you turn the router on you should be greeted with some messages from U-Boot, followed by the instruction to hit some key to stop autoboot. Do this and you will get to the prompt. If you didn’t see anything, the strong likelihood is that TX and RX are the wrong way around, or your computer is expecting flow control which the 3 wire connection does not provide. If you see garbage, try a different speed.

Interesting commands to try first in U-Boot are help and printenv.

You will also need to configure a TFTP server on a network that’s accessible to the device: how you do that will vary according to which TFTP server you’re using and so is out of scope for this document.

HINT: [tufted], a rudimentary TFTP server, is supplied with Liminix for development purposes. It may or may not fit your needs here.

Modules are a means of abstraction which allow "bundling" of configuration options related to a common purpose or theme. For example, the dnsmasq module defines a template for a dnsmasq service, ensures that the dnsmasq package is installed, and provides a dnsmasq user and group for the service to run as. The ppp module defines a service template and also enables various PPP-related kernel configuration.

Not all modules are included in the configuration by default, because that would mean that the kernel (and the Busybox binary providing common CLI tools) was compiled with many unnecessary bells and whistles and therefore be bigger than needed. (This is not purely an academic concern if your device has little flash storage). Therefore, specifying a service is usually a two-step process. For example, to add an NTP service you first add modules/ntp to your imports list, then you create a service by calling config.system.service.ntp.build { .... } with the appropriate service-dependent configuration parameters.

Merely including the module won’t define the service on its own: it only creates the template in config.system.service.foo and you have to create an actual service using the template. This is an intentional choice to allow the creation of multiple differently-configured services based on the same template - perhaps e.g. when you have multiple networks (VPNs etc) in different trust domains, or you want to run two SSH daemons on different ports. (For the background to this, please refer to the architecture decision record <adr/module-system>)

In Liminix a service is any kind of long-running task or process on the system, that is managed (started, stopped, and monitored) by a service supervisor. A typical SOHO router might have services to

(Some of these might not be considered services using other definitions of the term: for example, this L2TP process would be a "client" in the client/server classification; and enabling packet forwarding doesn’t require any long-lived process - just a setting to be toggled. However, there is value in being able to use the same abstractions for all the things to manage them and specify their dependency relationships - so in Liminix "everything is a service")

The service supervision system enables service health monitoring, restart of unhealthy services, and failover to "backup" services when a primary service fails or its dependencies are unavailable. The intention is that you have a framework in which you can specify policy requirements like "ethernet wan dhcp-client should be restarted if it crashes, but if it can’t start because the hardware link is down, then 4G ppp service should be started instead".

Any attribute in config.services will become part of the default set of services that s6-rc will try to bring up. Services are usually started at boot time, but controlled services are those that are required only in particular contexts. For example, a service to mount a USB backup drive should run only when the drive is attached to the system. Liminix currently implements three kinds of controlled service:

Secrets (such as wifi passphrases, PPP username/password, SSH keys, etc) that you provide as literal values in configuration.nix are processed into into config files and scripts at build time, and eventually end up in various files in the (world-readable) /nix/store before being baked into a flashable image. To change a secret - whether due to a compromise, or just as part of to a routine key rotation - you need to rebuild the configuration and potentially reflash the affected devices.

To avoid this, you may instead use a "secrets service", which is a mechanism for your device to fetch secrets from a source external to the Nix store, and create at runtime the configuration files and scripts that start the services which require them.

Not every possible parameter to every possible service is configurable using a secrets service. Parameters which can be configured this way are those with the type liminix.lib.types.replacable. At the time this document was written, these include:

To use a runtime secret for any of these parameters:

For example, given you had an HTTPS server hosting a JSON file with the structure

you could use a configuration.nix fragment something like this to make those keys visible to ssh:

There are presently two implementations of a secrets service:

Liminix services are built on s6-rc, which is itself layered on s6. Services are defined at build time in your configuration (see Services for information) and can’t be added to/changed at runtime, but to monitor events or diagnose problems you may need to inspect them on the running system. Here are some of the most commonly used s6,-rc commands:

s6-rc-up-tree brings up a service and all services that depend on it, except for any services that depend on a "controlled" service that is not currently running. Controlled services are not started at boot time but in response to external events (e.g. plugging in a particular piece of hardware) so you probably don’t want to be starting them by hand if the conditions aren’t there.

A service may be up or down (there are no intermediate states like "started" or "stopping" or "dying" or "cogitating"). Some (but not all) services have "readiness" notifications: the dependents of a service with a readiness notification won’t be started until the service signals (by writing to a nominated file descriptor) that it’s prepared to start work. Most services defined by Liminix also have a timeout-up parameter, which means that if a service has readiness notifications and doesn’t become ready in the allotted time (defaults 20 seconds) it will be terminated and its state set to down.

If the process providing a service dies, it will be restarted automatically. Liminix does not automatically set it to down.

(If the process providing a service dies without ever notifying readiness, Liminix will restart it as many times as it has to until the timeout period elapses, and then stop it and mark it down.)

If your system has a writable root filesystem (JFFS2, btrfs etc -anything but squashfs), we have mechanisms for in-places updates analogous to nixos-rebuild, but the operation is a bit different because it expects to run on a build machine and then copy to the host device using ssh.

To use this, build the outputs.updater target and then run the update.sh script it generates.

The update script uses min-copy-closure to copy new or changed packages to the device, then (perhaps) reboots it. The reboot behaviour can be affected by flags:

It doesn’t delete old packages automatically: to do that run min-collect-garbage, which will delete any packages not in the current system closure. Note that Liminix does not have the NixOS concept of environments or generations, and there is no way back from this except for building the previous configuration again.

Liminix is initially installed from a monolithic firmware.bin - and unless you’re running a writable filesystem, the only way to update it is to build and install a whole new firmware.bin. However, you probably would prefer not to have to remove it from its installation site, unplug it from the network and stick serial cables in it all over again.

It is not (generally) safe to install a new firmware onto the flash partitions that the active system is running on. To address this we have levitate, which a way for a running Liminix system to "soft restart" into a ramdisk running only a limited set of services, so that the main partitions can then be safely flashed.

For the most part, for common use cases, we hope that Liminix modules provide service templates for all the services you will need, and you will only have to pass the right parameters to build.

But if you’re reading this then our hopes are in vain. To create a custom service of your own devising, use the oneshot or longrun functions:

Services may have dependencies: as you see above in the cowsayd example, it depends on some service called config.services.lan, meaning that it won’t be started until that other service is up.

Modules in Liminix conventionally live in modules/somename/default.nix. If you want or need to write your own, you may wish to refer to the examples there in conjunction with reading this section.

A module is a function that accepts {lib, pkgs, config, ... } and returns an attrset with keys imports, options, config.

The NixOS manual section Writing NixOS Modules is a quite comprehensive reference to writing NixOS modules, which is also mostly applicable to Liminix except that it doesn’t cover service templates.

All of the NixOS module types are available in Liminix. These Liminix-specific types also exist in pkgs.liminix.lib.types:

In the future it is likely that we will extend this to include other useful types in the networking domain: for example; IP address, network prefix or netmask, protocol family and others as we find them.

Unless your changes depend on particular hardware devices, you may want to test your new/changed module with one of the emulated "devices" which runn on your build machine using the free QEMU machine emulator. They are

This means you don’t need to keep flashing or messing with U-Boot: it also enables testing against emulated network peers using QEMU socket networking, which may be preferable to letting Liminix loose on your actual LAN. To build,

This creates a result/ directory containing a vmlinux and a rootfs, and a shell script run.sh which invokes QEMU to run that kernel with that filesystem. It connects the Liminix serial console and the QEMU monitor to stdin/stdout. Use ^P (not ^A) to switch to the monitor.

If you run with --background /path/to/some/directory as the first parameter, it will fork into the background and open Unix sockets in that directory for console and monitor. Use nix-shell --run connect-vm to connect to either of these sockets, and ^O to disconnect.

How you get your image onto hardware will vary according to the device, but is likely to involve taking it apart to add wires to serial console pads/headers, then using U-Boot to fetch images over TFTP. The OpenWrt documentation has a good explanation of what you may expect to find on the device.

tufted is a rudimentary TFTP server which runs from the command line, has an allowlist for client connections, and follows symlinks, so you can have your device download images direct from the ./result directory without exposing /nix/store/ to the internet or mucking about copying files to /tftproot. If the permitted device is to be given the IP address 192.168.8.251 you might do something like this:

Now add the device and server IP addresses to your configuration:

and then build the derivation for outputs.default or outputs.mtdimage (for which it will be an alias on any device where this is applicable). You should find it has created

For a faster edit-compile-test cycle, you can build a TFTP-bootable image which boots directly from RAM (using phram) instead of needing to be flashed first. In your device configuration add

and then build outputs.tftpboot. This creates a file result/boot.scr, which you can copy and paste into U-Boot to transfer the kernel and filesystem over TFTP and boot the kernel from RAM.

You probably don’t want to be testing a device that might serve DHCP, DNS and routing protocols on the same LAN as you (or your colleagues, employees, or family) are using for anything else, because it will interfere. You also might want to test the device against an "upstream" connection without having to unplug your regular home router from the internet so you can borrow the cable/fibre/DSL.

bordervm is included for this purpose. You will need

You need to "hide" the Ethernet device from the host so that QEMU has exclusive use of it. For PCI this means configuring it for VFIO passthru; for USB you need to unload the module(s) it uses. I have this segment in my build machine’s configuration.nix which you may be able to adapt:

Then you can execute run-border-vm in a buildEnv shell, which starts up QEMU using the NixOS configuration in bordervm-configuration.nix.

Inside the VM

To configure bordervm, you need a file called bordervm.conf.nix which you can create by copying and appropriately editing bordervm.conf-example.nix

This section describes some Nix language style points that we attempt to adhere to in this repo. Some are more aspirational than actual.

The Nix code in Liminix is MIT-licenced (same as Nixpkgs), but the code it combines from other places (e.g. Linux, OpenWrt) may have a variety of licences. Copyright assignment is not expected: just like when submitting to the Linux kernel you retain the copyright on the code you contribute.

Automated builds are run on each push to the main branch. This tests that (among other things)

You can view the build output at https://build.liminix.org . The tests are defined in ci.nix.

Unfortunately there’s no (easy) way I can make my CI infrastructure run your code, other than merging it. But see Running tests for how to exercise the same code locally on your machine.

Sometimes you can add a package and it causes the image size to balloon because it has dependencies on other things you didn’t know about. Build the outputs.manifest attribute, which is a JSON representation of the filesystem, and you can run nix-store --query on it.

For development, the supported GL.iNet devices are all good choices if you can find them, as they have a builtin "debrick" procedure in the boot monitor and are also comparatively simple to attach serial cables to (soldering not required), so are lower-risk than some other devices.

For a more powerful device, something with an ath10k wireless would be the safe bet, or the Linksys E8450 which seems popular in the OpenWrt community.

This device is based on a 64 bit Mediatek MT7622 ARM platform, and is mostly feature-complete in Liminix but as of Dec 2024 has seen very little actual use.

The GL-MT300A is based on a MT7620 chipset.

For flashing from U-Boot, the firmware partition is from 0xbc050000 to 0xbcfd0000.

WiFi on this device is provided by the rt2800soc module. It expects firmware to be present in the "factory" MTD partition, so - assuming we want to use the wireless - we need to build MTD support into the kernel even if we’re using TFTP root.

The GL-MT300N-v2 "Mango" is is very similar to the gl-mt300a, but is based on the MT7628 chipset instead of MT7620. It’s also marginally cheaper and comes in a yellow case not a blue one. Be sure your device is v2 not v1, which is a different animal and has only half as much RAM.

This target produces an image for QEMU, the "generic and open source machine emulator and virtualizer".

MIPS QEMU emulates a "Malta" board, which was an ATX form factor evaluation board made by MIPS Technologies, but mostly in Liminix we use paravirtualized devices (Virtio) instead of emulating hardware.

Building an image for QEMU results in a result/ directory containing run.sh vmlinux, and rootfs files. To invoke the emulator, run run.sh.

The configuration includes two emulated "hardware" ethernet devices and the kernel mac80211_hwsim module to provide an emulated wlan device. To read more about how to connect to this network, refer to qemu-networking in the Development manual.

This target produces an image for the QEMU "virt" platform using a 64 bit CPU type.

ARM targets differ from MIPS in that the kernel format expected by QEMU is an "Image" (raw binary file) rather than an ELF file, but this is taken care of by run.sh. Check the documentation for the qemu target for more information.

This target produces an image for the QEMU "virt" platform using a 32 bit CPU type.

ARM targets differ from MIPS in that the kernel format expected by QEMU is an "Image" (raw binary file) rather than an ELF file, but this is taken care of by run.sh. Check the documentation for the QEMU (MIPS) target for more information.

This is a 32 bit ARMv7 MVEBU device, which is usually shipped with TurrisOS, an OpenWrt-based system. Rather than reformatting the builtin storage, we install Liminix on to the existing btrfs filesystem so that the vendor snapshot/recovery system continues to work (and provides you an easy rollback if you decide you don’t like Liminix after all).

The install process has two stages, and is intended that you should not need to open the device and add a serial console (although it may be handy for visibility, and in case anything goes wrong). First we build a minimal installation/recovery system, then we reboot into that recovery image to prepare the device for the full target install.

Zyxel NWA50AX is quite close to the GL-MT300N-v2 "Mango" device, but it is based on the MT7621 chipset instead of the MT7628.

type one of "fit", "uimage"

default

type one of "primary", "secondary"

default

type null or string

default

type one of "btrfs", "ext4", "jffs2", "squashfs", "ubifs"

default

type attribute set of s6-rc service

type function that evaluates to a(n) function that evaluates to a(n) anything

Busybox provides stripped-down versions of many usual Linux/Unix tools, and may be configured to include only the commands (termed "applets") required by the user or by other included modules.

These are attributes of the hardware not of the application you want to run on it, and would usually be set in the "device" file: devices/manuf-model/default.nix

type unsigned integer, meaning >=0

type unsigned integer, meaning >=0

default

type attribute set of anything

type signed integer

type string

type string

type string

type string

type strings concatenated with "\n"

default

type list of string

type path

default

type string

default

type boolean

default

type boolean

default

type signed integer

default

type one of "zimage", "uimage"

default

User- and group-related configuration.

Changes made here are reflected in files such as :file:/etc/shadow, :file:/etc/passwd, :file:/etc/group etc. If you are familiar with user configuration in NixOS, please note that Liminix does not have the concept of "mutable users" - files in /etc/ are symlinks to the immutable store, so you can’t e.g change a password with passwd

type attribute set of (submodule)

type signed integer

type list of string

default

type attribute set of (submodule)

type string

default

type string

example

default

type signed integer

type list of string

default

type string

default

type signed integer

Allows creation of Layer 2 software "bridge" network devices. A common use case is to merge together a hardware Ethernet device with one or more WLANs so that several local devices appear to be on the same network.

path modules/bridge/default.nix

This is for use if you have an IPv6-capable upstream that provides address information and/or prefix delegation using DHCP6. It provides a service to request address information in the form of a DHCP lease, and two dependent services that listen for updates to the DHCP address information and can be used to update addresses of network interfaces that you want to assign those prefixes to

path modules/dhcp6c/default.nix

This module includes a service to provide DNS, DHCP, and IPv6 router advertisement for the local network.

path modules/dnsmasq/default.nix

Provides a service to create an nftables ruleset based on configuration supplied to it.

path modules/firewall/default.nix

Hostapd (host access point daemon) enables a wireless network interface to act as an access point and authentication server, providing IEEE 802.11 access point management, and IEEE 802.1X/WPA/WPA2/EAP Authenticators. In less technical terms, this service is what you need for your Liminix device to provide a wireless network that clients can connect to.

If you have more than one wireless network interface (e.g. wlan0, wlan1) you can run an instance of hostapd on each of them.

path modules/hostapd/default.nix

path modules/ifwait/default.nix

Mount

Mount filesystems

path modules/mount/default.nix

Basic network services for creating hardware ethernet devices and adding addresses

path modules/network/default.nix

A network time protocol implementation so that your Liminix device may synchronize its clock with an accurate time source, and optionally also provide time service to its peers. The implementation used in Liminix is Chrony

path modules/ntp/default.nix

ppoe (PPP over Ethernet) provides a service to address the case where your Liminix device is connected to an upstream network using PPPoE. This is typical for UK broadband connections where the physical connection is made by OpenReach ("Fibre To The X") and common in some other localities as well: check with your ISP if this is you.

l2tp (Layer 2 Tunelling Protocol) provides a service that tunnels PPP over the Internet. This may be used by some ISPs in conjunction with a DHCP uplink, or other more creative forms of network connection

path modules/ppp/default.nix

Secrets

path modules/secrets/default.nix

Provide SSH service using Dropbear

path modules/ssh/default.nix

path modules/uevent-rule/default.nix

Virtual LANs give you the ability to sub-divide a LAN. Linux can accept VLAN tagged traffic and presents each VLAN ID as a different network interface (eg: eth0.100 for VLAN ID 100)

Some Liminix devices with multiple ethernet ports are implemented using a network switch connecting the physical ports to the CPU, and require using VLAN in order to send different traffic to different ports (e.g. LAN vs WAN)

path modules/vlan/default.nix

Watchdog

Enable hardware watchdog (for devices that support one) and feed it by checking the health of specified critical services. If the watchdog feeder stops, the device will reboot.

path modules/watchdog/default.nix

This creates an image called firmware.bin suitable for squashfs or jffs2 systems. It can be flashed from U-Boot (if you have a serial console connection), or on some devices from the vendor firmware, or from Liminix when using levitate

If you are flashing from U-Boot, the file flash.scr is a sequence of commands which you can paste at the U-Boot prompt to to transfer the firmware file from a TFTP server and write it to flash. Please read the script before running it: flash operations carry the potential to brick your device

This output is intended for developing on a new device. It assumes you have a serial connection and a network connection to the device and that your build machine is running a TFTP server.

The output is a directory containing kernel and root filesystem image, and a script boot.scr of U-Boot commands that will load the images into memory and run them directly, instead of first writing them to flash. This saves time and erase cycles.

It uses the Linux phram driver to emulate a flash device using a segment of physical RAM.

table: 0x8d8ba0

table: 0x8d8ba0

This output provides a UBIFS filesystem image and a small U-Boot script to make the manual installation process very slightly simpler. You will need a serial connection and a network connection to a TFTP server containing the filesystem image it creates.

In this case the important value is ubi0

Expect there to be existing volumes and for some or all of them to be important. Unless you know what you’re doing, don’t remove anything whose name suggests it’s related to uboot, or any kind of backup or recovery partition. To see how much space is free:

Now we can make our new root volume

3) transfer the root filesystem from the build system and write it to the new volume. Paste the contents of result/flash.scr one line at a time into U-Boot:

Now we have the root filesystem installed on the device. You can even mount it and poke around using ubifsmount ubi0:liminix; ubifsls /

4) optional: before you configure the device to boot into Liminix automatically, you can try booting it by hand to see if it works:

Once you’ve done this and you’re happy with it, reset the device to return to U-Boot.

5) Instructions for configuring autoboot are likely to be very device-dependent and you should consult the Liminix documentation for your device. (If you’re bringing up a new device, some detective work may be needed. Try running printenv and trace through the flow of execution from (probably) $bootcmd and look for a suitable variable to change)

updater

For configurations with a writable filesystem, create a shell script that runs on the build system and updates the device over the network to the new configuration

This target is for use with the qemu, qemu-aarch64, qemu-armv7l devices. It generates an executable run.sh which invokes QEMU. It connects the Liminix serial console and the QEMU monitor to stdin/stdout. Use ^P (not ^A) to switch between monitor and stdio.

If you call run.sh with --background /path/to/some/directory as the first parameter, it will fork into the background and open Unix sockets in that directory for console and monitor. Use nix-shell --run connect-vm to connect to either of these sockets, and ^O to disconnect.

Liminix VMs are networked using QEMU socket networking. The default behaviour is to connect

Refer to border-network-gateway for details of how to start an emulated upstream on the "access" network that your Liminix device can talk to.