Messages

It's both interesting and annoying how well a system can work with slightly defective RAM. I got a used PC from a buddy (who is unlikely to fake it) and it had a RAM error that would only manifest in memtest86+ at around the 5th pass, and only in test #8, who never noticed any problems, even when specifically asked about it. That's why one successful memtest run is just a starting point and a complete build is being left to test for as long as possible but never less than 24 hours total (might interleave some installation or other use), even longer (up to 1 week continuous) if it's going to be used for anything important like a server of any sort. none of this helps if the defect manifests only after a year of use, which is why I'd like OPNSense (or rather: every appliance OS) to have some sort of lightweight user-mode background testing service.

compare CPU load on rtl8127. Copying single 50GB file from the unraid server (with AQC113 NIC) throughput was all over the place from 900 MB(yte)/s to 1.10GB/s with one core maxed out. I put the AQC113 NIC back in and got a stable smooth throughput at 1.09GB/s and none of the cores were maxed out. I did play with different settings including settings RSS queues from 8 to 4, but none helped. Is it a driver issue? maybe

Probably a driver issue, as I was able to get the IRQ load to spread across CPUs on my puny RTL8111 NIC only after much tinkering with the tunables. It's odd that the Windows driver would be just as crappy as the BSD one (even the vendor driver would not do it by itself), especially with much more recent hardware. However, my MoBo had stability issues with MSI-X that had to be resolved through firmware updates, so possibly the driver is just being conservative. May also be a limitation of the OS / networking stack that ties one stream of data to one CPU unless the driver counteracts it. Multiple concurrent streams tend to spread over cores much more readily than a single stream from what little I've looked at.

Code Select Expand

Der Unterschied ist, dass mit höherer Temperatur [i]alle[/i] (sub)molekularen Prozesse schneller ablaufen, also auch alle Alterungsprozesse in Materialien, Oxidation, Elektromigration usw.Theoretisch, ja. Wie sieht es mit praktischen und echten Effekten aus? Ausfall nach 11 Jahren und einem Monat anstelle von 11 Jahren?

Wohl eher Ausfall kurz nach Ablauf der Garantiezeit vs. Ausfall nach 10 Jahren. Besonders interessant wird es demnächst werden, wenn wir erfahren, ob die Eigenschaften des Niedrigtemperatur-Bleifreilotes zu vorzeitigen Ausfällen führen, weil z.B. durch den niedrigen Schmelzpunnkt thermische Effekte zu Versprödung der Lötungen und somit Kontaktverlust führen. AFAIK steht der massenhafte Einsatz Desselben aber noch aus.

Code Select Expand

Allerdings habe ich mich auch selten mit der Kühlung von HDDs abgegeben und trotzdem haben es viele ewig überlebt, allerdings kamen die meist nur auf 43°C, keinesfalls und schon gar nicht dauerhaft auf 60°. Also mich würde es stören, ganz besonders bei Hardware, die auf Jahrzehnte hin zuverlässig laufen soll, eine Firewall z.B. .Nun gut, das ist halt deine gefühlte Wahrheit, dass eine HDD auf 43° jahrelang zuverlässig läuft, nicht aber auf 60°.
Rein wissenschaftlich gesehen ist es hingegen irrelevant. Die Hersteller sind ja nicht doof. Die geben aus gutem Grund 5y Garantie und eine Temperaturbereich von 10-60°. Gäbe es auch nur eine 1% Chance eines höhren Ausfalles, wäre der Range 10-55°

Also was denn nun? Anfangs schießt Du dagegen, und nun bist Du dabei (43°->11 Jahre, 60°->5 Jahre)? Außerdem sind die Zeiten, in denen 5 Jahre Garantie bei Festplatten nahezu Standard waren, lange vorbei. Heute bekommt man mit ganz viel Glück noch 3 Jahre als Standard, meistens ist es exakt das gesetzlich vorgeschriebene Minimum von 2 Jahren (nachdem die schon auf 1 Jahr oder sogar weniger runter waren). Alles andere kostet extra als "Garantieverlängerungsoption", was aber rein gar nichts an der geplanten Lebensdauer des Produktes ändert, im Gegensatz zu der von Dir völlig korrekt dargestellten Standardgarantie (mit der Verlängerungsoption be/überzahlt man nämlich genau Deine 1%). Der Hersteller möchte nämlich auch nicht, dass das Gerät deutlich länger hält als die Garantiezeit. "Wissenschaftlich" haben aber keine unserer Einzelerfahrungen irgendeine Relevanz, es wird nicht umsonst für eine aussagekräftige Untersuchung eine Mindestanzahl in den Hunderten und alles unter exakt kontrollierten Bedingungen vorausgesetzt.

Code Select Expand

wenn man schon nichts weiter unternimmt, sollte man zumindest die natürliche Konvektion / Kamineffekt unterstützenKamineffekt ist bei Computern ein Ammenmärchen. Der wird brutal überschätzt. Das zieht vielleicht bei einem passiven Gehäuse, wenn da aber nur ein einzelner 80mm Lüfter dreht, ist Feierabend. Du könntest eine Case mit einem 120mm Lüfter am Heck auf den Rücken stellen (so dass er voll gegen den Kamineffekt arbeiten müsste) und könntest vermutlich keinen Temperaturunterschied messen.

Mir ist schon klar, daß es beim stinknormalen PC-Gehäuse keinen Kamineffekt gibt, dazu sind die Dimensionen (Höhe vs. Breite) viel zu weit vom Notwendigen weg, selbst ohne den ganzen Krempel im Inneren. Da hat man nur die natürliche Konvektion, die nicht identisch mit dem Kamineffekt ist. Bei Geräten wie einer Firewall-Appliance, einem Switch o.Ä., insgesamt alles, was mit 1HE oder sogar nur 0,5HE daherkommt, sieht das aber anders aus, und darum ging es AFAICS beim OP?

Sorry für den Rant, aber ich kann solche "gefühlten Wahrheiten" nicht unkommentiert im Raum stehen lassen. Es ist bewusst provokant geschrieben und ich habe nicht für jede meiner Behauptungen selbst einen wissenschaftlichen Beweis. Den muss ich IMHO aber auch nicht erbringen, da ich die Behauptungen nicht in den Raum gestellt habe. Dies soll lediglich als kritischer Denkanstoss gelesen werden.

Dem kann ich mich nur anschließen: ich wollte und konnte solche Behauptungen wie "60° ist kein Problem, und 80° auch nicht" genausowenig im Raum stehen lassen. Besonders nicht, wenn ich gegenteilige Erfahrungen gemacht habe (3 identische Laptopplatten, eine mit 61° Maximaltemp, eine mit 43° Maximaltemp und eine mit 23° Maximaltemp für je etwa 1000h. Nach ca. 3 Jahren im Dauerbetrieb mit geringer Last aber aktiver Kühlung bei ca. 23° bekam zuerst die 61er defekte Sektoren, 1 Jahr später die 43er und die 23er war noch immer fehlerfrei, als der ganze Stapel weitere 2 Jahre später außer Betrieb genommen wurde). Die Garantiezeit haben sie somit alle überstanden, die war bei denen damals noch 3 Jahre. Zu SSDs kann ich noch keine Aussage machen, weil ich dafür zu wenig Langzeiterfahrungen damit sammeln konnte.

Bei Prozessoren hat man sich an die hohen Temperaturen gewöhnt, weil die internen Sensoren im Die integriert sind und daher ungefähr die Kerntemperatur Tj messen, wohingegen alle externen Sensoren (also in Festplatten und anderen Geräten) schon bestenfalls nur noch die Gehäusetemperatur eines Bauteils messen können, die gern mal 30° niedriger als die Kerntemperatur ist. Bei Festplatten dann sowieso nur noch die Temperatur an einer, hoffentlich sinnvoll gewählten, Stelle. Zudem ist dann das Gerät auf Temperaturen an dieser Stelle ausgelegt, nicht aber darauf, komplett und dauerhaft so heiss zu sein, wie es aber wird, wenn es mit einer Heizung (AKA CPU) in einem lüfterlosen, verschlossenen Gehäuse eingesperrt ist.
Unabhängig von der Kühlsituation ist aber eine Auslegung des Gerätes mit genug Toleranz essenziell für Zuverlässigkeit. Nicht umsonst wird bei Billigprodukten gern die Hälfte der VRM-Komponenten nicht bestückt, weil es ohne diese halt meistens auch die Garantiezeit gerade so übersteht. Aber selbst (besonders?) Billighardware lebt länger, wenn man sie anständig kühlt. Ich habe jedenfalls lieber seltener Downtime bei (semi-)kritischer Infrastruktur als häufigen Tausch, selbst wenn auf Garantie, und gerade bei Datenträgern steht der physische Tausch des Gerätes in keinem Verhältnis zum restlichen Aufwand, das Gesamtsystem wieder betriebsbereit zu machen (z.B. Backups zurückzuspielen dauert deutlich länger als der eigentliche Komponententausch, und wenn das Ersatzteil nicht nahezu identisch ist, kommt noch anderer Vorbereitungsaufwand hinzu).

Mir ist aber eigentlich vollkommen schnuppe, was der OP macht, meinetwegen kann er das Teil auch in eine Heizdecke einpacken oder bei 80° in den Backofen stellen. ;)

Was soll es deine SSD jucken, ob sie mit 40° oder 80° läuft? Wo soll da ein Unterschied sein?

Der Unterschied ist, dass mit höherer Temperatur alle (sub)molekularen Prozesse schneller ablaufen, also auch alle Alterungsprozesse in Materialien, Oxidation, Elektromigration usw. . Außerdem sinkt mit höherer Temperatur bei Halbleitern aus Silizium der Widerstand, wodurch ggfs. der fließende Strom steigt, und erhöhter Strom ist auch wieder eine höhere Belastung für die Komponenten. Korrekt ausgelegte Hardware kommt damit natürlich klar, aber die Lebensdauer wird trotzdem leiden (nur ggfs. nicht merklich, weil sie auch so noch hoch genug ist). Temperaturunterschiede und die damit verbundenen Materialbewegungen führen außerdem immer zu mechanischem Stress. Idealerweise wäre das komplette System überall auf der exakt gleichen Temperatur, die sich auch niemals ändern sollte. Diese Forderung ist natürlich vollkommen absurd. Außerdem weiss niemand, ob irgendeine Hardware korrekt ausgelegt ist, wie man z.B. am Intel LPC-Bug gesehen hat, mit dem ich mich derzeit herumärgere (im Prozessor ist da ein Transistor, der die Clockleitung auf einen definirten Pegel zieht, zu schwach ausgelegt, wird somit dauerhaft überlastet und verreckt dadurch innerhalb weniger Jahre, es gibt außer dem Tausch des Prozessors keinen dauerhaften Fix dafür).

Glücklicherweise werden auf MoBos inzwischen ja keine "nassen" Elkos mehr verbaut, damit ist das Austrocknungsproblem hoffentlich endgültig Geschichte... außer, dass manchmal gemischt bestückt wird, wo die Belastung nicht groß ist (im Audiomodul z.B.). Netzteile sind auch fast immer mit nassen Elkos bestückt, obwohl es auch da mehr als sinnvoll wäre, Festkörperelektrolyte zu nutzen.

Allerdings haben SSDs immer das Problem der eigentlichen Speicherung: es werden Ladungen gespeichert wie in einem Kondensator, isoliert durch eine hauchdünne Oxydschicht, die durch gezieltes Anlegen von Überspannung zum Schreiben durchbrochen wird (und dadurch geschädigt wird, woher die begrenzten Schreibzyklen resultieren). Umso schlimmer bei mehrstufigen Speichern, die nicht nur einen Zustand je Zelle, sondern 3 oder gar 4 speichern, indem mehrere Ladezustände ausgewertet werden. Na jedenfalls führt jede Belastung (also auch thermische) der Oxydschicht zu einer Schädigung und damit verliert die Zelle ihre Ladung immer schneller. Darum "funktioniert" eine SSD auch scheinbar zuverlässig, wenn man direkt nach dem Beschreiben verifiziert, aber nach ein paar Tagen tauchen die Fehler dann auf, weil die ersten Ladungen sich verändert haben. Obwohl Elektronen ja nicht einfrieren können, könnte ich mir außerdem vorstellen, dass durch die schnellere Molekularbewegung im Kristall die Elektronen indirekt schneller abtransportiert werden. Das ist allerdings reine Spekulation meinerseits.

Allerdings habe ich mich auch selten mit der Kühlung von HDDs abgegeben und trotzdem haben es viele ewig überlebt, allerdings kamen die meist nur auf 43°C, keinesfalls und schon gar nicht dauerhaft auf 60°. Also mich würde es stören, ganz besonders bei Hardware, die auf Jahrzehnte hin zuverlässig laufen soll, eine Firewall z.B. .

BTW, wenn man schon nichts weiter unternimmt, sollte man zumindest die natürliche Konvektion / Kamineffekt unterstützen, indem man die Kiste mit den Lüftungsschlitzen nach oben so aufstellt, dass die Luft möglichst vertikal an allen Komponenten vorbeikommt, und die wärmsten Teile oben sind, damit nicht die aufsteigende heiße Luft den Rest zusätzlich beheizt. Falls die Kiste überhaupt keine Lüftungsschlitze hat, dann wenigstens die hoffentlich vorhandenen Kühlrippen am Gehäuse passend ausrichten... und es nicht in die Sonne stellen.

You may be having an MTU / MSS issue. IPv6 doesn't have working PMTU discovery yet, but it's header is longer than the IPv4 one, which needs to be accounted for. IPv6 also cannot fragment packets mid-flight, which further complicates things. Intermediate routers may have arbitrarily low MTUs, down to 1200 IIRC, which is much less than the usual 1400+ of IPv4. Add to this the tunnel and you are going down a lot. You can try hard-setting some low MTU size like, say, 800, on the WAN interface and see if things start working then. If so, you can gradually increase it until you hit "your" personal MTU max. This, however, is best tested with leaving the MTU on WAN at default values and instead using, on the command line, "ping6 -s 800 www.google.com" (where the 800 is the packet size to be tested; you'll likely arrive at something around 1180, so you can choose your increments accordingly). Note the "6" in "ping6" since without it, you use IPv4 and thus invalidate the result.

Du könntest mal schauen, was im exportierten .csv ankommt. Möglicherweise braucht wirklich nur der letzte Punkt "alte Regeln löschen" ausgeführt zu werden, vielleicht sogar nur, um der GUI zu sagen, daß das erledigt ist.

Maybe whatever piece of how-to you got these information from should be updated to include that [new] only appears between 26.1 and 27.x, and that the steps work wothout installing the plugin (as they seem to do, as I gather from your report). There seem to be a bunch of "appliance users" around who will eventually stumble across this issue during the coming ages. ;)

No idea what causes this to break now; I kept "Far gateway" checked and it hasn't failed ever since. Maybe the code that makes it work in my case is the path that actually sets the address if both "fargw" is set and ipprotocol is ipv6 (in line 780)? It unconditionally deletes it in line 774 but the syntax explicitly used in 782 differs from what I expect will appear in 794?

As stupid as it sounds: wait until it fixes itself. I had the same issue during the last weeks with dynv6.com: first, the addresses kept resolving to the old one, then after a few days the entire hostname resolution failed. Luckily, the IPv4 fallback had come back from a similar failure a month ago, so I postponed the troubleshooting, and just today, the hostname came back online. My experience is that these dynamic DNS providers tend to have such issues every couple years, and unless you have some sort of priority access, you can only wait them out.

The only thing you could try on your end is to change the way your ddns client figures out its address, so, change the interface to monitor between "WAN" and the interface name (idk if you actually can enter this there), and also the "Check IP method". Maybe the provider you chose for that is down.

Since the previous update (noticed it after hotfix _8 but may have existed earlier), for IPv6 I need to set the gateway to "far gateway" to make OPNsense assign a default route for IPv6. This was not necessary before. I don't mind, but it still seems off somehow. The setup may be a little unusual in that (as some may recall from previous issues) my WAN interface has a bunch of different IP6 addresses, with two prefixes (one local and one public), because it is a router-behind-router setup but with the public side on the "interconnect LAN". Both addresses are assigned by the external router via SLAAC. To have reliable routing, reliable admin access and cohesive logs I set the route through the local address of the external router via the gateway configuration.
I assume that, once again, the ordering of the IP addresses matters, like with the gateway watcher. But the ordering is essentially random, so it must not be relied on, but since there is no "main address", the code cannot pin down which is supposed to be the "main" address. Also, I re-order the addresses via a script after the fact, but that should not normally affect the default route. The script removes and re-adds IP addresses, so it might be reasonable to assume that the default route gets purged when the respective address vanishes, but 1) there always is at least one address available in each prefix and 2) the issue persists across reboots, and it never failed before, and "far gateway" seems to reliably fix the problem.

So, long story short: is this intended? IOW, is it to be expected that the default route isn't set if the gateway has multiple prefixes, assigned by SLAAC?

Yes, a display emulator would be a relatively easy but not a really satisfying fix, but yeah, I will consider this when I run out of options.

Just get one for a couple of bucks and be HAPPY! :)

No, this still is a hard/firm/software bug and the emulator is a workaround with additional costs, not only in hardware but also in power draw and maintenance effort required. Since there are several different systems exhibiting the issue (maybe @Colt45 actually also didn't consider the previous connection state?), this would be either an EFI (immature, just like BIOS was 30 years ago), HDMI (especially HDCP is a PoS IMNSHO, waste of power, hassle and bugs such as these are pre-determined) or FreeBSD issue (which ultimately is due to the overly complex and contrived and ultimately worthless BS that the aforementioned schemes force upon OS developers, and these asinine b*tards demand licensing fees on top of all this even, and for what? So we cannot use our devices that we paid for the way they are meant to be used. Sorry for the rant.).

I have some port-forward NAT rules to two computers behind the firewall the RDP port is open on one of them

Close that and put the service behind a VPN !!!

Totally concur, this is a service with critical security impact and thus must be protected at (nearly) all(!) cost!

However, the connection limit should still work.

Wenn die Ergebnisse mit curl/wget (30–50 Mbit/s) und Ookla-PCAP (15–35 Mbit/s) nicht so unterschiedlich wären, würde auch eine ISP-seitige Drosselung in Frage kommen. So sieht es (erstmal) nicht danach aus.

Diesen Effekt bekommt man, wenn die Single-Thread Performance des Zielrechners zu schlecht ist. Das sollte natürlich in Deinem Fall nicht so sein, und eigentlich auch nicht an der Sensebox haken, zumindest, wenn die nicht der Zielrechner ist. Testen könnte man mal mit einem normalen PC am WAN der Sensebox, um diese auszuschließen. Vielleicht ist irgendwas im Traffic Shaping vergurkt?

Looking more closely at the entire log there must be something (ph/f)ishy going on with the connection. The algorithms don't match either, nor does the key format.
(debug1: kex: algorithm: sntrup761x25519-sha512@openssh.com
debug1: kex: host key algorithm: ssh-ed25519
vs.
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: rsa-sha2-512)

Also, the password auth is not in the available methods so it cannot succeed: Mine says:
debug1: Authentications that can continue: publickey,password,keyboard-interactive
the OPs says:
debug1: Authentications that can continue: publickey

MITM attack going on?

Without having tried it for lack of need ATM (but will likely arise in the future): does it have a way of restricting discovers reflection to specific (V)LANs, so that, say, the IoT VLAN cannot discover a phone nor TV, while the guest VLAN can see the TV VLAN but not the phones VLAN, but not wake up devices in the server and office VLANs, etc.? Or would that just be set up via conventional firewall rules?