Wireshark mailing list archives

Re: Default encodage for FT_ABSOLUTE_TIME


From: Michael Mann via Wireshark-dev <wireshark-dev () wireshark org>
Date: Fri, 8 Sep 2017 10:50:46 -0400


I just took a look at packet-zep.c, and the "timestamp field" is being added explicitly with proto_tree_add_time, which 
negates the need for an encoding.  Are you looking to convert that to proto_tree_add_item and pass the correct 
encoding?  That's the only time the encoding needs to be specified.
All of the encoding formats still display the same way in Wireshark, the encoding is just to tell the dissection engine 
how to interpret the bytes its being passed from tvb.
 
 
 
-----Original Message-----
From: Remy Leone <remy.leone () inria fr>
To: Developer support list for Wireshark <wireshark-dev () wireshark org>
Sent: Fri, Sep 8, 2017 10:38 am
Subject: [Wireshark-dev] Default encodage for FT_ABSOLUTE_TIME



Hello,


I'm looking currently at epan/dissectors/packet-zep.c and I don't see any encoding specified for FT_ABSOLUTE_TIME. If 
nothing is specified, which one is the default? Here is a reminder of the different encoding taken from the 
documentation that don't specify that:



 For FT_ABSOLUTE_TIME fields, the encoding specifies the form in which
 the time stamp is specified, as well as its byte order.  The time stamp
 encodings that are currently supported are:
 
     ENC_TIME_TIMESPEC - 8 bytes; the first 4 bytes are seconds since
         the UN*X epoch (1970-01-01 00:00:00 UTC) and the next 4 bytes
         are nanoseconds since that second.  (I.e., a UN*X struct
         timespec with a 4-byte time_t.)
 
     ENC_TIME_NTP - 8 bytes; the first 4 bytes are seconds since the NTP
         epoch (1900-01-01 00:00:00 GMT) and the next 4 bytes are 1/2^32's of
         a second since that second.  (I.e., a 64-bit count of 1/2^32's of a
         second since the NTP epoch, with the upper 32 bits first and the
         lower 32 bits second, even when little-endian.)
 
     ENC_TIME_TOD - 8 bytes, as a count of microseconds since the System/3x0
         and z/Architecture epoch (1900-01-01 00:00:00 GMT).
 
     ENC_TIME_RTPS - 8 bytes; the first 4 bytes are seconds since the UN*X
         epoch and the next 4 bytes are are 1/2^32's of a second since that
         second.  (I.e., it's the offspring of a mating between UN*X time and
         NTP time.)  It's used by the Object Management Group's Real-Time
         Publish-Subscribe Wire Protocol for the Data Distribution Service.
 
     ENC_TIME_TIMEVAL - 8 bytes; the first 4 bytes are seconds since the
         UN*X epoch and the next 4 bytes are microseconds since that
         second.  (I.e., a UN*X struct timeval with a 4-byte time_t.)
 
     ENC_TIME_SECS - 4 to 8 bytes, representing a value in seconds since
         the UN*X epoch.
 
     ENC_TIME_MSECS - 6 to 8 bytes, representing a value in milliseconds
         since the UN*X epoch.
 
     ENC_TIME_SECS_NTP - 4 bytes, representing a count of seconds since
         the NTP epoch.  (I.e., seconds since the NTP epoch.)
 
     ENC_TIME_RFC_3971 - 8 bytes, representing a count of 1/64ths of a
         second since the UN*X epoch; see section 5.3.1 "Timestamp Option"
         in RFC 3971.
 
     ENC_TIME_MSEC_NTP - 4-8 bytes, representing a count of milliseconds since
         the NTP epoch.  (I.e., milliseconds since the NTP epoch.)



Best regards


Rémy

___________________________________________________________________________Sent via:    Wireshark-dev mailing list 
<wireshark-dev () wireshark org>Archives:    https://www.wireshark.org/lists/wireshark-devUnsubscribe: 
https://www.wireshark.org/mailman/options/wireshark-dev             mailto:wireshark-dev-request () wireshark 
org?subject=unsubscribe
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe

Current thread: