pfSense 2.5 EEE Problem

haithabu84

Hallo,

ich habe heute bei pfSense 2.5.1 ein interessantes Phänomen beobachtet:

Wenn man in den Tunables oder per sysctl das EEE für igb NIC deaktivieren möchte, dann hängen sich diese weg. Es geht dann kein Traffic mehr raus, sie sind aber nach wie vor als "UP" gekennzeichnet.

Im syslog konnte ich folgenden Fehler ausmachen:

pfSense kernel: arpresolve: can't allocate llinfo for 136.20.110.22 on igb0

Ich habe eine Art Multi-WAN (Einmal normale Datenverbindungen, einmal SIP-Anbindung) konfiguriert und egal ob man es nur für eine oder zwei Schnittstellen konfiguriert, alle Schnittstellen am Controller frieren ein. Ich muss dann auf der CLI jeweils ein:

ifconfig igb down
ifconfig igb up

ausführen, danach funktionieren diese wieder. Wenn man das nicht weiß, ist das ein ganzer schöner Fallstrick und man sucht erstmal an anderer Stelle, da es so ein Verhalten in 2.4.5p1 nicht gegeben hat.

Hat jemand ein ähnliches Problem gehabt? Ist das überhaupt bekannt? Soll das so sein?

Gruß

JeGr

@haithabu84 Wenn du am HW Treiber des NICs Änderungen machst, kann es immer sein, dass der NIC resettet werden muss. Es steht nicht umsonst auch bei den Optionen für Flow Control etc. in der GUI, dass es sein kann, dass das System dann neu gestartet werden muss. Wenn man also so eine Tunable setzt muss man damit rechnen.

Soll das so sein: Soll natürlich nicht, aber da das Treiber/Interfaceabhängig ist, kann da pfSense wenig dafür/dagegen tun. Da sind wir auf OS/HW Ebene. Und da ist es bei Custom HW oft "YMMV" - kann bei jedem anders sein. Ich kenne Boxen bei denen flog beim Rausnehmen der Hardware Checksum Offloading die Box weg. Neustart notwendig, danach alles super. Andere Boxen schlucken das nach ein paar Sekunden einfach und machen Business as usual. Immer sehr HW abhängig.

Randnotiz: ich habe das EEE vom Intel Treiber noch nie anfassen müssen. Wüsste auch nicht warum, es gab hier noch nie Probleme. Dass das ggf. in 2.4.5 anders ist, kann Treiber-geschuldet sein, das muss nichts mit pfSense selbst zu tun haben, weswegen von dort auch keine Warnung kommen kann. Intel hatte sich ja leider mit ein paar Treiberänderungen der letzten Zeit nicht ganz so sehr mit Ruhm bekleckert (X520 und IXL seien als Beispiel genannt).

Cheers

haithabu84

@jegr In 2.4.5 musste ich mir den Treiber für ixl selbst kompilieren. Da der mitgelieferte absolut grottig lief. Also Treiber Source von Intel geladen und mit FreeBSD 11.3 Header erstellt.

Lief dann sehr sauber für ein dreivirtel Jahr. Nun hatte ich Bauchschmerzen wegen dem OpenSSL-Bug und bin deshalb zu 2.5.1 und finde hier gravierende Bugs vor. Das da jede Hardware anders reagiert unter Umständen... geschenkt. Aber das hier sogut wie kein Repsonse kommt und alle Schnittstellen vom Controller betroffen sind, zumindest fragwürdig. Auch das Problem mit dem Multi-WAN ist eine interessante Angelegenheit. Seitdem ich pfSense einsetze (5 Jahre), nie Probleme gemacht und nun sowas. Aber das nur am Rande. Soviel zum Thema "stable".

Das EEE muss ich abschalten da die Glasfaser-Modems von meinem Anbieter dies entweder nicht aktiv haben oder schlecht implementiert. Es kam schon unter 2.4.5 zu dauerhaften sporadischen Paketverlusten. Sobald EEE deaktiviert wurde, lief alles sauber. Das selbe Bild zeichnet sich auch unter 2.5.1, deshalb habe ich daran überhaupt herumgewerkelt.

JeGr

@haithabu84 said in pfSense 2.5 EEE Problem:

@jegr In 2.4.5 musste ich mir den Treiber für ixl selbst kompilieren. Da der mitgelieferte absolut grottig lief. Also Treiber Source von Intel geladen und mit FreeBSD 11.3 Header erstellt.

Lief dann sehr sauber für ein dreivirtel Jahr. Nun hatte ich Bauchschmerzen wegen dem OpenSSL-Bug und bin deshalb zu 2.5.1 und finde hier gravierende Bugs vor. Das da jede Hardware anders reagiert unter Umständen... geschenkt. Aber das hier sogut wie kein Repsonse kommt und alle Schnittstellen vom Controller betroffen sind, zumindest fragwürdig. Auch das Problem mit dem Multi-WAN ist eine interessante Angelegenheit. Seitdem ich pfSense einsetze (5 Jahre), nie Probleme gemacht und nun sowas. Aber das nur am Rande. Soviel zum Thema "stable".

Das EEE muss ich abschalten da die Glasfaser-Modems von meinem Anbieter dies entweder nicht aktiv haben oder schlecht implementiert. Es kam schon unter 2.4.5 zu dauerhaften sporadischen Paketverlusten. Sobald EEE deaktiviert wurde, lief alles sauber. Das selbe Bild zeichnet sich auch unter 2.5.1, deshalb habe ich daran überhaupt herumgewerkelt.

OK Modemprobleme sehe/verstehe ich. Ist natürlich aber nicht schön und wäre ggf. auch ein Punkt den man mit dem ISP klären könnte? Nur als Frage.

Was die restlichen Punkte angeht: schwierig. Ja, 2.5.0 und .1 waren keine Meisterleistungen an Stabilität. Wobei man sagen muss, 2.5 war abgesehen von dem ganzen IPsec Chaos eigentlich ein recht guter Wurf initial. Dass dann der Wireguard Kram, OpenSSL und Co für 2.5.1 kamen und das gepusht wurde, OK. Wo und warum sich der Kernel/Filtering Bug als Regression (als das wird er geführt) in 2.5.1 wieder eingeschlichen hat (ja den gabs schonmal in der Vergangenheit und in der FE/Plus Version), weiß ich nicht, da fehlt mir die Einsicht. Aber sowas kommt - so ärgerlich es ist - vor. Klar kann man jetzt meckern bezüglich "Stabilität" - mach ich auch :) Aber wie du sagst, 5 Jahre gabs eher weniger Probleme. Wobei ich da sagen muss, da gab es zu 2.3 und 2.4 Zeiten auch schonmal solche Würfe. Hast du anscheinend nicht mitbekommen - lucky you - da wurde auch mal hie und da geflucht. Man hat eben immer mal solche Montagsgeschichten.

Und nein, ich denke weder dass das ein Zeichen ist, noch dass das was mit Plus zu tun hat, noch sonstwas. Plus hat seine eigenen Schwierigkeiten aktuell und mit 21.02 gehabt - die ARM User wissen was ich meine - und selbst aktuell gibts noch seltsame Effekte auf 21.05 zu beobachten, die man nicht ganz sortieren kann. Alle haben da wohl mit FreeBSD 12 UND zugleich mit mehreren großen Package Updates zu kämpfen. OVPN ist 2.5 geworden. Strongswan wurde stark aktualisiert und anders angesprochen nach zig Jahren. Das sind alles große Brocken abseits von pfSense selbst, mit denen man zu kämpfen hat. Und ich sehe es sogar doppelt, da ich das gleiche wie hier auch bei OPNsense mache und dort dann zwischendurch ähnliche Schmerzen an anderer Stelle lesen.

QA wird eben immer versucht aber manchmal hat man dann sowohl als Entwickler als auch als Kunde so ein Pik Ass gezogen, dass man sich wünscht, einfach nochmal zurückzurollen. Aber man kann sichs manchmal eben nicht aussuchen - nur das beste draus machen. Und wenn ich dann sehe in den anderen Buglisten, was sich andere Firewalls leisten - dann wird das zwar nicht besser und keine Entschuldigung - aber es bekommt ein anderes Niveau bzw. Stellenwert. Und mit der 2.5.2-RC bzw. 2.6-dev sieht man ja durchaus, dass sie Volldampf dran sind, da baldmöglichst Abhilfe zu schaffen :)

@jegr In 2.4.5 musste ich mir den Treiber für ixl selbst kompilieren. Da der mitgelieferte absolut grottig lief. Also Treiber Source von Intel geladen und mit FreeBSD 11.3 Header erstellt.

Der mitgelieferte ist übrigens auch von Intel in FreeBSD 11 eingecheckt worden. Und nicht wirklich verbessert worden. Daher gabs leider eben kein Update. Da verlässt sich pfSense auch ein Stück weit auf FreeBSD, denn ansonsten müssten sie gleich alles machen und das macht die Workload natürlich auch wesentlich größer, wenn ich zukünftig auch noch alle Treiber etc. selbst managen will. Schwierige Entscheidung :/

Aber ich fühle das, wir haben gerade auch unsere Probleme mit einer Geräteserie und IXL Treibern, die sehr grottig reagieren und segfaulten.

War nicht als Belehrung oder Entschuldigung gedacht (könnte ich eh nicht - da nichts mit Netgate zu tun), sondern eher als "anderer Blickwinkel" :)

haithabu84

@jegr Ich kann einige Punkte nachvollziehen, aber dennoch ist die Enttäuschung über die Entwicklung groß. Ja, es gab auch in der Vergangenheit einige heikle Momente in Updates, aber irgendwie eher immer so in "Spezial-Konstellationen" die man so selten eingesetzt hat das sie einfach nicht ins Gewicht fielen.

Die jetzigen Fehler sind aber alle so eher vermeidbar und in dieser Situation nie dagewesen. Einfache Dinge, wie robustes PortForwarding, da gibt es keine zwei Meinungen... das muss einfach laufen.

Du kannst mir auch nicht erzählen das mit der Einführung von der Community und Plus Edition hier nicht ganz klar ein finanzieller Aspekt zum Nachteil der Community verfolgt wird. Hier werden grob gravierende Unterschiede Einzug halten zwischen diesen beiden Versionen, als wären es zwei völlig neue Produkte.

Das man jetzt Geld verdienen will damit, ist für mich OK, aber nicht die Art und Weise. Hätte man die Community zu Beta-Testern gemacht und dann die Plus Edition als Stable nachgezogen, alles andere sonst gleich, dann würde niemand was sagen. Aber hier wird eine Version, scheinbar bewusst, abgeschwächt um die Leute ins Abo oder zu den eigenen Produkten zu drängen. Aber das wird das Anfang vom Ende.

Von der beobachteten Problematik um die Einführung von WireGuard-Code von Netgate ins FreeBSD, fange ich gleich gar nicht erst an...

Btw: Letzte Chance für pfSense... das Update auf 2.5.2 und ich werde jetzt mal die Kiste von Grund auf neu machen, also ohne Tweaks oder Config-Anpassungen. Dann mal schauen wie es läuft.

JeGr

@haithabu84 said in pfSense 2.5 EEE Problem:

Die jetzigen Fehler sind aber alle so eher vermeidbar und in dieser Situation nie dagewesen. Einfache Dinge, wie robustes PortForwarding, da gibt es keine zwei Meinungen... das muss einfach laufen.

Das war aber kein "einfaches" PFW, sondern spezifisch nur bei MultiWAN / multiplen GWs. Könnte man auch als Spezialkonfiguration sehen, der normale Kunde hat nicht unbedingt mehrere Leitungen.

Du kannst mir auch nicht erzählen das mit der Einführung von der Community und Plus Edition hier nicht ganz klar ein finanzieller Aspekt zum Nachteil der Community verfolgt wird. Hier werden grob gravierende Unterschiede Einzug halten zwischen diesen beiden Versionen, als wären es zwei völlig neue Produkte.

Ich erzähle gar nichts, ich sage nur, dass das vielfach nur einfach Hörensagen und Meinungen sind, die hier gepostet werden. Tatsächlich verwertbare Punkte konnte ich bislang noch keine finden. Es wurde/wird gefixt mit entsprechender Manpower egal ob bei Plus oder CE, ansonsten gäbe es jetzt keine 2.5.2 in der Mache. Das jetzt als Aufhänger zu nehmen weil ein Release daneben ging, ist IMHO quark.

Hätte man die Community zu Beta-Testern gemacht und dann die Plus Edition als Stable nachgezogen, alles andere sonst gleich, dann würde niemand was sagen. Aber hier wird eine Version, scheinbar bewusst, abgeschwächt um die Leute ins Abo oder zu den eigenen Produkten zu drängen. Aber das wird das Anfang vom Ende.

Wo wird hier eine Version abgeschwächt? Nimmt dir jemand Features aus der CE? Nein. Es wurde klar angekündigt "Plus bekommt Firmen/Enterprise Features nach und nach". Hat sie noch nicht mal. Ich sehe da also keinen Grund jetzt ein Drama vom Zaun zu brechen wenns noch nichtmal nen Grund dafür gibt. Der kann noch kommen - natürlich. Aber aktuell ist es quatsch.

Und ob das ein kluger Move ist oder nicht, die Plus "schneller" upzudaten bzw. zu entwickeln und neues dort einzubringen sei dahingestellt. Aus Sicht der Hardware - wie in deinem erlebten Fall in deinem OP - ist GENAU das der Sinn. Man hat eine sehr schmale Hardware Palette: ARM #1, ARM #2, Atom C3xxx und Xeon-D 1st gen aktuell. Mehr nicht. Heißt ich kann extrem gut abgestimmt für genau diese Umgebungen testen und bauen. Ich kenne definiert welche Accelerator drin sind, ich weiß welche NICs verbaut sind etc. etc. - Aus Entwicklersicht macht das also völlig Sinn. Dass es nicht das ist, was man sich im OSS Umfeld wünscht à la Proxmox oder bspw. auch RedHat/Fedora ist ein anderes Blatt.

Abo oder zu den eigenen Produkten zu drängen. Aber das wird das Anfang vom Ende.

Spekulation über ein "Abos", das weder angekündigt noch bestätigt ist. Da diskutiere ich nicht, solange keiner weiß wie "Plus" überhaupt später für Whitelabel Boxen gekauft/zugebucht werden kann. Bis dahin sind es nur Unterstellungen. Zumal schon länger klar/bekannt ist, dass man als Prosumer/Poweruser oder im Lab die Plus problemlos kostenfrei bekommt - wie auch TNSR, was es sonst nur als "payed product" gibt. Da zu unterstellen, dass sie nur Geld schneidern wollen ist etwas weit hergeholt. Ne unlimitierte Lab/Testversion will ich von anderen Herstellern erstmal sehen - die richtig Kohle mit ihrem Produkt ziehen wollen.

Von der beobachteten Problematik um die Einführung von WireGuard-Code von Netgate ins FreeBSD, fange ich gleich gar nicht erst an...

Wird besser sein, denn da war Netgate selbst ja nur Randbeteiligter. Komisch dass aber da keiner mit Fackeln und Heugabeln Sturm gegen den WG Code Entwickler oder gar die FreeBSD Kernel Member läuft, die nach 4 Augen Prinzip den Code einfach in den Kernel reingewinkt haben. Ist selbstredend viel öffentlichkeitswirksamer, wenn man hinterher gegen den Sponsor schießt, der Geld in die Hand genommen hat um das Feature einzukaufen weil damals keine Sau interesse dran hatte es zu machen. Aber yay, wenn jetzt der Erfinder selbst kommt und alles rettet, dann sind ja garantiert alle anderen die bösen Buben - Fall geklärt :D Zynisch? Sarkastisch? Jap. Nicht gegen dich, aber gegen die Situation per se und alle, die da nur tumb mit dem Finger auf pfSense und Netgate zeigen. Das war in der Fuckup Kette ein eher nachgelagertes Glied. Aber dazu hatte ich im WG Thread schonmal länger mit entsprechenden Links was zu geschrieben. Das jetzt hier anzubringen ist aber falsch abgebogen.

Btw: Letzte Chance für pfSense... das Update auf 2.5.2 und ich werde jetzt mal die Kiste von Grund auf neu machen, also ohne Tweaks oder Config-Anpassungen. Dann mal schauen wie es läuft.

Kann man so machen - keine Frage. Da ja gern OPNsense als Vergleich eingeworfen wird - joa. Gern. Aber denen steht das Update auf FBSD12 auch noch bevor, man verabschiedet sich dazu von Hardened BSD als Zwischenlayer und schraubt gleichzeitig an der UI. Das ist toll und bringt das Ding natürlich voran, aber dafür knallt es auch ständig an allen Ecken und Enden. Wenn das besser gefällt - klaro - let's go. Hat aber auch nen Grund, warum ihre neue Business Edition mit den Builds hinterherhinkt - damit es eben nicht ständig scheppert ;) Und da ich dort genauso das Forum manage wie hier und wir Kunden in beiden Feldern haben - da gab es das auch schon oft genug, dass - was du so schön "einfache Dinge" nennst - einfach mal in einem Minor Update geflogen und explodiert sind. Und auf Rückfrage kam dann sogar "das war so gewollt, das ist ein Feature". Ja supi :)

Man kanns eben nicht jedem recht machen. Die einen schreien weils nicht schnell (genug) geht, den anderen ist es nicht langsam/stabil genug - irgendwo ist immer nen Kompromiss drin. Sei es bei der Entwicklung, Wireguard, Updates, etc. etc.
Vielfalt ist für alle gut und wer ein wenig in der Entwicklung drin steckt weiß, dass solche Zeiten/Bugs scheiße sind, aber manchmal ist eben der Wurm drin. Das gefällt den Entwicklern selbst am allerwenigsten. Die würden sich jetzt sicher auch gern auf neue Sachen und Updates konzentrieren statt Regression Bugs suchen und fixen zu müssen die eigentlich schon abgeschlossen gedacht waren.

Nochmal zur Klärung: ich halte Kritik für wichtig und richtig, aber meckern und Extremente werfen ist unnötig. Zumal wenn es pure Gerüchte oder Gefühle sind.
Dein "einziges" Problem im Threadstart war zudem "das Interface hängt/geht down" bei einer Interface/HW nahen Aktion die treiberbedingt sein kann. Verstehe immer noch nicht was daran jetzt so schlimm ist/war, dass das so ein Faß werden muss :)