# Revision history [back]

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.

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);