Project

General

Profile

Actions

Bug #8620

closed

arpwatch database page is not accessible

Added by Vladimir Lind over 6 years ago. Updated over 6 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
arpwatch
Target version:
Start date:
07/05/2018
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Affected Version:
2.4.3_1
Affected Plus Version:
Affected Architecture:

Description

On CE-2.4.3-p1 I am not able to open https://172.21.41.148/pkg_edit.php?xml=arpwatch.xml - getting 504

from upstream, client: 172.21.41.249, server: , request: "GET /arpwatch_database.php HTTP/1.1", upstream: "fastcgi://unix:/var/run/php-fpm.socket", host: "172.21.41.148", referrer: "https://172.21.41.148/pkg_edit.php?xml=arpwatch.xml"

Actions #1

Updated by Jim Pingle over 6 years ago

  • Project changed from pfSense to pfSense Packages
  • Category changed from Package System to arpwatch
  • Target version deleted (2.4.4)
Actions #2

Updated by Cino . over 6 years ago

The issue I have with arpwatch is different but I'm pretty sure they are related. After a day or two of arpwatch running, the process becomes unresponsive. The database page becomes inaccessible. You can't stop the service, kill -9 arpwatch, killall arpwatch seem to have no effect. Due to process becoming unresponsive when rebooting pfsense; the reboot hangs and pfsense needs to be manually powered off and back on again.

As a workaround to this, I manually uninstalled the arpwatch binaries using the pkg command. I then installed arpwatch from the main FreeBSD repository http://pkg.freebsd.org/freebsd:11:x86:64/latest/All/arpwatch-2.1.a15_10.txz. The package between the two repositories are the same name, but I noticed there is a difference in file size. 1 or 2KBs.

Actions #3

Updated by Sven L over 6 years ago

Cino . wrote:

The issue I have with arpwatch is different but I'm pretty sure they are related. After a day or two of arpwatch running, the process becomes unresponsive. The database page becomes inaccessible. You can't stop the service, kill -9 arpwatch, killall arpwatch seem to have no effect. Due to process becoming unresponsive when rebooting pfsense; the reboot hangs and pfsense needs to be manually powered off and back on again.

I experienced exactly the same. In my case after some time running arpwatch my whole pfsense box hung up, and only a forced restart fixed it. Also the email notifications dont work correct - every notification gets send out twice.
I've heard from other users that known devices wont get saved after a pfsense restart, the settings dont make a difference.

Actions #4

Updated by Cino . over 6 years ago

Sven L wrote:

I experienced exactly the same. In my case after some time running arpwatch my whole pfsense box hung up, and only a forced restart fixed it. Also the email notifications dont work correct - every notification gets send out twice.
I've heard from other users that known devices wont get saved after a pfsense restart, the settings dont make a difference.

I've experienced the same email notification issue too. What I found, arpwatch has two processes running for each interface its watching. Looks like when pfsense boots up, its starting arpwatch twice. I haven't found what is causing it but I added a startup script to stop than to start arpwatch again on bootup as a workaround

Actions #5

Updated by Dave Bergman over 6 years ago

I'm having the same problems. Woke up this morning to find all devices that have a static IP set were off line and I could not access the Web GUI. The only way to get pfsense running was a hard reset. All through the day I could see devices going offline as there leases ran out.

Actions #6

Updated by DL Ford over 6 years ago

I am also experiencing this. My best guess is that Arpwatch is starting itself at boot, then pfSense is starting Arpwatch again after that (or pfSense starts it first? I'm not sure).

In addition to what others have mentioned, I have noticed these facts:
1) After installing Arpwatch everything works fine, there is one instance of Arpwatch running per configured interface.
2) After a reboot, trouble starts, two instances of Arpwatch running per interface.
3) After configuring Arpwatch, if you disable it in the pfSense webconfigurator, and then reboot, Arpwatch works as expected, one instance running per interface, no repeat emails for existing hosts, you can view the database from the webconfigurator and it does get updated by Arpwatch. The only downside to this is that it doesn't show up in the pfSense webconfigurator as a running service, but it is in fact running and working correctly at this point.

I would suggest to others in the meantime to install and configure Arpwatch from the webconfigurator, then uncheck "Enable Arpwatch", click save, and reboot. That is the state my system is in at this point, I will report here if I see any issues arise from running it this way. I would also suggest anyone doing this keep an eye on this thread, because when this issue gets fixed you'll need to enable Arpwatch again in the webconfigurator.

Actions #7

Updated by Mathias Möller over 6 years ago

I have exactly the same problems. The actual workaround is not to enable arpwatch, so it will be automaticly startet on next bootup.

Actions #8

Updated by Sven L over 6 years ago

Its been two months now.. are there any news?

Actions #9

Updated by Dallas Haselhorst over 6 years ago

I'm interested in a fix for this as well. On 2.4.3-p1 I have the same issues -- multiple emails and nothing in the database. I haven't seen the unresponsive interface issue because I removed the package and verified the processes stopped as soon as I discovered the other problems and learned that was was a possible side effect. Prior to removing the package, I checked and there were two identical processes (same network, same email) running.

Actions #10

Updated by Jim Pingle over 6 years ago

  • Status changed from New to Feedback
  • Assignee set to Jim Pingle

Should be improved by https://github.com/pfsense/FreeBSD-ports/commit/aa78e490fe92d5640a742bbe77012a5ba626b084 but the full fix requires a 2.4.4 snapshot along with arpwatch pkg version 0.1.1. Will be available whenever the next new round of snapshots is up.

Actions #11

Updated by Jim Thompson over 6 years ago

  • Target version set to 2.4.4
Actions #12

Updated by Anonymous over 6 years ago

On 2.4.4.a.20180829.1926 (gitsync'd to master) with arpwatch version 0.1.1,

Seeing one instance of arpwatch for each interface immediately after installing:

root     1740   0.0  0.6 10688  5608  -  S    01:16    0:00.02 /usr/local/sbin/arpwatch -N -z -f /usr/local/arpwatch/arp_vtnet1.dat -i vtnet1 -m user@host.local
root     1995   0.0  0.6 10688  5608  -  S    01:16    0:00.02 /usr/local/sbin/arpwatch -N -z -f /usr/local/arpwatch/arp_vtnet0.dat -i vtnet0 -m user@host.local
root     5632   0.0  0.3  6968  2820  -  S    01:16    0:00.00 sh -c ps uxaww | grep arpw 2>&1
root     6245   0.0  0.2  6564  2460  -  S    01:16    0:00.00 grep arpw

However, after a reboot there are two instances of arpwatch for each interface:

root    39338   0.0  0.6 10688  5640  -  S    01:18   0:00.02 /usr/local/sbin/arpwatch -N -z -f /usr/local/arpwatch/arp_vtnet1.dat -i vtnet1 -m user@host.local
root    39620   0.0  0.6 10688  5612  -  S    01:18   0:00.02 /usr/local/sbin/arpwatch -N -z -f /usr/local/arpwatch/arp_vtnet0.dat -i vtnet0 -m user@host.local
root    39953   0.0  0.6 10688  5624  -  S    01:18   0:00.02 /usr/local/sbin/arpwatch -N -z -f /usr/local/arpwatch/arp_vtnet1.dat -i vtnet1 -m user@host.local
root    40019   0.0  0.6 10688  5640  -  S    01:18   0:00.02 /usr/local/sbin/arpwatch -N -z -f /usr/local/arpwatch/arp_vtnet0.dat -i vtnet0 -m user@host.local
root    52030   0.0  0.3  6968  2808  -  S    01:20   0:00.00 sh -c ps uxaww | grep arpw 2>&1
root    52147   0.0  0.2  6564  2460  -  S    01:20   0:00.00 grep arpw
Actions #13

Updated by Vladimir Lind over 6 years ago

Yup, seeing the same on Wed Aug 29 19:26:24 EDT 2018 with pfSense-pkg-arpwatch-0.1.1:

root 37039 0.0 0.3 6968 2596 - S 12:34 0:00.00 sh -c ps auxww | grep arpwatch 2>&1
root 37290 0.0 0.0 408 324 - R 12:34 0:00.00 grep arpwatch
root 87034 0.0 0.6 8640 5052 - S 12:08 0:00.03 /usr/local/sbin/arpwatch -f /usr/local/arpwatch/arp_vmx1.dat -i vmx1 -m
root 87553 0.0 0.6 8640 5080 - S 12:08 0:00.02 /usr/local/sbin/arpwatch -f /usr/local/arpwatch/arp_vmx2.dat -i vmx2 -m

After reboot:

root 22222 0.0 0.6 8640 5176 - S 12:44 0:00.01 /usr/local/sbin/arpwatch -f /usr/local/arpwatch/arp_vmx1.dat -i vmx1 -m
root 22586 0.0 0.6 8640 5176 - S 12:44 0:00.01 /usr/local/sbin/arpwatch -f /usr/local/arpwatch/arp_vmx1.dat -i vmx1 -m
root 22951 0.0 0.6 8640 5176 - S 12:44 0:00.01 /usr/local/sbin/arpwatch -f /usr/local/arpwatch/arp_vmx2.dat -i vmx2 -m
root 23035 0.0 0.6 8640 5176 - S 12:44 0:00.01 /usr/local/sbin/arpwatch -f /usr/local/arpwatch/arp_vmx2.dat -i vmx2 -m
root 36004 0.0 0.3 6968 2804 - S 12:44 0:00.00 sh -c ps auxww | grep arpwatch 2>&1
root 36637 0.0 0.3 6564 2468 - S 12:44 0:00.00 grep arpwatch

Database is displayed OK:

Database
OPT1 10.100.100.2 00:0c:29:33:40:84 unknown Thu Aug 30 12:23:22 2018
OPT1 10.100.100.1 00:0c:29:22:ba:8b unknown Thu Aug 30 12:23:22 2018

Actions #14

Updated by Jim Pingle over 6 years ago

Looks like one line of my commit is missing, will push a correction momentarily. The package is OK, the problem is on #8850

Actions #15

Updated by Jim Pingle over 6 years ago

OK to test again after a gitsync or an update to a snapshot which includes my last commit on #8850

Actions #16

Updated by Vladimir Lind over 6 years ago

Gitsynced, retested - now looks good, no arpwatch duplicated processes

Actions #17

Updated by Jim Pingle over 6 years ago

  • Status changed from Feedback to Resolved
Actions

Also available in: Atom PDF