THIS IS A TEST INSTANCE. Feel free to ask and answer questions, but take care to avoid triggering too many notifications.
0

Wireshark won't dissect time protocol completely

  • retag add tags

The latest wireshark does not appear to properly decode time protocol (RFC 868) completely. Only response packets are decoded but not request packets. I believe this may have to do with the fact that a request packet is zero data length and thus maybe doesn't trigger the dissector. I've added debug code to the dissector and it's only triggered once despite there being a request and response packet on the same ports/IPs. I've searched the forums but don't see any answers on this protocol.

The wireshark version is 2.6.3.

Further analysis confirmed my theory and this is due to this section in packet-udp.c

  if (udph->uh_ulen == 8) {
    /* Empty UDP payload, nothing left to do. */
    return;
  }

No parsing of sub-protocols is attempted if the UDP length is 8 (header only) as I expected. However, this is still a valid TIME packet that should be tagged accordingly based on destination port. I'm uncertain of the impact of removing this code though to other sub-protocols of UDP.

Worker99's avatar
1
Worker99
asked 2018-10-01 17:13:02 +0000
cmaynard's avatar
11.1k
cmaynard
updated 2018-10-01 18:26:41 +0000
edit flag offensive 0 remove flag close merge delete

Comments

Can you share a link to the capture file, e.g. CloudShark, Google Drive, DropBox etc.

Can you also amend your question with the actual Wireshark version you're using, "latest" leaves a lot of possibilities.

grahamb's avatar grahamb (2018-10-01 17:33:31 +0000) edit
add a comment see more comments

2 Answers

0

The code in question was added in November 2015, with the following commit message:

UDP: Don't throw malformed errors for empty UDP payload

Unfortunately, it's unclear which erroneous malformed errors were being thrown. In any case, it would appear that this change was the wrong fix to that problem.

I would suggest opening up a Wireshark bug report referencing this change, and as grahamb suggested, please attach a small capture file to the bug report depicting the problem with the TIME packet.

cmaynard's avatar
11.1k
cmaynard
answered 2018-10-01 18:23:01 +0000, updated 2018-10-01 18:47:56 +0000
edit flag offensive 0 remove flag delete link

Comments

add a comment see more comments
0

Further analysis confirmed my theory and this is due to this section in packet-udp.c

if (udph->uh_ulen == 8) { /* Empty UDP payload, nothing left to do. */ return; }

No parsing of sub-protocols is attempted if the UDP length is 8 (header only) as I expected. However, this is still a valid TIME packet that should be tagged accordingly based on destination port. I'm uncertain of the impact of removing this code though to other sub-protocols of UDP.

This does lead to some other protocols possibly throwing a malformed packet error. One of those protocols is RTCP. Changing the time protocol to correctly return true may prevent this in this instance, but maybe not others. The only way to know for certain will be to remove this, and wait for reports to occur, and fix those in the sub-protocols.

Change for time protocol is this:

if (pinfo->srcport == pinfo->match_uint) {
    /* seconds since 1900-01-01 00:00:00 GMT, *not* 1970 */
    guint32 delta_seconds = tvb_get_ntohl(tvb, 0);
    proto_tree_add_uint_format(time_tree, hf_time_time, tvb, 0, 4,
            delta_seconds, "%s",
            abs_time_secs_to_str(wmem_packet_scope(), delta_seconds-2208988800U,
                (absolute_time_display_e)time_display_type, TRUE));
    return tvb_captured_length(tvb);
}
else
{
    return TRUE;
}
Worker99's avatar
1
Worker99
answered 2018-10-01 18:49:20 +0000, updated 2018-10-01 18:50:27 +0000
edit flag offensive 0 remove flag delete link

Comments

For reference, bug 15159 was filed and is tracking this.

cmaynard's avatar cmaynard (2019-01-03 20:15:29 +0000) edit
add a comment see more comments

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account. This space is reserved only for answers. If you would like to engage in a discussion, please instead post a comment under the question or an answer that you would like to discuss.

Add Answer