IPFire Hardware-Upgrade

ALIX.2D13 bei hoher Netzlast

Als ich letztes Jahr meinen IPCop 2.x nach IPFire 2.x migriert habe, hatte ich befürchtet, dass in absehbarer Zeit neue Hardware nötig sein wird. Dieses Jahr war mit einem langersehntem Upgrade meiner Internet-Leitung dieses Upgrade unausweichlich. Bei maximalem Datendurchsatz über die neue Leitung stiegen CPU-Last und Temperatur des Eigenbau-Routers sehr stark an - so stark, dass sämtlicher Netzwerk-Verkehr stark verlangsamt wurde.

APU-Produktserie

Seit 6 Jahren verrichtete ein ALIX.2D13-Board von PC Engines seinen Dienst als IPCop bzw. IPFire. Da ich mit der Hardware sehr zufrieden war, wollte ich beim gleichen Hersteller bleiben. Vor einiger Zeit hatte ich schon die APU.1D-Produktpalette entdeckt - gegenüber der ALIX-Serie verfügt diese über einige interessante Erneuerungen:

  • AMD Embedded G-Series T40E APUs - 64-bit Dual-Core
  • CF-Kartenslot wurde durch ein SD-Pendant ersetzt
  • 6 Gbit/s SATA- und mSATA-Anschlüsse
  • Gigabit Ethernet statt 100 Mbit/s-Netzwerk
  • Mini PCI-Express-Slots statt MiniPCI Card-Slots
  • SIM-Kartenslot für UMTS-Modems

Mit Begeisterung habe ich gesehen, dass es mit der APU.2-Serie bereits einen Nachfolger mit Quad-Core APUs, größerem Cache und sogar ECC-Speicher gibt. Allerdings genießen diese Produkte meiner Meinung nach einen Beta-Status, da die BIOS-Firmware noch nicht fertig gestellt wurde - es fehlen einige Funktionen:

  • Booten von SD
  • iPXE-Unterstützung
  • ECC-Speichersicherung

Darüber hinaus ergab eine kurze Google-Recherche, dass es bei einigen Linux-Distributionen Treiberprobleme gibt - also erstmal keine Option für mich, auch, wenn der preisliche Unterschied nicht groß ist.

Modell CPU Takt Kerne Cache RAM
ALIX.2D13 AMD Geode LX800 500 Mhz 2 128 KB 256 MB
APU.1D2 AMD G T40E 1 Ghz 2 512 KB 2 GB
APU.1D4 AMD G T40E 1 Ghz 2 512 KB 4 GB
APU.2B2 / 2C2 AMD GX-412TC 1 Ghz 4 2 MB 2 GB
APU.2B4 / 2C4 AMD GX-412TC 1 Ghz 4 2 MB 4 GB ECC

Letztendlich habe ich mich also für das APU.1D4 entschieden. Um das Setup abzurunden, habe ich beim Online-Shop meiner Wahl passend zum Bundle noch eine 802.11ac-fähige WLAN-Karte bestellt. Anstatt einer SD-Karte entschied ich mich für eine mSATA-SSD vom Typ Kingston SMS200S3/60G - das sollte auch für zusätzliche Aufgaben, wie Proxy-Server und Update-Accelerator ausreichen. 🙂

Installation auf mSATA-SSD

Normalerweise besteht eine Installation von IPFire auf eingebetteten Systemen durch die Übertragung eines Abbilds auf eine Speicherkarte. Bei einer mSATA-SSD gestaltet sich das etwas schwieriger, wenn man nicht gerade einen passenden Adapter hat. Glücklicherweise verfügen die APU-Boards über das CoreBoot-BIOS und können so auch über das Netzwerk oder von USB booten. Nach dem Einschalten des Geräts und einem Tastendruck auf F10 wird das Boot-Menü geöffnet. Sobald die IPFire-CD startet, muss im Menü "Serial console options" der Punkt "Install IPFire (serial)" gewählt werden, um die Installation auszuführen. Andernfalls wird die serielle Konsole nicht verwendet und die Installation kann nicht durchgeführt werden.

Wenn eine SSD zum Einsatz kommt, empfiehlt es sich, nicht mehr benutzte Blöcke in periodischen Abständen freizugeben. Das erfordert TRIM-Support, den der Linux-Kernel schon seit geraumer Zeit bietet. Durch das Freigeben wird einerseits die Langlebigkeit der SSD optimiert, andererseits wirkt es auch der Verlangsamung der Schreibzugriffe entgegen. Im IPFire-Forum gibt es ein Beispiel eines Cronjobs, den ich auf meinem System wöchentlich ausführen lasse:

 1# hdparm -I /dev/sda | grep TRIM
 2 * Data Set Management TRIM supported (limit 1 block)
 3
 4# vi /etc/fcron.weekly/batched_discard
 5#!/bin/sh
 6LOG=/var/log/batched_discard.log
 7echo "*** $(date -R) ***" >> $LOG
 8fstrim -v / >> $LOG
 9fstrim -v /boot >> $LOG
10fstrim -v /var >> $LOG
11
12ESC ZZ
13# chmod 0755 /etc/fcron.weekly/batched_discard
14# /etc/init.d/fcron stop ; /etc/init.d/fcron start

WLAN

Nach erfolgter Installation fiel mir auf, dass in der Netzwerk-Konfiguration des IPFire keine WLAN-Karte zur Auswahl stand. Erkannt wurde sie jedoch:

1# lspci|grep Qualcomm
205:00.0 Network controller: Qualcomm Atheros QCA986x/988x 802.11ac Wireless Network Adapter

Der Grund hierfür war, dass der für diese Karte benötigte Treiber (ath10k) eine benötigte Firmware nicht nachladen kann, das kann auch im Boot-Protokoll nachgelesen werden:

 1# less /var/log/bootlog
 2...
 3[   12.095632] ath10k_pci 0000:05:00.0: irq 47 for MSI/MSI-X
 4[   12.095723] ath10k_pci 0000:05:00.0: pci irq msi interrupts 1 irq_mode 0 reset_mode 0
 5[   12.372230] ath10k_pci 0000:05:00.0: Direct firmware load failed with error -2
 6[   12.372240] ath10k_pci 0000:05:00.0: Falling back to user helper
 7[   12.374067] ath10k_pci 0000:05:00.0: could not fetch board data 'ath10k/QCA988X/hw2.0/board.bin' (-2)
 8[   12.374321] ath10k_pci 0000:05:00.0: Direct firmware load failed with error -2
 9[   12.374326] ath10k_pci 0000:05:00.0: Falling back to user helper
10[   12.376061] ath10k_pci 0000:05:00.0: could not fetch firmware file 'ath10k/QCA988X/hw2.0/firmware-2.bin': -2
11[   12.376093] ath10k_pci 0000:05:00.0: Direct firmware load failed with error -2
12...

Abhilfe schafft das Bereitstellen der benötigten Firmware - diese ist auf GitHub zu finden. Im IPFire-Wiki ist eine Auflistung der benötigten Firmware-Dateien je nach Hardware zu finden. In meinem Fall waren die folgenden Kommandos notwendig, um die WLAN-Karte zur Kooperation zu zwingen:

1# mkdir -p /lib/firmware/ath10k/QCA988X/hw2.0/ ; cd $_
2# wget https://github.com/kvalo/ath10k-firmware/raw/master/QCA988X/board.bin
3# https://raw.githubusercontent.com/kvalo/ath10k-firmware/master/QCA988X/10.2/firmware-3.bin_10.2.2.39.6-1 -O firmware-3.bin

Nach einem Rebot stand die Karte dann zur Verfügung - allerdings habe ich bisher noch keinen Weg gefunden, den 802.11ac-Standard zu verwenden.

Übersetzungen: