PCAP-NG output bug?

This issue was migrated from bug 3524 in our old bug tracker.

Original bug information:

Reporter: Daniel Dawson
Status: RESOLVED FIXED
Product: Wireshark
Component: GTK+ UI
OS: All
Platform: All
Version: unspecified

Attachments:

pcapng-bug.pcapng: PCAP-NG sample, produced from Wireshark 1.2.0pre2
pcapng-bug.pcap: PCAP sample corresponding to PCAP-NG sample

Daniel Dawson said:

Build Information: Version 1.0.7

Compiled with GTK+ 2.14.7, with GLib 2.20.0, with libpcap 1.0.0, with libz 1.2.3.3, with POSIX capabilities (Linux), with libpcre 7.8, without SMI, with ADNS, with Lua 5.1, with GnuTLS 2.6.4, with Gcrypt 1.4.4, with MIT Kerberos, with PortAudio V19-devel (built Oct 12 2008), without AirPcap.

Running on Linux 2.6.28.10-ddawson, with libpcap version 1.0.0.

Built using gcc 4.3.3.

Currently (as of 1.0.7) Wireshark produces PCAP-NG files that appear (to me) to violate the spec. These files contain one Interface Description Block, and have Enhanced Packet Blocks with interface ID=1. However, the spec reads, in part: "Interface ID: Tools that write / read the capture file associate a progressive 16-bit number (starting from '0') to each Interface Definition [sic] Block" (section 3.2). This is from http://www.winpcap.org/ntar/draft/PCAP-DumpFileFormat.html

Apologies if this has been fixed already.

added uigtk label

Gerald Combs said:

Can you try 1.2.0pre2 or one of the SVN builds at http://www.wireshark.org/download/automated/? 1.2.0 is scheduled to be released next week, and the 1.0 branch is speeding toward deprecation.

Pcap-ng support in 1.0.x was experimental. It has changed a lot since 1.0 was released.

Daniel Dawson said:

Okay, I tried it (and also a recent 1.3.0 snapshot). IDs are still 1.

(Interestingly, while 1.0.7 was able to read its own PCAP-NGs, these later versions are not decoding them properly, as if they're not picking up the encap type. But that's for another bug.)

In case it matters, the 1.0.7 I was using is from Debian testing ('squeeze'). The others I built from source with 'make debian-package'.

Michael Tüxen said:

(In reply to comment #2)  
> Okay, I tried it (and also a recent 1.3.0 snapshot). IDs are still 1.  
>  
> (Interestingly, while 1.0.7 was able to read its own PCAP-NGs, these later  
> versions are not decoding them properly, as if they're not picking up the encap  
> type. But that's for another bug.)  
>  
> In case it matters, the 1.0.7 I was using is from Debian testing ('squeeze').  
> The others I built from source with 'make debian-package'.  
>  

Can you provide a capture file which shows the problem?
If you do not want to out is here, you can send it to me:
Michael.Tuexen@micmac.franken.de

Best regards
Michael

Daniel Dawson said:

Created attachment 3105 PCAP-NG sample, produced from Wireshark 1.2.0pre2

Okay, I made a very brief capture, with just 2 frames. That's plenty to demonstrate what I'm talking about. Note the values at offsets 0x38 and 0xC4, which should be 0x00000000, if I understand the spec correctly, but are actually 0x00000001.

Daniel Dawson said:

Created attachment 3106 PCAP sample corresponding to PCAP-NG sample

Here is the same capture in PCAP format. I'm including this because of the decoding issue I mentioned above, to ensure that people can look at the data properly in WS if necessary.

Michael Tüxen said:

(In reply to comment #5)  
> Created an attachment (id=3106) [details]  
> PCAP sample corresponding to PCAP-NG sample  
>  
> Here is the same capture in PCAP format. I'm including this because of the  
> decoding issue I mentioned above, to ensure that people can look at the data  
> properly in WS if necessary.  
>  

OK, I checked in a fix. Please retest with
http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=rev&revision=28696
and let me know if this fixes your issue.

Best regards
Michael

Daniel Dawson said:

Yes, that fixes it. Thanks.

closed