Ask Your Question
0

Wireshark won't dissect time protocol completely

asked 2018-10-01 17:13:02 +0000

Worker99 gravatar image

updated 2018-10-01 18:26:41 +0000

cmaynard gravatar image

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.

edit retag flag offensive 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 gravatar imagegrahamb ( 2018-10-01 17:33:31 +0000 )edit

2 Answers

Sort by ยป oldest newest most voted
0

answered 2018-10-01 18:23:01 +0000

cmaynard gravatar image

updated 2018-10-01 18:47:56 +0000

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.

edit flag offensive delete link more
0

answered 2018-10-01 18:49:20 +0000

Worker99 gravatar image

updated 2018-10-01 18:50:27 +0000

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;
}
edit flag offensive delete link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower

Stats

Asked: 2018-10-01 17:13:02 +0000

Seen: 35 times

Last updated: Oct 01