Проводник диссектора: формат эпохи времени - PullRequest
Новая
       7

Проводник диссектора: формат эпохи времени

0 голосов
/ 15 января 2019

Я пишу диссектор из Wireshark (разновидность C, а не Lua).

У меня есть поля времени, равные uint64, представляющие наносекунды с эпохи Unix.

Я бы хотел напечатать время в удобочитаемом формате в wireshark.

Я искал документацию, чтобы показать, как это сделать, и нашел только эту связанную с временем функцию proto_tree_add_time, в https://anonsvn.wireshark.org/wireshark/trunk-1.6/doc/README.developer.

В итоге я пишу вспомогательную функцию, подобную этой: 

static void add_pretty_time(tvbuff_t* tvb, proto_tree* body, unsigned field_offset, int field_id)
{
    uint64_t raw_time = tvb_get_letoh64(tvb, field_offset);
    nstime_t time;
    time.secs = raw_time / 1000000000;
    time.nsecs = raw_time % 1000000000;
    proto_tree_add_time(body, field_id, tvb, field_offset, 8, &time);
}

Есть ли какой-нибудь более изящный способ, предоставляемый Wireshark, чтобы сделать это? Например, FT_UINT64, BASE_DEC в массиве hf_register_info может указывать, что это поле должно быть проанализировано как uint64 и отображено в десятичном формате. Было бы идеально, если бы в массиве hf_register_info было что-то вроде FT_EPOCH64, ISO_FORMAT.

1 Ответ

0 голосов
/ 15 января 2019

Для полей FT_ABSOLUTE_TIME кодировка указывает форму, в которой указывается метка времени и порядок байтов. Отметка времени поддерживаемые в настоящее время кодировки находятся по адресу: https://github.com/wireshark/wireshark/blob/master/doc/README.dissector#L1648

ENC_TIME_SECS_NSECS - 8, 12, or 16 bytes.  For 8 bytes, the first 4
    bytes are seconds and the next 4 bytes are nanoseconds; for 12
    bytes, the first 8 bytes are seconds and the next 4 bytes are
    nanoseconds; for 16 bytes, the first 8 bytes are seconds and
    the next 8 bytes are nanoseconds.  The seconds are seconds
    since the UN*X epoch (1970-01-01 00:00:00 UTC).  (I.e., a UN*X
    struct timespec with a 4-byte or 8-byte time_t or a structure
    with an 8-byte time_t and an 8-byte nanoseconds field.)

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_SECS_USECS - 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.)

Ни один из них не соответствует наносекундам uint64 прошедшей эпохи.

Помощник add_pretty_time, написанный в вопросе, является правильным подходом, поскольку мы вынуждены использовать proto_tree_add_time вместо стандартного proto_tree_add_item с помощью встроенных кодировок.

Это все еще требует, чтобы массив hf_register_info имел правильные значения: то есть мы должны использовать основанный на времени тип поля и основанный на времени формат отображения. Пример первого: FT_ABSOLUTE_TIME. Пример последнего: ABSOLUTE_TIME_UTC. Где найти список каждого: https://github.com/boundary/wireshark/blob/master/epan/proto.c#L4742 и https://github.com/wireshark/wireshark/blob/master/doc/README.dissector#L147 соответственно.

...