“Stuck in a rut without broadband? We shine the spotlight on the RUT-240.”
Jay configures the RUT-240 as an LTE - Ethernet bridge, and reviews it in the process
Routing 4G cellular data to a BSD network using bridge mode on the RUT-240
Note: During the preparation of this article, Exotic Silicon discovered a low severity security bug in this device.
We contacted Teltonika Networks regarding this issue, but did not receive a response within 48 hours.
Since most configurations are not affected, and a workaround is available, we have prepared a page with details of this bug.
Update 20230519: The above vulnerability has been assigned CVE-2023-31728, and is fixed in firmware version 07.04.2. For more details see our resolution follow-up page.
The RUT-240 from Teltonika networks is a small and fairly inexpensive 4G router which is commonly used to provide internet connectivity for remote devices that are either in locations without regular fixed-line broadband, or where high availability is required.
Think smart meters, monitoring systems, and so on.
In the case of high availability, the RUT-240 is connected in line with a conventional internet router, and it's own cellular connection is only used when a lack of connectivity is detected.
Both of these configurations often involve the use of a special SIM card, to which the cellular operator has provisioned a static, public IP address, thus allowing inbound connections to the connected remote devices, (as well as access to the router itself for configuration and admin purposes).
Well, today we're going to use our RUT-240 for a completely different purpose. No special SIM required, and we're not going to be travelling out in to the wilds either. Just a regular pre-paid SIM, and the normal office surroundings.
Instead, we'll be exploring the use of this router as a backup connection for an existing OpenBSD-based router, or even - within limits - as a replacement for fixed line broadband. This latter option might make sense on a short term basis in a new office that hasn't been fully connected yet, or in a temporary office in an awkward location where DSL or fibre isn't available. Attending a conference, but all the decent hotels are fully booked? Stuck on a boat in dry dock? Not a problem!
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.
As a bonus, although operating in bridge mode obviously means that we lose access to a lot of the router's capabilities, it's still possible to use the SMS sending and receiving functions, as well consult the logs of signal strength and configure the cellular data side of things from it's web interface.
Dongles - not a good alternative
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.
This is not always the case when using a dongle. Whilst many are reliable enough for ad-hoc connectivity on a laptop on the move, continuous use in a server or router application is something quite different. A lot of these USB dongle devices also have odd quirks such as not supporting IPv6, but in many cases the biggest problem is that they don't support the use of external antennas. If relying on a trace on a dongle circuit board as an antenna wasn't bad enough, unless you want to put the device on the end of a long USB extension cable, that sorry excuse for an antenna will be located a few centimetres away from wherever the server's USB socket is.
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.
For example, CVE 2022-45934 which involves the kernel bluetooth stack is unlikely to be a concern on a device such as the RUT-240 which doesn't include bluetooth hardware, (although note that some other routers from Teltonika networks do include bluetooth functionality).
Product lifecycle and replacement
As of Q1 2023, the RUT-240 that we are looking at today has now entered end of life, having been on the market since 2017.
This is really a non-issue, though, as a replacement product has already been announced - the RUT-241 - and in terms of features and functionality, this new device is almost identical to the RUT-240.
Obviously for new deployments the RUT-241 should now be considered instead, if only on the basis that it will almost certainly receive software updates well beyond the point when the RUT-240 no longer does.
However, it's worth pointing out that running either device in bridge mode can potentially mitigate any future security flaws that might be discovered. Given that bridge mode disables a lot of internal features, certain blocks of code where vulnerabilities could lie will simply never get the chance to run.
A look at the hardware
Supported frequency bands
The RUT-240 is available in several regional variations. These each use slightly different modems and offer compatibility with the frequency bands commonly used in different regions of the world.
The unit we are using today is actually the global version, which supports the widest range of frequencies. As a research organisation, this gives us the maximum flexibility for our needs. However, in regular use it should be sufficient to ensure that your unit supports the bands that your chosen operator uses, or at least some of them.
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.
The pin which is supplied to eject the SIM tray is also quite useful for pressing the reset button, although doing so is slightly cumbersome when the antennas are connected.
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.
It's worth noting that the WAN socket can be re-purposed as a second LAN socket, allowing us to connect two local devices directly to the RUT-240.
Good quality SIM adaptors
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.
Perhaps not an issue in the office, but a potential timesaver if the device is located in a remote location that's not easily accessible.
Thoughts on the web interface
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.
The GUI isn't particularly demanding of the browser, and works well when accessed using surf. It's somewhat navigable from the keyboard, with form elements being tabbed to in a sensible order and in most cases having a clearly visible outline indicating focus. Unfortunately, the main menu items on the left are not accessible via tabbing, but overall it's reasonably good.
Our desired configuration
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).
Of course, the DHCP server won't be allocating addresses from it's own private pool, but instead will just be handing the single address it has to the first machine that asks for it, (or we also have the option to set a specific MAC address to receive it). For IPv6, the RUT-240 will take exactly one or two addresses for itself, but otherwise just announce the whole /64 prefix.
Multiple local devices when operating in bridge mode
Of course, it's physically possible to connect more than one local device to the RUT-240, either by re-purposing the WAN socket or using a switch connected to the LAN interface. We can even simulate this configuration to a degree without extra hardware by simply changing the MAC address of the single device that we have connected.
If we do try to obtain a second IPv4 address from the RUT-240 via DHCP whilst it is in this bridge configuration, it will indeed assign us an IPv4 address from the private network range. However, this address will not provide any connectivity to the internet as it will not be NAT'ed, and can only be used to talk to the RUT-240 itself, or possibly another machine on the LAN. In other words, it's un-routable, or locally scoped.
This will also happen if there is no cellular network connectivity at the moment that the single OpenBSD machine we have connected requests it's IP addresses.
For IPv6, this issue of unroutable addresses from a private range doesn't really exist, as we almost always have a large subnet to allocate various global addresses from and can therefore fully support multiple locally connected devices even when in bridge mode. Clients that connect via IPv6 are also configured with a unique local address from the fd00::/8 range, in fact many clients will configure two, a normal address and a temporary one as per RFC 8981.
So yes, this can mean that you end up with five IPv6 addresses, the link-local address, two ULAs, and two global IPs.
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 IPv6 subnet provisioned by the ISP will be announced by the RUT-240 via slaac, it will take a couple of addresses for itself, and we will get a couple of global IPv6 addresses assigned to the network adaptor in the OpenBSD machine. We'll also get IPv6 ULA addresses assigned to both devices with an fd00::/8 prefix.
Configuration on the OpenBSD router side
On the OpenBSD machine, the configuration for the network card is about as simple as it could get:
description "4G router"
The description is just an arbitrary string that is displayed in the output of ifconfig and helps to identify this particular interface.
To receive our IP address allocations we need to ensure that dhcpleased and slaacd are both running, although obviously if your cellular ISP has been asleep for the last twenty years and doesn't provide IPv6, (shame on them!), then slaacd will not be necessary.
If we want to automatically configure the use of the DNS resolvers indicated by the ISP, then we will also need to be running resolvd.
However, note that in most cases this is not absolutely necessary. It's perfectly possible to avoid running resolvd altogether and simply add the required nameserver directives to /etc/resolv.conf. These could be open, public DNS resolvers, or alternatively we could run resolvd just once to discover the addresses of the ISP's own resolvers and add them to /etc/resolv.conf, at which point as long as we don't expect them to change, resolvd doesn't need to run anymore.
Note that when using resolvd to configure DNS, the router not only supplies the IPv4 DNS from the ISP, but also supplies it's own IPv6 ULA, in other words an fd00::/8 address. Like most routers, the RUT-240 can act as a DNS resolver and in fact we could just configure it's private IPv4 address, (usually 192.168.1.1), as a nameserver in /etc/resolv.conf.
The problem here, as we will see shortly, is that we likely want to have a firewall rule on the RUT-240 blocking access to it's IPv6 endpoint addresses from the WAN. Since the cellular and LAN interfaces are bridged, this same rule also blocks access to it's IPv6 endpoint addresses, making this nameserver entry in /etc/resolv.conf inoperable.
A workaround is to add a separate pass rule to the firewall on the RUT-240, not based on zone, (which won't work), but based on the MAC address of the OpenBSD machine.
Either that, or just configure static DNS entries.
The simple configuration described above will get us dual stack connectivity to the internet on the local machine. Routing of this to other machines on the LAN will obviously require further configuration which is highly dependent on your local network setup, and beyond the scope of this article.
Configuring the RUT-240
No SIM yet!
Install the SIM after configuring the device
Initially, we won't insert a SIM in to the device, as we don't want it to connect to the cellular network until we've updated the firmware and made some changes to it's configuration.
For this demonstration we're using a brand new and previously unconfigured RUT-240, which is starting out with it's factory default settings and an old firmware version.
Connecting the router and first boot
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:
em0: flags=a48843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,AUTOCONF6TEMP,AUTOCONF6,AUTOCONF4> mtu 1500
Theoretically the router is accessible using the default login credentials by anyone who can pick up the signal and deduce the wifi password.
To be fair, in practice the NWID and wifi password are unique and are etched on to the bottom of the unit. We also note that, whilst our unit is an older one which had a fixed default username and password of admin/admin01, Teltonika Networks released a product change notification on 20220818 informing that new RUT-240 units would be shipped with a unique default password, which also goes a long way to mitigating this issue.
However we would still prefer to see WIFI functionality disabled by default, because if an as-yet unknown vulnerability exists in the network stack, webserver, or ssh daemon then access without the correct credentials might indeed be possible.
Having an access point enabled is a bad default configuration, as it creates a small but real window of opportunity for anybody to connect to the device remotely before we have had a chance to correctly secure it.
Disabling the default accesspoint
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.
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.
We need to click the slider on the right, but then also select save and apply. If we don't save and apply, but instead just click on to the interface configuration dialogue, the interface still shows as being on.
At this point, presumably due to changing the network configuration, we lost our dynamically assigned IPv4 address on the test system.
This is no big deal, we can simply down and up the interface on the OpenBSD machine or even just set our own static IP address of, say, 192.168.1.2 for use during this initial setup until we are ready to receive an IPv4 address from the ISP.
Disabling Remote Management Services
Back at the Status / Overview page, we can switch the web GUI to advanced mode using the toggle at the top of the screen, to see all of the available options, and also verify that our WIFI interface is, indeed, disabled.
Next, we want to disable RMS, or Remote Management Services, in the Services / Cloud solutions / RMS menu. Here we change connection type from enabled to disabled.
Tweaking the web interface visuals
If you've been enjoying the fresh and breezy visuals of the web interface, be prepared for a potential disappointment. The new firmware changes the look of the menu on the left from being light blue and unobtrusive, to being a dark blue. The icons are also slightly different.
More importantly the font size in the right hand pane is now smaller than it was before, with more empty space around the various elements.
The good news is that the CSS for the web interface is easily modifyable. The relevant files are in /www/css, and you can either create a whole new custom color scheme and layout from scratch or just make the desired modifications to the existing files.
Updating the firmware
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.
We've never bricked a RUT-240 by doing a firmware upgrade. However, the process does take slightly longer than might be expected, so just be patient and whatever you do, don't power cycle the device whilst the firmware update is in progress!
Now we can log in to the device again, and we will be using the new firmware.
Disabling the WAN interface
Although not particularly necessary, since we are not going to be using the WAN socket we can disable this interface in the Network / Interfaces / General menu.
Configuring the cellular interface
At this point, we're ready to configure the cellular interface, mob1s1a1. This is surprisingly straightforward, and also done from the Network / Interfaces / General menu.
In general settings:
Change mode from NAT to bridge
Change PDP type from IPv4 to IPv4/IPv6
In advanced settings:
Change use builtin IPv6 management from on to off
That's it for the mob1s1a1 interface settings!
Configuring the LAN interface
In general settings:
Leave all setting as their defaults
In advanced settings:
Change use built in IPv6 management from on to off
The general setup and advanced settings don't need to be changed from the defaults
Under IPv6 settings, we change Router Advertisement Service from disabled to server
IPv6 suffix - a useful option
The value that we put in the IPv6 suffix field will be used by the RUT-240 to construct it's own, or more accurately one of it's own, global IPv6 addresses.
Our ISP will most likely give us a /64 prefix, meaning that the first 16 hex digits of our global IPv6 addresses are determined by the ISP. If we don't specify a value here, then the RUT-240 will simply fill in the lower 16 hex digits to create a global IPv6 address for itself. This IPv6 address can be used to make inbound connections to the device, and even if we don't want to enable remote management it's still useful to be able to ping the RUT-240 remotely to check that it's alive.
The advantage of specifying a value here, such as ::1234, is that as well as creating it's own address, the RUT-240 will create a second one using this value for the lower 64 bits. The upshot of all this is that instead of trying to remember and accurately type an IPv6 address containing 32 hex digits, we only need to concern ourselves with the /64 prefix that the ISP supplies, and the short suffix that we define here, (which could even be just a single digit).
So in simple terms, set IPv6 suffix to something like ::FF or ::1234 in order to give the RUT-240 an almost static IPv6 address, that's almost as easy to remember and type in as an IPv4 address.
Adding a new firewall rule
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:
Add type: open ports on router
Name: bitbucket1, (obviously this can be anything you like)
External port: 22, (we'll change this to 'all' in a moment, but we need to put something here for now)
With these filled in, select 'add', (not 'save and apply'). Now we get to the full dialogue for editing the rule we just added.
Change restrict to address family from IPv4 and IPv6 to IPv6 only
Change source zone from wan to any zone (forward)
Destination zone should already be device (input)
Change destination port from 22 to any by deleting 22
Change action from accept to either reject or block depending on your preference
Now we can, 'save and apply', and the rule has been successfully added.
Firewall ruleset editing interface
If you are accustomed to editing /etc/pf.conf on an OpenBSD machine, then be aware that the firewall rules in the web interface of the RUT-240 are parsed from top to bottom, and the first matching rule is followed.
It's basically the equivalent of having every rule in /etc/pf.conf set to 'quick'.
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:
em0: flags=a48843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,AUTOCONF6TEMP,AUTOCONF6,AUTOCONF4> mtu 1500
Now we are finally ready to insert a SIM into the RUT-240.
Inserting the SIM
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:
em0: flags=a48843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,AUTOCONF6TEMP,AUTOCONF6,AUTOCONF4> mtu 1500
What's more, the connection is alive and fully working!
# ping6 -c 5 exoticsilicon.com
PING exoticsilicon.com (2a03:6000:6f64:639::8): 56 data bytes
64 bytes from 2a03:6000:6f64:639::8: icmp_seq=0 hlim=48 time=279.370 ms
64 bytes from 2a03:6000:6f64:639::8: icmp_seq=1 hlim=48 time=255.801 ms
64 bytes from 2a03:6000:6f64:639::8: icmp_seq=2 hlim=48 time=277.944 ms
64 bytes from 2a03:6000:6f64:639::8: icmp_seq=3 hlim=48 time=237.905 ms
64 bytes from 2a03:6000:6f64:639::8: icmp_seq=4 hlim=48 time=277.776 ms
--- exoticsilicon.com ping statistics ---
5 packets transmitted, 5 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 237.905/265.759/279.370/16.451 ms
# telnet legacy1.exoticsilicon.com 25
Connected to legacy1.exoticsilicon.com.
Escape character is '^]'.
220-IPv4 is obsolete, please use IPv6 next time
220 mx2.exoticsilicon.com ESMTP
Of course the cellular connection has been brought up using automatic and likely non-optimal settings. It can be tweaked in Network / Mobile / General to select a particular mode, (such as 4G only), and frequency band.
Miscellaneous notes and observations
When making a lot of changes to the configuration, it occasionally happens that you get assigned an IPv4 address from the ISP but it isn't routable anywhere from the OpenBSD machine. Toggling the relevant interface down and back up on that machine is usually the quickest way to fix this.
If you ever lose contact with the RUT-240 via such an IP address set by DHCP, then set a static address of 192.168.1.2 on the interface temporarily to get back in.
After rebooting the RUT-240 from the web interface, sometimes the page needs to be refreshed manually otherwise it just sits there spinning.
A change of IP address will also require you to log in to the web GUI again, so it's well worth memorising the router admin password!
When the ISP assigns an IPv6 subnet, the router chooses an address for itself and displays it on the main web GUI page, (Status/Overview).
This address is active and responds to pings, even if RAS isn't set up to pass the configuration of the subnet to the host.
If the 'IPv6 suffix' value in the 'interfaces:lan/advanced settings' menu is set, an address will be created using it to specify the low bytes.
This address is not displayed on the Status/Overview page.
Whilst in bridge mode, the router firewall is only effective against it's own IPv6 addresses. Adding a firewall rule to block access to an IPv6 address assigned to another machine was ineffective, (which is pretty much as we would expect it to be in bridge mode).
SSH access to the RUT-240 using key authentication didn't work with an ed25519 key, nor with an ecdsa key, but did work with an older rsa key.
(Update 20230519: firmware version 07.04.3 adds support for using ed25519 and ecdsa keys.)
If you're looking for a 4G LTE router that you can use in the way we've seen today, the RUT-240 is a nice choice.
+Solid build quality, small footprint, and DIN rail mountable.
+Frequent firmware updates with comprehensive changelogs.
+Fully supports IPv6.
+Can be used in bridge mode as an LTE - Ethernet bridge.
+Comprehensive set of features when used in regular, non-bridge mode.
+Useful SMS handling features built-in.
+WI-FI support includes OWE and WPA-3, (with up to date firmware).
+Supports ed25519 keys and ecdsa keys for key-based authentication to ssh, (since firmware 07.04.3).
-Web interface isn't fully navigable without a pointing device.
-Default WIFI accesspoint configuration is not ideal.