Category Archives: arch linux

arch linux, gateways, ipv6, linux, networking, raspberry pi, raspbian, systemd, ubuntu, vpn

Network Configuration and Services

I have written a lot of drivel previously about the various aspects of managing network service, as I’ve tried to figure out the improvements that have been made in linux networking over the last 30 years. I don’t read the kernel threads, and don’t know what’s happening a lot of the time, and haven’t been good about being attentive to release notes, so I get behind and then have to catch up. Previous efforts to catch up have usually been in a hurry when something was busted, and weren’t comprehensive.

This time I have tried to be a bit more comprehensive, so I could settle on the set of solutions and tools I am going to use on the 20 or so different boxes where I have to set this stuff up. A few of them actually need something special, but not most of them. Still, things have to be consistent, and I need to know what I’m doing – at least better than I previously did.

Continue reading Network Configuration and Services →
arch linux, ipv6, linux, networking, systemd, ubuntu

Using IWD instead of wpa_supplicant

1 Comment

I always feel like I am a few years behind. Here is another example. Here at nearly the end of 2021 I have learned about IWD (iNet Wireless Daemon), which is a replacement for wpa_supplicant.

This is just to record a few facts about experiences over the last couple of days, subsequent to receiving and setting up a new frame.work laptop. I install Arch on this laptop, and initially followed what I had previously done in the earlier post: Switching to systemd-networkd.

One of the problems described in that post is that if one follows what it says, a side-effect is the loss of any very good “graphical” way to switch a laptop from one SSID to another. I detail there how I used a downloaded package called wpa_gui to do that, but while it is a good step forward, it is a bit clunky. Maybe I’m not using it exactly right… I mean no disrespect to its authors, and am glad it exists; but I went looking for something else. And I discovered the IWD package.

When I downloaded and installed IWD, in ignorance, I managed to completely eliminate my wireless device and spent a good deal of time recovering. Following are some things I learned. But there are two different changes in my environment going on here, and while they are related I’m not claiming that one requires the other. One of the changes is the substitution of IWD for wpa_supplicant as the party responsible for interacting with wireless radios, selecting one, authenticating to it, and making it available as a device. The second change is that I have begun to use NetworkManager again, in conjunction with systemd-networkd.

IWD is a systemd service, as is wpa_supplicant, NetworkManager, and systemd-networkd, and it is possible to create a great deal of confusion when all of these bits are installed on the same system. If one desires to have more confusion, one has only to do all this on an ubuntu system, where the presence of Canonical’s netplan software adds another order of magnitude increase in complexity, and additional opportunities for foot target practice.

One of the big opportunities for confusion arises when IWD renames network devices. If one has “.network” files (for steering systemd-networkd) which rely upon matches on the device names, surprise! the device names (like wlp11S0) get changed to (e.g.) wlan0 by IWD.

I probably don’t understand all this well enough to attempt to explain it, and will probably only look foolish if I try, so instead I will just detail where I ended up on two of my laptops.

I have enabled the services IWD, systemd-networkd and NetworkManager. In /etc/NetworkManager/NetworkManager.conf I have a [device] section containing the setting “wifi.backend=iwd” which instructs NetworkManager to rely on IWD rather than wpa_supplicant, and prevents NetworkManager from trying to start a wpa_supplicant. I have removed the local service file /etc/systemd/system/wpa_supplicant/wpa_supplicant@wlp11s0 (which I had described in my previous blog post), and have stopped and disabled (and even masked) the associated wpa_supplicant@wlp11s0 service as well as the plain wpa_supplicant service. Update, March, 2022, I was trying to switch some things around on a Debian 11 box, and was unable to get a wireless connection until after reading some stuff in upstream on NetworkManager I found a suggestion that I add: iwd-config-path=auto in the [main] section of /etc/NetworkManager/NetworkManager.conf (same file where I put in the backend spec). Until I did this it was unable to connect to anything.

In /etc/systemd/network I have a .network file for 09_<laptop>_wireless.network containing the networkd description, same as before, except that the [match] now says “name=wl*” instead of the previous “name=wlp*” (because of IWD changing the name from wlp11s0 to wlan0).

Finally, one of these laptops is still ubuntu, so one gets the additional joy of netplan. There, in the /etc/netplan directory I went back to a yaml file which names the “renderer” as NetworkManager instead of systemd-networkd. My current, perhaps flawed understanding of this setting in netplan is that when netplan runs at boot time it uses the (collected and merged) yaml files to build at boot time the files for either systemd-networkd (in /run/systemd/network/), or for NetworkManager (in /run/NetworkManager/). These generated files will then get combined with similar files from /lib and from /etc (the latter having greatest priority, the former having least, and /run in the middle).

Going back to NetworkManager has one downside for me, the thing which drove me earlier to abandon NetworkManager in favor of systemd-networkd, and that is the specification of the IPv6 DUID to be used when soliciting an IPv6 address from DHCPv6. I can’t find information about how to stipulate the DUID to be used (for example in this nm_connection documentation). What I have done is develop better tools to figure out what NetworkManager decided to send, so I can arrange for the DHCPDv6 server to assign a static address to that DUID.

arch linux, backup, linux, mac

Attaching and backing up the iphone

I have an iPhone 11. From time to time it would be nice to be able to attach it to my network. Always a struggle.

The old Macbook Pro can only run High Sierra, and then only with some special jiggery-pokery. I can sometimes get iTunes on the Macbook to connect to the iPhone, and can usually figure out how to get data into some app using that, or to do a backup, but it is a hassle. The Windows 10 box with iTunes won’t connect to it at all, and (typical of Windows) won’t explain why. I really just want to mount it without all the fuss.

I found a guy on the net who claimed to be able to mount his iPhone on Arch, so I tried following his instructions, which basically involved installing a few libraries usbmuxd, libplist, libimobiledevice and ifuse, the last of which I had to install from AUR. That was easy enough.

Then reboot, plug in the iphone, and voila. It is detected.

I created a directory /ginger, and mounted it with ifuse /ginger, and Bob’s your uncle, I have access to its disk on Arch.

Then I checked on a whim whether I could do a backup. Sure enough libimobiledevice comes with idevicebackup2 which, supposedly, will do a backup of the device. Alas, it doesn’t work, complaining of a protocol mismatch, which according to the net means that the version 1.3.0-3 available on Arch is not the latest, and I need 1.3.1. The option is to download from git and compile from source.

This is low priority for me. I still can do an occasional backup on the Macbook, when I think of it, either locally or to iCloud, via iTunes. The local backup is stored in /Users/dee/Library/Application Support/MobileSync/backup and can be copied elsewhere by root. I don’t actually have much on the iPhone that needs a backup. Many people have their contacts and calendar exclusively on the phone, but I keep both my contacts and calendar in radicale on my server and connect to them from everywhere.

I may eventually do this if there comes a time the backups become important. For now I’ll just wait till a later version shows up in Arch.

arch linux, ipv6, linux, networking, raspbian, systemd, ubuntu

Switching to systemd-networkd

Since moving to IPv6 I have had two recurrent problem: one with some conflict between systemd and the kernel over the /proc/sys/net/ipv6/conf/*/accept_ra, and the second with losing the static ipv6 address assignments on some boxes. I believe the former problem to have something to do with systemd wanting to have control of the sysctl variables, such as accept_ra.

The latter problem is due to the various bits of software that want to have a say in the control of the network. In part some of this is my own fault, as I do have these various bits installed – and if they weren’t installed they could not be causing trouble.

I installed NetworkManager in some places, even when it hadn’t been installed by default, because I wanted to be able to control things with the network applet in gnome. I installed dhclient even though it wasn’t installed, because I wanted better ability to see and control the dhcpv6 leases, particularly the DUID, and network manager made that difficult (and astonishingly, in some cases simply didn’t work).

Continue reading Switching to systemd-networkd →
arch linux, gateways, ipv6, linux, mac, networking, openssh, postfix, raspberry pi, raspbian, security, ubuntu, vpn

IPv6 Re-implementation

This is a follow up to the activities in IPv6 implementation, which was published on March 2nd and revised up through March 19th, as new challenges were addressed. Since March 19th a great deal of what I wrote has been revised, as I have learned a lot more.

The main issue was that there remained a number of problems with the implementation of IPv6 in my residence.

  • The biggest was the question how to handle the delegated prefix, particularly in renumbering. Over the course of the last several months I have to note that Comcast has never changed my prefix, except early on, when I forced it to do so by changing my DUID. And I don’t think it likely that my prefix would change unless some great catastrophe befalls which results in my being down for a very extended period – like 30 days; or more likely there is some change in my service (a change in ISP, or perhaps fiber arriving in my area).
  • The first implementation required that I make patches to the code of my router. This meant that I would have to figure out how to carry those patches forward in the event of firmware updates from Ubiquiti, the maker of the Edgerouter-X that I am using.
  • The implementation was pretty fragile, with a lot of unrelated bits in different places. In particular there was a lot of hand-waving in trying to assign and maintain a separate network for the virtual machines on one of the interior boxes.
Continue reading IPv6 Re-implementation →
arch linux, boot issues, gateways, linux, networking, raspberry pi, raspbian, ubuntu

Waiting for networks

I was revising some things in my startup scripts. I have a sort of generalized startup script in all the boxes in my constellation, which is capable of doing 8 or 10 different things that various of the boxes need to do at startup.

For example, the various gateway boxes need to open up (auto)ssh connections to my house with reverse tunnels so I can reach them. On some boxes I want them to open a vncserver so I can get a graphical environment up. On some others they may need to mount some filesystems, with smb or nfs. On some of them I want them to figure out where their router is, in case I want to open up their router in a browser. On some I need them to establish the keychain.

Continue reading Waiting for networks →
arch linux, cloud, ipv6, linux, networking, ubuntu, vpn

IPv6 implementation

This post describes my first attempt at implementation of IPv6, a process that took place over a span of a couple of months. After this was done, and was working, a “better way” emerged, which will be the subject of an additional post. I leave this in here for the sake of documenting what I did the first time, but in the unlikely event that anyone finds this while looking on the net for information about implementing a similar arrangement, I urge you to find the other post, and read it as well. This implementation was fragile.

A few weeks back (10 Feb) my friend Mr. G and I exchanged an email in which he said of a possible project “…but this would be an opportunity to learn IPv6”, reminding me that I have for a long time wanted to learn more about IPv6. Part of the genesis of that email conversation was a recent switch by my brother-in-law to a new ISP that employed CGN, so called Carrier Grade Nat, which had disrupted arrangements I had in place for reaching my brother-in-law’s home network. Mr G. opined that the move towards CGN, and other things the ISPs were doing, raised the specter that someday, perhaps sooner than we expect, anyone desiring to do more with their network than occasionally use a browser would find ourselves having to move to ipv6.

More, I have actually wanted to use IPv6 for a long while, but had been under the impression (erroneously) that Comcast really wasn’t ready for this, that all they would give me was a 6to4 tunnel, which I barely understood anyway.

Continue reading IPv6 implementation →
arch linux, boot issues, linux, networking, ubuntu

Stop pulseaudio startup under gdm

GDM is the display manager I’m using under Arch. I think it is the default DM in Arch, but I don’t really remember if I’ve changed it. In any case, the issue that has arisen is that when GDM is started by systemd after a reboot, it is launched with its own pulseaudio daemon. Then when I log in, as dee, I get a second pulseaudio daemon for dee (which is actually the desired one).

Most of the time this doesn’t matter, I guess. But I’m interested in enabling network sources in pulseaudio so I can (perhaps) have the boxes in the basement send their sound upstairs to oregano. Right now avahi is broadcasting two different network sound services on oregano, one from dee and one from gdm.

I want to stop pulseaudio from launching under gdm.

I thought this would be a simple matter of turning off autospawn in the client conf. The client conf is located in ~/.config/pulse (I think it used to be in ~/.pulse and was moved to be more “correct”). And ~ for gdm is /var/lib/gdm, so I tried client.conf in both .config/pulse/client.conf and .pulse/client.conf, but neither worked.

Poked around a little more and discovered that /usr/lib/systemd/user has a pulseaudio.service and pulseaudio.socket so these are actually being launched there by systemd. After a little reading I found that one could mask them by creating a local user override in ~/.config/systemd (for gdm this is /var/lib/gdm/.config/systemd), so I put in a /var/lib/gdm/.config/systemd/user/pulseaudio.socket and symlinked it to /dev/null.

And when I rebooted, sure enough I got not pulseaudio daemon for gdm.

arch linux, linux

libmtp udev rules

After updating Arch today I found I could no longer mount usb storage devices – usb sticks. The log shows the device coming up, but then messages from MTP saying: 

mtp-probe: bus: 2, device: 5 was not an MTP device

I have seen this before. It is irritating, I am doing something else, my head full of whatever it is, and suddenly usb sticks won’t mount.

Continue reading libmtp udev rules →
arch linux

Arch Keys

Needed to install calibre on oregano, for a downloaded e-book. So, I found calibre in the Arch User Repository, AUR.

I’ve been using AUR a good deal, but I constantly forget what to do and have to look it up: copy the url for the git link, create a directory, git clone from the link. cd into the directory, non-root. Inspect the BUILDPKG for safety. Then:

Continue reading Arch Keys →