Messages

Add an trailing dot!

nslookup
google.com.

Not tried an reboot yet but experiencing the same problems.

https://forum.opnsense.org/index.php?topic=37470.0

If i have some spare time left i will try to reboot.

Also unable to deploy certificate to a Synology with 2fa enabled.

When running
acme.sh --home /var/etc/acme-client/home --deploy --deploy-hook synology_dsm -d "*.domain.com"

I am unable to authenticate against my Synology nas.

Is there way to run the automation settings in the CLI ?

Digging further is see that the config file isnt changed at all after modifying the device ID in the gui.
I have 2 certificates, the domain.conf of 1 has a device_id and device_name but with a wrong id.
The other domain doesnt have the device_id and device_name set.

@annoniempjuh, had the same before 23.7.5 with a working 1500mtu. For testing i deleted those dommy interfaces and set MTU on WAN 1508. After the upgrade all parent interfaces adjusted automaticly to allow 1500 MTU on PPPoE.

Interfaces - point to point - devices edit the PPPoE tunnel under advanced no Mtu set?

My situation PPPoE over vlan6.

With 23.7.5 no additional devices configured to force an MTU of 1500 on the WAN interface.

Just updated to 23.7.5.

Deleted all dummy interfaces "Physical NIC" "VLAN", checked WAN PPPoE is set to 1508 calculated MTU is 1500.
Upgrade to 23.7.5 and voila! 1500 MTU on PPPoE

Nope completely empty.

Not able to reboot right now, will try later today.
But when is was trying to resolve the issue i rebooted several times and the MTU stays at 1500.

https://forum.opnsense.org/index.php?topic=35282.0

Experienced the same!

With 23.1 and before i had an MTU of 1500 over my PPPoE connection.
With an dummy interface on the physical interface MTU set to 1512 [Vlan 4bits PPPoE 8bits].

ISP is KPN Netherlands, PPPoE over vlan6.

After the upgrade to 23.7 everything seemed to work fine, but when looking into interfaces - Overview PPPoE I saw that my MTU was 1492!

Fixed the problem to assign an interface to igb0_vlan6 and set the MTU there to 1508.

Is there anything changed why the MTU is not honored in 23.7?

After updating to 23.1.2 my system log is full of messages from apps.plugin.

Code Select Expand

2023-03-09T13:32:12
apps.plugin Cannot fetch process 71508 command line (command 'pgrep')
2023-03-09T13:30:20
apps.plugin Cannot fetch process 18869 command line (command 'pgrep')
2023-03-09T13:29:22
apps.plugin Cannot fetch process 23812 command line (command 'pgrep')
2023-03-09T13:29:13
apps.plugin Cannot fetch process 12741 command line (command 'pgrep')

When i tried to restart Netdata the folowing message appeared in the logs.

Code Select Expand

apps.plugin should either run as root (now running with uid 302, euid 302) or have special capabilities. Without these, apps.plugin cannot report disk I/O utilization of other processes. Your system does not support capabilities. To enable setuid to root run: sudo chown root:netdata /usr/local/libexec/netdata/plugins.d/apps.plugin; sudo chmod 4750 /usr/local/libexec/netdata/plugins.d/apps.plugin;

Is something changed in the permissions of Netdata?

I am running OPNsense 22.1.10, requesting prefix through PPPoE "/48".

Everything is working fine clients can get an IPv6 address through SLAAC.
When I was trying to run Wireguard over IPv6 and it didn't connect.

In Wireguard client i was trying to connect to the IPv6 address that was on the LAN site of my OPNsense install.

After some digging around I found out that the Wireguard interface IPv6 address was showing up in an traceroute from the internet to my LAN IPv6 address.
Also when I run a traceroute "from the internet" to any of my clients in my LAN is see the extra hop with the IP address of the Wireguard interface.

When restarting Wireguard the extra hop from the traceroute was gone, and I am able to connect to Wireguard over IPv6.

How is it possible that this extra hop is added after reboot?

Removed patch 4b6fa9e, upgrade to 22.1.5 and IPv6 is working instantly.

The FE80 address is the gateway for IPv6.
I think the info in the SSH screenshot is wrong, because the Preifx ID "0" is selected for LAN and not WAN.

Thanks for the patch!

If there is anything else you would like know, let me know and i take a look.