Hochverfügbare Firewall mit Thin-Client Fujitsu Futro S920 und OPNsense

Heute möchte ich einmal ein wenig von Hard- und Software-Komponenten meines heimischen Netzwerks erzählen, die für sich gesehen zwar unscheinbar wirken, aber umso wichtiger sind. Seit einiger Zeit nutze ich als Firewall die Software OPNsense, bis vor kurzem lief diese auf zwei Thin-Client-Systemen Fujitsu Futro S900. Der folgende Artikel wird mehr eine Bildergeschichte denn detaillierte Anleitung sein, denn inzwischen haben zwei Systeme des Typs Fujitsu Futro S920 den Platz eingenommen, deren Aufbau und Einrichtung ich ein wenig skizzieren wollte.

Router, Firewall, Netzwerke

Vor etlichen Jahren wurde in der c’t über Router-Kaskaden berichtet. Mit einer derartigen Konfiguration zweier oder mehrerer Router ist es möglich, hinter einem Internet-Anschluss mehrere, unterschiedliche Netze aufzuspannen, so dass diese voneinander abgeschottet sind und jeweils einem eigenen Anwendungsbereich dienen. Als Beispiel sei eine Trennung von privater Nutzung zu geschäftlicher Verwendung genannt, oder etwa um Smart-Home-Devices in ein eigenes Netz zu stecken. Die Anwendungen sind vielfältig, und die Idee, einen weiteren Router inkl. Firewall hinter dem ersten Router, d.h. in meinem Falle der FRITZ!Box einzusetzen, gefiel mir auch aus Sicherheitsaspekten. Nach einer Weile des Betriebs eines zweiten WLAN-Routers, wie im Artikel der c’t  beschrieben, hatte ich zunächst den EdgeRouter X von Ubiquiti im Einsatz. Dabei handelt es sich um eine kleine, schicke Kiste, die von außen leicht mit einem 5-Port-Switch verwechselt werden kann, und mit der ich tatsächlich auch nur positive Erfahrungen gemacht habe. Wiederum ein wenig später wollte ich jedoch mehr, am liebsten natürlich eine Lösung, die vollständig auf Open Source basiert, ausbaufähig ist, eine gute Admin-UI bietet usw..

OPNsense und Appliances

Dafür schien OPNsense sehr geeignet, das sich selbst als “Open-Source-, einfach zu benutzende, einfach aufzubauende, HardenedBSD basierte Firewall- und Routing-Lösung” bezeichnet. Hinter OPNsense steht das niederländische Unternehmen Deciso B.V., das neben Support auch kommerzielle Varianten und Komplettsysteme, die so genannten Appliances vertreibt. Der Anschaffungswiderstand für ein derartiges System war mir natürlich etwas zu hoch, schließlich ist man erst recht als Privatanwender immer auf der Suche nach einer möglichst günstigen Alternative. Diese konnte auch gerne aus gebrauchter Hardware bestehen. Jedoch möchte man sich ungern einen zwar funktionsfähigen, aber älteren kompletten PC oder gar Server nur für Routing- und Firewall-Zwecke hinstellen, allein der Stromverbrauch spricht dagegen.

OPNsense-Hardware für den Heimgebrauch

Eine Alternative stellten Thin-Client-Systeme dar. Diese, eigentlich für den Einsatz in Unternehmen gedachte Hardware ist zwar weniger leistungsfähig als normale PCs, aber statt dessen mit Vorzügen ausgestattet wie platzsparend zu sein und einen geringen Stromverbrauch zu bieten, daneben können sie lüfterlos und somit leise sein. Dennoch sind die meisten Thin Clients mit einer AMD- oder Intel-CPU ausgestattet, somit kann jedes kompatible Betriebssystem darauf eingesetzt werden. Üblicherweise wird von den Herstellern ein eigenes, auf Linux oder Windows (Embedded) basierendes System mitgeliefert, aber weder dies, noch der Betrieb mit spezieller Basissoftware auf dem Server sind hier relevant, schließlich soll das Gerät mit OPNsense bestückt werden.

Allerdings ist nicht jeder Thin-Client geeignet. Das fertige System muss mindestens zwei, besser drei oder mehr Netzwerk-Schnittstellen besitzen. Standardmäßig ist meist ein Netzwerk-Anschluss auf dem Mainboard des Thin-Clients vorhanden, somit muss eine Erweiterung der Anschlüsse mittels Netzwerkkarte möglich sein, was die Verfügbarkeit eines (PCIe-)Steckplatzes voraussetzt.

Thin-Client Fujitsu Futro S920

Beispielsweise erfüllen die Fujitsu Thin Clients der Typen Futro S900 oder Futro S920 diese Voraussetzungen, und tatsächlich werden sie auch gerne für genau diesen Einsatzzweck verwendet. So finden sich zahlreiche Artikel, die den Auf- und Umbau beschreiben, die Hardware vorstellen usw.. Das geht so weit, dass aktuell nahezu kein Thin-Client Futro S920 auf Ebay verfügbar ist, und wenn doch, dann nur in schlechter Ausstattung, zu überteuerten Preisen, oder alles gleichzeitig. Dagegen ist der Fujitsu Futro S900 bereits ab etwa 15,- EUR erhältlich. Zum Zeitpunkt, als ich meine Exemplare des Futro S920 erstanden habe, lag der Preis bei knapp über 50,- EUR, viel mehr würde ich auch heute dafür nicht ausgeben. Schließlich ist es immer noch gebrauchte Hardware, die aus Unternehmens-Beständen stammt, dort längst abgeschrieben oder deren Leasing-Vertrag ausgelaufen ist, und nun von spezialisierten Unternehmen “refurbished” werden. Also im besten Fall zumindest, d.h. generalüberholt, gereinigt und geprüft. Der gewerbliche Verkäufer muss darauf im Übrigen mindestens 12 Monate Gewährleistung bieten. Und nicht zuletzt ist im Sinne der Nachhaltigkeit und Schonung von Ressourcen die Weiterverwendung von gebrauchter Hardware natürlich ebenfalls zu begrüßen.

Was das Innere der Geräte anbetrifft, waren meine bisherigen Erfahrungen durchweg positiv. Zwar findet sich mitunter noch das eine oder andere Staubkorn, aber größtenteils war die Hardware tatsächlich gereinigt – oder wurde in einer fusselfreien Umgebung betrieben. Von außen war leider der eine oder andere wirklich störende Aufkleber vorhanden, oder aber Klebereste, die sich dem Versuch der Entfernung widersetzt hatten. Daher empfehle ich, ein wenig Isopropanol nebst Wattepads für die Reinigung bereit zu halten.

Die Hardware-Komponenten für die Firewall

Zusätzlich zum Thin-Client wurden noch weitere Komponenten benötigt, die Einkaufsliste in aller Kürze:

Anzahl Bezeichnung Preis (ca.)
2 Thin-Client Fujitsu Futro S920 50 – 60 EUR
2 Netzwerkkarte Intel PRO/1000 PT Quad-Port Server Adapter LP 25 – 35 EUR
2 Fujitsu Riser Card D3318 30 EUR
2 mSATA SSD 30 EUR

 

Die genannten Preise verstehen sich als ungefähre Angaben zum Zeitpunkt des Kaufs, je nach Händler kommen Versandkosten hinzu. Mehr würde ich persönlich für die Bestandteile auch nicht ausgeben, aktuell finden sich bei Ebay jedoch Angebote für den Fujitsu Futro S920, die mit über 200,- und sogar über 300,- EUR jenseits von Gut und Böse liegen. Zum Vergleich – neue Exemplare des Typs Futro S930, die noch einmal eine höhere Prozessorleistung bieten, sind ab etwa 130,- EUR verfügbar.

Thin-Client Fujitsu Futro S920

Im Thin-Client Fujitsu Futro S920 steckt meist ein AMD GX-415GA SOC mit integrierter Radeon HD 8330E Grafik, wobei Letztere für den Betrieb als Router oder Firewall völlig irrelevant ist. Laut Datenblatt sind auch weitere Ausstattungsvarianten verfügbar, wobei die Optionen GX-424CC und GX-222GC eher selten zu finden sind. Die RAM-Ausstattung kann variieren, in diesem Fall gilt je mehr, desto besser, ich würde somit zu den maximal möglichen 4 GB RAM raten. Als Massenspeicher kommen Flash-SSDs im mSATA-Format zum Einsatz. Bei den von mir erstandenen Exemplaren bestand die Ausstattung aus 8 GB SSDs. Obwohl dies für OPNsense vollkommen ausreichend ist, tatsächlich belegt das komplette System gerade einmal 2,1 GB, habe ich mich für den Kauf von neuen SSDs entschieden. Der hauptsächliche Grund dafür ist, dass ich SSDs als Verschleißteile ansehe, und beim Kauf nicht bekannt ist, wie lange diese bereits im Einsatz waren bzw. wie viele Schreibzyklen bereits stattgefunden haben. Und nicht zuletzt sind selbst wesentlich größere SSDs günstig zu erhalten, und bieten nebenbei noch Reserve für weitere Anwendungen, umfassende Logfiles etc..

Massenspeicher mSATA SSDs

Für jeweils ca. 30 EUR habe ich daher die Kingston SUV500MS mit 120 GB und die Transcend Highspeed TS128GMSA230S mit 128 GB erstanden. Die Wahl unterschiedlicher Typen bzw. Hersteller erfolgte aus dem Grund, dass ich die Hoffnung habe, dass ein möglicher Ausfall nicht zum selben Zeitpunkt stattfindet.

Riser-Card Fujitsu D3318

Zu guter Letzt fehlt noch eine Netzwerkkarte, die mittels PCIe-Schnittstelle angeschlossen wird. Das Mainboard des Futro S920 besitzt eine solche Schnittstelle, jedoch ist diese nur mittels Riser-Card nutzbar, da aufgrund des flachen Gehäuses die Karte parallel zum Mainboard und somit um 90 Grad gedreht erfolgen muss. Beim Kauf meiner Thin-Client-Exemplare war eine solche Riser-Card nicht enthalten, was auch den Standardfall darstellen dürfte. Fujitsu bietet dafür die Riser-Card mit der Bezeichnung D3318 an. Tatsächlich habe ich auf diese Lösung zurück gegriffen, da mir nicht bekannt war, ob Riser-Cards anderer Hersteller zu den Gehäuse-Abmessungen des Futro S920 passen würden. Für einen eher simplen Adapter auf einer Leiterplatte ca. 30 EUR auszugeben, mag im ersten Moment nicht angebracht wirken, aber immerhin handelte es sich um eher seltene Original-Ersatzteile.

Netzwerkkarte Intel Pro/1000 PT Quad Port

Als Netzwerkkarte kommt eine Intel Pro/1000 PT PCIe-Karte zum Einsatz, hier mit vier Ports, auch als Quad Port bezeichnet. Varianten mit zwei Ports gibt es zu Preisen ab ca. 15 EUR, vier Ports sind für ungefähr den doppelten Preis zu erhalten. Ob diese nun ein Branding von Fujitsu, IBM oder auch gar keines besitzen, ist letztlich nicht entscheidend, da letztlich derselbe Intel-Chipsatz zum Einsatz kommt. Es muss sich jedoch um eine Low-Profile-Karte (LP) handeln, da das Gehäuse des Futro S920 nur eingeschränkt Platz bietet.

Wie versprochen: Das Bilderbuch

Das folgende Foto zeigt das Innenleben des Fujitsu Futro S920. Die mSATA-SSD (Mitte, links) und die Riser-Card sind bereits eingebaut. Das RAM-Modul befindet sich unten links, der CPU-Kühler dominiert das Mainboard, wobei kein Lüfter zum Einsatz kommt, das gesamte System somit passiv gekühlt wird.

Hochverfügbare Firewall mit Thin-Client Fujitsu Futro S920 und OPNsense 1

Aus dieser Perspektive ist die Riser-Card etwas besser zu erkennen:

Hochverfügbare Firewall mit Thin-Client Fujitsu Futro S920 und OPNsense 2

Nach Einbau der Netzwerkkarte (oben) wirkt das System schon etwas gefüllter:

Hochverfügbare Firewall mit Thin-Client Fujitsu Futro S920 und OPNsense 3

Mit dem auf dem Mainboard enthaltenen RJ-45-Netzwerk-Anschluss stehen nun insgesamt fünf RJ-45-Ports zur Verfügung:

Hochverfügbare Firewall mit Thin-Client Fujitsu Futro S920 und OPNsense 4

Und fertig – im Vordergrund einer der neuen Thin-Clients Futro S920, im Hintergrund die vorherige Generation Fujitsu Futro S900.

Hochverfügbare Firewall mit Thin-Client Fujitsu Futro S920 und OPNsense 5

Verkabelt, gelabelt, aufgebaut, und eingeschaltet:

Hochverfügbare Firewall mit Thin-Client Fujitsu Futro S920 und OPNsense 6

OPNsense auf dem Fujitsu Futro S920

Bei der Einrichtung bin ich letztlich nach der Anleitung von OPNsense vorgegangen. Nach dem Download und der Verifikation der Prüfsumme (SHA256) des OPNsense-USB-Installer-Images (Typ vga) muss zunächst ein USB-Speicherstick damit bestückt werden. Dafür habe ich das Tool Rufus in der portablen Version eingesetzt, eine Installation ist somit nicht notwendig.

Je nach vorheriger Einstellung bootet der Futro S920 von der internen Festplatte, oder versucht auch gerne, im Netz ein Boot-Image zu finden. Die Boot-Reihenfolge kann im BIOS gewählt werden, bzw. man gelangt in ein Boot-Menü durch das Drücken der entsprechenden Funktionstasten während des Systemstarts. Das Boot-Menü kann mittels F12 erreicht werden, von dort ist auch die Möglichkeit vorhanden, ins BIOS zu springen, um beispielsweise dessen Einstellungen auf die Defaults zurück zu setzen. Der USB-Stick sollte im Boot-Menü angezeigt werden, nach Wahl desselben erscheint nach kurzer Zeit die Installer-Console. Die Installation ist tatsächlich eine Sache von Minuten, die meisten Standard-Einstellungen können beibehalten werden. Die einzige Änderung bestand bei mir in der Angabe einer vom Standard 192.168.1.1 abweichenden IP-Adresse, damit das System in meinem LAN erreicht werden konnte.

Alle Komponenten, d.h. insbesondere die Netzwerkkarte und deren Anschlüsse wurden korrekt erkannt, wobei die Schnittstelle auf dem Mainboard unter dem Namen “re0” zu finden ist, während die Intel-Karte die Bezeichnungen “em0” bis “em3” erhält, dabei werden die Interfaces von oben nach unten durchnummeriert.

Da ich bereits die vorherige Generation Futro S900 im Einsatz hatte, OPNsense dort wie gewünscht lief, wollte ich ausprobieren, ob sich die Konfiguration einfach übernehmen ließ. OPNsense bietet die Möglichkeit, die komplette Konfiguration als XML-Datei herunterzuladen und dieses Backup auch wieder einzuspielen (System -> Konfiguration -> Sicherungen). Da auch zuvor bereits Intel-Netzwerkkarten im Einsatz waren, so dass OPNsense die Schnittstellen ebenfalls als em0 und em1 bezeichnete, stand dem Versuch der direkten Übernahme auch nichts im Wege. Tatsächlich funktionierte es auf Anhieb, d.h. zunächst Konfiguration des ersten Systems sichern, dann auf dem neuen primären System wiederherstellen. So einfach und problemlos wie man es sich nur wünschen konnte! Nach dem Reboot war der Futro S920, der nun das neue, primäre System darstellen sollte, bereits vollständig einsatzbereit. Mit dem zweiten System funktionierte dies in genau derselben Art und Weise, auch hier wurden alle Einstellungen übernommen, so dass keine weitergehende Konfiguration mehr notwendig war. Natürlich empfiehlt es sich, die Einstellungen anschließend genau zu prüfen.

Hochverfügbarkeit mit zwei Systemen und ein paar Protokollen

Auf den Aspekt der Hochverfügbarkeit möchte ich noch kurz eingehen. Wie beschrieben, laufen zwei Systeme parallel, bzw. genau genommen handelt es sich um ein Master- und ein Backup-System. Detaillierte Hinweise finden sich im Abschnitt über High Availability im OPNsense-Manual. Dabei sind das primäre bzw. Master- und das sekundäre, d.h. Backup-System über eine Netzwerk-Schnittstelle direkt verbunden, in meinem Fall über den zweiten Port der Netzwerkkarte, als em1 bezeichnet.

Dabei erfolgt die Zuweisung der entsprechenden Schnittstelle in der Konfiguration:

Hochverfügbare Firewall mit Thin-Client Fujitsu Futro S920 und OPNsense 7

Die Schnittstellen erhalten in OPNsense eigene, sprechende Namen, in dem Fall “LAN“, “WAN_FritzBox” oder “PFSYNC“. Dabei dient das pfSync-Protokoll zur Synchronisierung des Firewall-Status, so dass ein unterbrechungsfreier Betrieb möglich ist. Bei Ausfall des ersten Systems übernimmt das Backup-System nahtlos den Betrieb. Mt pfSync einher geht die Verwendung von CARP (Common Address Redundancy Protocol). Die Firewalls besitzen dabei virtuelle IP- und MAC-Adressen, über die die Kommunikation mit den Clients, d.h. allen Rechnern im Netz, erfolgt. Als Gateway-Adresse der Clients, die sie z.B. per DHCP erhalten, fungiert somit diese virtuelle IP-Adresse anstatt der echten IP-Adresse einer der Firewall-Maschinen. Fälle nun das Master-System aus, bemerkt das bisherige Backup-System diesen Ausfall und übernimmt die virtuelle IP. Ist der Master wieder verfügbar, erfolgt automatisch die umgekehrte Übernahme, die virtuelle IP wird also wieder den Master zugeordnet. Zur Konfiguration im Detail finden sich ausführliche Hinweise in der Anleitung von OPNsense.

Hochverfügbare Firewall mit Thin-Client Fujitsu Futro S920 und OPNsense 8

Die UI von OPNsense besitzt ein Dashboard, in dem alle Informationen übersichtlich zusammengefasst sind:

Hochverfügbare Firewall mit Thin-Client Fujitsu Futro S920 und OPNsense 9

In diesem Beispiel ist die PFSYNC-Schnittstelle noch nicht einsatzbereit, das zweite System war hier noch nicht aktiv, wurde neu gestartet oder ähnliches.

Hochverfügbare Firewall mit Thin-Client Fujitsu Futro S920 und OPNsense 10

Hier zeigen sich einerseits die Schnittstellen “grün”, alles funktioniert wie gewünscht, andererseits ist hier eine kleine Unschönheit zu finden. Denn nach dem letzten Upgrade auf die neueste OPNsense-Version sind die Titel der Dashboard-Bereiche nicht mehr so wie zuvor… Ein nächstes Update dürfte dies wahrscheinlich wieder beheben.

OPNsense – mein Fazit

Insgesamt kann ich OPNsense uneingeschränkt empfehlen. Während der letzten knapp zwei Jahres gab es weder größere, noch kleinere Probleme. Die zuvor eingesetzte Hardware in Form zweier Fujitsu Futro S900 hat sich ebenfalls bewährt, und ich gehe davon aus, dass dies in gleicher Weise für die aktuellen Futro S920 Systeme gilt. Auch wenn OPNsense störungsfrei im Hintergrund agiert, sollte man ab und wann einen Blick darauf werfen, um etwaige Updates einzuspielen. Da auch ein Reboot des Masters nicht zum Ausfall der Verbindung führt, werden die Teilnehmer im Netzwerk gar nichts davon bemerken.

 

10 Gedanken zu „Hochverfügbare Firewall mit Thin-Client Fujitsu Futro S920 und OPNsense“

  1. Moin, das sieht nach einer günstigen guten Opnsense Hardware aus.
    Ich habe da 3 Fragen.
    Unterstützt die CPU AES-NI?
    Was für ein Durchsatz bekommst du mit dieser Konfiguration?
    Die Riser-Card Fujitsu D3318 scheint man leider nirgends zu bekommen. Hast ein Tipp wo man die bekommt?

    1. Laut einschlägiger CPU-Info-Seiten wird AES vom AMD GX-415GA SOC unterstützt. Den Durchsatz habe ich nicht gemessen, ich hänge an einem 100 MBit-DSL-Anschluss, damit hatte ich jedenfalls keine Probleme, soll heißen, der maximale Durchsatz der Leitung wird locker erreicht. Wie das aussieht, wenn auf der Firewall als VPN-Client dient, kann ich Dir jedoch nicht sagen, zwar verwende ich WireGuard, aber nicht auf dem OPNsense-Node.
      Die Riser-Card hatte ich von Immel Datentechnik GmbH, aber der Shop listet sie aktuell nicht mehr. Eine andere Empfehlung habe ich leider nicht, am besten mal suchen, vielleicht finden sich noch Restbestände. Und sicherlich ist es auch möglich, andere Riser-Cards zu nutzen, bei meiner Suche bin ich auf eine “DeLock Riser Card” gestoßen, wollte da aber nicht erst ausprobieren und ggf. feststellen, dass sie zu kurz ist o.ä..

      1. Habe den Delock Riser probiert.
        https://geizhals.de/53102152
        Höhe ist ok, auf Grund der Länge des Risers passt er aber erstmal nicht ins Gehäuse, ist zu lang.
        Da der Riser nur 15€ kostet, hab ich nen Stück (1-2cm) von der Platine abgeschnitten. Am Ende der Platine sind keine Leiterbahnen, das passt also.
        Habe nen Teppichmesser genommen und auf jeder Seite der Platine ca 10-15x eingeritzt und am Ende vorsichtig gebrochen. Wenn es zu viel Kraft erfordert, lieber nochmal nen Stück weiter mit dem Messer einritzen.

        Hab jetzt eine Quad-Port NIC mit Broadcom BCM5719 (35€ bei ebay) in ein Futro S930 (99€ bei ebay) verbaut und soweit keine Probleme in ersten Belastungstests. Das Gerät ist aber noch nicht effektiv im Einsatz.

        Grüße!

        1. Danke für den Link!

          Kannst du einschätzen wie lang die Riser-Card höchstens sein darf? Die originale ist aktuell sehr schwer zu finden.

  2. Hallo,
    können auch m-SATA SSDs mit längerer Bauform eingebaut werden, oder kollidiert das dann mit dem CPU-Kühler. Danke und Gruß Christoph

    1. Hallo!

      Evtl. kannst Du eine Antwort aus dem zweiten Foto im Beitrag erhalten. An der rechten Seite des CPU-Kühlers ist der Anschluss für die mSATA-SSD, somit kann es nicht weiter nach rechts gehen. Und links dürfte zwischen SSD und den Pins des mir unbekannten Anschlusses gerade mal 1 cm Platz sein, insofern würde ich darauf tippen, dass es nicht möglich ist (mir sind momentan auch keine längeren mSATA-SSDs bekannt).
      Ich meine aber, in irgendeinem Blog-Beitrag gesehen zu haben, wie eine 2,5″-Festplatte bzw. -SSD eingebaut wurde, dafür wäre neben bzw. unterhalb der Netzwerkkarte noch Platz, kann mich aber nicht erinnern, welcher Anschluss dafür verwendet wurde (evtl. sogar ein USB-Anschluss von außen nach innen gezogen für eine “externe” Platte?).

      Beste Grüße,
      Ralf

  3. Danke für dein Feedback. Ich möchte einen Futro S920 mit einer SSD zum NAS umbauen. Ich denke es wird darauf hinauslaufen, dass ich per Riser-Card eine PCIe 4x Karte für M.2 SSDs einsetzen werde. Die Futros sind echt ein Geheimtipp, schaut man sich derzeit die Preise für Raspberry PIs an. Auch die Leistung erscheint mir etwas höher.

  4. Hi

    Hast du irgend welche einstellungen für die Netzwerkkarte vorgenommen?
    Ich habe ein Futro S930 mit der scheinbar gleichen Quad Netzwerkkarte wie du auch hast (Intel (IBM) 45W1959 und dem Chip 82571EB). Leider startet der Rechner ohne Log eintrag einfach neu sobald etwas Netzwerklast erzeugt wird.

    Egal ob Opnsense oder Pfsense… Laut Internet ist der Bug bekannt aber es wurde wohl keine Lösung gefunden.
    https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240944

    Gruß

    Nils

    1. Hallo!

      Danke für den Hinweis, Einstellungen habe ich tatsächlich keine vorgenommen, die Maschinen rennen seit der Einrichtung bei mir ohne Probleme. Hier der Output von pciconf und dmesg, vielleicht war auf den Exemplaren im BIOS oder so bereits etwas geändert?


      root@zarrentin:~ # pciconf -l -vbc
      [...]
      em0@pci0:3:0:0: class=0x020000 card=0x11bc8086 chip=0x10bc8086 rev=0x06 hdr=0x00
      vendor = 'Intel Corporation'
      device = '82571EB/82571GB Gigabit Ethernet Controller (Copper)'
      class = network
      subclass = ethernet
      bar [10] = type Memory, range 32, base 0xfe8a0000, size 131072, enabled
      bar [14] = type Memory, range 32, base 0xfe880000, size 131072, enabled
      bar [18] = type I/O Port, range 32, base 0xd020, size 32, enabled
      cap 01[c8] = powerspec 2 supports D0 D3 current D0
      cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message
      cap 10[e0] = PCI-Express 1 endpoint max data 256(256) NS
      link x4(x4) speed 2.5(2.5) ASPM disabled(L0s)
      ecap 0001[100] = AER 1 0 fatal 1 non-fatal 0 corrected
      ecap 0003[140] = Serial 1 001b...
      em1@pci0:3:0:1: class=0x020000 card=0x11bc8086 chip=0x10bc8086 rev=0x06 hdr=0x00
      vendor = 'Intel Corporation'
      device = '82571EB/82571GB Gigabit Ethernet Controller (Copper)'
      class = network
      subclass = ethernet
      bar [10] = type Memory, range 32, base 0xfe840000, size 131072, enabled
      bar [14] = type Memory, range 32, base 0xfe820000, size 131072, enabled
      bar [18] = type I/O Port, range 32, base 0xd000, size 32, enabled
      cap 01[c8] = powerspec 2 supports D0 D3 current D0
      cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message
      cap 10[e0] = PCI-Express 1 endpoint max data 256(256) NS
      link x4(x4) speed 2.5(2.5) ASPM disabled(L0s)
      ecap 0001[100] = AER 1 0 fatal 1 non-fatal 0 corrected
      ecap 0003[140] = Serial 1 001b21...
      em2@pci0:4:0:0: class=0x020000 card=0x11bc8086 chip=0x10bc8086 rev=0x06 hdr=0x00
      vendor = 'Intel Corporation'
      device = '82571EB/82571GB Gigabit Ethernet Controller (Copper)'
      class = network
      subclass = ethernet
      bar [10] = type Memory, range 32, base 0xfe7a0000, size 131072, enabled
      bar [14] = type Memory, range 32, base 0xfe780000, size 131072, enabled
      bar [18] = type I/O Port, range 32, base 0xc020, size 32, enabled
      cap 01[c8] = powerspec 2 supports D0 D3 current D0
      cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message
      cap 10[e0] = PCI-Express 1 endpoint max data 256(256) NS
      link x4(x4) speed 2.5(2.5) ASPM disabled(L0s)
      ecap 0001[100] = AER 1 0 fatal 1 non-fatal 0 corrected
      ecap 0003[140] = Serial 1 001b2...
      em3@pci0:4:0:1: class=0x020000 card=0x11bc8086 chip=0x10bc8086 rev=0x06 hdr=0x00
      vendor = 'Intel Corporation'
      device = '82571EB/82571GB Gigabit Ethernet Controller (Copper)'
      class = network
      subclass = ethernet
      bar [10] = type Memory, range 32, base 0xfe740000, size 131072, enabled
      bar [14] = type Memory, range 32, base 0xfe720000, size 131072, enabled
      bar [18] = type I/O Port, range 32, base 0xc000, size 32, enabled
      cap 01[c8] = powerspec 2 supports D0 D3 current D0
      cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message
      cap 10[e0] = PCI-Express 1 endpoint max data 256(256) NS
      link x4(x4) speed 2.5(2.5) ASPM disabled(L0s)
      ecap 0001[100] = AER 1 0 fatal 1 non-fatal 0 corrected
      ecap 0003[140] = Serial 1 001b2...


      root@zarrentin:~ # dmesg
      ---<>---
      Copyright (c) 2013-2019 The HardenedBSD Project.
      Copyright (c) 1992-2019 The FreeBSD Project.
      Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
      The Regents of the University of California. All rights reserved.
      FreeBSD is a registered trademark of The FreeBSD Foundation.
      FreeBSD 12.1-RELEASE-p20-HBSD #0 4dbd2ffa241(stable/21.7)-dirty: Tue Oct 26 08:46:43 CEST 2021
      root@sensey:/usr/obj/usr/src/amd64.amd64/sys/SMP amd64
      FreeBSD clang version 8.0.1 (tags/RELEASE_801/final 366581) (based on LLVM 8.0.1)
      VT(vga): resolution 640x480
      HardenedBSD: initialize and check features (__HardenedBSD_version 1200059 __FreeBSD_version 1201000).
      CPU: AMD GX-415GA SOC with Radeon(tm) HD Graphics (1497.22-MHz K8-class CPU)
      Origin="AuthenticAMD" Id=0x700f01 Family=0x16 Model=0x0 Stepping=1
      Features=0x178bfbff
      Features2=0x3ed8220b
      AMD Features=0x2e500800
      AMD Features2=0x154037ff
      Structured Extended Features=0x8
      XSAVE Features=0x1
      SVM: NP,NRIP,AFlush,DAssist,NAsids=8
      TSC: P-state invariant, performance statistics
      [...]
      em0: port 0xd020-0xd03f mem 0xfe8a0000-0xfe8bffff,0xfe880000-0xfe89ffff irq 27 at device 0.0 on pci3
      em0: Using 1024 TX descriptors and 1024 RX descriptors
      em0: Using an MSI interrupt
      em0: Ethernet address: 00:1b:xx:xx:xx:xx
      em0: netmap queues/slots: TX 1/1024, RX 1/1024
      em1: port 0xd000-0xd01f mem 0xfe840000-0xfe85ffff,0xfe820000-0xfe83ffff irq 26 at device 0.1 on pci3
      em1: Using 1024 TX descriptors and 1024 RX descriptors
      em1: Using an MSI interrupt
      em1: Ethernet address: 00:1b:xx:xx:xx:xx
      em1: netmap queues/slots: TX 1/1024, RX 1/1024
      pcib4: at device 4.0 on pci2
      pci4: on pcib4
      em2: port 0xc020-0xc03f mem 0xfe7a0000-0xfe7bffff,0xfe780000-0xfe79ffff irq 25 at device 0.0 on pci4
      em2: Using 1024 TX descriptors and 1024 RX descriptors
      em2: Using an MSI interrupt
      em2: Ethernet address: 00:1b:xx:xx:xx:xx
      em2: netmap queues/slots: TX 1/1024, RX 1/1024
      em3: port 0xc000-0xc01f mem 0xfe740000-0xfe75ffff,0xfe720000-0xfe73ffff irq 24 at device 0.1 on pci4
      em3: Using 1024 TX descriptors and 1024 RX descriptors
      em3: Using an MSI interrupt
      em3: Ethernet address: 00:1b:xx:xx:xx:xx
      em3: netmap queues/slots: TX 1/1024, RX 1/1024
      [...]
      em0: link state changed to UP
      intsmb0: at device 20.0 on pci0
      smbus0: on intsmb0
      lo0: link state changed to UP
      aesni0: on motherboard
      em1: link state changed to UP
      em1: link state changed to DOWN
      em0: link state changed to DOWN
      em0: promiscuous mode enabled
      carp: demoted by 240 to 240 (interface down)
      carp: demoted by 240 to 480 (pfsync bulk start)
      em0: deletion failed: 3
      em0: deletion failed: 3
      em0: deletion failed: 3
      re0: promiscuous mode enabled
      carp: demoted by 240 to 720 (interface down)
      carp: 3@re0: INIT -> BACKUP (initialization complete)
      carp: demoted by -240 to 480 (interface up)
      re0: link state changed to UP
      re0: deletion failed: 3
      re0: deletion failed: 3
      re0: deletion failed: 3
      carp: 3@re0: BACKUP -> INIT (hardware interface up)
      re0: promiscuous mode disabled
      re0: promiscuous mode enabled
      carp: 3@re0: INIT -> BACKUP (initialization complete)
      em1: link state changed to UP
      pflog0: permanently promiscuous mode enabled
      carp: 1@em0: INIT -> BACKUP (initialization complete)
      carp: demoted by -240 to 240 (interface up)
      em0: link state changed to UP
      carp: 1@em0: BACKUP -> MASTER (master timed out)
      carp: demoted by -240 to 0 (pfsync bulk done)
      WARNING: attempt to domain_add(netgraph) after domainfinalize()
      carp: 3@re0: BACKUP -> MASTER (preempting a slower master)

      Was mich ein wenig wundert, ist die Angabe der AMD-Mikroarchitektur in dem Bugzilla-Eintrag. Dort werden ausdrücklich “Steamroller” und “Piledriver” genannt. Wenn ich es richtig sehe, gehört die CPU AMD GX-415GA aus dem Futro S920 hingegen zu “Jaguar”, wobei die CPU in Deinem S930 zu “Puma” gehören müsste. Trotz der Übersicht alles ein wenig verwirrend, denn beide haben anscheinend denselben Ursprung (“Bobcat”), nur ist die in Deinem S930 etwas neuer, während die im Bug-Eintrag genannten auf “Bulldozer” zurückgehen.

      Verglichen mit einem der im Bugzilla-Eintrag angegebenen Outputs von pciconf ist mir folgendes aufgefallen:


      cap 10[e0] = PCI-Express 1 endpoint max data 256(256) NS
      link x4(x4) speed 2.5(2.5) ASPM disabled(L0s)

      ASPM (Active-state power management) ist bei den Geräten hier somit abgeschaltet. (Ich war’s nicht! 😀 ) Das wird im Bugzilla-Eintrag zum Schluss thematisiert, evtl. kannst Du das bei Dir prüfen.

      Viel Erfolg & Beste Grüße!

  5. Hi

    Bei mir ist ASPM aktiviert wie in dem Bug Report… Sonst sieht es eigentlich so aus wie bei dir… Kann gerade leider keinen Auszug hier rein posten.

    Leider habe ich im Bios und im Netz keine möglichkeit gefunden das ganze zu deaktivieren. Unter Linux mit Grub wäre es ja einfach pcie_aspm=off”, für FreeBSD habe ich nichts ähnliches gefunden.

    Ich denke ich werde mich mal nach einer anderen Netzwerkkarte umsehen müssen.

    Trotzdem Danke für die Hilfe 🙂

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Tags: