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 - forca

#1
thx for the info, unfortunately it was autoenabled since last "mini"-update and let my system run into a oom-killer:

2026-01-21T01:01:04 Notice kernel <3>[148875] pid 63743 (unbound), jid 0, uid 59, was killed: failed to reclaim memory
2026-01-21T01:01:03 Notice kernel <3>[148874] pid 94211 (netstat), jid 0, uid 0, was killed: failed to reclaim memory
2026-01-21T01:01:02 Notice kernel <3>[148872] pid 85969 (hostwatch), jid 0, uid 377, was killed: failed to reclaim memory
2026-01-21T00:54:00 Notice kernel [148450] swp_pager_getswapspace(31): failed
2026-01-21T00:54:00 Notice kernel [148450] swap_pager: out of swap space
2026-01-21T00:53:59 Notice kernel [148450] swp_pager_getswapspace(13): failed
2026-01-21T00:53:00 Notice kernel [148390] swp_pager_getswapspace(24): failed

so, ca after 2-3 days my 16GB ram was "overflowed".

here some screenshots (3, within 1 minunte or even less):






I have already disables this service, but why is it enabled per default? any ideas about "possible" memory leak?

I noticed also some logs from the service itself:

2026-01-21T08:53:42 Warning hostwatch 2026-01-21T07:53:42.608373Z WARN hostwatch: Failed to initialize capture for device: pfsync0
2026-01-21T08:53:42 Warning hostwatch 2026-01-21T07:53:42.607962Z WARN hostwatch: Failed to initialize capture for device: usbus0
2026-01-21T07:14:01 Warning hostwatch 2026-01-21T06:14:01.595423Z WARN hostwatch: Failed to initialize capture for device: pfsync0
2026-01-21T07:14:01 Warning hostwatch 2026-01-21T06:14:01.594986Z WARN hostwatch: Failed to initialize capture for device: usbus0
#2
any news about? on the dashboard are still public-keys instead of names visible.

names would be very very nice :):)
#3
another way to go, would be (even if ugly), to go via API, e.g. like here:
https://docs.opnsense.org/development/api/plugins/firewall.html

so I can now read (get) this one nat-rule via curl-call. So it should be possible on schedule add/delete this one nat-rule...

but it seems to be very ugly and not reliable.

Another question, if you consider the config.xml and an firewall(filter) rule with an activated schedule inside, we do see an such definition:

<sched>tst_tmp_rule1</sched>

If I would now inject this line into a nat-rule rule (e.g. by hijacking the /conf/config.xml), would the schedule work for my nat-rule?
#4
@franco

is it meanwhile possible to add a schedule for nat-rules (port forwarding)?
cause, I need a tmp (dynamic) nat-rule, that does redirect do a specific dns (in separated vlan) for some days or some hours in a day, otherwise (normal operating) it is using a "normal" dns (without any nat-redirects).

How can I do this? because the your mentioned above way would not work here
#5
Development and Code Review / Re: mdns-repeater
September 04, 2019, 11:22:23 AM
any news about working mdns-repeater with OpenVPN devices (tun)?

would be very nice..