| Bug ID |
12116
|
| Summary |
editcap does not adjust time for frames with absolute timestamp 0 < t < 1 secs
|
| Product |
Wireshark
|
| Version |
Git
|
| Hardware |
x86
|
| OS |
All
|
| Status |
UNCONFIRMED
|
| Severity |
Minor
|
| Priority |
Low
|
| Component |
Extras
|
| Assignee |
[email protected]
|
| Reporter |
[email protected]
|
Build Information:
Wireshark 2.1.0 (v2.1.0rc0-1955-gd2a4400 from unknown)
Copyright 1998-2016 Gerald Combs <[email protected]> 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 GTK+ 2.24.23, with Cairo 1.8.8, with Pango 1.28.1, with
libpcap, without POSIX capabilities, with libnl 3, with libz 1.2.3, with GLib
2.28.8, without SMI, with c-ares 1.10.0, with Lua 5.1, without GnuTLS, with
Gcrypt 1.4.5, without Kerberos, with GeoIP, with PortAudio V19-devel (built Jul
8 2010), without AirPcap.
Running on Linux 2.6.32-573.12.1.el6.x86_64, with locale en_US.UTF-8, with
libpcap version 1.4.0, with libz 1.2.3, with Gcrypt 1.4.5.
Intel(R) Core(TM) i5-3340M CPU @ 2.70GHz (with SSE4.2)
Built using gcc 4.4.7 20120313 (Red Hat 4.4.7-16).
--
editcap assumes that a frame that has tv_sec == 0 does not have a supported
timestamp and skips adjusting the time. However, I have some pcap files that
were generated from a raw signal capture via a broken tool and have packets
starting close to the epoch. I know the offset I need to fix the capture, but
editcap -t <time_adj> input.pcap output.pcap leaves the timestamp on the first
39 packets (that have time < 1) while changing the timestamp on the others.
Using editcap is the first thing you'd want to do with such broken files, and
you can't fix the time offset without fixing the time offset first. I have a
fix, I'll send it to Gerrit.
You are receiving this mail because:
- You are watching all bug changes.
