So why are we looking specifically at the RUT-240? Well unlike many 4G routers, especially at this price point, the RUT-240 allows us to configure it in bridge mode. This means that we can pass the data connection from a cellular provider more or less straight through to the Ethernet port of another machine, without having any tedious NAT or IP masquerading in the way.

In other words, it looks to the next connected device very much like a wired broadband router that's operating as a simple modem.

This is pretty handy when our existing infrastructure is based on BSD machines and we already do any required routing, NAT or other munging of network packets on those.

To be fair, the RUTOS system of the RUT-240, (which is based on OpenWRT), is fairly nice and capable when operating in non-bridge mode, and for small uncomplicated networks it's certainly possible that you could get good results by using it in that way.

However, if we just want to drop an extra cellular connection in to our existing router setup for redundancy and have all of the familiar firewalling and logging options at our disposal, then bridge mode on the RUT-240 is the way to go.

In theory, we could avoid the need for a separate 4G router altogether, and use a cheap USB 4G dongle to get the same access to a cellular network from our BSD machine. Unfortunately, whilst this might seem like a good idea, in practice it has some disadvantages.

The RUT-240 will quite happily just sit there in bridge mode for weeks on end, reliably forwarding packets over a regular Ethernet connection, minding it's own business, and letting the device it's connected to do the same. Rebooting the connected machine doesn't affect the cellular connection, and if the link goes down then re-connecting will be mostly transparent.

The most up to date firmware available for the RUT-240 at the time of writing is RUT_2_R_00.07.04.1 from 20230324, and that is what we will be using in the configuration examples below.

In most cases you will want to use the most up to date firmware available, but in case you want to check for any differences in operation between that and the exact version we used to prepare the following examples, the hash for the firmware we are using is:

Since it's original launch, the RUT-240 has had plenty of firmware updates made available for it. It's worth noting that whilst the changelogs mention a fair number of security fixes, this is in part due to comprehensive reporting and fixing of low severity bugs.

The RUT-240 is a physically small device, suitable for use on a desk but also capable of being mounted on DIN rails.

In the box we get the unit itself, the power supply, three antennas, a set of sim card adaptors along with a pin to remove the sim tray, a network cable and some paperwork.

There are three external connections on the back for antennas, two SMA connectors for the cellular connectivity, and an RP-SMA connector for WI-FI. The antennas supplied with the unit are fairly basic, but they have worked acceptably well in our tests. A recessed reset button is also included on the rear panel.

On the front we have the power connector, sim tray, two Ethernet ports, and a few LEDs to indicate device status, cellular network type and signal strength. The power connector also doubles as a basic GPIO port for connection to other devices, providing one input and one output. A special break-out cable is available as an accessory if you want to make use of it.

The Ethernet ports are both 100baseT. Surprisingly this is true even on the newer RUT-241, where we might have expected to see gigabit or even 2500baseT wired connectivity even if only due to component availability rather than for performance reasons.

Of course, for the main intended purpose, 100baseT isn't exactly a limitation here. Typical uses of the RUT-240 involve connecting it to an existing wired internet connection via the WAN socket and passing that through to another device connected to the LAN side, with the possibility of routing traffic via 4G LTE if the wired WAN connectivity fails. In these cases, even if the connection between the existing devices was syncing at 1000baseT, (or beyond), then unless our actual internet connection can provide bandwidth in excess of 100 mbit then we don't really lose anything in terms of raw speed. Technically, latency might be worse, but the difference will be so small as to be lost in the noise compared to the extra latency created by the packet processing of the RUT-240.

In any case, our use of the device in bridge mode to pass 4G LTE connectivity directly over a single wired connection, neatly sidesteps this limitation. If our existing OpenBSD-based router does indeed have gigabit or faster connectivity to the internet, then it won't be affected by the connection of the RUT-240 to a separate network interface. Whilst the 4G LTE interface can theoretically provide 150 Mbit of bandwidth, in reality speeds above or even close to 100 Mbit are difficult to achieve.

The RUT-240 accepts a mini SIM, (I.E. the largest size in common use today).

The supplied SIM card adaptors for micro and nano SIMs are nicely made and much more sturdy than the flimsy pieces of plastic that result from pushing out a smaller size SIM from a multi-sized card. The supplied adaptors have clear plastic covering one side, so that a SIM can be placed on to them like a tray and will stay in place without relying on being a tight enough fit not to fall straight through.

Although our use of bridge mode will mean that we won't be spending a whole lot of time configuring RUTOS or making use of many of it's features, it's worth noting that using the web interface is a fairly tranquil and enjoyable experience.

In terms of physical hardware connections, our RUT-240 will be directly connected to a server running OpenBSD via a standard 100base-T Ethernet connection.

The SIM card that we intend to use in the RUT-240 is a regular, consumer-orientated, pre-paid SIM. This provides access to cellular data services over both IPv4 and IPv6, with a single dynamic IPv4 address and a /64 IPv6 subnet address block. The IPv4 address is subjected to CGNAT and therefore not a public IP, but the IPv6 block is publicly accessible, in other words it allows direct inbound connections.

We want to assign both the single IPv4 address and the IPv6 subnet to the server, with no further routing or address translation.

Since the IPs are not static but dynamically allocated, we need a way to automatically configure the addressing that has been provided to us by the cellular ISP on the OpenBSD machine. In the computer world, we would expect this to be done via DHCP for IPv4, and slaac for IPv6. DHCPv6 also exists as an alternative to slaac for the configuration of IPv6 connections, but since DHCPv6 is not natively supported by the OpenBSD base system we prefer to use slaac.

However, cellular data connections don't usually use DHCP and slaac over the air, but are instead more often than not brought up and configured using protocols specific to the cellular technology in use, (GPRS, 3G, 4G LTE, etc). A few ISPs have been known to assign IPv6 blocks using slaac, but this is uncommon.

The upshot of this is that whilst the RUT-240 won't have any difficulty configuring it's own IP addresses, we somehow need to pass that configuration information to our OpenBSD router. In other words, despite being in bridge mode we need the router to run a DHCP server, (for IPv4), and send router advertisements, (for IPv6).

In summary then, the IPv4 address supplied by the ISP will be allocated to our OpenBSD machine and the RUT-240 will also be sitting on the same network port on a IPv4 address from the private un-connected networks range, (typically 192.168.1.1). This gives us access to it's web-based user interface as well as ssh if we decide to enable it.

The description is just an arbitrary string that is displayed in the output of ifconfig and helps to identify this particular interface.

First, we'll connect the LAN socket on the RUT-240 to the network interface in the OpenBSD machine. In our case, the interface is em0.

The next step is to apply power, at which point the signal strength lights will flash on and off for about 60 seconds. After that, because we don't have a SIM in the RUT-240 yet and so there is obviously no cellular network connectivity, the 2G 3G and 4G lights will all flash on and off.

Up to this point, the output from ifconfig regarding the network interface that the RUT-240 is connected to on the OpenBSD machine would have shown no carrier, and been something like this:

Accordingly, the first task we will perform is to disable the WIFI functionality. We can easily do this from the web-based interface, which can be accessed at the IP address 192.168.1.1. Both plain http and https are supported, but be aware that since the RUT-240 uses a self-signed certificate you will likely see a certificate warning in your browser when accessing it over https.

The login page is simple enough, but does require javascript to be enabled. The first thing we are prompted to do is to set a new password. Set a strong password, but try to make it reasonably easy to remember because the chances are that you will need to enter it several times during the configuration process as some changes will invalidate our login session and require us to log in again.

We're then taken in to a setup wizard. We'll skip this and do the configuration manually, but first we'll take the opportunity to sync the clock with the browser, by clicking the 'sync with browser' button, as the RTC in the RUT-240 is almost certainly going to be incorrect if it's been left unused and in storage for an extended period of time.

After skipping the wizard, we're taken in to the main Status / Overview page. Here we can clearly see that the WIFI interface is enabled and up.

Clicking on the information icon i takes us to a configuration page where we can disable the interface.

Having got this far, we're now ready to upgrade the firmware to the latest version.

Since we're going to upgrade the firmware manually, we'll first disable FOTA firmware updates in System / Firmware / FOTA configuration. The relevant option is 'enable FOTA', and we can change it from the default of on to off.

Obviously we need to have downloaded the new firmware image ahead of time.

To actually upgrade the firmware, we go to System / Firmware / Update firmware, ensure that 'keep settings' is set to on so that we don't lose the configuration that we've already done, and click browse to select the firmware image in the local filesystem.

Note that as soon as you select the firmware image in the file selector, the upload to the RUT-240 begins automatically. Once the upload has completed, we're presented with some information about the new firmware image and asked if we want to go ahead with the upgrade, and since we do, we click proceed.

After about 15 seconds, the lights go out on the router. Then a few seconds later, the signal strength indicators start flashing in a left to right to left pattern, which is actually quite mesmerising. This lasts almost exactly 60 seconds.

Then the same five lights just start flashing on and off. This is somewhat less mesmerising, and even slightly worrying as it has the subtle suggestion that perhaps you've managed to brick the device. All this time, the web browser will still be showing the spinner and say upgrading.

If we look at the output of ifconfig on the connected OpenBSD machine during this time, it will initially show a data carrier and the IP address previously obtained. When the RUT-240 starts to boot in to the new firmware, the carrier will briefly disappear then come back, and a second or so later the previously assigned IP address will disappear. The ifconfig output will continue to show a carrier, but with no IP addresses assigned, (except the IPv6 link-local address).

After about another 2 minutes and 20 seconds, the five lights will stop flashing, and at this point the device has booted in to the new firmware.

The 2G 3G and 4G lights will flash as they did before, since we don't have a sim card in the device, and ifconfig will report that an IPv4 address in the 192.168.1.0/24 range has been assigned, (most likely the same one that we had before).

If the web browser continues to show the spinner at this point, refreshing the page should take us back to the login screen.

Next, we're going to add a firewall rule blocking all traffic to the IPv6 addresses of the RUT-240 itself.

This shouldn't be necessary, but due to the firmware issue we discovered during the preparation of this article and which is discussed below, it's advisable to add this rule if you are running the RUT-240 in bridge mode with an IPv6 capable cellular connection.

The required page of the web interface is Network / Firewall / Traffic rules.

First disable all pre-existing rules that are enabled by default. We don't need any of them if we are operating in bridge mode.

Next, add a new rule. The web configuration interface is a bit unusual here, in that we have to fill in a few fields in order to add a new rule, and then a more complete dialogue opens where we can set the values that we actually want. Select the following options:

With these filled in, select 'add', (not 'save and apply'). Now we get to the full dialogue for editing the rule we just added.

At this point, if we check the output of ifconfig on the OpenBSD machine, we should see that IPv6 ULA addresses have been assigned to the interface:

We can monitor the status of the cellular connection in Status / Network / Mobile. Currently this is rather empty and boring, showing us little more than our IMEI and the fact that no sim is inserted.

Shortly after inserting the SIM, (on our test system it took about eight seconds), the display will change to show that a connection has been made to the cellular network. We can see the name of the operator, network type, ID of the cell that we are connected to, signal strength, and more.

Looking at the output from ifconfig, we can see that global IP addresses have been assigned: