strange errorThere were error(s) loading the rules: pfctl: SIOCGIFGROUP: Device not configured

Ellis Michael Lieberman

@pfsss
In my case, PPPoE never actually seems to drop. There is no reset. The IP "conflict" is reported, I see, both via the network tool and in real time, a loss of connectivity, but without any rest, all eventually within about 60 seconds comes back stable again. The only thing the log notes is the IP conflict from an unknown MAC address.

The error 65 I was experiencing was, today, resolved via a multi-day series of contacts with my ISP that finally got them to resolve something on their side. My only mystery is now the phantom MAC address and the IP address the phantom is creating. There are literally no more log entries in the gateway log. But even after the error 65 errors ended the phantom MAC address issue remained.

I have put a block on that MAC address in the managed switch the router is directly connected to as @stephenw10 is convinced it's something on my LAN. The errors can take as much as 36 hours between incidents, so I am just waiting.

(In the meantime, there is apparently damage to transpacific fiber cable connecting the Philippines to the USA and Europe. So, if the problem is an outside attack, as a fellow on Reddit is claiming, the cable cut may be dampening the effort. My bandwidth within the Philippines is currently fantastic. I suspect it's because international traffic is hobbled :-) )

stephenw10

@pfsss If you have a WAN with a lot of buffer bloat or just very lossy you may need to tune the gateway monitoring so it doesn't trigger at latency or packet loss levels that are expected.
If you only have one gateway you can also just disable the monitoring action for it so it never gets marked down.

PPPoE uses NetGraph to create the connections. It is first created as ng0 and then renamed as ppppoe0. That's expected.

stephenw10

@Ellis-Michael-Lieberman Yeah I would expect to see the mystery MAC in the switch table if it passed the switch. But those entries will expire so it would only be there for some time after it appears.

No I wouldn't expect to see any traffic from a switch MAC masking the original source unless any of those switches are layer 3 and actually routing.

The only time I've seen MAC addresses being 'NAT'd' is when using WIFI extenders which are almost always a terrible idea!

stephenw10

@Ellis-Michael-Lieberman said in strange errorThere were error(s) loading the rules: pfctl: SIOCGIFGROUP: Device not configured:

00:0c:43:e1:76:29

Googling that MAC address shows it's the default used in a bunch of OpenWRT based firmwares. I'd bet this is an access point somehow dropping to it's default values temporarily. I could imagine it doing that at boot when the boot loader checks for PXE boot options. However that would definitely interrupt any wifi devices using it. Unless perhaps you have enough coverage that devices switch APs seamlessly?
If the APs you have show uptime that would rule it out.

Ellis Michael Lieberman

@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.)

stephenw10

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?

Ellis Michael Lieberman

@stephenw10

No, none of them are using Ralink.

pfsss

@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!

stephenw10

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.

Ellis Michael Lieberman

@stephenw10 ,
I can see where that might be a problem. I have a static public IP, and no issues with downloads causing problems.

pfsss

@stephenw10
if I disable the gateway monitoring , can this affect my ddns service? thanks!

stephenw10

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.

pfsss

@stephenw10
hi. after I change the monitoring threshold , this error still happens when I am downloading at very fast speed. here is a error log

Mar 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.

stephenw10

@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.

pfsss

@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!

stephenw10

Like this: https://forum.netgate.com/post/1102086

pfsss

@stephenw10 thanks to your instructions! my gateway has run without crash for a few days!

pfsss

@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!

stephenw10

Right it looks like re0 went down for some other reason, like the modem rebooted. Is that possible?

pfsss

@stephenw10 no, the log has no reboot information. in addition, the admin php shows that the gateway has run for many days.