Vivacom's Mobix dual-stack (IPv4/IPv6) LTE router configuration for LTE routers running OpenWRT

This document demonstrates the configuration of a dual-stack (IPv4/IPv6) subscription to Viacom service "Mobix" (Internet home access over LTE) on OpenWRT LTE routers.

Vivacom, which is valid for any other LTE operator in the vicinity, provides its customers outside the big cities with 4G/LTE home routers. They are not without their disadvantages. The biggest disadvantage is the low speed you get if your location is not well covered. Even mounting an external antenna to the router doesn't make the speed go up if the device resides inside a building. Furthermore, the RTT average fluctuates a lot, resulting in a dreadful SSH shell-typing encounter.

The only viable approach to resolving the issues associated with the RTT deviation is to procure a superior 4G/LTE router running OpenWRT that is capable of supporting MIMO. You might also want to get an external MIMO antenna to improve the router's reception and transmission capabilities.

Another benefit of using OpenWRT-based 4G/LTE routers is the possibility of obtaining an IPv6 /64 Internet connectivity for the devices connected to your home network. Vivacom operates a dual-stack IPv4/IPv6 network. It assigns to the external network interface of the customer's LTE router one public IPv4 address and one IPv6 address if the router supports IPv6 subscription. Furthermore, that router is assigned a /64 IPv6 address segment for addressing devices within the internal (home) network. That's a significant step forward in implementing IPv6 at the end-user level. Sadly, most of the routers given to customers are incapable of performing IPv6 LTE subscriptions. The latter is yet another reason to buy and adopt modern OpenWRT LTE routers at home.

The LTE OpenWRT routers provided by Teltonika are very robust and durable devices. I like those devices because they are easy to manage and do not heat up. What I have at home is a pair of RUT-series LTE routers:

RUT241

RUT901

Below, I'm showing how to set up RUT241, but the same procedure works for RUT901. Both have what you need to work with MIMO and IPv6 LTE subscriptions. Note that they are equipped with MIMO antennas by default. If you have a place to mount the antennas, you may want to consider using outdoor LTE antennas to increase signal reception and transmission efficiency. I use this one:

MIMO 4G/5G Log Periodic Antenna

Insert the SIM card into the router and switch it on. Use a browser to connect to the router and set it up initially (if the setup is not done already). Go to "Network" > "Mobile" and set there manually B3 frequency band (that band provides better coverage and higher speed):

Then go to "Status" > "Overview" and set there a profile that uses the "mobix-static" APN (it provides the static IPv4/IPv6 address subscription). In the web interface, go to "Network" > "WAN" and edit the settings for the network interface mob1s1a1. Select "Custom" from the "APN" dropdown menu, then type "mobix-static" into the "Custom APN" text box. Press the "SAVE & APPLY" button to save and apply those settings:

At that moment, the LTE router will re-subscribe to Vivacom's network and obtain its static public IPv4 address. No IPv6 address will be configured at this time. To configure the IPv6 subscription, you need to use the command-line interface for editing the dual-stack subscription settings (the web interface does not offer a menu for managing the IPv6 subscription). Use an SSH client to connect to the router. Then open the file /etc/config/networks and find the entry section for the interface mob1s1a1. Be sure the "pdtptype" is set to "ipv4v6". That's a must-have for requesting a dual-platform subscription. It is recommended that the option 'ipv6' be set to 1.

  config interface 'mob1s1a1'
        option proto 'wwan'
        option modem '1-1'
        option metric '2'
        option sim '1'
        option pdp '1'
        option username 'vivacom'
        option password 'vivacom'
        option auth 'pap'
        option pdptype 'ipv4v6'
        option force_apn '-1'
        option auto_apn '0'
        option apn 'mobix-static'
        option delegate '1'
        option force_link '0'
        option dhcpv6 '0'
        option method 'nat'
        option ipv6 '1'
  

Then save and close the file, and execute:

ifup mob1s1a1

Wait for 10–15 seconds. Afterwards, you will be able to see information about the success of the requested dual-stack configuration on mob1s1a1. Simply execute:

ip addr show

and find there in the output information about the addresses configured on the mobile network interface (in my case, that interface has the name wwan0).

11: wwan0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 1000
    link/none
    inet 95.3.65.17/32 brd 255.255.255.255 scope global wwan0
       valid_lft forever preferred_lft forever
    inet6 2a01:5a8:1a4:14c:6c78:f01f:daf3:4150/64 scope global
       valid_lft forever preferred_lft forever
    inet6 fe80::c965:519:7205:f216/64 scope link stable-privacy
       valid_lft forever preferred_lft forever
12: br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 00:1e:42:4f:74:72 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.1/24 brd 192.168.1.255 scope global br-lan
       valid_lft forever preferred_lft forever
    inet6 2a01:5a8:1a4:fff::1/64 scope global noprefixroute
       valid_lft forever preferred_lft forever
    inet6 fdb5:99f7:fdfa::1/60 scope global noprefixroute
       valid_lft forever preferred_lft forever
    inet6 fe80::21e:42ff:fe4f:7472/64 scope link
       valid_lft forever preferred_lft forever

Pay attention to the configuration shown. The public IPv4 is assigned to the interface wwan0. The same interface has a dynamically generated IPv6 address that isn't fixed (static). In fact, you get a static IPv6 subnet—the one that is configured on the LAN interface. Which means that your static IPv6 address on the LTE router is 2a01:5a8:1a4:fff::1/64 (assigned to br-lan), not 2a01:5a8:1a4:14c:6c78:f01f:daf3:4150 (assigned to wwan0).

What's left is to enable DHCP6 and router advertising in the home network (connect to the br-lan interface of the LTE router). That is necessary if the device connected to the home network should be given an IPv6 address and an IPv6 default route. Open the file /etc/config/dhcp and add to the "config dhcp lan" section the following set of instructions:

  
    option dhcpv6 server
    option ra server
    option ra_flags 'managed-config other-config'
  

Finally, restart the router and enjoy the dual-stack connectivity.

Read More

Using OpenSSL "ec" tool to encrypt the just-generated EC keys with ciphers stronger than 3DES

It is considered prudent to store the EC keys securely, to prevent OpenSSL library and tools from writing the keys unencrypted to the local file system. While it is possible to encrypt the generated key afterwards, it is considered important to prevent the key from appearing in its unencrypted form in any file. Such disclosure of the key will definitely occur if openssl ecparam -genkey is used with -out (that implies storing the unencrypted key in a file). The root cause of the issue is due to the inability to enable password protection when openssl ecparam -genkey is invoked to generate EC keys. That inability is what makes necessary the subsequent use of the "ec" tool to encrypt the generated EC keys. On the other side, the OpenSSL man pages that come with the OpenSSL installation on Red Hat Enterprise Linux 8/9 (and its derivatives), do not mention the use of a cipher other than 3DES with "ec". This ambiguity causes considerable confusion. This short post explains how to use strong AES encryption to protect the just-generated EC key with a password.

Generate an EC key, but instead of storing the result in a file, send it to the "ec" tool. Even if both the help information and man page of "ec" do not provide any information on how to request AES encryption, specify the corresponding AES cipher in the command line:

openssl ecparam -genkey -name secp384r1 | openssl ec -aes-256-cbc -out my.key

But can we employ a cipher different than 3DES and aes-256-cbc? You can answer that question by checking what is supported by your OpenSSL installation. To do that just type:

openssl --help

and analyze the output. For example, the following ciphers are supported on Red Hat Enterprise Linux 9:

aes-128-cbc       aes-128-ecb       aes-192-cbc       aes-192-ecb       
aes-256-cbc       aes-256-ecb       aria-128-cbc      aria-128-cfb      
aria-128-cfb1     aria-128-cfb8     aria-128-ctr      aria-128-ecb      
aria-128-ofb      aria-192-cbc      aria-192-cfb      aria-192-cfb1     
aria-192-cfb8     aria-192-ctr      aria-192-ecb      aria-192-ofb      
aria-256-cbc      aria-256-cfb      aria-256-cfb1     aria-256-cfb8     
aria-256-ctr      aria-256-ecb      aria-256-ofb      base64            
bf                bf-cbc            bf-cfb            bf-ecb            
bf-ofb            camellia-128-cbc  camellia-128-ecb  camellia-192-cbc  
camellia-192-ecb  camellia-256-cbc  camellia-256-ecb  cast              
cast-cbc          cast5-cbc         cast5-cfb         cast5-ecb         
cast5-ofb         des               des-cbc           des-cfb           
des-ecb           des-ede           des-ede-cbc       des-ede-cfb       
des-ede-ofb       des-ede3          des-ede3-cbc      des-ede3-cfb      
des-ede3-ofb      des-ofb           des3              desx              
idea              idea-cbc          idea-cfb          idea-ecb          
idea-ofb          rc2               rc2-40-cbc        rc2-64-cbc        
rc2-cbc           rc2-cfb           rc2-ecb           rc2-ofb           
rc4               rc4-40            rc5               rc5-cbc           
rc5-cfb           rc5-ecb           rc5-ofb           seed              
seed-cbc          seed-cfb          seed-ecb          seed-ofb          
zlib  

If you're moving a file with an encrypted EC key from one system to another, make sure that the OpenSSL installation there supports the cipher you used. Otherwise, the EC key won't be decrypted.

Read More

How to enable the screen/window sharing (screen casting) on Rocky Linux 9 (GNOME)

By default (fresh installation of the distribution and the apps) the desktop applications available on Rocky Linux 9 (GNOME desktop) cannot share the entire screen, a window, or a browser tab.

That problem appears due to a combination of a missing package (xdg-desktop-portal-gnome), which might not be installed by default, and systemd services (xdg-desktop-portal and/or pipewire), which are either missing or not enabled.

To solve the issue you need to install xdg-desktop-portal-gnome

sudo dnf -y install xdg-desktop-portal-gnome

and enable/start/restart the required services (as user):

systemctl --user enable --now pipewire
systemctl --user restart xdg-desktop-portal.service

Read More