| Summary: | arpwatch does runs but doesn't do anything | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Matthew Galgoci <mgalgoci> |
| Component: | libpcap | Assignee: | Michal Sekletar <msekleta> |
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 20 | CC: | aledvink, jason.donald.burgess, jsynacek, mgalgoci, msekleta, paul, rainer.traut, thozza |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | libpcap-1.5.3-1.fc20 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2014-01-17 05:44:03 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
|
Description
Matthew Galgoci
2013-12-12 22:40:54 UTC
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. |