Leap/SLES 15.5 – strange compatibility problem between tcpdump, libpcap and arping from iputils

My readers know that I presently work again with virtual networks. A part of my studies is related to ARP and routes on veth devices with VLAN-interfaces. I follow the packet transfer across VLANs with tcpdump, which itself depends on libpcap. On Leap 15 the relevant package is: libpcap1. ARP commands were generated by the arping command, which gets available after an installation of the package “iputils“.

This worked perfectly on a laptop. I know for a presentation had to use another system with the same kernelversion and virtual networking support. There I got strange messages for ARP packets passing a veth endpoint’s main device (in my example: veth2V) on their way to a VLAN interface (“veth2V.30) on the same veth endpoint:

netns2:~ # tcpdump -n -e -i any -v
tcpdump: data link type LINUX_SLL2
tcpdump: listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes

15:15:36.334692 veth2V B   ifindex 2 46:b9:81:00:00:1e ethertype ARP (0x0806), length 52: Unknown Hardware (36461) (len 0), Unknown Protocol (0x0000) (len 1), Unknown (2048) 
        0x0000:  8e6d 0000 0001 0800 0604 0001 46b9 8b4b  .m..........F..K
        0x0010:  8e6d c0a8 0501 ffff ffff ffff c0a8 0502  .m..............
15:15:36.334692 veth2V.30 B   ifindex 4 46:b9:8b:4b:8e:6d ethertype ARP (0x0806), length 48: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.5.2 (ff:ff:ff:ff:ff:ff) tell 192.168.5.1, length 28
15:15:36.334720 veth2V.30 Out ifindex 4 d2:85:39:c8:43:fc ethertype ARP (0x0806), length 48: Ethernet (len 6), IPv4 (len 4), Reply 192.168.5.2 is-at d2:85:39:c8:43:fc, length 28
15:15:36.334721 veth2V Out ifindex 2 d2:85:81:00:00:1e ethertype ARP (0x0806), length 52: Unknown Hardware (17404) (len 0), Unknown Protocol (0x0000) (len 1), Unknown (2048) 
        0x0000:  43fc 0000 0001 0800 0604 0002 d285 39c8  C.............9.
        0x0010:  43fc c0a8 0502 46b9 8b4b 8e6d c0a8 0501  C.....F..K.m....

I had never seen similar messages in comparable experiments with veths before. And these messages about “Unknown Hardware”. In addition the length of the Ethernet packets were wrong. I did not get such errors on my laptop where I had prepared the setups of the virtual VLANs.

It took me some time to find the difference between the systems: iputils as well as tcpdump on both systems came from the Network:Utilites-repository “https://download.opensuse.org/repositories/network:/utilities/15.5/”.

However, libpcap1 on the presentation system came from the main SLES 15.5 OSS repository in version 1.10.1-150400.1.7. On my laptop I had instead fetched the library from the Network:Utilites-repository, too.

Changing libpcap1 to the present version 1.10.4-lp155.92.1 from the Network:Utilites-repository led to correct tcpdump information:

netns2:~ # tcpdump -n -e -i any -v
tcpdump: data link type LINUX_SLL2
tcpdump: listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes

15:38:44.899645 veth2V B   ifindex 2 f2:5b:23:ba:16:8a ethertype ARP (0x0806), length 48: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.5.2 (ff:ff:ff:ff:ff:ff) tell 192.168.5.1, length 28
15:38:44.899645 veth2V.30 B   ifindex 4 f2:5b:23:ba:16:8a ethertype ARP (0x0806), length 48: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.5.2 (ff:ff:ff:ff:ff:ff) tell 192.168.5.1, length 28
15:38:44.899667 veth2V.30 Out ifindex 4 9a:88:24:0c:f9:99 ethertype ARP (0x0806), length 48: Ethernet (len 6), IPv4 (len 4), Reply 192.168.5.2 is-at 9a:88:24:0c:f9:99, length 28
15:38:44.899669 veth2V Out ifindex 2 9a:88:24:0c:f9:99 ethertype ARP (0x0806), length 48: Ethernet (len 6), IPv4 (len 4), Reply 192.168.5.2 is-at 9a:88:24:0c:f9:99, length 28

Interestingly, even if one changed both tcpdump, iputils and libpcap1 to the main Leap /SLES 15.5 repository the problem would come up, too.

So, there seems to be something severely wrong with libpcap1 of the main Leap /SLES 15.5 repositories.

 

Revival of an old Terra 1541 Pro with Opensuse Leap 15.5

My wife and I use the expression “Windust” for the Windows operative system. A “dust” is a somewhat stupid person in Norwegian. I will use this expression below.

My wife has a rather old laptop (Terra 1541 Pro). I has survived Windust 7 up to the latest Windust 10. It was the only one of our laptops with a full Windows installation. We used it for communication with some customers that had Windows, only. Skype, Teams are the keywords.

During the last Windust 10 updates the laptop got slower and slower. In addition, according to MS, the laptop does not qualify for Windows 11. A neighbor of us had the same problem. What do Windust users (as our neighbor) do in such situations? They either try a full Windows (10) installation from scratch – and/or buy themselves a new laptop. It is so typical and so “dust” …

Revival with Linux?

My wife and I are retired persons. We no longer need to care about customers who depend on Windust. For the few remaining ones a small virtual installation under KVM on a workstation is sufficient for all practical purposes. So, we thought: This old laptop is a typical case for a revival cure with Linux.

A good friend of us organized a new rechargeable battery block for us and we ordered a 1 TB SSD in addition. The screen has a 1920×1080 resolution, the RAM is 16GB. Graphics is Intel based. All in all, for non-professional purposes it is a well equipped laptop. We therefore decided to finally say good bye to our last Windows installation which slowed down the laptop.

Opensuse Leap 15.5 installation

Yesterday, I installed Opensuse Leap 15.5 on the laptop. From an ISO-image on DVD. No problems occurred during the installation process.
[At least as long as I did not try to add special SW repositories with YaST2. Opensuse has build a remarkable bug into Yast2’s software(= RPM) management. More about this in another post.]

The good news is: The laptop works with Leap 15.5 and KDE like a charm. And it is now less noisy (ventilation!) than with Windows 10. All special keys for controlling screen brightness and speaker levels work. No problem to attach Kontact (with Kmail) and Thunderbird to our IMAP-server. Multimedia programs like Clementine do their work. Our standard browsers (FF, Chromium, Opera), too. Yesterday we watched the Norwegians handball team play against Slovenia during the EM in Germany via a live stream on Firefox on this laptop and on an HDMI-attached HD TV that extended the laptop screen. Automatically recognized and after answering a question, in which direction we wanted to extend, automatically activated.

After a short configuration network connections can be set up via Ethernet cable, if we want to work in our inner LAN network with Linux systems, only. These systems are configured via firewalls to trust each other partially and with respect to certain services. Internet connection happens via routing through a perimeter firewall. Alternatively my wife can directly connect to a WLAN of our router, when she just wants to access the Internet. Networkmanager, priorities for automatic connections and sensing a plugged-in network cable are used to make an adequate automatic choice of the system: If the Ethernet cable is plugged in a cable based connection is used, only. If the cable is unplugged WLAN is activated automatically. And vice versa.
A small script for avoiding double connections (LAN and WiFi) can be added to the “/etc/NetworkManager/dispatcher.d”. This is discussed in “man nmcli-examples” and at [1]. I recommend all users of Linux laptops with Network manager to study the little script:

#!/bin/bash
export LC_ALL=C

enable_disable_wifi ()
{
    result=$(nmcli dev | grep "ethernet" | grep -w "connected")
    if [ -n "$result" ]; then
        nmcli radio wifi off
    else
        nmcli radio wifi on
    fi
}

if [ "$2" = "up" ]; then
    enable_disable_wifi
fi

if [ "$2" = "down" ]; then
    enable_disable_wifi
fi

Do not forget to give the script executable rights. Works perfectly.

Do we miss any Windows SW on the old laptop?

Straight answer: No. My wife has used GIMP, Gwenview, showFoto (with ufraw) and Inkscape for image manipulations for years. GIMP and Inkscape also on Windust. We both use Libreoffice Draw for drawings and simple graphics. Libreoffice (with Writer, Calc, Impress) has been a sufficient and convenient replacement for MS Office already for many years. For creating tax reports we use LinHaBU. The little we do with Web development these days can be done with Eclipse. Linux offers a variety of FTP-tools. All in all our needs are covered and our requirements very well fulfilled.

The old laptop will get a hopefully long 2nd life with Linux at our home in Norway.

Some security considerations

One thing that may be important for professional people: You may want to have a fully encrypted system. This can, of course, be achieved with LUKS. And in contrast to an often heard argument it is not true that this requires an unencrypted and therefore insecure “/boot”-partition. I have written articles on setting up a fully encrypted Linux system with the help of LUKS on laptops in this blog.

TPM offers options to detect HW-modifications of your system. See e.g. [5]. This is certainly useful. But, as you have an old laptop with Windust, you probably have lived with many more and SW-related risks regarding your security for a long time. So, no reason to forget or replace your laptop by a new one. Most Windust users that I know do not even have a Bitlocker encryption active on their systems.

While the BitLocker encryption of Windust may require TPM 2.0 to become safe again (unsafe SHA-1 support in TPM 1.2), we can gain a high level of security regarding disk encryption on Linux with LUKS alone. One can even find some arguments why TPM (2.0) may not make fully encrypted Linux laptops more secure. Opensuse and other distributions do support TPM 2.0 and secure boot. So, the question is not whether some Linux distribution actively supports TPM, but whether we really need or want to use it. See e.g. the discussion and warnings here.

In my private opinion, the old game of Windows supporting the HW-industry and vice versa just goes into a new cycle and the noise about HW- and firmware based attacks ignores at least equally big risks regarding SW (OS and applications).

Even under security considerations I see no major reason why one should not use older laptops with a full LUKS encryption. A major difference is that we do not put secrets and keys for an automatic decryption into a TPM-chip which could have backdoors. A LUKS setup is a bit more inconvenient than Bitlocker with TPM, but with all partitions encrypted (no separate /boot-partition!) not really un-safer. The big advantage of LUKS full encryption without TPM is: No knowledge of the key passphrase, no decryption. But this is all stuff for a more detailed investigation. A fully LUKS encrypted Linux setup would in any case probably be significantly safer than an old Windust installation with Bitlocker and TPM 1.x.

If your security requirements are not top level most reasons not to use old laptops are not valid in my opinion. So, give Linux a try on your old machines before throwing them away.

Conclusion and some preliminary security considerations

Old laptops can remain a valuable resource – even if they are not fit for Windows 11 according to MS. Often enough they run very well under Linux. If you have major security requirements consider a full disk encryption with LUKS. This may not be as safe as LUKS with TPM 2.0 and a two-phase-authentication, which you would have to take care of during setup, but it may be much safer as the Windust installation you have used before.

And do not forget: TPM is no protection against attacks which use vectors against SW-vulnerabilities.

Links

[1] https://unix.stackexchange.com/ questions/ 346778/ preventing-double-connection-over-wlan0-and-usb-0-in-network-manager-gnome

[2] TPM and Arch Linux: https://wiki.archlinux.org/ title/ Trusted_Platform_Module
See also the warnings in
https://wiki.archlinux.org/ title/ User:Krin/ Secure_Boot, _full_disk_encryption, _and_TPM2_unlocking_install

[3] Bruce Schneier on TPM attacks: See https://www.schneier.com/tag/tpm/ and
https://www.schneier.com/ blog/ archives/2021/08/ defeating-microsofts-trusted-platform-module.html

[4] TPM 2.0 vulnerabilities: https://www.tomsguide.com/ news/ billions-of-pcs-and-other-devices-vulnerable-to-newly-discovered-tpm-20-flaws

[5] A positive look on TPM from Red Hat: https://next.redhat.com/ 2021/05/13/ what-can-you-do-with-a-tpm/

Opensuse Leap 15.5 – YaST2 bug – no repositories can be added via YaST2

In one of the last posts I have said that upgrades of running Opensuse Leap 15.4-systems to Leap 15.5 are a smooth business. However, a major bug in the present Leap 15.5 did not appear on my radar until now.

During the upgrades of most of my systems I just continued using a system-specific bunch of active Opensuse repositories – like the “graphics” and the “security” repositories. I used the ${releasever}-mechanism during the upgrades to point zypper to the new versions of the repositories. This all went well and after the upgrade I found the 15.5-versions of those repositories, which I had used on Leap 15.4 before, integrated into the YaST2-software and package management of Leap 15.5.

But, two days ago, I installed Leap 15.5 on a laptop from an ISO-image on a DVD. Such an installation only sets up basic Leap 15.5 repositories. So, after the installation I wanted to add further repositories via YaST2’s software-management. This did not work at all. The repositories simply did not appear in the list of managed repositories afterwards.

I fiddled around for about an hour. It became clear by switching views on repos and so called “services” that the requested new repositories were handled by YaST as SW-services, instead as standard repositories. Whatever “services” are going to be good for in the future. I could find some information at
https://news.opensuse.org/ 2023/07/31/ try-out-cdn-with-opensuse-repos/.

I moved in the end to zypper on the command line to add repositories. Which worked …. A good reason to suspect a bug.

Bug: Adding repositories with YaST2 does not work presently

Indeed: The following two links showed that other Opensuse users had the same problem and that there is a related bug-entry at Opensuse’s bugzilla:
https://forums.opensuse.org/ t/ cant-add-repos/ 171641
https://bugzilla.opensuse.org/ show_bug.cgi?id=1218399

Well, YaST2 is a central tool-box for Opensuse systems. And who would deny that the package manager is one of the most important tools on any Linux system? So, old kinds of questions regarding quality assurance came to my mind: Are changes to central Leap components tested thoroughly at Opensuse? In particular as also SLES is affected …. Unbelievable …

The affected package is yas2-packager 4.5.17-150500.3.3.1.

Workaround

Adding repositories directly via zypper (which is used by YaST2) still works. So, you can add add repositories like the security repository, with command analogous to the following:

mytux:~ # zypper ar -f https://download.opensuse.org/repositories/security/15.5 security
Adding repository 'security' 
..................................................................................[done]
Repository 'security' successfully added

URI         : https://download.opensuse.org/repositories/security/15.5
Enabled     : Yes
GPG Check   : Yes
Autorefresh : Yes
Priority    : 99 (default priority)

Repository priorities are without effect. All enabled repositories share the same priority.

These repos afterward appear in the YaST2 packet manger and are fully usable to install RPM packages.

Weird aspect of the YaST2 packet manager: Opensuse and Nvidia services cannot be deleted via YaST2

After some updates of leap 15.5 you may find that all basic repositories have been switched to “services” at “cdn.opensuse.org”. What is disturbing: A fresh installation of Leap 15.5 from an ISO-image does not show any of the services displayed in the image above.

Once you got the “services” in your Leap 15.5 installation you may want to delete them and restrict your system to the standard repositories at “download.opensuse.org”. But this does not work with YaST2. Which appears as an additional bug. You may switch to “services” and delete them in the views coming up. And everything afterward gives you the impression that they are gone. But no: After a restart of YaST2 and the packet manager all Opensuse services appear restored again.

Conclusion

YaST2’s present packet manager for Leap 15.5 has a major bug: Repositories can not be added. In addition one cannot get rid of the new Opensuse services. Let us hope that we get a new and error free version of YaST2’s packet manager soon.