Description of problem: After upgrading to ngrep.x86_64 1.47-0.1.a39256b.el7, ngrep always fails with the message pcap compile: no VLAN support for data link type 113 Version-Release number of selected component (if applicable): 1.47-0.1.a39256b.el7 How reproducible: 100% reproducable Steps to Reproduce: 1. Create a pcap file with tcpdump; the contents are irrelevant. Call it one.pcap. 2. ngrep -q -I /tmp/one.pcap -O - . | file - Actual results: Ngrep fails with the message "pcap compile: no VLAN support for data link type 113" Expected results: /dev/stdin: data Additional info: The last working EPEL version of ngrep appears to be 1.45-17.git20131221.16ba99a.el7. There is a copy of the working version available on an EPEL mirror site, http://mirror.ancl.hawaii.edu/linux/epel/7/x86_64/n/ngrep-1.45-17.git20131221.16ba99a.el7.x86_64.rpm (as of 0100Z on 2016-Dec-03). This bug has the same symptoms that were reported in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=558209.
Sorry, I overreacted - it turns out that ngrep is only failing for It appears that tcpdump files with encapsulation type "ethernet (1)" are not affected and can be processed with the new ngrep, but tcpdump files with encapsulation type "linux cooked-mode capture (25)" are affected and cause it to fail. On an RHEL 7.3 system, it appears that running tcpdump on an individual ethernet adapter (e.g., tcpdump -i ens192 -c 1 -w /tmp/cooked.pcap) produces a file with ethernet encapsulation, but running tcpdump on all active adapters (tcpdump -i all -c 1 -w /tmp/cooked.pcap) produces a linux cooked-mode capture. I will attach examples of each type of pcap for reference.
Created attachment 1227532 [details] Tcpdump pcap with Encapsulation type: Linux cooked-mode capture (25)
Created attachment 1227533 [details] Tcpdump pcap with Encapsulation type: Ethernet (1)
I'm going to close this bug, since it's a very specific use cases that has problem (and the problem is code-related and not package related). I would suggest reporting it upstream (https://sourceforge.net/p/ngrep/bugs/), but do not expect a fix any time soon (last ngrep commit was 15+ months ago). In case a fix is developed, I can import it or rebasing to a version that has the fix, or importing the patch. Best
"since it's a very specific use cases" - i catch in in EVERYDAY usage! Simple: ngrep -d any '' udp (all udp) - same error. Need rollback to non-broke version.
Hi, I'm the author of ngrep. This is helpful feedback, and I'm going to look into this. Thanks for the report. In the future, please report upstream, or at least CC me here. ngrep is mature software at 18 years old, and therefore doesn't see regular development unless there is a problem that needs fixing. Thanks again, --jordan
OK, I think I have fixed this in master (https://github.com/jpr5/ngrep), and would be grateful if someone could try it out and let me know, as I don't have access to a RedHat environment to test myself. Quick background can be found at: https://github.com/jpr5/ngrep/commit/ce64df46ddbc4d059b7c59a958f4a65da543b303 TL;DR: VLAN in the BPF filter and SLL-originating data (e.g. from `-d any`) don't mix. Also appears to be a logical bug auto-detecting VLAN header frames, which this patch also fixes by turning off VLAN when encountering SLL or `-d any`. Thanks again for the feedback. cheers, --jordan
Still doesn't work for me (ran as root): # ngrep -V ngrep: V1.47-git, libpcap version 1.5.3 # ngrep -d any interface: any pcap compile: no VLAN support for data link type 113 # rpm --query centos-release centos-release-7-3.1611.el7.centos.x86_64
well, after i uninstalled myself, this worked :) V1.47.1-git ngrep -d any worked just fine, thank you for fixing it!
for people like me the way I installed it was to 1. download the latest zip from https://github.com/jpr5/ngrep/releases 2. unzip it 3. cd inside the unzipped folder 4. run ./configure && make && make install This installed the ngrep into /usr/local/bin/ngrep. I could run it from there by specifying a full path, or make a link for all users and root by making symlinks: ln -s /usr/local/bin/ngrep /usr/bin/ngrep ln -s /usr/local/bin/ngrep /usr/sbin/ngrep (if you already have ngrep installed, that file /usr/bin/ngrep and/or /usr/sbin/ngrep needs to be removed first) after that i was able to just run ngrep -d any without any issues. Thanks again :)
(In reply to Fabio Alessandro Locati from comment #4) > I'm going to close this bug, since it's a very specific use cases that has > problem (and the problem is code-related and not package related). I would > suggest reporting it upstream (https://sourceforge.net/p/ngrep/bugs/), but > do not expect a fix any time soon (last ngrep commit was 15+ months ago). In > case a fix is developed, I can import it or rebasing to a version that has > the fix, or importing the patch. > > Best A fix has been made in ngrep git almost a year ago. Is there any plan to pull latest and update the ngrep rpm package?
ngrep-1.47-1.1.20180101git9b59468.el7 has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-7c13ed4263
ngrep-1.47-1.1.20180101git9b59468.el7 has been pushed to the Fedora EPEL 7 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-7c13ed4263
ngrep-1.47-1.1.20180101git9b59468.el7 has been pushed to the Fedora EPEL 7 stable repository. If problems still persist, please make note of it in this bug report.