https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=3001
Summary: Display of durations in IPFIX biflows confuses forward
and reverse start/end times
Product: Wireshark
Version: 1.1.x (Experimental)
Platform: Other
OS/Version: All
Status: NEW
Severity: Normal
Priority: Medium
Component: Wireshark
AssignedTo: wireshark-bugs@xxxxxxxxxxxxx
ReportedBy: alex.dupuy@xxxxxxx
Depends on: 2764
Created an attachment (id=2406)
--> (https://bugs.wireshark.org/bugzilla/attachment.cgi?id=2406)
packet capture of IPFIX biflow PDUs
Build Information:
Version 1.1.2 (SVN Rev 26535)
Copyright 1998-2008 Gerald Combs <gerald@xxxxxxxxxxxxx> and contributors.
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 with GTK+ 2.10.14, with GLib 2.12.13, with libpcap 0.9.7, with libz
1.2.3, with POSIX capabilities (Linux), with libpcre 7.3, without SMI, without
c-ares, with ADNS, without Lua, with GnuTLS 1.6.3, with Gcrypt 1.2.4, without
Kerberos, without PortAudio, without AirPcap.
Running on Linux 2.6.23.17-88.fc7, with libpcap version 0.9.7.
Built using gcc 4.1.2 20070925 (Red Hat 4.1.2-27).
--
When dissecting an IPFIX PDU containing start and end times for both directions
of a biflow, no distinction is made between forward and reverse directions.
This can lead to bizarre (or worse, subtly incorrect) output for the flow
durations computed from start and end times.
In the attached packet capture (IPFIX-out4.pcap) containing IPFIX biflow PDUs
from a simulated network, millisecond (sysTimeTick) start and end timestamps
for both the forward and reverse direction flows in the biflow are present (you
can see this in the screenshot for the template packet, which I will attach
presently). When displaying the biflow data PDUs, three durations are
displayed: forward start - forward end, reverse start - forward end, and
reverse start - reverse end (you can see this in the screenshot for the data
packet, which I will attach presently). This happens because the duration
display (and timestamps) are added whenever a start or end timestamp field is
processed, and both start and end are present - with no distinction made for
forward or reverse directions.
In a previous layout of the PDUs, where the data fields were forward start,
reverse start, forward end, reverse end, the display was not obviously wrong,
but the computed duration for the forward direction used the reverse start time
(most recent observed start). I spend several hours trying to understand why
my forward start timestamps were sometimes zero until I finally realized that
they weren't - wireshark was displaying the reverse start timestamps for both
durations. If I hadn't had zero timestamps for some biflows, I would never
have noticed that the information was incorrect.
I will also be attaching a patch to epan/dissectors/packet-netflow.c that
addresses this issue. It does not fully resolve the general case of the
problem, which is that start and end are not tracked separately for the four or
five different types of timestamps (relative millisecond, absolute
second/millisecond/microsecond/nanosecond) - in a PDU which contained both
relative millisecond and absolute nanosecond start and end timestamps (and no
biflows) you would see the same sort of confusion. In practice, there is not
much point in having both types of timestamp present in a single PDU, so I
don't think it is likely that this problem will occur - but the developer
confusion if it does could be pretty significant.
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.