strange errorThere were error(s) loading the rules: pfctl: SIOCGIFGROUP: Device not configured
-
@stephenw10,
There are three APs on the LAN that do use OpenWRT but their uptimes are:30d 19h 5m 25s 30d 19h 5m 28s 30d 19h 5m 34s
The last reboot was following a power outage here. So they were not rebooting recently.
There are two Archer APs here, one TP-Link AP and two Comfast APs. They do not appear to use OpenWRT but none have rebooted since the power outage. [We have solar power during the day, with commercial at night with Lithium battery backup for the loss of commercial. There was one night that the commercial was out for so long that the batteries failed. :-) Life in the third world.]
The ISP provided as a Bridge (can be set as a router but not in my case) does use OpenWRT but it also didn't reboot and it is on the WAN side. (It's reboot takes about three minutes and the PPPoE session would have needed to be reset.)
-
Hmm, hard to imagine that MAC would exposed at any time other than at reboot. Unless some process was doing it deliberately, which seems very unlikely.
Any of those devices using a Ralink SoC?
-
No, none of them are using Ralink.
-
@stephenw10
my gateway gets down every time I using the Download at very fast speed. the behaviour is strange after gateway gets down, I cannot dial to connect to the ISP unless I reboot the device.gateway monitoring cannot be stopped, because my ISP changes my ip every few days. there should be a monitor to watch the change of gateways.
I think ' tune the gateway monitoring' is better way. how to change the gateway monitoring in the web? thanks!
-
The latency and loss alarm values can be set in System > Routing > Gateways: Edit the gateway.
If the ISP changes your IP that should force it to reconnect to update. That shouldn't require gateway monitoring.
-
@stephenw10 ,
I can see where that might be a problem. I have a static public IP, and no issues with downloads causing problems. -
@stephenw10
if I disable the gateway monitoring , can this affect my ddns service? thanks! -
It would if for example you have DDNS using a failover gateway group. If you only have one gateway though it would not. Changes in the WAN IP would still trigger the DDNS client to update.
However you should disable the
gateway monitoring action
not the monitoring itself if you choose to do so. -
@stephenw10
hi. after I change the monitoring threshold , this error still happens when I am downloading at very fast speed. here is a error logMar 9 00:18:00 sshguard 71108 Now monitoring attacks. Mar 9 00:18:45 ppp 26135 [wan_link0] LCP: no reply to 1 echo request(s) Mar 9 00:18:47 check_reload_status 430 Linkup starting re0 Mar 9 00:18:47 kernel re0: watchdog timeout Mar 9 00:18:47 kernel re0: link state changed to DOWN Mar 9 00:18:47 kernel re0.1233: link state changed to DOWN Mar 9 00:18:47 check_reload_status 430 Linkup starting re0.1233 Mar 9 00:18:48 check_reload_status 430 Reloading filter Mar 9 00:18:48 ppp 26135 caught fatal signal TERM Mar 9 00:18:48 ppp 26135 [wan] IFACE: Close event Mar 9 00:18:48 ppp 26135 [wan] IPCP: Close event Mar 9 00:18:48 ppp 26135 [wan] IPCP: state change Opened --> Closing Mar 9 00:18:48 ppp 26135 [wan] IPCP: SendTerminateReq #6 Mar 9 00:18:48 ppp 26135 [wan] IPCP: LayerDown
below is another error log similar to the above
Mar 9 00:05:00 sshguard 91853 Exiting on signal. Mar 9 00:05:00 sshguard 20179 Now monitoring attacks. Mar 9 00:05:08 ppp 25847 [wan_link0] LCP: no reply to 1 echo request(s) Mar 9 00:05:11 check_reload_status 430 Linkup starting re0 Mar 9 00:05:11 kernel re0: watchdog timeout Mar 9 00:05:11 kernel re0: link state changed to DOWN Mar 9 00:05:11 kernel re0.1233: link state changed to DOWN Mar 9 00:05:11 check_reload_status 430 Linkup starting re0.1233 Mar 9 00:05:12 check_reload_status 430 Reloading filter Mar 9 00:05:12 ppp 25847 caught fatal signal TERM Mar 9 00:05:12 ppp 25847 [wan] IFACE: Close event Mar 9 00:05:12 ppp 25847 [wan] IPCP: Close event Mar 9 00:05:12 ppp 25847 [wan] IPCP: state change Opened --> Closing Mar 9 00:05:12 ppp 25847 [wan] IPCP: SendTerminateReq #4 Mar 9 00:05:12 ppp 25847 [wan] IPCP: LayerDown
by the way, the new version of PfSense 2.7.2 has the same 'sshguard Exit' log problem as described in the other post which says affecting all the 2.6 versions.
-
@pfsss said in strange errorThere were error(s) loading the rules: pfctl: SIOCGIFGROUP: Device not configured:
Mar 9 00:18:47 kernel re0: watchdog timeout
Try the realtek-kmod driver pkg. If you see that error you should always try that.
-
@stephenw10 said in strange errorThere were error(s) loading the rules: pfctl: SIOCGIFGROUP: Device not configured:
realtek-kmod driver pkg
how to try, type this in the command line? thanks!
-
Like this: https://forum.netgate.com/post/1102086
-
@stephenw10 thanks to your instructions! my gateway has run without crash for a few days!
-
@stephenw10 after I apply your instruction in this post
@stephenw10 said in strange errorThere were error(s) loading the rules: pfctl: SIOCGIFGROUP: Device not configured:
https://forum.netgate.com/post/1102086
the error occurs today morning again:
There were error(s) loading the rules: pfctl: SIOCGIFGROUP: Device not configured - The line in question reads [0]: @ 2024-04-15 05:26:36
the log of the kernel is as below:
Apr 15 05:25:20 kernel re0.1154: link state changed to DOWN Apr 15 05:25:20 check_reload_status 430 Linkup starting re0.1154 Apr 15 05:25:21 check_reload_status 430 Reloading filter Apr 15 05:25:21 ppp 83198 caught fatal signal TERM Apr 15 05:25:21 ppp 83198 [wan] IFACE: Close event Apr 15 05:25:21 ppp 83198 [wan] IPCP: Close event Apr 15 05:25:21 ppp 83198 [wan] IPCP: state change Opened --> Closing Apr 15 05:25:21 ppp 83198 [wan] IPCP: SendTerminateReq #4 Apr 15 05:25:21 ppp 83198 [wan] error writing len 8 frame to b0: Network is down Apr 15 05:25:21 ppp 83198 [wan] IPCP: LayerDown Apr 15 05:25:22 php-cgi 4636 rc.kill_states: rc.kill_states: Removing states for IP 2XX.XXX.XXX.XXX/32 Apr 15 05:25:22 php-cgi 4636 rc.kill_states: rc.kill_states: Removing states for interface pppoe1 Apr 15 05:25:22 check_reload_status 430 Rewriting resolv.conf Apr 15 05:25:22 ppp 83198 [wan] IFACE: Removing IPv4 address from pppoe1 failed(IGNORING for now. This should be only for PPPoE friendly!): Can't assign requested address Apr 15 05:25:22 ppp 83198 [wan] IPV6CP: Close event Apr 15 05:25:22 ppp 83198 [wan] IPV6CP: state change Opened --> Closing Apr 15 05:25:22 ppp 83198 [wan] IPV6CP: SendTerminateReq #3 Apr 15 05:25:22 ppp 83198 [wan] error writing len 8 frame to b0: Network is down Apr 15 05:25:22 ppp 83198 [wan] IPV6CP: LayerDown Apr 15 05:25:23 php-cgi 8237 rc.kill_states: rc.kill_states: Removing states for IP fe80:::XXXX%pppoe1/32 Apr 15 05:25:23 php-cgi 8237 rc.kill_states: rc.kill_states: Removing states for interface pppoe1 Apr 15 05:25:24 check_reload_status 430 Reloading filter Apr 15 05:25:24 check_reload_status 430 Rewriting resolv.conf Apr 15 05:25:24 ppp 83198 [wan] IFACE: Down event Apr 15 05:25:24 ppp 83198 [wan] IFACE: Rename interface pppoe1 to pppoe1 Apr 15 05:25:24 ppp 83198 [wan] IFACE: Set description "WAN" Apr 15 05:25:25 check_reload_status 430 Linkup starting re0 Apr 15 05:25:25 kernel re0: link state changed to UP Apr 15 05:25:25 kernel re0.1154: link state changed to UP Apr 15 05:25:25 check_reload_status 430 Linkup starting re0.1154 Apr 15 05:25:25 ppp 83198 [wan] IPV6CP: SendTerminateReq #4 Apr 15 05:25:25 ppp 83198 [wan] IPCP: SendTerminateReq #5 Apr 15 05:25:26 check_reload_status 430 Reloading filter Apr 15 05:25:26 ppp 76934 Multi-link PPP daemon for FreeBSD Apr 15 05:25:26 ppp 76934 process 76934 started, version 5.9 Apr 15 05:25:26 ppp 76934 waiting for process 83198 to die... Apr 15 05:25:26 php-fpm 56878 /rc.linkup: calling interface_dhcpv6_configure. Apr 15 05:25:26 php-fpm 56878 /rc.linkup: Gateway, NONE AVAILABLE Apr 15 05:25:26 php-fpm 56878 /rc.linkup: Default gateway setting as default. Apr 15 05:25:26 php-fpm 56878 /rc.linkup: Gateway, none 'available' for inet6, use the first one configured. 'WAN_SLAAC' Apr 15 05:25:26 check_reload_status 430 Restarting IPsec tunnels Apr 15 05:25:26 check_reload_status 430 updating dyndns wan Apr 15 05:25:26 ppp 83198 [wan] Bundle: Shutdown Apr 15 05:25:26 ppp 83198 [wan_link0] Link: Shutdown Apr 15 05:25:26 ppp 83198 process 83198 terminated Apr 15 05:25:27 ppp 76934 web: web is not running Apr 15 05:25:27 ppp 76934 [wan] Bundle: Interface ng0 created Apr 15 05:25:27 ppp 76934 [wan_link0] Link: OPEN event Apr 15 05:25:27 kernel ng0: changing name to 'pppoe1' Apr 15 05:25:27 ppp 76934 [wan_link0] LCP: Open event Apr 15 05:25:27 ppp 76934 [wan_link0] LCP: state change Initial --> Starting Apr 15 05:25:27 ppp 76934 [wan_link0] LCP: LayerStart Apr 15 05:25:27 ppp 76934 [wan_link0] PPPoE: Connecting to ''
according to the log, this crush is not caused by the watch dog timeout. is this also caused by the Realtek driver? THX!
-
Right it looks like re0 went down for some other reason, like the modem rebooted. Is that possible?
-
@stephenw10 no, the log has no reboot information. in addition, the admin php shows that the gateway has run for many days.
-
Anything in between? A switch? It looks like it lost link for some reason.
-
@stephenw10 the router connects to the wan directly through the physical port and using pppoe to connect to the ISP
-
Well you might try putting a switch in between if you can. It lost link for some reason. That could be a link negotiation issue. Though it's difficult to test if it didn't happen for 28days!
Did it actually cause a problem beyond triggering the alert?
-
@stephenw10 there is no other issue affects me. the network re-acquires a new ip through PPPOE, and the network is ok. i will watch out such error the next a few days.