Arpwatch reports bogons frequently
-
I have both enabled - and getting notification.. The one clearly states 0.0.0.0 changes.. Which would be like client doing a discover ;)
Oh, cool,. thats good to know . I will enable the other also, as long as I get the MAC change, new MAC etc,etc I can enable it.
This place is awesome, I don't say it enogh-but there yah go.
Thanks for the 4rth time:-)
Happy family, turkey day, beer and wine :-)
-
@johnpoz Where is this GUI available from please?
-
@1server under arpwatch on the pfsense gui ;)
-
@johnpoz said in Arpwatch reports bogons frequently:
pfsense
Oh I didn't realise pfsense was an OS :)
I was looking for a GUI for centos
Thanks for such a fast response
-
@1server hahaah - so what this forum thread came up on some google search?
-
@johnpoz yeah I was searching bogons
-
@johnpoz said in Arpwatch reports bogons frequently:
@1server under arpwatch on the pfsense gui ;)
Only if you installed arpwatch package. I never installed it because I was under the impression from a few years back that it caused some issues in some of the 2.3.x/2.4.x versions of pfsense.
-
@jdeloach very true.. Yeah that won't be there if you don't have arpwatch installed..
-
G Gertjan referenced this topic on
-
Hello, same here, I clicked the options "Disable 0.0.0.0" and bogons, and still I cant get rid of messages in system log: arpwatch 61114 reused old ethernet address 0.0.0.0 , or arpwatch 61538 flip flop 0.0.0.0 . Is there any way, hot to really disable it on arpwatch?
-
@georgecz58 Same problem here - the option "Disable 0.0.0.0" doesn't seem to work, my logs are still full of messages like
arpwatch[22477]: reused old ethernet address 0.0.0.0 88:15:44:a8:8a:20 (1e:a3:ab:20:86:85)and would also generate notifications if I didn't disable that by patching arpwatch.inc...The correct command line option is passed by the GUI configurator ( -z ) so it must be a bug in arpwatch itself.
I don't actually want any notifications from Arpwatch, I only want to use it to build a table of all active mac / ip addresses on the network that it has seen, as having such a table available can be very useful during network troubleshooting, so it's a shame it's spamming the system log with useless notifications.
The log spamming is causing the log to rotate very frequently drowning out useful information so I'm probably going to turn it off.
-
@dbmandrake ok spent a few minutes playing with this.. Seems to me the problem is just some limitations with arpwatch itself.
A few quick little tests I ran into a problem with the disable bogon.. If I turn that on, it then registered 0.0.0.0 for the mac of my device when it tried to get a dhcp via discover.
You would then prob have an issue with flip flop, when some other device did a discover..
Need to do some more playing.. But seems to me there should just be an option in arpwatch to just plain ignore anything with IP of 0.0.0.0, ie don't log it as bogon, don't ever log it as an IP for a mac, and don't ever log it for a flip flop, etc..
Just plain ignore anything with 0.0.0.0 should be an option. But I would think that would have to be changed in arpwatch itself.
Seems to me any use of arpwatch is going to come with some log spam issues. Or bogus entries like this in the arp db.
So my take away from this little play session, is if you want to use arpwatch you going to have to deal with some log spam in one way or another.. I would think just ignoring anything with 0.0.0.0 would useful option in arpwatch but maybe I am missing something where that could be an issue? Not sure if something could be done on pfsense inc for arpwatch, or if that would have to be something done upstream in arpwatch.
Your change to the inc to not send notification on such stuff might be valuable patch for those wanting to use arpwatch.. What exactly did you change in the inc?
edit: seeing stuff like this as I thought
I changed my mac on my machine to 17 vs 16 and yeah it logs the nonsense.. And notice one of my other machines now as a 0.0.0.0 entry as well..
I would suggest we put in a very detailed redmine about this stuff - but not sure what all could be done locally on pfsense, it just seems to be arpwatch.. If you tell it not to not report any bogon, then 0.0.0.0 becomes just an IP, while the not report 0.0.0.0 changes might limit the log spam on dhcp stuff.. But now what my db is going to fill up with 0.0.0.0 being reported for every mac when it does dhcp? And going to get changes every time 0.0.0.0 for a new mac?
edit2: Ok the more I play with this the more nonsense I see..
Doesn't look like disable bogon is very useful.. So now 169.254 are going to get registered when clients use that in their dhcp process, etc.. or when issue with dhcp and clients send any traffic at all from those APIPA addresses..
-
@johnpoz said in Arpwatch reports bogons frequently:
@dbmandrake ok spent a few minutes playing with this.. Seems to me the problem is just some limitations with arpwatch itself.
A few quick little tests I ran into a problem with the disable bogon.. If I turn that on, it then registered 0.0.0.0 for the mac of my device when it tried to get a dhcp via discover.
You would then prob have an issue with flip flop, when some other device did a discover..
"Disable bogons" does work, if it's unticked I see
arpwatch[14559]: bogon 0.0.0.0 88:15:44:a8:8a:b0while if it's ticked I seereused old ethernet address 0.0.0.0 88:15:44:a8:89:ea (88:15:44:a8:89:ca)Not much improvement though to be sure.Ticking or unticking "disable 0.0.0.0" makes no difference to the logging that I can see. I've confirmed it passes the correct command line options so it has got to be a bug in the arpwatch binary, nothing to do with the user interface or something PFSense specific.
The supported options are here.
-z is the option that should disable reporting changes involving 0.0.0.0 and the UI is setting it appropriately but it seems to make no difference.
I tried adding the -q option, (testing at the command line first) according to the man page "The -q flag suppresses reports being logged or printed to stderr." However despite arpwatch -h listing q as a valid flag, adding the -q flag causes arpwatch to simply exit reporting its usage options as if you have provided invalid flags - it doesn't seem to accept -q as a valid option, so that's potentially a second bug. Without that -q option suppressing logging to syslog doesn't seem possible.
Need to do some more playing.. But seems to me there should just be an option in arpwatch to just plain ignore anything with IP of 0.0.0.0, ie don't log it as bogon, don't ever log it as an IP for a mac, and don't ever log it for a flip flop, etc..
Just plain ignore anything with 0.0.0.0 should be an option. But I would think that would have to be changed in arpwatch itself.
Yeah, -z, but it doesn't seem to work. Logging a flip flop of mac address is useful as it can identify IP address conflicts and other shenanigans, but as it stands now it alerts not only every time a new device comes onto the network, but also every time a DHCP renewal occurs because a discover comes from 0.0.0.0.
This excessive logging makes the logging feature useless IMHO.
Seems to me any use of arpwatch is going to come with some log spam issues. Or bogus entries like this in the arp db.
So my take away from this little play session, is if you want to use arpwatch you going to have to deal with some log spam in one way or another.. I would think just ignoring anything with 0.0.0.0 would useful option in arpwatch but maybe I am missing something where that could be an issue? Not sure if something could be done on pfsense inc for arpwatch, or if that would have to be something done upstream in arpwatch.
Your change to the inc to not send notification on such stuff might be valuable patch for those wanting to use arpwatch.. What exactly did you change in the inc?
I just commented out the code to send notifications, as I didn't want notifications, since I can't refine them to only the notifications I want. I have pushover enabled for notifications which is useful because it will notify me when I reboot the router when it goes down and up (or an unexpected reboot) and also for things like certificate expiry, but Pushover and Arpwatch just don't go together as it floods my pushover client with useless messages.
The patch is here:
--- arpwatch.inc.bak 2023-03-23 10:47:43.612197000 +0000 +++ arpwatch.inc 2023-03-23 10:49:22.128800000 +0000 @@ -251,13 +251,14 @@ $message = preg_replace("/^(\n){4}/", '', $message); $send_subject = "{$config['system']['hostname']}.{$config['system']['domain']} - Arpwatch Notification : {$subject[1]}"; - send_smtp_message($message, $send_subject); - if (function_exists('notify_via_telegram')) { - notify_via_telegram($send_subject . " - " . $message); - } - if (function_exists('notify_via_pushover')) { - notify_via_pushover($send_subject . " - " . $message); - } +# Disable sending notifications +# send_smtp_message($message, $send_subject); +# if (function_exists('notify_via_telegram')) { +# notify_via_telegram($send_subject . " - " . $message); +# } +# if (function_exists('notify_via_pushover')) { +# notify_via_pushover($send_subject . " - " . $message); +# } } ?>As I say, it just comments stuff out. It needs to be put into a custom patch in the patch manager with a base directory of /usr/local/pkg. (Love the patch manager, possibly one of the best features in PFSense for those with command line / php experience...)
edit: seeing stuff like this as I thought
I changed my mac on my machine to 17 vs 16 and yeah it logs the nonsense.. And notice one of my other machines now as a 0.0.0.0 entry as well..
I would suggest we put in a very detailed redmine about this stuff - but not sure what all could be done locally on pfsense, it just seems to be arpwatch.. If you tell it not to not report any bogon, then 0.0.0.0 becomes just an IP, while the not report 0.0.0.0 changes might limit the log spam on dhcp stuff.. But now what my db is going to fill up with 0.0.0.0 being reported for every mac when it does dhcp? And going to get changes every time 0.0.0.0 for a new mac?
I suspect as it looks like the problem lies with the FreeBSD arpwatch binary it is not likely to get fixed by the PFSense guys. Reporting the problem upstream to the arpwatch author is probably a better long term bet (and a contact email address is on the man page) but even if fixed the time before it found its way into a FreeBSD release PFSense bases on could be quite long.
I've decided to turn it off for now and maybe check back in 2.7.0 (which will have a FreeBSD 14.0 base) to see if anything has improved with the arpwatch binary.
-
@dbmandrake said in Arpwatch reports bogons frequently:
check back in 2.7.0 (which will have a FreeBSD 14.0 base)
I'm on 23.01 so I would think/hope that on the latest binary, its for sure binary for freebsd 14..
If for sure seems like there are few different issues at play.. I had not played with arpwatch in long time, didn't even have it installed. There was an issue awhile back, where would cause a lockup.. And I had removed it back then..
But yeah there sure seems some work needs to be done to make it less log/notification spammy that is for sure..
I know reporting issues or requests for stuff upstream quite often can take some time - There was an issue with dhcp ttl in freebsd long time ago that I had reported.. Took 2 years for them to finally fix it. Reported in 2012, not fixed until 2014 almost exactly 2 years between.. Maybe things reported by netgate can get more traction?
I had fixed that myself and provided the update to anyone that wanted it with new compile of the dhcp client - maybe we could do something ourselves with arpwatch.
-
@1OF1000Quadrillion thank you for making this topic and thanks to all of the contributors.
I wanted to say that I found this via Google and that I am having the same situation. Running pfSense Plus 23.09.1-RELEASE (amd64) on bare metal. I suppose I will uninstall arpwatch for now.
-
another optoin to avoid 0.0.0.0 &169.254.0.0 spam is to igmore the mac-addr's
from arpwatch>settings, click the +Add button at the bottom
add any mac you don't want alerts for
