Description of problem: I'm attempting to run arpwatch on a lan segment on my fedora 20 laptop to track down a layer2 networking issues. When I run arpwatch, I pass it the following options: "-i em1 -u arpwatch -e root -s 'root (Arpwatch)'" Arpwatch does start, however it doesn't appear to actually do anything. Syslog shows: Dec 12 17:36:21 razor arpwatch: listening on em1 Dec 12 17:36:21 razor systemd: Started Arpwatch daemon which keeps track of ethernet/ip address pairings. But nothing is logged. If I strace the arpwatch process as root, I don't see it doing anything at all. Version-Release number of selected component (if applicable): 2.1a15-30.fc20 How reproducible: 100% Steps to Reproduce: 1. start arpwatch 2. ?? 3. profit. Actual results: Arpwatch starts and then does nothing. It just runs there, not logging anything. Expected results: Arpwatch records mac/ip pairs in /var/lib/arpwatch/arp.dat and sends emails and/or logs to syslog however configured. Additional info: I also attempted running arpwatch as the root user (-u root) as well as temporarily disabling selinux. It did not matter.
Not doing anything for me either.
Is is really doing nothing? Is it at least consuming any unusual amounts of computer resources? What if you let it run for, let's say, 15 minutes? How busy is your network? Can you try pinging the machine from another one on the same network? I tried a few times and it always responded (debug mode). But, it sometimes takes a while and I'm not sure why. All I can say is that the program is waiting for pcap_loop() from libpcap to run its callback: (gdb) bt #0 0x00007ffff78c7a70 in __poll_nocancel () from /lib64/libc.so.6 #1 0x00007ffff7ba86a5 in pcap_wait_for_frames_mmap () from /lib64/libpcap.so.1 #2 0x00007ffff7ba8fc5 in pcap_read_linux_mmap_v3 () from /lib64/libpcap.so.1 #3 0x00007ffff7bad39d in pcap_loop () from /lib64/libpcap.so.1 #4 0x0000555555556cb6 in main (argc=2, argv=<optimized out>) at ./arpwatch.c:430 Any hints that might make debugging easier are welcome.
I'm going to leave arpwatch run for an hour or so and see what happens. Admittedly, previously I would leave it run for a few minutes and see no activity and I would just assume it's not doing anything after stracing and seeing nothing happen. This is on Fedora 20, but this same bug affects both F20 and RHEL7.
Leaving arpwatch running for over an hour does not seem to make a difference.
First, arpwatch only reacts when an ARP packet arrives at the specified interface. If there are no ARP packets coming to the interface, nothing happens. On my machine, ARP packets arrive *very* sporadically, so it looks like arpwatch doesn't do anything. However, there are a few problems that I've found: 1) Arpwatch doesn't update its database when it's not specified using the "-f <path-to-db>" on the command line. 2) Even when 1) is satisfied, arpwatch doesn't update its database when selinux is in the enforcing mode. When 1) *and* 2) are met, arpwatch works. I assume that it "works" like that on every machine, but just to be sure... Matthew, can you please confirm?
Actually, comment 5 seems to only apply to my machine, which has been upgraded from Fedora 19. I tried again on fresh Fedora 20 install and arpwatch doesn't work at all. Whenever it's supposed to process an ARP packet, it ends up eating 100% CPU. ... Starting program: /usr/sbin/arpwatch -u arpwatch -i ens3 -f /var/lib/arpwatch/arp.dat -d ... (gdb) bt #0 pcap_read_linux_mmap_v3 (handle=0x7f36708bc030, max_packets=0, callback=0x7f366e9ac980 <process_ether>, user=0x0) at ./pcap-linux.c:4460 #1 0x00007f366e55739d in pcap_loop (p=0x7f36708bc030, cnt=cnt@entry=0, callback=callback@entry=0x7f366e9ac980 <process_ether>, user=user@entry=0x0) at ./pcap.c:856 #2 0x00007f366e9abcc0 in main (argc=8, argv=0x7fff9d5438e8) at ./arpwatch.c:428 # rpm -q libpcap libpcap-1.5.0-1.20131108git459712e.fc20.x86_64 Reassigning to libpcap to get more insight.
This is indeed a libpcap bug. Issue has been discussed here [1] and there is a patch for it. I am planning to push a new version of libpcap soon-ish. Once it hits updates-testing please test and provide karma. Until then, sorry for inconvenience. [1] https://github.com/the-tcpdump-group/libpcap/issues/333
Just wanted to add, same results on my machine (FC20, x86_64) but with the added annoyance of the arpwatch process taking up 100% of its execution thread while doing nothing. :)
libpcap-1.5.3-1.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/libpcap-1.5.3-1.fc20
After updating libpcap from koji, arpwatch again works. Jan 15 13:02:59 razor systemd: Started Arpwatch daemon which keeps track of ethernet/ip address pairings. Jan 15 13:03:01 razor arpwatch: new station 172.31.1.68 90:a4:de:39:22:e0 Jan 15 13:03:10 razor arpwatch: new station 172.31.1.38 0:1e:a9:82:6a:75 Jan 15 13:03:30 razor arpwatch: new station 172.31.1.254 0:7:e:28:41:d3 Nice work!
Confirmed here as well. Working like a top after installing updated PCAP libraries. Nice work!
Package libpcap-1.5.3-1.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing libpcap-1.5.3-1.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-0949/libpcap-1.5.3-1.fc20 then log in and leave karma (feedback).
libpcap-1.5.3-1.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.