Bug 1401152 - ngrep 1.47-0.1.a39256b.el7 always fails with "pcap compile: no VLAN support for data link type 113"
Summary: ngrep 1.47-0.1.a39256b.el7 always fails with "pcap compile: no VLAN support f...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora EPEL
Classification: Fedora
Component: ngrep
Version: epel7
Hardware: x86_64
OS: Linux
unspecified
urgent
Target Milestone: ---
Assignee: Fabio Alessandro Locati
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-12-03 01:06 UTC by Ira Byerly
Modified: 2018-09-17 19:54 UTC (History)
7 users (show)

Fixed In Version: ngrep-1.47-1.1.20180101git9b59468.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
RHEL 7.3 x86_64
Last Closed: 2018-09-17 19:54:46 UTC


Attachments (Terms of Use)
Tcpdump pcap with Encapsulation type: Linux cooked-mode capture (25) (1.09 KB, application/octet-stream)
2016-12-03 02:18 UTC, Ira Byerly
no flags Details
Tcpdump pcap with Encapsulation type: Ethernet (1) (290 bytes, application/octet-stream)
2016-12-03 02:19 UTC, Ira Byerly
no flags Details

Description Ira Byerly 2016-12-03 01:06:52 UTC
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.

Comment 1 Ira Byerly 2016-12-03 02:16:21 UTC
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.

Comment 2 Ira Byerly 2016-12-03 02:18:13 UTC
Created attachment 1227532 [details]
Tcpdump pcap with Encapsulation type: Linux cooked-mode capture (25)

Comment 3 Ira Byerly 2016-12-03 02:19:27 UTC
Created attachment 1227533 [details]
Tcpdump pcap with Encapsulation type: Ethernet (1)

Comment 4 Fabio Alessandro Locati 2016-12-25 10:44:41 UTC
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

Comment 5 dragonfly.net 2017-01-27 14:28:29 UTC
"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.

Comment 6 Jordan Ritter 2017-09-06 19:39:56 UTC
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

Comment 7 Jordan Ritter 2017-09-06 21:44:14 UTC
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

Comment 8 devjacksmith 2017-09-14 14:07:52 UTC
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

Comment 9 devjacksmith 2017-09-14 14:42:05 UTC
well, after i uninstalled myself, this worked :)
V1.47.1-git ngrep -d any worked just fine, thank you for fixing it!

Comment 10 devjacksmith 2017-09-14 14:51:39 UTC
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 :)

Comment 11 Eugene Kanter 2018-07-11 17:39:15 UTC
(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?

Comment 12 Fedora Update System 2018-09-01 07:46:44 UTC
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

Comment 13 Fedora Update System 2018-09-02 05:44:20 UTC
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

Comment 14 Fedora Update System 2018-09-17 19:54:46 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.