# Revision history [back]

### Wireshark won't dissect time protocol completely

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.

### Wireshark won't dissect time protocol completely

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.

 3 None cmaynard 10696 ●10 ●244 ●164 https://www.igt.com/

### Wireshark won't dissect time protocol completely

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.

 4 None cmaynard 10696 ●10 ●244 ●164 https://www.igt.com/

### Wireshark won't dissect time protocol completely

The latest wireshark does not appear to properly decode time protocol (RFC 868) (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.