"Recent posts
#21
25.7, 25.10 Series / Re: [SOLVED] hostwatch at 100%...
Last post by franco - Today at 09:38:27 AMInterfaces: Settings: ARP Handling is dead, long live the two tunables :)
But yes something similar needs to be done. We'll have a coordination meeting later about it and try to work through the reported items.
Cheers,
Franco
But yes something similar needs to be done. We'll have a coordination meeting later about it and try to work through the reported items.
Cheers,
Franco
#22
25.7, 25.10 Series / Re: [SOLVED] hostwatch at 100%...
Last post by Patrick M. Hausen - Today at 09:21:01 AM@franco I just noticed the hotfix. What about making the "changed ethernet address" messages configurable? We already have Interfaces: Settings: ARP Handling. I have that enabled although I do not have multiple interfaces in the same broadcast domain. Apple TVs do weird things with power saving states and proxy ARP ;-)
#23
Announcements / Re: OPNsense 25.7.11 released
Last post by franco - Today at 09:12:50 AMNote to people who were already on 25.7.11 and 27.7.11_1: a modified hostwatch
version was published disabling two excessive log messages. Applying the
hotfix 25.7.11_2 will not restart hostwatch. Please do so under Interfaces:
Neighbors: Automatic Discovery by either using "apply" or the restart button
in the service widget. Other reported issues will be addressed shortly.
A hotfix release was issued as 25.7.11_2:
o system: fix edge case in tunable reset with one single tunable in the default config
o ports: hostwatch 1.0.5 disables two excessive log messages
version was published disabling two excessive log messages. Applying the
hotfix 25.7.11_2 will not restart hostwatch. Please do so under Interfaces:
Neighbors: Automatic Discovery by either using "apply" or the restart button
in the service widget. Other reported issues will be addressed shortly.
A hotfix release was issued as 25.7.11_2:
o system: fix edge case in tunable reset with one single tunable in the default config
o ports: hostwatch 1.0.5 disables two excessive log messages
#24
General Discussion / Where is TCP processed - CPU? ...
Last post by chemlud - Today at 09:10:41 AMHi, have a problem that bugs me for years, no solution found yet:
Two clients with Linux, same update status:
1. SLOW: Libretrend i7 with Coreboot, Realtek NIC
2. FAST: Old Dell Precision M6500 notebook with Intel NIC.
Problem: when downloading e.g. updates, the FAST ist 30-times faster than SLOW, see attached.
Same mirrors,RJ45 cables changed twice, both attached to the same switch. So no real explanation.
Yesterday I did some iperf between the two clients.
For UDP, it does not matter, which is server and whicch is client:
20260118145326,SLOW,FAST,45678,1,0.0-30.0,3935190,1048952,0.025,0,2677,0.000,0
20260118145446,FAST,SLOW,45678,1,0.0-30.0,3935190,1048950,-nan,0,-1,-0.000,0
But for TCP direction matters:
20260118144505,SLOW,FAST,45678,1,0.0-30.0,3533963328,941434163
20260118144740,FAST,SLOW,45678,1,0.0-30.1,1690173504,449722645
-------------------------
First thought: RJ45 in SLOW machine is Realtek. But I have Realtek in other machines with same linux, always maxing out the bandwith possible. So I don't think it'S simply Realtek.
Why only TCP makes a difference? Is there offloading and that doesn't work properly in the SLOW machine? Maybe due to Coreboot?
Any ideas how this difference in TCP-speed might be explainable?
:-)
Two clients with Linux, same update status:
1. SLOW: Libretrend i7 with Coreboot, Realtek NIC
2. FAST: Old Dell Precision M6500 notebook with Intel NIC.
Problem: when downloading e.g. updates, the FAST ist 30-times faster than SLOW, see attached.
Same mirrors,RJ45 cables changed twice, both attached to the same switch. So no real explanation.
Yesterday I did some iperf between the two clients.
For UDP, it does not matter, which is server and whicch is client:
20260118145326,SLOW,FAST,45678,1,0.0-30.0,3935190,1048952,0.025,0,2677,0.000,0
20260118145446,FAST,SLOW,45678,1,0.0-30.0,3935190,1048950,-nan,0,-1,-0.000,0
But for TCP direction matters:
20260118144505,SLOW,FAST,45678,1,0.0-30.0,3533963328,941434163
20260118144740,FAST,SLOW,45678,1,0.0-30.1,1690173504,449722645
-------------------------
First thought: RJ45 in SLOW machine is Realtek. But I have Realtek in other machines with same linux, always maxing out the bandwith possible. So I don't think it'S simply Realtek.
Why only TCP makes a difference? Is there offloading and that doesn't work properly in the SLOW machine? Maybe due to Coreboot?
Any ideas how this difference in TCP-speed might be explainable?
:-)
#25
25.7, 25.10 Series / Re: in dnsmasq dhcp: leases: b...
Last post by Patrick M. Hausen - Today at 08:49:29 AMMy regular workflow is:
- connect new $DEVICE to network
- look up lease in the "DHCP UI"
- create static mapping
- delete dynamic lease (if necessary)
- powercycle device
Specifically if you connect a whole lot of new IoT thingies - who cares about lease times etc? Switch it off and on again, the IP stack in these things is reduced to the max, anyway.
- connect new $DEVICE to network
- look up lease in the "DHCP UI"
- create static mapping
- delete dynamic lease (if necessary)
- powercycle device
Specifically if you connect a whole lot of new IoT thingies - who cares about lease times etc? Switch it off and on again, the IP stack in these things is reduced to the max, anyway.
#26
Hardware and Performance / Re: [solved] Intel i226 Firmwa...
Last post by Waldus66668 - Today at 08:45:33 AMI find EFI version on NVM tool easier to use. Simply grab eeupdate64e.efi form Intel driver pack, boot into EFI shell and run command like:
You only specify nic number and name of NVM file to flash. No need to worry about configuration file.
Code Select
eeupdate64e.efi /nic=1 /d=FXVL_125C_V_1MB_2.32.binYou only specify nic number and name of NVM file to flash. No need to worry about configuration file.
#27
25.7, 25.10 Series / Re: in dnsmasq dhcp: leases: b...
Last post by knebb - Today at 08:44:29 AMOk, re-read the specs and can confirm the above offered "delete the ip on server" appears to be working. Although with a minor inconvinience:
For the server the IP is not assigned while it is still in use by the client.
So what happens when another client requests an IP address?
-client A has IP .12 and its leases got deleted on the server side
-client A still uses this IP as long as half of lease time hast not elapsed
-client B starts DHCPDISCOVER to get an IP
-server offers IP .12 to client B as it is marked as available
-client B sends an ARP request to check the IP
-client A sends ARP reply ("this is my IP")
-client B send DCHPDECLINE to server
-server marks this IP as "invalid" for further usage
-client B starts over with DHCPDISCOVER
-server offers different IP .13 to client B and client B uses this one...
-on the client A when half lease time has elapsed it'll ask for further usage of IP .12
-server declines further usage (as it is marked invalid) with DHCPNACK
-client A starts over with DHCPDISCOVER and will get a different IP .14
So indeed the protocol is fail-safe and you can delete a lease on the server side without any friction in the network.
The minor glicht I mentioned is the fact there is an IP address in use which (for the server) has not bee assigned. At least for half of lease time.
And this is not reflected in the server state...
And there is a second problem:
The IP will not be release or renewed before half of the lease time has passed. So when using a static lease for this client it will use the IP not earlier. And this is the same for both cases where I delete the lease on server side or create a static lease....
So I still do not REALLY see the advantage of such a "delete" functionality.
/KNEBB
For the server the IP is not assigned while it is still in use by the client.
So what happens when another client requests an IP address?
-client A has IP .12 and its leases got deleted on the server side
-client A still uses this IP as long as half of lease time hast not elapsed
-client B starts DHCPDISCOVER to get an IP
-server offers IP .12 to client B as it is marked as available
-client B sends an ARP request to check the IP
-client A sends ARP reply ("this is my IP")
-client B send DCHPDECLINE to server
-server marks this IP as "invalid" for further usage
-client B starts over with DHCPDISCOVER
-server offers different IP .13 to client B and client B uses this one...
-on the client A when half lease time has elapsed it'll ask for further usage of IP .12
-server declines further usage (as it is marked invalid) with DHCPNACK
-client A starts over with DHCPDISCOVER and will get a different IP .14
So indeed the protocol is fail-safe and you can delete a lease on the server side without any friction in the network.
The minor glicht I mentioned is the fact there is an IP address in use which (for the server) has not bee assigned. At least for half of lease time.
And this is not reflected in the server state...
And there is a second problem:
The IP will not be release or renewed before half of the lease time has passed. So when using a static lease for this client it will use the IP not earlier. And this is the same for both cases where I delete the lease on server side or create a static lease....
So I still do not REALLY see the advantage of such a "delete" functionality.
/KNEBB
#28
25.7, 25.10 Series / Re: How can I automatically re...
Last post by tessus - Today at 08:36:11 AMUnfortunately none of the solutions here worked. The Renew DNS for Wireguard on stale connections cronjob doesn't work in my case, because wg reports the connection as active (not stale) even though the gateway is down. So the action that should be triggered to restart the wg service is not triggered.
My current workaround is rather hacky (hardcoded wg service id), but it works. I will look into the script that is triggered in the previous mentioned cronjob. When I first looked into it I saw that it determined the id automatically.
Without further ado...
Use pluginctl -S wireguard to find the id of the wireguard connection. Make a note of that id.
Check which sockets are in use for your GW monitoring: ls -la /var/run/dpinger_*.sock (Make a note of the one you want to monitor. e.g. /var/run/dpinger_INTERFACE_NAME.sock)
Create a file, e.g. /root/bin/check-wg.sh (permissions 0750) and replace the values for SOCKET and WIREGUARD_ID
Unfortunately you can't add a cronjob by using crontab -e, because any manually added entries will be removed (either after a reboot or firmware update - I didn't check which, but my entry wasn't persisted).
Thus create another file: /etc/cron.d/check-wg
That's it.
My current workaround is rather hacky (hardcoded wg service id), but it works. I will look into the script that is triggered in the previous mentioned cronjob. When I first looked into it I saw that it determined the id automatically.
Without further ado...
Use pluginctl -S wireguard to find the id of the wireguard connection. Make a note of that id.
Check which sockets are in use for your GW monitoring: ls -la /var/run/dpinger_*.sock (Make a note of the one you want to monitor. e.g. /var/run/dpinger_INTERFACE_NAME.sock)
Create a file, e.g. /root/bin/check-wg.sh (permissions 0750) and replace the values for SOCKET and WIREGUARD_ID
Code Select
#!/bin/sh
SOCKET=/var/run/dpinger_INTERFACE_NAME.sock
WIREGUARD_ID=ad78e2ad-7ed9-422d-a0b9-ee7ed2795a3
RES=$(cat $SOCKET |cut -d ' ' -f2-)
DT=$(date +"%Y-%m-%d %H:%M:%S %z")
if [[ "$RES" == "0 0 100" ]]; then
echo -n "[$DT] "
/usr/local/sbin/pluginctl -s wireguard restart $WIREGUARD_ID
# If you don't use or want gotify notifications delete the following lines (except the fi)
TOKEN="$(cat ~/.config/gotify/cli.json |jq -r .token)"
URL="$(cat ~/.config/gotify/cli.json |jq -r .url)"
TITLE="check-wg ($(hostname -s))"
TEXT="Wireguard restarted"
curl -m 10 -so /dev/null -X POST "${URL}/message?token=$TOKEN" -F "title=$TITLE" -F "message=$TEXT"
fi
Unfortunately you can't add a cronjob by using crontab -e, because any manually added entries will be removed (either after a reboot or firmware update - I didn't check which, but my entry wasn't persisted).
Thus create another file: /etc/cron.d/check-wg
Code Select
SHELL=/bin/sh
PATH=/etc:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
REQUESTS_CA_BUNDLE=/usr/local/etc/ssl/cert.pem
*/5 * * * * root /root/bin/check-wg.sh >>/var/log/check-wg.log
That's it.
#29
25.7, 25.10 Series / Re: Hostwatch - high disk writ...
Last post by OPNenthu - Today at 07:59:15 AMNice! 👍
I don't follow GitHub that closely and totally missed this.
I don't follow GitHub that closely and totally missed this.
#30
25.7, 25.10 Series / Re: hostwatch at 100% CPU
Last post by tessus - Today at 07:55:17 AMOk, I think this topic is done/solved.
I suspect that the service has a bug somewhere which causes the CPU to run amok. It is a pretty new service after all and it is easy to deactivate it.
Personally I don't need the service, but I understand that people have requested this feature. Who knows, maybe I will activate it again in the future. I am certain the devs will fix the current issues over time.
Patrick's explanation what the service does exactly was very helpful.
I suspect that the service has a bug somewhere which causes the CPU to run amok. It is a pretty new service after all and it is easy to deactivate it.
Personally I don't need the service, but I understand that people have requested this feature. Who knows, maybe I will activate it again in the future. I am certain the devs will fix the current issues over time.
Patrick's explanation what the service does exactly was very helpful.
