While I have some networking experience using copper networks, I have never configured fiber networking in the past. As I needed to connect two buildings across 150 meters of cable distance, preferably with 10Gbps speeds, this was the moment to get my first fiber network running. However, I wanted to do it entirely using open source software, in this case OpenWRT.

SFP+ tranceivers usually advertise their compatibility with certain hardware manufactures. Unfortunately, I didn’t find any advertising OpenWRT or even Linux compatibility. So I was a bit sceptical aboud which tranceivers to order. After a brief period of research, I decided to just go for it and order two SFP+ tranceivers from fs.com, announcing “Generic” support. And I was very glad to find out they worked out of the box on my OpenWRT SFP+ devices.

Motivation

I want to switch my network setup to open source software (and hardware) as much as possible. Therefore, I was looking for a modern OpenWRT WiFi device for quite a while now. I wanted stable OpenWRT support, enough computing power, memory and storage to run OpenWRT with some packages smoothly, preferably in open hardware. Most importantly, I wanted to directly go for WiFi 7 from my current WiFi 5 network. Even if I do not own any WiFi 7 devices yet, I want to use my new networking equipment for years to come, and therefore be future-proof. I also needed an SFP+ slot for cross-site connectivity, and preferably 2.5GiB+ copper ethernet as well to support the fast WiFi network.

Motivation

In my home network, I use a separate VLAN for guest access, i.e. devices that are allowed to connect to the internet but should not have access to local devices. Of course, the guest network should be available via a separate WiFi SSID as well. However, configuring this took me quite a while in LuCi and the reForis interface on my new Turris Omnia NG routers. While I am quite familiar with Linux networking on the command line, OpenWRT configuration is quite new to me. And although most configurations translate well from plain Linux networking to OpenWRT, there are some trivialities I still need to wrap my head around.

I want to access metrics of my OpenWRT networking equipment in my Prometheus/Grafana setup. Luckily, there are OpenWRT packages for exporters that provide Prometheus endpoints directly on the device and require no external services.

To enable Prometheus monitoring on the OpenWRT device, I install the corresponding exporter packages, e.g. via SSH:

ssh root@host opkg install prometheus-node-exporter-lua-hwmon prometheus-node-exporter-lua-netstat prometheus-node-exporter-lua prometheus-node-exporter-lua-nat_traffic prometheus-node-exporter-lua-thermal prometheus-node-exporter-lua-openwrt prometheus-node-exporter-lua-ethtool prometheus-node-exporter-lua-nft-counters prometheus-node-exporter-lua-uci_dhcp_host prometheus-node-exporter-ucode prometheus-node-exporter-lua-snmp6 prometheus-node-exporter-ucode-dnsmasq prometheus-node-exporter-ucode-wireguard prometheus-node-exporter-lua-wifi prometheus-node-exporter-lua-wifi_stations

WiFi related packages may be excluded if the device has no WiFi radios. There are more packages available that may be included if corresponding hardware / services are used. Note that there are two kinds of Prometheus exporters for OpenWRT, the lua ones and the ucode ones. I prefer the lua ones as there are more exporters available for the lua framework.

As I have recently started using OpenWRT on network equipment, I frequently wanted to add an OpenWRT device as a client to my Wireguard VPN. I usually create a Wireguard config like this:

lukas@netherlands:~$ cat devicename.conf
[Interface]
Address = a.b.c.d/32, fc00:0:0:c::d/64
PrivateKey = <redacted>

[Peer]
PublicKey = <redacted>
AllowedIPs = <local subnets>
Endpoint = example.com:port
PersistentKeepalive = 10

This config can be imported into OpenWRT using LuCI after installing the luci-proto-wireguard package (which includes required Wireguard packages as dependencies) and restarting the network component in System -> Startup -> Initscripts. Then just add a new interface in Network -> Interfaces, select “WireGuard VPN” as protocol and set an appropriate name. The interface settings will open, at the bottom of the “General Settings” tab is a button to load an existing configuration, which will accept a configuration in the above format and also set up appropriate peers (which could otherwise be imported individually).

A colleague of mine asked me how LVM allocates physical extends when resizing volumes. So I decided to do a bit of research.

man 8 lvm has a section called ALLOCATION that describes how LVM allocates space, no matter if creating or resizing logical volumes (LVs). Basically, LVM tries to allocate new physical extends consecutively to any existing physical extends (PEs) if possible. When multiple LVs exist, extending the first one with consecutive PEs will not be possible, as the following PEs are already occupied by the second LV. Therefore, LVM will allocate the PEs following the last LV to the first LV.

This is a collection of useful OpenSSL commands I don’t use frequently enough to remember them.

Generate and read CSRs

To generate a certificate signing request, first create a configuration file ( Source ):

[req]
distinguished_name = req_distinguished_name
req_extensions = v3_req
prompt = no
utf8 = yes
[req_distinguished_name]
C = DE
ST = Nordrhein-Westfalen
L = Bochum
O = Ruhr-Universität Bochum
CN = einrichtung.ruhr-uni-bochum.de (die Hauptdomain)
[v3_req]
subjectAltName = @alt_names
[alt_names]
DNS.1 = einrichtung.ruhr-uni-bochum.de
DNS.2 = www.einrichtung.ruhr-uni-bochum.de

And create a private key: openssl genrsa -out einrichtung.rub.de.key 4096. Afterwards, generate the CSR from the private key and the configuration file: openssl req -new -out einrichtung.rub.de.csr -key einrichtung.rub.de.key -config csr.conf. View the contents of the CSR using openssl req -in einrichtung.rub.de.csr -noout -text.

For verbose services, I like to limit the maximum log file size of the corresponding systemd units independently, to avoid flushing system messages of other, less verbose services from the journal.

In systemd-journald, this is possible using a log namespace. Add the following to the systemd unit definitions that should be moved to the new namespace, e.g. using systemctl edit:

[Service]
LogNamespace=mylognamespace

And create the corresponding log namespace by creating a configuration file /etc/systemd/journald@mylognamespace.conf, e.g. by copying the main configuration file /etc/systemd/journald.conf.

A common issue I encounter after setting up Arch Linux hosts occurs when installing go packages:

clean.go:8:2: github.com/Jguer/aur@v1.2.3: Get "https://proxy.golang.org/github.com/%21jguer/aur/@v/v1.2.3.zip": dial tcp: lookup proxy.golang.org on [::1]:53: read udp [::1]:41284->[::1]:53: read: connection refused

The error messages say connection refused which may be misleading. In my case, this issue is always related to using systemd-resolved for DNS resolution without setting up the stub-resolv.conf. DNS resolution in other tools like curl works, which makes this issue even harder to detect. But go seems to rely on /etc/resolv.conf, so if that is not set up as a link to /run/systemd/resolve/stub-resolv.conf, the errors above will appear.

I know, the introduction says

there is no much point in publishing the 999th blog on Linux / ZigBee / HomeAssistant / whatever

and yet already the first post will be at least somewhat HomeAssistant related. But I think that this is a poorly-covered detail on the internet, so it might be worth a read.

A couple of weeks ago, HomeAssistant deprecated the core and supervised installation methods, requiring a migration to a VM- or container-based setup .

Hello World. Posts seem to work.