https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=15844
Bug ID: 15844
Summary: tshark and editcap: An error occurred while writing
to the file "output,pcapng": Internal error.
Product: Wireshark
Version: Git
Hardware: x86
OS: Mac OS X 10.4
Status: UNCONFIRMED
Severity: Normal
Priority: Low
Component: Capture file support (libwiretap)
Assignee: bugzilla-ad...@wireshark.org
Reporter: jyo...@gsu.edu
Target Milestone: ---
Created attachment 17175
--> https://bugs.wireshark.org/bugzilla/attachment.cgi?id=17175&action=edit
Example of tcpdump files with noncontiguous IDBs
Build Information:
Version 3.1.0rc0-968-ge44d4e740edf (v3.1.0rc0-968-ge44d4e740edf)
Copyright 1998-2019 Gerald Combs <ger...@wireshark.org> and contributors.
License GPLv2+: GNU GPL version 2 or later
<http://www.gnu.org/licenses/old-licenses/gpl-2.0.html> This is free software;
see the source for copying conditions. There is NO warranty; not even for
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Compiled (64-bit) with Qt 5.12.1, with libpcap, without POSIX capabilities,
with GLib 2.37.6, with zlib 1.2.11, with SMI 0.4.8, with c-ares 1.15.0, with
Lua 5.2.4, with GnuTLS 3.4.17, with Gcrypt 1.7.7, with MIT Kerberos, with
MaxMind DB resolver, with nghttp2 1.21.0, with brotli, with LZ4, with Snappy,
with libxml2 2.9.9, with QtMultimedia, with SpeexDSP (using bundled resampler),
with SBC, with SpanDSP, with bcg729.
Running on Mac OS X 10.13.6, build 17G7024 (Darwin 17.7.0), with Intel(R)
Core(TM) i7-4980HQ CPU @ 2.80GHz (with SSE4.2), with 16384 MB of physical
memory, with locale en_US.UTF-8, with light display mode, with HiDPI, with
libpcap version 1.8.1 -- Apple version 79.20.1, with GnuTLS 3.4.17, with Gcrypt
1.7.7, with brotli 1.0.7, with zlib 1.2.11, binary plugins supported (14
loaded). Built using clang 4.2.1 Compatible Apple LLVM 10.0.1
(clang-1001.0.46.4).
Wireshark is Open Source Software released under the GNU General Public
License.
Check the man page and https://www.wireshark.org for more information.
--
tshark and editcap when used to create new pcapng from existing pcpang files,
will generate a truncated and malformed pcapng file if they encounter
noncontiguous IDBs while processing the input file.
> $ tshark -r original.pcapng -w output.pcapng
> tshark: An error occurred while writing to the file "output,pcapng": Internal
> error.
> $
> $ editcap original.pcapng output.pcapng
> editcap: An error occurred while writing to the file "output.pcapng":
> Internal error.
> $
See attached original.pcapng file.
Long version:
On a macOS I used Apple's tcpdump with their proprietary pktap interface to
create a multi-interface pcpang file:
> $ sudo tcpdump -i pktap,en0,vmnet6 -w original.pcapng icmp
> tcpdump: data link type PKTAP
> tcpdump: listening on pktap,en0,vmnet6, link-type PKTAP (Apple DLT_PKTAP),
> capture size 262144 bytes
> ^C12 packets captured
> 331 packets received by filter
> 0 packets dropped by kernel
> $
The internal pcapng block structure of the original.pcapng appears as follows:
> $ ngd -qD original.pcapng
> +++Quiet Summary
> +++Reading from original.pcapng
> +++This machine is little-endian.
> +++The following section is little-endian.
> 00000000: Block #1: Section Header Block (0x0a0d0d0a), Total Length (header)
> = 156 (0x0000009c), Body at offset 00000008, Trailer at offset 00000098, next
> (if any) at offset 0000009c
> 0000009c: Block #2: Interface Description Block (0x00000001), Total Length
> (header) = 32 (0x00000020), Body at offset 000000a4, Trailer at offset
> 000000b8, next (if any) at offset 000000bc
> 000000bc: Block #3: Darwin Process Event Block (0x80000001), Total Length
> (header) = 56 (0x00000038), Body at offset 000000c4, Trailer at offset
> 000000f0, next (if any) at offset 000000f4
> 000000f4: Block #4: Enhanced Packet Block (0x00000006), Total Length (header)
> = 160 (0x000000a0), Body at offset 000000fc, Trailer at offset 00000190, next
> (if any) at offset 00000194
> 00000194: Block #5: Enhanced Packet Block (0x00000006), Total Length (header)
> = 152 (0x00000098), Body at offset 0000019c, Trailer at offset 00000228, next
> (if any) at offset 0000022c
> 0000022c: Block #6: Enhanced Packet Block (0x00000006), Total Length (header)
> = 160 (0x000000a0), Body at offset 00000234, Trailer at offset 000002c8, next
> (if any) at offset 000002cc
> 000002cc: Block #7: Enhanced Packet Block (0x00000006), Total Length (header)
> = 152 (0x00000098), Body at offset 000002d4, Trailer at offset 00000360, next
> (if any) at offset 00000364
> 00000364: Block #8: Enhanced Packet Block (0x00000006), Total Length (header)
> = 160 (0x000000a0), Body at offset 0000036c, Trailer at offset 00000400, next
> (if any) at offset 00000404
> 00000404: Block #9: Enhanced Packet Block (0x00000006), Total Length (header)
> = 152 (0x00000098), Body at offset 0000040c, Trailer at offset 00000498, next
> (if any) at offset 0000049c
> 0000049c: Block #10: Interface Description Block (0x00000001), Total Length
> (header) = 36 (0x00000024), Body at offset 000004a4, Trailer at offset
> 000004bc, next (if any) at offset 000004c0
> 000004c0: Block #11: Enhanced Packet Block (0x00000006), Total Length
> (header) = 152 (0x00000098), Body at offset 000004c8, Trailer at offset
> 00000554, next (if any) at offset 00000558
> 00000558: Block #12: Enhanced Packet Block (0x00000006), Total Length
> (header) = 152 (0x00000098), Body at offset 00000560, Trailer at offset
> 000005ec, next (if any) at offset 000005f0
> 000005f0: Block #13: Enhanced Packet Block (0x00000006), Total Length
> (header) = 152 (0x00000098), Body at offset 000005f8, Trailer at offset
> 00000684, next (if any) at offset 00000688
> 00000688: Block #14: Enhanced Packet Block (0x00000006), Total Length
> (header) = 152 (0x00000098), Body at offset 00000690, Trailer at offset
> 0000071c, next (if any) at offset 00000720
> 00000720: Block #15: Enhanced Packet Block (0x00000006), Total Length
> (header) = 152 (0x00000098), Body at offset 00000728, Trailer at offset
> 000007b4, next (if any) at offset 000007b8
> 000007b8: Block #16: Enhanced Packet Block (0x00000006), Total Length
> (header) = 152 (0x00000098), Body at offset 000007c0, Trailer at offset
> 0000084c, next (if any) at offset 00000850
> $
In the report above we see the second IDB is written as the 10th block of this
pcapng file.
Unlike Wireshark which writes all Interface Description Blocks (IDBs) at the
beginning of a pcapng file, Apple's tcpdump, when generating pcapng files, will
defer generating the second and any subsequent IDBs until the first packet is
seen on any of the subsequent interfaces. In other words there will generally
be one of more EPBs between the various IDBs in Apple tcpdump generated pcapng
files.
In addition to discontiguous IDBs, when using Apple's tcpdump pktap interface
(or their rvi0 interface (which is created using Xcode's cli rvictl tool))
tcpdump will also add Apple proprietary Darwin Process Event Blocks (DPEBs) and
Apple proprietary options to the EPBs.
In the report below using Apple's tcpdump and its proprietary -k option we can
see that packets 1-6 used interface 'en0' and that packets 7-12 used interface
'vmnet8'. Interface 'en0' information was conveyed inside of the first IDB
(Block #2 from above). Interface 'vmnet8' information was conveyed inside of
the second IDF (Block #10 from above). The process information
"vmnet-natd:60296" seen in packets 1, 3 and 5 was conveyed in the DPEB (Block
#3 from above).
> $ tcpdump -# -n -k -r original.pcapng
> reading from PCAP-NG file original.pcapng
> 1 20:24:43.887148 (en0, proc vmnet-natd:60296, svc BE, out) IP 10.0.0.3
> > 10.0.0.1: ICMP echo request, id 1049, seq 0, length 64
> 2 20:24:43.889071 (en0, svc BE, in) IP 10.0.0.1 > 10.0.0.3: ICMP echo
> reply, id 1049, seq 0, length 64
> 3 20:24:44.893246 (en0, proc vmnet-natd:60296, svc BE, out) IP 10.0.0.3
> > 10.0.0.1: ICMP echo request, id 1049, seq 1, length 64
> 4 20:24:44.895115 (en0, svc BE, in) IP 10.0.0.1 > 10.0.0.3: ICMP echo
> reply, id 1049, seq 1, length 64
> 5 20:24:45.894514 (en0, proc vmnet-natd:60296, svc BE, out) IP 10.0.0.3
> > 10.0.0.1: ICMP echo request, id 1049, seq 2, length 64
> 6 20:24:45.896432 (en0, svc BE, in) IP 10.0.0.1 > 10.0.0.3: ICMP echo
> reply, id 1049, seq 2, length 64
> 7 20:24:48.213375 (vmnet8, svc BE, in) IP 192.168.73.144 > 192.168.73.1:
> ICMP echo request, id 1305, seq 0, length 64
> 8 20:24:48.213395 (vmnet8, svc BE, out) IP 192.168.73.1 >
> 192.168.73.144: ICMP echo reply, id 1305, seq 0, length 64
> 9 20:24:49.216393 (vmnet8, svc BE, in) IP 192.168.73.144 > 192.168.73.1:
> ICMP echo request, id 1305, seq 1, length 64
> 10 20:24:49.216416 (vmnet8, svc BE, out) IP 192.168.73.1 >
> 192.168.73.144: ICMP echo reply, id 1305, seq 1, length 64
> 11 20:24:50.222542 (vmnet8, svc BE, in) IP 192.168.73.144 > 192.168.73.1:
> ICMP echo request, id 1305, seq 2, length 64
> 12 20:24:50.222560 (vmnet8, svc BE, out) IP 192.168.73.1 >
> 192.168.73.144: ICMP echo reply, id 1305, seq 2, length 64
> $
This same pcapng can be successfully displayed by tshark, albeit without the
proprietary Apple information:
> $ tshark -r original.pcapng
> 1 0.000000 10.0.0.3 → 10.0.0.1 ICMP 98 Echo (ping) request
> id=0x0419, seq=0/0, ttl=63
> 2 0.001923 10.0.0.1 → 10.0.0.3 ICMP 98 Echo (ping) reply
> id=0x0419, seq=0/0, ttl=64 (request in 1)
> 3 1.006098 10.0.0.3 → 10.0.0.1 ICMP 98 Echo (ping) request
> id=0x0419, seq=1/256, ttl=63
> 4 1.007967 10.0.0.1 → 10.0.0.3 ICMP 98 Echo (ping) reply
> id=0x0419, seq=1/256, ttl=64 (request in 3)
> 5 2.007366 10.0.0.3 → 10.0.0.1 ICMP 98 Echo (ping) request
> id=0x0419, seq=2/512, ttl=63
> 6 2.009284 10.0.0.1 → 10.0.0.3 ICMP 98 Echo (ping) reply
> id=0x0419, seq=2/512, ttl=64 (request in 5)
> 7 4.326227 192.168.73.144 → 192.168.73.1 ICMP 98 Echo (ping) request
> id=0x0519, seq=0/0, ttl=64
> 8 4.326247 192.168.73.1 → 192.168.73.144 ICMP 98 Echo (ping) reply
> id=0x0519, seq=0/0, ttl=64 (request in 7)
> 9 5.329245 192.168.73.144 → 192.168.73.1 ICMP 98 Echo (ping) request
> id=0x0519, seq=1/256, ttl=64
> 10 5.329268 192.168.73.1 → 192.168.73.144 ICMP 98 Echo (ping) reply
> id=0x0519, seq=1/256, ttl=64 (request in 9)
> 11 6.335394 192.168.73.144 → 192.168.73.1 ICMP 98 Echo (ping) request
> id=0x0519, seq=2/512, ttl=64
> 12 6.335412 192.168.73.1 → 192.168.73.144 ICMP 98 Echo (ping) reply
> id=0x0519, seq=2/512, ttl=64 (request in 11)
> $
But in the command below tshark is unable to produce a new pcapng file based on
the original.pcapng file. Here's is a trivial tshark command that would
normally produce a copy of the input pcapng file (with unknown pcpang blocks
removed); but instead causes tshark to abort with an "Internal error.":
> $ tshark -r original.pcapng -w tshark.original.output
> tshark: An error occurred while writing to the file "tshark.original.output":
> Internal error.
> $
This is the internal pcapng block structure of resulting malformed pcapng
output file:
> $ ngd -qD tshark.original.output
> +++Quiet Summary
> +++Reading from tshark.original.output
> +++This machine is little-endian.
> +++The following section is little-endian.
> 00000000: Block #1: Section Header Block (0x0a0d0d0a), Total Length (header)
> = 148 (0x00000094), Body at offset 00000008, Trailer at offset 00000090, next
> (if any) at offset 00000094
> 00000094: Block #2: Interface Description Block (0x00000001), Total Length
> (header) = 32 (0x00000020), Body at offset 0000009c, Trailer at offset
> 000000b0, next (if any) at offset 000000b4
> 000000b4: Block #3: Enhanced Packet Block (0x00000006), Total Length (header)
> = 144 (0x00000090), Body at offset 000000bc, Trailer at offset 00000140, next
> (if any) at offset 00000144
> 00000144: Block #4: Enhanced Packet Block (0x00000006), Total Length (header)
> = 144 (0x00000090), Body at offset 0000014c, Trailer at offset 000001d0, next
> (if any) at offset 000001d4
> 000001d4: Block #5: Enhanced Packet Block (0x00000006), Total Length (header)
> = 144 (0x00000090), Body at offset 000001dc, Trailer at offset 00000260, next
> (if any) at offset 00000264
> 00000264: Block #6: Enhanced Packet Block (0x00000006), Total Length (header)
> = 144 (0x00000090), Body at offset 0000026c, Trailer at offset 000002f0, next
> (if any) at offset 000002f4
> 000002f4: Block #7: Enhanced Packet Block (0x00000006), Total Length (header)
> = 144 (0x00000090), Body at offset 000002fc, Trailer at offset 00000380, next
> (if any) at offset 00000384
> 00000384: Block #8: Enhanced Packet Block (0x00000006), Total Length (header)
> = 144 (0x00000090), Body at offset 0000038c, Trailer at offset 00000410, next
> (if any) at offset 00000414
> 00000414: Block #9: Enhanced Packet Block (0x00000006), Total Length (header)
> = 144 (0x00000090), Body at offset 0000041c, Trailer at offset 000004a0, next
> (if any) at offset 000004a4
> Oops: Block #9, at offset 0000041c (decimal 1052) short read, expecting 136
> octets, but only saw 0.
> $
As expected tshark removed the DPEB (original Block #3) but tshark unexpectedly
removed the second IDF which should have block #9. It its place we have a
truncated version of the 7th EPB (original Block #11) that references the now
missing second IDB (original Block #10).
Using Apple's tcpdump we can confirm that Apple's proprietary process
information (information conveyed by the DPEB) is missing from this tshark
generated pcapng file. Only the first 6 EPBs frames can be displayed; the 7th
EPB was truncated.
> $ tcpdump -# -n -k -r tshark.original.output
> reading from PCAP-NG file tshark.original.output
> 1 20:24:43.887148 (en0, out) IP 10.0.0.3 > 10.0.0.1: ICMP echo request,
> id 1049, seq 0, length 64
> 2 20:24:43.889071 (en0, in) IP 10.0.0.1 > 10.0.0.3: ICMP echo reply, id
> 1049, seq 0, length 64
> 3 20:24:44.893246 (en0, out) IP 10.0.0.3 > 10.0.0.1: ICMP echo request,
> id 1049, seq 1, length 64
> 4 20:24:44.895115 (en0, in) IP 10.0.0.1 > 10.0.0.3: ICMP echo reply, id
> 1049, seq 1, length 64
> 5 20:24:45.894514 (en0, out) IP 10.0.0.3 > 10.0.0.1: ICMP echo request,
> id 1049, seq 2, length 64
> 6 20:24:45.896432 (en0, in) IP 10.0.0.1 > 10.0.0.3: ICMP echo reply, id
> 1049, seq 2, length 64
> tcpdump: pcap_loop: truncated dump file; tried to read 136 bytes, only got 0
> $
And tshark also reports that this file has been truncated:
> $ tshark -r tshark.original.output
> 1 0.000000 10.0.0.3 → 10.0.0.1 ICMP 98 Echo (ping) request
> id=0x0419, seq=0/0, ttl=63
> 2 0.001923 10.0.0.1 → 10.0.0.3 ICMP 98 Echo (ping) reply
> id=0x0419, seq=0/0, ttl=64 (request in 1)
> 3 1.006098 10.0.0.3 → 10.0.0.1 ICMP 98 Echo (ping) request
> id=0x0419, seq=1/256, ttl=63
> 4 1.007967 10.0.0.1 → 10.0.0.3 ICMP 98 Echo (ping) reply
> id=0x0419, seq=1/256, ttl=64 (request in 3)
> 5 2.007366 10.0.0.3 → 10.0.0.1 ICMP 98 Echo (ping) request
> id=0x0419, seq=2/512, ttl=63
> 6 2.009284 10.0.0.1 → 10.0.0.3 ICMP 98 Echo (ping) reply
> id=0x0419, seq=2/512, ttl=64 (request in 5)
>
> tshark: The file "tshark.original.output" appears to have been cut short in
> the middle of a packet.
> $
When using editcap to create a new pacpng file from the original.pcapng,
editcap also aborts and reports an "Internal error":
> $ editcap original.pcapng editcap.original.output
> editcap: An error occurred while writing to the file
> "editcap.original.output": Internal error.
> $
A dump of the block structure of editcap's output file reveals a virtually
identically malformed pcapng file as seen above when tshark aborted:
> $ ngd -qD editcap.original.output
> +++Quiet Summary
> +++Reading from editcap.original.output
> +++This machine is little-endian.
> +++The following section is little-endian.
> 00000000: Block #1: Section Header Block (0x0a0d0d0a), Total Length (header)
> = 148 (0x00000094), Body at offset 00000008, Trailer at offset 00000090, next
> (if any) at offset 00000094
> 00000094: Block #2: Interface Description Block (0x00000001), Total Length
> (header) = 32 (0x00000020), Body at offset 0000009c, Trailer at offset
> 000000b0, next (if any) at offset 000000b4
> 000000b4: Block #3: Enhanced Packet Block (0x00000006), Total Length (header)
> = 144 (0x00000090), Body at offset 000000bc, Trailer at offset 00000140, next
> (if any) at offset 00000144
> 00000144: Block #4: Enhanced Packet Block (0x00000006), Total Length (header)
> = 144 (0x00000090), Body at offset 0000014c, Trailer at offset 000001d0, next
> (if any) at offset 000001d4
> 000001d4: Block #5: Enhanced Packet Block (0x00000006), Total Length (header)
> = 144 (0x00000090), Body at offset 000001dc, Trailer at offset 00000260, next
> (if any) at offset 00000264
> 00000264: Block #6: Enhanced Packet Block (0x00000006), Total Length (header)
> = 144 (0x00000090), Body at offset 0000026c, Trailer at offset 000002f0, next
> (if any) at offset 000002f4
> 000002f4: Block #7: Enhanced Packet Block (0x00000006), Total Length (header)
> = 144 (0x00000090), Body at offset 000002fc, Trailer at offset 00000380, next
> (if any) at offset 00000384
> 00000384: Block #8: Enhanced Packet Block (0x00000006), Total Length (header)
> = 144 (0x00000090), Body at offset 0000038c, Trailer at offset 00000410, next
> (if any) at offset 00000414
> 00000414: Block #9: Enhanced Packet Block (0x00000006), Total Length (header)
> = 144 (0x00000090), Body at offset 0000041c, Trailer at offset 000004a0, next
> (if any) at offset 000004a4
> Oops: Block #9, at offset 0000041c (decimal 1052) short read, expecting 136
> octets, but only saw 0.
> $
Using the attached command file 'reorderTake1' we can generate a new pcapng
from the blocks contained in the original.pcapng. The reorderTake1.pcapng file
structure differs from the original.pcapng in that the second IDB (Block #10
from original.pcapng) has been moved up to be the Block #4.
The reorderTake1 command file simply contains a series of 'xxd -p -s <OFFSET>
original.pcapng' commands.
The following command was used to build the reorderTake1.pcapng file:
> $ source ./reorderTake1 | xxd -p -r >reorderTake1.pcapng
The internal structure on the reorderTake1.pcapng file shows the second IDB is
now Block #4.
> $ ngd -qD reorderTake1.pcapng
> +++Quiet Summary
> +++Reading from reorderTake1.pcapng
> +++This machine is little-endian.
> +++The following section is little-endian.
> 00000000: Block #1: Section Header Block (0x0a0d0d0a), Total Length (header)
> = 156 (0x0000009c), Body at offset 00000008, Trailer at offset 00000098, next
> (if any) at offset 0000009c
> 0000009c: Block #2: Interface Description Block (0x00000001), Total Length
> (header) = 32 (0x00000020), Body at offset 000000a4, Trailer at offset
> 000000b8, next (if any) at offset 000000bc
> 000000bc: Block #3: Darwin Process Event Block (0x80000001), Total Length
> (header) = 56 (0x00000038), Body at offset 000000c4, Trailer at offset
> 000000f0, next (if any) at offset 000000f4
> 000000f4: Block #4: Interface Description Block (0x00000001), Total Length
> (header) = 36 (0x00000024), Body at offset 000000fc, Trailer at offset
> 00000114, next (if any) at offset 00000118
> 00000118: Block #5: Enhanced Packet Block (0x00000006), Total Length (header)
> = 160 (0x000000a0), Body at offset 00000120, Trailer at offset 000001b4, next
> (if any) at offset 000001b8
> 000001b8: Block #6: Enhanced Packet Block (0x00000006), Total Length (header)
> = 152 (0x00000098), Body at offset 000001c0, Trailer at offset 0000024c, next
> (if any) at offset 00000250
> 00000250: Block #7: Enhanced Packet Block (0x00000006), Total Length (header)
> = 160 (0x000000a0), Body at offset 00000258, Trailer at offset 000002ec, next
> (if any) at offset 000002f0
> 000002f0: Block #8: Enhanced Packet Block (0x00000006), Total Length (header)
> = 152 (0x00000098), Body at offset 000002f8, Trailer at offset 00000384, next
> (if any) at offset 00000388
> 00000388: Block #9: Enhanced Packet Block (0x00000006), Total Length (header)
> = 160 (0x000000a0), Body at offset 00000390, Trailer at offset 00000424, next
> (if any) at offset 00000428
> 00000428: Block #10: Enhanced Packet Block (0x00000006), Total Length
> (header) = 152 (0x00000098), Body at offset 00000430, Trailer at offset
> 000004bc, next (if any) at offset 000004c0
> 000004c0: Block #11: Enhanced Packet Block (0x00000006), Total Length
> (header) = 152 (0x00000098), Body at offset 000004c8, Trailer at offset
> 00000554, next (if any) at offset 00000558
> 00000558: Block #12: Enhanced Packet Block (0x00000006), Total Length
> (header) = 152 (0x00000098), Body at offset 00000560, Trailer at offset
> 000005ec, next (if any) at offset 000005f0
> 000005f0: Block #13: Enhanced Packet Block (0x00000006), Total Length
> (header) = 152 (0x00000098), Body at offset 000005f8, Trailer at offset
> 00000684, next (if any) at offset 00000688
> 00000688: Block #14: Enhanced Packet Block (0x00000006), Total Length
> (header) = 152 (0x00000098), Body at offset 00000690, Trailer at offset
> 0000071c, next (if any) at offset 00000720
> 00000720: Block #15: Enhanced Packet Block (0x00000006), Total Length
> (header) = 152 (0x00000098), Body at offset 00000728, Trailer at offset
> 000007b4, next (if any) at offset 000007b8
> 000007b8: Block #16: Enhanced Packet Block (0x00000006), Total Length
> (header) = 152 (0x00000098), Body at offset 000007c0, Trailer at offset
> 0000084c, next (if any) at offset 00000850
> $
But tshark still aborts when making a new pacpng file using reorderTake1.pcapng
as the input file.
> $ tshark -r reorderTake1.pcapng -w tshark.take1.output
> tshark: An error occurred while writing to the file "tshark.take1.output":
> Internal error.
> $
A dump of the tshark.take1.output file reveals that both the DPEB (Block #3)
and the second IDB (Block #4) were not written to the new file and that tshark
again aborted processing when it encountered the 7th EPB (the first EPB that
references the (missing) second IDB.
> $ ngd -qD tshark.take1.output
> +++Quiet Summary
> +++Reading from tshark.take1.output
> +++This machine is little-endian.
> +++The following section is little-endian.
> 00000000: Block #1: Section Header Block (0x0a0d0d0a), Total Length (header)
> = 148 (0x00000094), Body at offset 00000008, Trailer at offset 00000090, next
> (if any) at offset 00000094
> 00000094: Block #2: Interface Description Block (0x00000001), Total Length
> (header) = 32 (0x00000020), Body at offset 0000009c, Trailer at offset
> 000000b0, next (if any) at offset 000000b4
> 000000b4: Block #3: Enhanced Packet Block (0x00000006), Total Length (header)
> = 144 (0x00000090), Body at offset 000000bc, Trailer at offset 00000140, next
> (if any) at offset 00000144
> 00000144: Block #4: Enhanced Packet Block (0x00000006), Total Length (header)
> = 144 (0x00000090), Body at offset 0000014c, Trailer at offset 000001d0, next
> (if any) at offset 000001d4
> 000001d4: Block #5: Enhanced Packet Block (0x00000006), Total Length (header)
> = 144 (0x00000090), Body at offset 000001dc, Trailer at offset 00000260, next
> (if any) at offset 00000264
> 00000264: Block #6: Enhanced Packet Block (0x00000006), Total Length (header)
> = 144 (0x00000090), Body at offset 0000026c, Trailer at offset 000002f0, next
> (if any) at offset 000002f4
> 000002f4: Block #7: Enhanced Packet Block (0x00000006), Total Length (header)
> = 144 (0x00000090), Body at offset 000002fc, Trailer at offset 00000380, next
> (if any) at offset 00000384
> 00000384: Block #8: Enhanced Packet Block (0x00000006), Total Length (header)
> = 144 (0x00000090), Body at offset 0000038c, Trailer at offset 00000410, next
> (if any) at offset 00000414
> 00000414: Block #9: Enhanced Packet Block (0x00000006), Total Length (header)
> = 144 (0x00000090), Body at offset 0000041c, Trailer at offset 000004a0, next
> (if any) at offset 000004a4
> Oops: Block #9, at offset 0000041c (decimal 1052) short read, expecting 136
> octets, but only saw 0.
> $
Interestingly editcap can in fact successfully produce a copy of the
reorderTake1.pcapng file:
> $ editcap reorderTake1.pcapng editcap.take1.output
> $
A dump of the editcap generated editcap.take1.output file reveals that two IDBs
are now contiguous:
> $ ngd -qD editcap.take1.output
> +++Quiet Summary
> +++Reading from editcap.take1.output
> +++This machine is little-endian.
> +++The following section is little-endian.
> 00000000: Block #1: Section Header Block (0x0a0d0d0a), Total Length (header)
> = 148 (0x00000094), Body at offset 00000008, Trailer at offset 00000090, next
> (if any) at offset 00000094
> 00000094: Block #2: Interface Description Block (0x00000001), Total Length
> (header) = 32 (0x00000020), Body at offset 0000009c, Trailer at offset
> 000000b0, next (if any) at offset 000000b4
> 000000b4: Block #3: Interface Description Block (0x00000001), Total Length
> (header) = 36 (0x00000024), Body at offset 000000bc, Trailer at offset
> 000000d4, next (if any) at offset 000000d8
> 000000d8: Block #4: Enhanced Packet Block (0x00000006), Total Length (header)
> = 144 (0x00000090), Body at offset 000000e0, Trailer at offset 00000164, next
> (if any) at offset 00000168
> 00000168: Block #5: Enhanced Packet Block (0x00000006), Total Length (header)
> = 144 (0x00000090), Body at offset 00000170, Trailer at offset 000001f4, next
> (if any) at offset 000001f8
> 000001f8: Block #6: Enhanced Packet Block (0x00000006), Total Length (header)
> = 144 (0x00000090), Body at offset 00000200, Trailer at offset 00000284, next
> (if any) at offset 00000288
> 00000288: Block #7: Enhanced Packet Block (0x00000006), Total Length (header)
> = 144 (0x00000090), Body at offset 00000290, Trailer at offset 00000314, next
> (if any) at offset 00000318
> 00000318: Block #8: Enhanced Packet Block (0x00000006), Total Length (header)
> = 144 (0x00000090), Body at offset 00000320, Trailer at offset 000003a4, next
> (if any) at offset 000003a8
> 000003a8: Block #9: Enhanced Packet Block (0x00000006), Total Length (header)
> = 144 (0x00000090), Body at offset 000003b0, Trailer at offset 00000434, next
> (if any) at offset 00000438
> 00000438: Block #10: Enhanced Packet Block (0x00000006), Total Length
> (header) = 144 (0x00000090), Body at offset 00000440, Trailer at offset
> 000004c4, next (if any) at offset 000004c8
> 000004c8: Block #11: Enhanced Packet Block (0x00000006), Total Length
> (header) = 144 (0x00000090), Body at offset 000004d0, Trailer at offset
> 00000554, next (if any) at offset 00000558
> 00000558: Block #12: Enhanced Packet Block (0x00000006), Total Length
> (header) = 144 (0x00000090), Body at offset 00000560, Trailer at offset
> 000005e4, next (if any) at offset 000005e8
> 000005e8: Block #13: Enhanced Packet Block (0x00000006), Total Length
> (header) = 144 (0x00000090), Body at offset 000005f0, Trailer at offset
> 00000674, next (if any) at offset 00000678
> 00000678: Block #14: Enhanced Packet Block (0x00000006), Total Length
> (header) = 144 (0x00000090), Body at offset 00000680, Trailer at offset
> 00000704, next (if any) at offset 00000708
> 00000708: Block #15: Enhanced Packet Block (0x00000006), Total Length
> (header) = 144 (0x00000090), Body at offset 00000710, Trailer at offset
> 00000794, next (if any) at offset 00000798
> $
This editcap.take1.output file can be successfully used as an input file to
tshark to make a complete copy.
> $ tshark -r editcap.take1.output -w tshark.editcap.take1.output
> $
And a dump of the tshark generated tshark.editcap.take1.output file reveals the
same block structure as the input file:
> $ ngd -qD tshark.editcap.take1.output
> +++Quiet Summary
> +++Reading from tshark.editcap.take1.output
> +++This machine is little-endian.
> +++The following section is little-endian.
> 00000000: Block #1: Section Header Block (0x0a0d0d0a), Total Length (header)
> = 148 (0x00000094), Body at offset 00000008, Trailer at offset 00000090, next
> (if any) at offset 00000094
> 00000094: Block #2: Interface Description Block (0x00000001), Total Length
> (header) = 32 (0x00000020), Body at offset 0000009c, Trailer at offset
> 000000b0, next (if any) at offset 000000b4
> 000000b4: Block #3: Interface Description Block (0x00000001), Total Length
> (header) = 36 (0x00000024), Body at offset 000000bc, Trailer at offset
> 000000d4, next (if any) at offset 000000d8
> 000000d8: Block #4: Enhanced Packet Block (0x00000006), Total Length (header)
> = 144 (0x00000090), Body at offset 000000e0, Trailer at offset 00000164, next
> (if any) at offset 00000168
> 00000168: Block #5: Enhanced Packet Block (0x00000006), Total Length (header)
> = 144 (0x00000090), Body at offset 00000170, Trailer at offset 000001f4, next
> (if any) at offset 000001f8
> 000001f8: Block #6: Enhanced Packet Block (0x00000006), Total Length (header)
> = 144 (0x00000090), Body at offset 00000200, Trailer at offset 00000284, next
> (if any) at offset 00000288
> 00000288: Block #7: Enhanced Packet Block (0x00000006), Total Length (header)
> = 144 (0x00000090), Body at offset 00000290, Trailer at offset 00000314, next
> (if any) at offset 00000318
> 00000318: Block #8: Enhanced Packet Block (0x00000006), Total Length (header)
> = 144 (0x00000090), Body at offset 00000320, Trailer at offset 000003a4, next
> (if any) at offset 000003a8
> 000003a8: Block #9: Enhanced Packet Block (0x00000006), Total Length (header)
> = 144 (0x00000090), Body at offset 000003b0, Trailer at offset 00000434, next
> (if any) at offset 00000438
> 00000438: Block #10: Enhanced Packet Block (0x00000006), Total Length
> (header) = 144 (0x00000090), Body at offset 00000440, Trailer at offset
> 000004c4, next (if any) at offset 000004c8
> 000004c8: Block #11: Enhanced Packet Block (0x00000006), Total Length
> (header) = 144 (0x00000090), Body at offset 000004d0, Trailer at offset
> 00000554, next (if any) at offset 00000558
> 00000558: Block #12: Enhanced Packet Block (0x00000006), Total Length
> (header) = 144 (0x00000090), Body at offset 00000560, Trailer at offset
> 000005e4, next (if any) at offset 000005e8
> 000005e8: Block #13: Enhanced Packet Block (0x00000006), Total Length
> (header) = 144 (0x00000090), Body at offset 000005f0, Trailer at offset
> 00000674, next (if any) at offset 00000678
> 00000678: Block #14: Enhanced Packet Block (0x00000006), Total Length
> (header) = 144 (0x00000090), Body at offset 00000680, Trailer at offset
> 00000704, next (if any) at offset 00000708
> 00000708: Block #15: Enhanced Packet Block (0x00000006), Total Length
> (header) = 144 (0x00000090), Body at offset 00000710, Trailer at offset
> 00000794, next (if any) at offset 00000798
> $
Interestingly editcap can handle an arbitrary number of DPEBs between IDBs when
making a new pcapng file whereas tshark can not have any.
--
You are receiving this mail because:
You are watching all bug changes.___________________________________________________________________________
Sent via: Wireshark-bugs mailing list <wireshark-bugs@wireshark.org>
Archives: https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe
