Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - sbellon

#1
Hi all,

I know this is a very minor issue compared to what functionality the product offers.

However, just having upgraded from 24.7 to 25.1, the font has changed and thus the readability of the web user interface. Compared to 24.7, now with 25.1 the font looks "condensed" in a way that the height/width ratio has changed considerably, making reading information in the UI harder for me.

When I use some browser developer tools I can see that it's due to the font family being declared as "SourceSansProRegular" with highest priority. If I remove that setting dynamically with the browser's dev tools, the font immediately returns to being clearly readable.

Is there any way to configure this within OPNsense itself or do I have to install browser extensions to change that?

BTW: I have checked with both, Firefox and Chrome (most recent versions) on a Debian GNU/Linux box as well as with Chrome Edge on Windows.
#2
Yes, I don't want to derail this thread any further, my assumption was, that such a large increase in states most likely is also correlated with an increase in CPU consumption. As I have seen a reduction in states with 24.7.3 in my setup, I just wanted to suggest also checking the OP's CPU issue with 24.7.3 to verify/falsify whether this also has been resolved.

But my assumption may be wrong and I won't hijack this any further.
#3
Quote from: irrenarzt on September 02, 2024, 12:10:03 AM
Do you happen to use any firewall aliases with large table entries loaded?

I discovered that by disabling Maxmind Geoblock, I'm able to reduce my temperatures and utilization to pre-24.7 levels. Since I made no alteration to any of mine between 24.1 and 24.7, I think python 3.11 introduced a bug.

Yes, I *do* use Maxmind Geoblock with country aliases that result in large table entries.

But then again, it all went back to pre-24.7 behaviour when upgrading to 24.7.3 as you can see in my state graph.

24.1.10 -> 24.7.1 on 2024-08-08
24.7.1 -> 24.7.2 on 2024-08-21
24.7.2 -> 24.7.3 on 2024-08-29

You can see this correlates perfectly with the graph. I'm pretty sure this is due to the FreeBSD ICMP issue and not Python.
#4
Just here to +1 everything you said. I had precisely the same symptoms and with 24.7.3 everything is back to normal again.
#5
The attached screenshot shows my "States" with the *EXACT* some configuration over the whole time of the plot.

You can clearly see the change when I upgraded from 24.1.10 to 24.7.1 on 08.08.2024 ... and the pattern also changes after the upgrade to 24.7.2 on 21.08.2024.

And guess what, now that I upgraded to 24.7.3 just yesterday, it is back to old behaviour (not easy to see yet in the screenshot, but if I adjust the axis scaling it can be clearly seen).

So, my assumption is, that this change in states also comes with a change in CPU utilization.

PS: and also my weird Android Wifi disconnects that I was chasing over the last weeks have miraculously vanished since I upgraded to 24.7.3 yesterday.  ;D
#6
I still have the theory that this is also connected to the ICMPv6 issue in 24.7.1 and 24.7.2 which was reverted in 24.7.3.
#7
When you upgrade to 24.7.3 ... is it still the same or is it reverted to pre-24.7 behavior?
#8
24.7, 24.10 Legacy Series / Re: 24.7 CPU Temps
August 29, 2024, 10:12:36 AM
Not saying this is related, but I agree that I see a change in the graphs after having upgraded to 24.7.1 and then after 24.7.2 as well. For me it's not the CPU temperature because I'm running that on a Proxmox VE and don't have that available inside OPNsense, but I can see how the usage of the "States" clearly (!) changed with the upgrade from 24.1.10 to 24.7.1 and then again to 24.7.2 as you can see from my attached screenshot (upgrade to 24.7.1 was on 08.08.24 and upgrade to 24.7.2 was on 21.08.24 - both clearly visible in the graph without further explanation).

I am not saying this change is a problem nor worth investigating, I'm just saying that I can clearly see this change in behaviour and this may very well have effects on CPU usage and/or memory usage and perhaps as a result even CPU temperature.

Oh, and yes, configuration has NOT changed AT ALL over this period of time.
#9
German - Deutsch / Re: ddclient ipv6 Problem?
February 27, 2024, 10:25:21 AM
Bei mir updated ddclient "native" mit Service desec sowohl IPv4 als auch IPv6.
#10
German - Deutsch / Re: IPV6 DSL Telekom Draytek Vigor 167
February 26, 2024, 02:14:06 PM
Hallo zusammen,

ich hab auch den Vigor 167 an einer OPNsense (virtualisiert auf Proxmox VE) mit Telekom Dual IP Stack. Ich lasse auch den Vigor das VLAN-Tag 7 setzen und habe ohne Probleme Dual IP Stack. Ich weiß, das hilft jetzt nicht weiter, aber daran, wer das VLAN-Tag setzt, liegt es also wohl nicht.

Gruß
Stefan
#11
I only get it working without pppoe0 not getting detached, if WAN2 is DHCPv6 and "Request only an IPv6 prefix" enabled. If I untick "Request only an IPv6 prefix" or configure SLAAC, then the pppoe0 inet6 immediately gets detached again (with all its consequences).
#12
Yes, I have already configured WAN interface with "Request only an IPv6 prefix" and "Use IPv4 connectivity".

But I had *not* configured those two on WAN2.

Now I have configured "Request only an IPv6 prefix" and "Use IPv4 connectivity" for WAN2 as well and it seems to work (incl. the gateway monitoring on WAN IPv6)!

I'll now try to get rid of the gateway groups as you suggested and try a failover situation.

Thanks for your helps so far, that helped a ton!
#13
Thanks a lot for your reply.

Yes, the issue may not be the same, but there aren't many other useful hits when googling for "inet6 detached" either. On a more general note: what acatually is the meaning of the detached keyword next to an inet6 address in the ifconfig output?

In my case, both WAN and WAN2 are using DHCPv6.

Yes, NOT specifying a monitor IP for WAN IPv6 gateway may be an option to get it working in "normal operating state", but as the WAN IPv6 gateway is a fe80:: address, I think this would not guarantee switching over to WAN2 if the IPv6 connectivity "behind" that fe80:: on the gateway is down, would it?

Regarding your other two comments:
1) I don't need gateway groups? I thought, this is what is being documented here: https://docs.opnsense.org/manual/how-tos/multiwan.html or did I misunderstand?
2) will have to look at the outbound NAT for WAN2 if the rest works. ;-)

Thanks for your help, very much appreciated!

Greetings,
Stefan
#14
I know, it's bad etiquette to follow up one's own posts, but I think, I'm onto something now...

I wanted to question why I cannot do


/usr/local/bin/dpinger -f -S -r 0 -i WAN_DHCP6 -B 2003:de:x:x:x:x:x:x -p /var/run/dpinger_WAN_DHCP6.pid -u /var/run/dpinger_WAN_DHCP6.sock -s 1s -l 4s -t 60s -d 1 2001:4860:4860::8888


even though ifconfig shows:


pppoe0: flags=88d1<UP,POINTOPOINT,RUNNING,NOARP,SIMPLEX,MULTICAST> metric 0 mtu 1492
        description: WAN (wan)
        inet 91.x.x.x --> ...
        inet6 fe80::x:x:x:x%pppoe0 ...
        inet6 2003:de:x:x:x:x:x:x prefixlen 64 detached autoconf


And then I noticed the detached! As soon as the LTE WAN2 is configured for IPv6, the pppoe0 inet6 on WAN goes to detached! (Most likely this also is in line with what I already noticed in post #2: The 2003:de:x:x:x:x:x:x address is missing from WAN in "Interfaces -> Overview".)

I googled and found:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=263986

Lo and behold, if I manually set ifconfig pppoe0 inet6 2003:de:x:x:x:x:x:x/64 so that the detached autoconf is gone, I can start dpinger and the WAN IPv6 gateway gets back online.

Is there any way via configuration to avoid the inet6 of WAN getting detached when having a WAN2 with IPv6?
#15
If I manually start


/usr/local/bin/dpinger -f -S -r 0 -i WAN_DHCP6  -p /var/run/dpinger_WAN_DHCP6.pid -u /var/run/dpinger_WAN_DHCP6.sock -s 1s -l 4s -t 60s -d 1 2001:4860:4860::8888


instead of


/usr/local/bin/dpinger -f -S -r 0 -i WAN_DHCP6 -B 2003:de:x:x:x:x:x:x -p /var/run/dpinger_WAN_DHCP6.pid -u /var/run/dpinger_WAN_DHCP6.sock -s 1s -l 4s -t 60s -d 1 2001:4860:4860::8888


what the OPNsense tries itself, then I can heal it, i.e. removing the -B bind source address helps.