Messages

Nichts für ungut. Ich habe das eben mal über mein altes boot environment geprüft. Das Problem tritt auch bei der vorherigen 24er-Version auf.

Hallo!

Ich habe seit dem Update auf die 25.1.1 (vermutlich seit 25.1 aber ich habe die Updates direkt hintereinander ausgeführt) ein Problem beim Zugriff auf mein internenes Netzwerk.
Beim Versuch vom WLAN-Netzwerk aus die Webseite eines Dienstes im Lan-Netzwerk aufzurufen, gibt es einen Timeout. Wenn ich bei sämtlichen Beteiligten in der Strecke auf den jeweiligen Interfaces ein tcpdump ausführe, sehe ich, dass zumindest Teile der TCP-Verbindung aus dem LAN-Netzwerk im WLAN-Netzwerk ankommen. Im Firewall-Live View sehe ich, dass meine Regeln für die Verbindung funktionieren.

Wenn ich auf meinem Notebook im WLAN ein tcpdump auf dem Wlan-Interface durchführe, während ich im Browser versuche die Seite zu laden, sehe ich folgendes:

Code Select Expand

15:45:43.887845 IP <SERVICE_IP>.<SERVICE_PORT> > <NOTEBOOK_HOSTNAME>.45678: Flags [S.], seq 1818494879, ack 3704609024, win 65160, options [mss 1460,sackOK,TS val 3825173449 ecr 2092189288,nop,wscale 7], length 0
15:45:43.890191 IP <SERVICE_IP>.<SERVICE_PORT> > <NOTEBOOK_HOSTNAME>.45678: Flags [.], ack 1449, win 524, options [nop,nop,TS val 3825173452 ecr 2092189293], length 0
15:45:43.890403 IP <SERVICE_IP>.<SERVICE_PORT> > <NOTEBOOK_HOSTNAME>.45678: Flags [.], ack 1877, win 546, options [nop,nop,TS val 3825173452 ecr 2092189293], length 0
15:45:43.894972 IP <SERVICE_IP>.<SERVICE_PORT> > <NOTEBOOK_HOSTNAME>.45678: Flags [P.], seq 1449:1831, ack 1877, win 546, options [nop,nop,TS val 3825173454 ecr 2092189293], length 382
15:45:48.896472 IP <SERVICE_IP>.<SERVICE_PORT> > <NOTEBOOK_HOSTNAME>.45678: Flags [F.], seq 1831, ack 1877, win 546, options [nop,nop,TS val 3825178455 ecr 2092189300], length 0
15:45:59.102445 IP <SERVICE_IP>.<SERVICE_PORT> > <NOTEBOOK_HOSTNAME>.45678: Flags [.], ack 1877, win 546, options [nop,nop,TS val 3825188664 ecr 2092194301], length 0
15:46:09.342742 IP <SERVICE_IP>.<SERVICE_PORT> > <NOTEBOOK_HOSTNAME>.45678: Flags [.], ack 1877, win 546, options [nop,nop,TS val 3825198904 ecr 2092194301], length 0
15:46:19.581905 IP <SERVICE_IP>.<SERVICE_PORT> > <NOTEBOOK_HOSTNAME>.45678: Flags [.], ack 1877, win 546, options [nop,nop,TS val 3825209143 ecr 2092194301], length 0
15:46:29.828197 IP <SERVICE_IP>.<SERVICE_PORT> > <NOTEBOOK_HOSTNAME>.45678: Flags [.], ack 1877, win 546, options [nop,nop,TS val 3825219390 ecr 2092194301], length 0
15:46:40.067283 IP <SERVICE_IP>.<SERVICE_PORT> > <NOTEBOOK_HOSTNAME>.45678: Flags [.], ack 1877, win 546, options [nop,nop,TS val 3825229628 ecr 2092194301], length 0

Ich interpretiere es so, dass zumindest einige Teile des Verbindungsversuchs durchkommen.
Da ich leider kurz nach der Aktualisierung der OpnSense auch meinen Wlan-AccessPoint auf eine neue OpenWrt-Version aktualisiert habe, bin ich mir nicht ganz sicher, an welcher Stelle das Problem verursacht wird. Ich habe aber aktuell nicht den Eindruck, dass der AP etwas 'verschluckt', weil ich auf dem Wlan-Interface der OpnSense sehe, dass der Verbindungsversuch ankommt.

Verbindungen ins Internet sind kein Problem. Deswegen ist mir das auch nicht sofort aufgefallen.

Ist jemandem soetwas evtl. auch aufgefallen? Gibt es in der neuen Version eine Änderung bei irgendwelchen Defaults/Automatischen Regeln durch die das evtl. verursacht werden könnte?

System: Protectli VP2420 (Celeron J6412)

Widget Temperature: 56°C
Reporting: ~50°C
sysctl dev.cpu.0.temperature: dev.cpu.0.temperature: 42.0C
sysctl -a | grep dev.cpu.0.temperature: dev.cpu.0.temperature: 52.0C

I am using the hwp_state driver and not powerd. Don't know if this is relevant.

> There is no other automatism, it will just revert automatically when the admin doesn't confirm within the timeframe.
> I do like the manual confirm, but not the timer. People forget, systems revert for the wrong reasons.

Maybe the timer thing could be an option that defaults to off and can be manually activated for certain use cases.

There could be problems with the WAN (PPPoE) connection after an update but the system could still be "active". For such cases some kind of auto-reboot would be nice.

@Patrick:
You may not always be in a position to power cycle the system easily.
I guess the whole point of this feature is about systems that are only available remote?
So maybe one could enhance your proposal with some kind of cron based success-check. E.g. reboot if the BE is not persisted after a certain amount of time?

Hallo!

Ich bin auch bei HTP. Allerdings ohne Business-Tarif.
Mein Anschluss ist ebenfalls auf Dual-Stack eingestellt.

Bei mir läuft IPv6 mit DHCPv6 (Use IPv4 connectivity, Request prefix only, Send prefix hint, Prefix size 56).
Die IPv6-Adressen sieht man in der Shell  auf dem pppoe0-Interface (ssh zur OpnSense; 8 Shell; und dann "ifconfig").

[x]

Correct, I forgot to mention yesterday, I am also using the Tunable dev.hwpstate_intel.x.epp = 90 (x = 0...5), on top of the dev.cpu.y.cx_lowest = C3 (y = 0...11)

Please could you share the link to the site with the information on what CPUs are compatible with the PowerD daemon, thank you

Sorry. I don't have a link i could provide. I just tried different settings of PowerD and saw no effect on frequencies or temperature. Afterwards i searched the forum and found some discussions about the topic that confirmed my suspicions.

In general, i guess, all CPUs that support Intel Speedshift have to use hwp instead of PowerD. Maybe you can find some information in the official FreeBSD documentation (https://docs.freebsd.org/en/books/handbook/config/#hwpstate_intel).

I also own a VP2420 flashed with Corebios.

After the installation of Opnsense i was a little bit concerned about the CPU temperature because it was running hotter than my previous system (APU4).
I don't have the option to use lots of fans in this environment and therefore sensitive to heat dissipation.
After some time i realized that the powerd-setting has no effect on this system. The CPU is not supported by the daemon. After using the tunables "dev.hwpstate_intel.*.epp" and setting them to "90" the CPU was running cooler and used lower frequencies most of the time.

After setting "dev.cpu.*.cx_lowest" to "C3" i am back at the level of the APU or evevn better.

Hi!

I don't think that i completely understood you problem. But i also struggle with IPV6 connectivity in Debian 12.

In my case i try to get a working SLAAC setup as this is what my mobiles seem to like. On the other hand my linux notebook with Debian 12 at first had only a link local IPv6 address. I tried to tweak it with several sysctl settings until i realised that it was using NetworkManager. Because that is new territory for me i disabled the IPv6 handling of NetworkManagerit for that connection (nmcli c m <WLAN Connection> ipv6.method ignore).

Now i have at least several IPv6 addresses. I still have connection problems which may be related to a missing default gateway... .

Long story short. I think the combination of NetworkManager and Ipv6 is a little bit special and may need some trial and error to get right.

For me the following somehow works:

Setting the tunable "dev.hwpstate_intel.*.epp" to 80 seems to avoid too much spiking of the CPU and results in a sane behaviour of the temperature widget.

I missed the fact that for newer CPUs the powerd daemon does not work.
As i don't need very much processing power for my setup there is no need for higher frequencies.

Hardware: J6412 Protectli VP2420

Hi Franco,

i guess i could try harder to explain myself.

> Guessing problems into open source is a bit taxing from a dev point of view because now it's not enough to be open it needs to be explained constantly

First of all i understand that it is sometimes tiring to explain things over and over. In my case i actually think you have a point because i *could* look into the sources and get some insights or be more precise with my statements. But you can't really expect this from every random person.

> RRD is not even using sysctl so not understood. It's actually using a tool that really really needs to be removed for the same reason that RRD backend needs a full rewrite.

Now what i tried to express was that it is probably a good idea to use one common source of truth for such data in general (because it is irritating having different vaues inside the GUI). And because i didn't knew that RRD was in need of a refactoring i thought that source of truth could be the RRD. But you can abstract that away if you like.

Similar to your idea

> We may have to write a small tool to fetch the temperatures in the background away from the GUI so when the GUI query comes in it reads the actual value, not the one while the CPU is busy processing the user request

The important thing being that there shouldn't be several ways to gather the data (tool and RRD) but only one way (tool) and the other consumer (widget, RRD) should ask the tool service for the values (to avoid different results and to avoid unnecessary load).

The second part about the means on how to read the actual values (sysctl dev.cpu) was meant to illustrate that it would be nice if one would use a more lightweight method for the central data crawler.
I compared that to "sysctl -a" in this context because i compared the RRD values to the output of the command line calls and "sysctl -a" was close to the RRD values in my case. Threrefore i asumed that it is using this command or at least something similar.


Greetings,
Stefan

We may have to write a small tool to fetch the temperatures in the background away from the GUI so when the GUI query comes in it reads the actual value, not the one while the CPU is busy processing the user request..?

Cheers,
Franco

Maybe you could just use the RRD data if it is available.

And if i understood your problem description it might be a good idea to use "sysctl dev.cpu" instead of "sysctl -a" for the RRD data.

I have a setup with a Fritzbox (german internet+wlan router) in front of a OPNsense box.

I also use an ULA.

And here the gateway monitor is working. So i guess there is no general problem with 2 routers.

I see the following:

- The widget shows 63°C
- The RRD health data shows an average of ~53°C
- "sysctl -a | grep temperature" shows 50°C
- "sysctl dev.cpu | grep temparature" shows 43°C

Not all executed at the exact same point in time but after several tries the trend is stable.

If i compare the visualization of the CPU-Widget with the output of "top" it looks also quite different. But maybe this is just the sampling intervall.

System: Celeron J6412 and thermal sensor configuration set to use the on-die thermal sensors.