strange errorThere were error(s) loading the rules: pfctl: SIOCGIFGROUP: Device not configured
-
@stephenw10
Do you see the RED "The Wall" in the second graphic above. That is what you see when an 'Device drops not an interface. And what is it monitoring? Intermapper is monitoring the address 192.168.1.1 on the device (the LAN port). So the drops are NOT an upstream issue. Maybe they're the phantom MAC address that is NOT on my system. (Unless you want to argue that the ISP bridge, on occasion forget's it's a bridge and starts announcing it self as my gateway.) So maybe? the drop can be related to an upstream issue, but it is the device does we see drop. The software I am using is Intermapper from Help Systems. It is getting its information via SNMP from the router/firewall.I never saw the issued related to the WAN port before, I never saw the device drops I see now, until the software upgrade occurred. The issues stared within hours.Until I got the 'email notification,' I had nothing in the logs other than a phantom MAC address that doesn't exist on my network to look at. But the email got me writing this.
For what it's worth the manufacturer associated with the MAC address does not have an obvious connection to the devices on my network..(See below). All such devices that are of the same tye but different manufacturer are assigned proper IP addresses and can be found on the network.
From https://en.wikipedia.org/wiki/Ralink
Ralink Technology, Corp. is a Wi-Fi chipset manufacturer mainly known for their IEEE 802.11 (Wireless LAN) chipsets. Ralink was founded in 2001 in Cupertino, California, then moved its headquarters to Hsinchu, Taiwan. On 5 May 2011, Ralink was acquired by MediaTek.Some of Ralink's 802.11n RT2800 chipsets have been accepted into the Wi-Fi Alliance 802.11n draft 2.0 core technology testbed. They have also been selected in the Wi-Fi Protected Setup (WPS) and Wireless Multimedia Extensions Power Save (WMM-PS) testbeds. Ralink was a participant in the Wi-Fi Alliance and the IEEE 802.11 standards committees.[1] Ralink chipsets are used in various consumer-grade routers made by Gigabyte Technology, Linksys, D-Link, Asus and Belkin, as well as Wi-Fi adaptors for USB, PCI, ExpressCard, PC Card, and PCI Express interfaces. An example of an adapter is the Nintendo Wi-Fi USB Connector which uses the Ralink RT2570 chipset to allow a Nintendo DS or Wii to be internetworked via a home computer.
-
OK well if it's monitoring the LAN side then the reported LAN IP conflict could certainly be causing it:
arp: 00:0c:43:e1:76:29 is using my IP address 192.168.1.1 on igc3How often do you see that logged?
Is igc3 the LAN interface?
Check the MAC address in the ARP table of the monitoring system when it shows as down.
The device is on your network somehow. Using that IP makes it likely to be a router/firewall of some sort.
-
@stephenw10
The MAC address does NOT appear on the arp table for: (1)the netgate device; (2) the DHCP server (a Linux server); (3) my desktop; the arp table of my managed switch. Angry IP scanner does not see it. There are 53 hosts plus mobile units, but in each case I know both the MAC address and the assigned IP.So either this is a phantom but real MAC address that only decided to come alive as soon as the last Netgate/FreeBSD code was installed (as nothing had at that time been added to the network, or it is the Netgate/FreeBSD code. Are you wanting to argue that the phantom MAC address and the attached gateway IP was always there and earlier Netgate/FreeBSD code wasn't good enough to see it? I am confused.
While at the same time, there was the appearance of the PPPoE issue regarding error 65 on the gateway.
-
@Ellis-Michael-Lieberman said in strange errorThere were error(s) loading the rules: pfctl: SIOCGIFGROUP: Device not configured:
The MAC address does NOT appear on the arp table for: (1)the netgate device; (2) the DHCP server (a Linux server); (3) my desktop; the arp table of my managed switch. Angry IP scanner does not see it.
That is when the firewall shows as down in the monitoring system?
It could be coincidental that the monitoring system stops being able to pull responses from the firewall and the firewall is logging another device using it's IP.
I would guess something is falling back to a default config or perhaps using that IP/MAC when it boots and then switching to something else.
However something on the LAN using the same IP would not cause a problem on the WAN side. That assumes igc3 is the LAN as I asked above?
-
@stephenw10
"It could be coincidental that the monitoring system stops being able to pull responses from the firewall and the firewall is logging another device using it's IP."But it never did for well over a year before the upgrade? And it don't do that for other devices? And an SNMP query can do that? Yeah, I'm not buying that.
"I would guess something is falling back to a default config or perhaps using that IP/MAC when it boots and then switching to something else."
It could be but power is stable and nothing here when running has that MAC address.
"That assumes igc3 is the LAN as I asked above?"
Yes igc3 is the LAN side. So both the LAN side and the WAN side are producing weirdness that they never produced before. How likely is that?
-
still no easy way to resolve this problem?
-
@pfsss
The problem persists.Mar 4 03:09:34 kernel arp: 00:0c:43:e1:76:29 is using my IP address 192.168.1.1 on igc3! Mar 4 03:09:36 kernel arp: 00:0c:43:e1:76:29 is using my IP address 192.168.1.1 on igc3!This MAC address does NOT exist on the LAN. I have a list of every MAC address on this LAN.
All the while here is the speed test on a 200GB fiber connection:
Speedtest by Ookla [error] Error: [101] Network unreachable Server: Panay Broadband (BCATVi) - Iloilo (id: 9935) ISP: Philippine Long Distance Telephone Idle Latency: 27.69 ms (jitter: 0.11ms, low: 27.62ms, high: 27.82ms) Download: 212.02 Mbps (data used: 296.8 MB) 27.88 ms (jitter: 7.20ms, low: 27.38ms, high: 296.45ms) Upload: 218.33 Mbps (data used: 221.7 MB) 28.66 ms (jitter: 0.79ms, low: 28.17ms, high: 36.35ms) Packet Loss: 0.0% Result URL: https://www.speedtest.net/result/c/47d96817-22ce-4051-87eb-22c8c191eff7Which makes no sense as I am getting a great through speed while at the same time am told "Network unreachable."
-
@Ellis-Michael-Lieberman said in strange errorThere were error(s) loading the rules: pfctl: SIOCGIFGROUP: Device not configured:
Mar 4 03:09:34 kernel arp: 00:0c:43:e1:76:29 is using my IP address 192.168.1.1 on igc3!
Mar 4 03:09:36 kernel arp: 00:0c:43:e1:76:29 is using my IP address 192.168.1.1 on igc3!Does it always appear like that with 2s between two warnings?
I'd be amazed if that's not a real conflict. I've never seen that alert triggered as a false positive.
I'd still guess it's something using that MAC at bootup, maybe trying to PXE boot. Something with a Ralink SoC probably.
Anything else that sees those broadcasts and updates it's ARP table would lose connectivity until it gets updated again. However you said you checked the ARP table on the monitoring system whilst it showed as down and it was correct. So it could be unrelated.
-
@stephenw10
First, not it is not always twice. It is often once. As is:Mar 3 20:25:00 sshguard 80813 Exiting on signal. Mar 3 20:25:00 sshguard 70235 Now monitoring attacks. Mar 3 20:29:29 kernel arp: 00:0c:43:e1:76:29 is using my IP address 192.168.1.1 on igc3! Mar 3 20:34:00 sshguard 70235 Exiting on signal. Mar 3 20:34:00 sshguard 47918 Now monitoring attacks. Mar 3 20:43:00 sshguard 47918 Exiting on signal.- Nothing was booting on the LAN. I have a log for that on the network monitoring tool.
- Everything that boots has a known MAC address which isn't that one.
I know each and every item on this LAN. I put these things on the LAN. Every item is accounted for and its MAC address is know. There is no Ralink devices here. - The reporting of a Down interface is on 30 second sweeps. The connection between the arp table and the DOWN map is not at the same time. The event had passed. The event was millisecond or two and then the Router has to regain the PPPoE traffic.
-
Ok likely unrelated then.
You should still find out what is sending from that MAC though. Something on that segment is and clearly it's something you don't know about.
-
@stephenw10 ,
Are you referring to the device that miraculously appeared the very moment I upgraded to the current version and was never there before? The one that miraculously installed itself, as I had not installed anything on the network?OK, so do you know of any exorcists? My Rolodex is not helpful when it comes to the supernatural.
-
I have logged into the managed switch the router is directly connect to via CLI.
Here is the setting:
mac address-table filtering 00:0c:43:e1:76:29 vid 1 MAC Address Table ------------------------------------------------------------ MAC VLAN Port Type Aging --- ---- ---- ---- ----- 00:0c:43:e1:76:29 1 filter no-aging 00:12:31:8f:30:6a 1 Gi1/0/2 dynamic aging 00:12:41:fc:82:a8 1 Gi1/0/15 dynamic agingHere is the description from the PDF of the manual for the switch;
14.4 mac address-table filtering Description The mac address-table filtering command is used to add the filtering address entry. To delete the corresponding entry, please use no mac address-table filtering command. The filtering address function is to forbid the undesired package to be forwarded. The filtering address can be added or removed manually, independent of the aging time. -
Ok so it's filtering that MAC on all ports? It will be interesting to see if that stops it logging in pfSense. Or perhaps more interesting if it doesn't!
-
@stephenw10
Yes, it is filtering on all ports.I was frustrated as to why the GUI interface for the managed switch didn't allow for MAC filtering. I downloaded the PDF for the switch and found that the CLI allowed for it.
There are two managed switches on this LAN. The one I configured is the one the router directly connects to on switch port #14. It's a straight CAT6 between the units.
-
Mmm, interesting. If the mystery device (assuming it exists!) is connected to the other switch ARP broadcasts may still reach clients.
-
Are you saying that the packet would show up with the MAC address of the other managed switch and get passed though?
There are five other unmanaged switches on this network. It that's the case, then it would get through regardless. Of the more than 50 (sometimes 60 with all the cellphones using WiFi, only the router and maybe three other device are directly connected. Everything else comes through other switches. (Of the 16 ports on the main managed switch, ten ports are in use. Four direct to devices and six to switches.)
-
@stephenw10 ,
I dumped the "show mac address-table" from the switch. The only PC that was running on the LAN was mine and the printer was off line. (This is a quiet time.)I ran "Angry IP" at my workstation and did a "stare and compare" of sorts, by copying the dump from the switch into a spreadsheet (sorted by MAC address), and then ran down the the results I got from Angry IP.
Often the dump from the switch shows a MAC address twice. Adding to the confusion is that many of the CCTV cameras have both a wired Ethernet MAC address and a WiFi MAC address plus the units report both even though only one is functioning frequently resulting in four listings for one camera on the dump. And what you have below is the actual dump of the MAC addresses.
As an example of the duplicates, the "MagicJack" is directly connected to the main managed switch, yet there are two listings in the dump. The D-link switch does have two listings 28:3b:82:7f:5e:e8, but the WiFi AP connected to it connected has very different MAC address 20:76:93:4e:26:27, as does the CCTV camera connected to it. (Other devices and are connected to it but were not 'on' at the time of the dump.) And the WiFi AP address 20:76:93:4e:23:e3 is connected to unmanaged switch connected to a different mail switch port while the address 20:76:93:50:4a:2b actually directly connected the main switch.
So, all the MAC addresses match the end device, not a switch port. For your edification, here are the results.
00:12:31:8f:30:6a CCTV 00:12:41:fc:82:a8 CCTV 00:12:41:fc:b8:d6 CCTV 00:12:42:10:0d:72 CCTV 00:12:43:6b:5a:1e CCTV 00:12:43:73:ba:c4 CCTV 00:2a:2b:fe:80:d1 CCTV 00:9b:fe:72:d1:2e CCTV 00:b5:d0:ef:17:bf CCTV 00:c8:1e:63:8d:e8 CCTV 06:77:f8:74:ab:52 Mobile Phone 08:00:27:25:77:23 VirtualBox Server 08:00:27:77:12:35 VirtualBox Server 08:00:27:ad:fd:b9 VirtualBox Server 08:00:27:d9:80:58 VirtualBox Server 10:27:f5:5d:21:1d TL-Link AP 20:76:93:4e:23:e3 WiFI-AP 20:76:93:4e:26:27 WiFI-AP 20:76:93:50:4a:2b WiFI-AP 22:09:5c:07:1d:2a BlackBox workstation 28:3b:82:7f:5e:e8 D-Link Managed Switch 28:3b:82:7f:5e:e9 D-Link Managed Switch 28:9c:6e:27:10:ce Mobile Phone 2a:03:3e:20:11:7e VM Host 30:ff:f6:83:0a:75 CCTV 30:ff:f6:83:0a:75 CCTV 30:ff:f6:8f:50:dc CCTV 30:ff:f6:8f:50:dc CCTV 30:ff:f6:90:ba:94 CCTV 30:ff:f6:90:ba:94 CCTV 50:c7:bf:d7:1b:e6 WiFI-AP 50:c7:bf:d7:1b:e6 WiFI-AP 54:f1:5f:fc:b1:b6 CCTV 54:f1:5f:fc:b1:b6 CCTV 60:be:b4:07:00:b5 Router 60:be:b4:07:00:b5 Router 6c:33:a9:1d:27:4b MagicJack 6c:33:a9:1d:27:4b MagicJack 88:28:7d:38:52:ca CCTV 88:28:7d:38:52:ca CCTV 88:28:7d:4e:fb:9f CCTV 88:28:7d:4e:fb:9f CCTV b0:48:7a:e2:5b:86 WiFI-AP b0:48:7a:e2:5b:86 WiFI-AP b4:fb:e3:36:18:74 CCTV b4:fb:e3:36:18:74 CCTV b4:fb:e3:36:30:4d CCTV b4:fb:e3:36:30:4d CCTV b4:fb:e3:36:41:c8 CCTV b4:fb:e3:36:41:c8 CCTV b4:fb:e3:36:44:54 CCTV b4:fb:e3:36:44:54 CCTV b4:fb:e3:36:47:0c CCTV b4:fb:e3:36:47:0c CCTV b4:fb:e3:39:49:1f CCTV b4:fb:e3:39:49:1f CCTV d6:f1:6e:cf:fe:17 Mobile Phone e0:e1:a9:bc:d2:fd CCTV e2:e0:b9:4a:8c:ce CCTV -
@Ellis-Michael-Lieberman @stephenw10
in my comprehension, my problem is caused by the the large loss at gateway, especially when the download speed is high, and then the system restarts my pppoe gateway, but using a new config called 'ng0' instead of the origin config 'pppoe1'. So no matter how I reconnect, pppoe remains failed unless I reboot my pfsense device to switch to the origin config file.is that right?
-
@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 :-) )
-
@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.
