There were error(s) loading the rules: pfctl: DIOCADDRULENV: Device busy
-
@stephenw10 sorry, I'm jet lagged and didn't even look at the dates. Ugh..
Here are the general logs after running that command at the shell:
Jan 10 21:27:45 php-fpm 406 /rc.openvpn: The command '/sbin/route -n6 get 'default' 2>/dev/null | /usr/bin/egrep 'flags: <.PROTO.>'' returned exit code '1', the output was ''
Jan 10 21:27:45 xinetd 63604 Starting reconfiguration
Jan 10 21:27:45 xinetd 63604 Swapping defaults
Jan 10 21:27:45 xinetd 63604 readjusting service 6969-udp
Jan 10 21:27:45 xinetd 63604 Reconfigured: new=0 old=1 dropped=0 (services)
Jan 10 21:28:39 rc.gateway_alarm 80695 >>> Gateway alarm: WG_VPN_HQ (Addr:10.100.92.1 Alarm:0 RTT:250.432ms RTTsd:20.860ms Loss:14%)
Jan 10 21:28:39 check_reload_status 446 updating dyndns WG_VPN_HQ
Jan 10 21:28:39 check_reload_status 446 Restarting IPsec tunnels
Jan 10 21:28:39 check_reload_status 446 Restarting OpenVPN tunnels/interfaces
Jan 10 21:28:39 check_reload_status 446 Reloading filter
Jan 10 21:28:40 php-fpm 405 /rc.openvpn: The command '/sbin/route -n6 get 'default' 2>/dev/null | /usr/bin/egrep 'flags: <.PROTO.>'' returned exit code '1', the output was ''
Jan 10 21:28:40 xinetd 63604 Starting reconfiguration
Jan 10 21:28:40 xinetd 63604 Swapping defaults
Jan 10 21:28:40 xinetd 63604 readjusting service 6969-udp
Jan 10 21:28:40 xinetd 63604 Reconfigured: new=0 old=1 dropped=0 (services)
Jan 10 21:40:13 rc.gateway_alarm 93364 >>> Gateway alarm: WG_VPN_HQ (Addr:10.100.92.1 Alarm:1 RTT:259.768ms RTTsd:29.231ms Loss:21%)
Jan 10 21:40:13 check_reload_status 446 updating dyndns WG_VPN_HQ
Jan 10 21:40:13 check_reload_status 446 Restarting IPsec tunnels
Jan 10 21:40:13 check_reload_status 446 Restarting OpenVPN tunnels/interfaces
Jan 10 21:40:13 check_reload_status 446 Reloading filter
Jan 10 21:40:15 php-fpm 28 /rc.openvpn: The command '/sbin/route -n6 get 'default' 2>/dev/null | /usr/bin/egrep 'flags: <.PROTO.>'' returned exit code '1', the output was ''
Jan 10 21:40:15 xinetd 63604 Starting reconfiguration
Jan 10 21:40:15 xinetd 63604 Swapping defaults
Jan 10 21:40:15 xinetd 63604 readjusting service 6969-udp
Jan 10 21:40:15 xinetd 63604 Reconfigured: new=0 old=1 dropped=0 (services)
Jan 10 21:40:57 rc.gateway_alarm 5473 >>> Gateway alarm: WG_VPN_HQ (Addr:10.100.92.1 Alarm:0 RTT:259.393ms RTTsd:31.093ms Loss:15%)
Jan 10 21:40:57 check_reload_status 446 updating dyndns WG_VPN_HQ
Jan 10 21:40:57 check_reload_status 446 Restarting IPsec tunnels
Jan 10 21:40:57 check_reload_status 446 Restarting OpenVPN tunnels/interfaces
Jan 10 21:40:57 check_reload_status 446 Reloading filter
Jan 10 21:40:58 php-fpm 406 /rc.openvpn: The command '/sbin/route -n6 get 'default' 2>/dev/null | /usr/bin/egrep 'flags: <.PROTO.>'' returned exit code '1', the output was ''
Jan 10 21:40:58 xinetd 63604 Starting reconfiguration
Jan 10 21:40:58 xinetd 63604 Swapping defaults
Jan 10 21:40:58 xinetd 63604 readjusting service 6969-udp
Jan 10 21:40:58 xinetd 63604 Reconfigured: new=0 old=1 dropped=0 (services)
Jan 10 21:41:00 sshguard 68209 Exiting on signal.
Jan 10 21:41:00 sshguard 76061 Now monitoring attacks.
Jan 10 21:47:35 php-fpm 28 /status_logs.php: Session timed out for user 'admin' from: 192.168.1.143 (Local Database)
Jan 10 21:47:45 php-fpm 28 /status_logs.php: Successful login for user 'admin' from: 192.168.1.143 (Local Database)
Jan 10 21:48:50 sshd 5970 Received disconnect from 192.168.1.143 port 64050:11: Normal Shutdown
Jan 10 21:48:50 sshd 5970 Disconnected from user admin 192.168.1.143 port 64050
Jan 10 21:49:21 sshd 55624 Accepted keyboard-interactive/pam for admin from 192.168.1.143 port 54238 ssh2 -
Hmm, no pf error then.
Without any openvpn config there shouldn't be anything triggered by running rc.openvpn.
I wonder if you still have any conf files remaining in /var/etc/openvpn?
-
@stephenw10 doesn't look like it
[23.09.1-RELEASE][admin@]/: cd /var/etc/openvpn
/var/etc/openvpn: No such file or directory.
[23.09.1-RELEASE][admin@]/: -
FYI
This week I just hit a similar issue where the PF machine ( Netgate pfSense Plus 23.09-RELEASE (amd64) ) was no longer smoothly pushing packets through and there was significant packet loss. After logging into webgui the notifications greeted with the following (date and time removed):pf_busy
PF was wedged/busy and has been reset. @ -DATE TIME- PF was wedged/busy and has been reset. @ -DATE TIME-Filter Reload
There were error(s) loading the rules: pfctl: DIOCADDRULENV: Device busy - The line in question reads [0]: @ -DATE TIME- There were error(s) loading the rules: pfctl: DIOCADDRULENV: Device busy - The line in question reads [0]: @ -DATE TIME- There were error(s) loading the rules: pfctl: SIOCGIFGROUP: Device not configured - The line in question reads [0]: @ -DATE TIME-The machine was rebooted and appears to functioning normal again.
When I have the time I will try to pull and review logs.
-
C clawsonn referenced this topic on Mar 8, 2024, 5:12 AM
-
@clawsonn My situation has not improved. My notices:
pf_busy
• PF was wedged/busy and has been reset. @ 2024-01-25 04:54:20
• PF was wedged/busy and has been reset. @ 2024-01-28 20:04:22
• PF was wedged/busy and has been reset. @ 2024-01-30 02:24:22
• PF was wedged/busy and has been reset. @ 2024-03-06 07:54:55
• PF was wedged/busy and has been reset. @ 2024-03-15 08:14:59
• PF was wedged/busy and has been reset. @ 2024-03-21 09:15:02
• PF was wedged/busy and has been reset. @ 2024-03-23 20:45:03
• PF was wedged/busy and has been reset. @ 2024-03-24 06:50:04
Filter Reload
• There were error(s) loading the rules: pfctl: DIOCADDRULENV: Device busy - The line in question reads [0]: @ 2024-01-25 04:54:21
• There were error(s) loading the rules: pfctl: DIOCADDRULENV: Device busy - The line in question reads [0]: @ 2024-01-28 20:04:23
• There were error(s) loading the rules: pfctl: DIOCADDRULENV: Device busy - The line in question reads [0]: @ 2024-01-30 02:24:23
• There were error(s) loading the rules: pfctl: DIOCADDRULENV: Device busy - The line in question reads [0]: @ 2024-03-06 07:54:56
• There were error(s) loading the rules: pfctl: DIOCADDRULENV: Device busy - The line in question reads [0]: @ 2024-03-15 08:15:00
• There were error(s) loading the rules: pfctl: DIOCADDRULENV: Device busy - The line in question reads [0]: @ 2024-03-21 09:15:03
• There were error(s) loading the rules: pfctl: DIOCADDRULENV: Device busy - The line in question reads [0]: @ 2024-03-23 20:45:04
• There were error(s) loading the rules: pfctl: DIOCADDRULENV: Device busy - The line in question reads [0]: @ 2024-03-24 06:50:05This should not be happening.
-
@stephenw10 Would be great if you could take a look at this, its happening quite consistently now
-
Still the 6100 running 23.09.1?
If you manually reload the ruleset in Status > Filter Reload does that trigger it?
-
@stephenw10 Yes sir, the 6100 running 23.09.1. Here is the output from the Filter Reload, it did not trigger any notices.
Initializing Creating aliases Creating gateway group item... Generating Limiter rules Generating NAT rules Creating 1:1 rules... Creating outbound NAT rules Creating automatic outbound rules Setting up TFTP helper Generating filter rules Creating default rules Pre-caching ... Creating filter rule ... Creating filter rules ... Setting up pass/block rules Setting up pass/block rules Creating rule Pre-caching Wireguard Port... Creating filter rule Wireguard Port ... Creating filter rules Wireguard Port ... Setting up pass/block rules Setting up pass/block rules Wireguard Port Creating rule Wireguard Port Pre-caching ping... Creating filter rule ping ... Creating filter rules ping ... Setting up pass/block rules Setting up pass/block rules ping Creating rule ping Pre-caching Default allow LAN to any rule... Creating filter rule Default allow LAN to any rule ... Creating filter rules Default allow LAN to any rule ... Setting up pass/block rules Setting up pass/block rules Default allow LAN to any rule Creating rule Default allow LAN to any rule Pre-caching ... Creating filter rule ... Creating filter rules ... Setting up pass/block rules Setting up pass/block rules Creating rule Pre-caching OpenVPN OpenVPN Users wizard... Creating filter rule OpenVPN OpenVPN Users wizard ... Creating filter rules OpenVPN OpenVPN Users wizard ... Pre-caching Homebridge Allow... Creating filter rule Homebridge Allow ... Creating filter rules Homebridge Allow ... Setting up pass/block rules Setting up pass/block rules Homebridge Allow Creating rule Homebridge Allow Pre-caching Block Default LAN... Creating filter rule Block Default LAN ... Creating filter rules Block Default LAN ... Setting up pass/block rules Setting up pass/block rules Block Default LAN Creating rule Block Default LAN Pre-caching Block Default LAN... Creating filter rule Block Default LAN ... Creating filter rules Block Default LAN ... Setting up pass/block rules Setting up pass/block rules Block Default LAN Creating rule Block Default LAN Pre-caching Allow Any... Creating filter rule Allow Any ... Creating filter rules Allow Any ... Setting up pass/block rules Setting up pass/block rules Allow Any Creating rule Allow Any Pre-caching Pass VPN traffic from WireGuard peers... Creating filter rule Pass VPN traffic from WireGuard peers ... Creating filter rules Pass VPN traffic from WireGuard peers ... Setting up pass/block rules Setting up pass/block rules Pass VPN traffic from WireGuard peers Creating rule Pass VPN traffic from WireGuard peers Pre-caching ... Creating filter rule ... Creating filter rules ... Setting up pass/block rules Setting up pass/block rules Creating rule Pre-caching Pass VPN traffic from WireGuard peers... Creating filter rule Pass VPN traffic from WireGuard peers ... Creating filter rules Pass VPN traffic from WireGuard peers ... Setting up pass/block rules Setting up pass/block rules Pass VPN traffic from WireGuard peers Creating rule Pass VPN traffic from WireGuard peers Pre-caching UNVR Allow... Creating filter rule UNVR Allow ... Creating filter rules UNVR Allow ... Setting up pass/block rules Setting up pass/block rules UNVR Allow Creating rule UNVR Allow Pre-caching Block Default LAN... Creating filter rule Block Default LAN ... Creating filter rules Block Default LAN ... Setting up pass/block rules Setting up pass/block rules Block Default LAN Creating rule Block Default LAN Pre-caching Allow Any... Creating filter rule Allow Any ... Creating filter rules Allow Any ... Setting up pass/block rules Setting up pass/block rules Allow Any Creating rule Allow Any Creating IPsec rules... Creating uPNP rules... Generating ALTQ queues Loading filter rules Setting up logging information Setting up Ethernet filter rules... Setting up SCRUB information Processing down interface states Running plugins Done -
Hmm, is there any sort of pattern to when it happens? When it's passing most traffic perhaps?
Is there anything else logged at the time?
-
@stephenw10 I have 3 locations. 3 6100, 2 of them are nearly identical configuration, most of the same components on the LAN. The 6100 that is throwing off these errors was replaced due to hardware at one time and so the config was restored. It's also the least configured of the 3 in terms of rules. I really wish I could give you more details but that location is pretty quiet..
-
@stephenw10 I forgot to mention that I have Tac Pro on this device, I plan to open a ticket
-
Yes, open a ticket if you haven't already. Link to this thread so TAC have the details here.
-
Just to be clear when this happens it just logs that and continues? It doesn't require manual intervention?
-
@stephenw10 It's crashed and I had to hire someone to go onsite and manually power cycle it
-
I assume not every time that error is shown though?
-
@stephenw10 No, just 2x
-
Hmm, OK. 2x too many!
Do you know if it remains responsive at the console when that happens?
-
@stephenw10 I wish I could say, but its a remote location and has only acted this way when I'm not on site... last time was 24 hours after I left...frustrating
-
Are you able to upload a status file to us to review?
-
@stephenw10 of course, pls tell me what to do =)