ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
July 17th, 2024 | 10:00am-11:55am SGT (UTC+8) | Online

Ethereal-dev: Re: [Ethereal-dev] Patch for UDP header length

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: Ulf Lamping <ulf.lamping@xxxxxx>
Date: Sun, 08 Jan 2006 22:12:42 +0100
Graeme Hewson wrote:

The attached patch puts out a warning if the UDP header Length field is longer than it ought to be.

Ethereal should also take account of UDP Jumbograms, as described in RFC 2675, where the Length field is zero, but I haven't included support for this in my patch since I don't have a sample packet.


Graeme Hewson

------------------------------------------------------------------------

--- packet-udp.c.orig	2006-01-02 11:50:50.000000000 +0000
+++ packet-udp.c	2006-01-08 20:29:03.000000000 +0000
@@ -224,8 +224,15 @@
      return;
    }
    if (tree) {
-      proto_tree_add_uint(udp_tree, hf_udp_length, tvb, offset + 4, 2, udph->uh_ulen);
-      proto_tree_add_uint_hidden(udp_tree, hf_udplite_checksum_coverage, tvb, offset + 4, 0, udph->uh_sum_cov);
+      if ((udph->uh_ulen > pinfo->iplen - pinfo->iphdrlen) && ! pinfo->fragmented) {
+        proto_tree_add_uint_format(udp_tree, hf_udp_length, tvb, offset + 4, 2,
+          udph->uh_ulen, "Length: %u (bogus, should be %u)", udph->uh_ulen,
+          pinfo->iplen - pinfo->iphdrlen);
+      } else {
+        proto_tree_add_uint(udp_tree, hf_udp_length, tvb, offset + 4, 2, udph->uh_ulen);
+        proto_tree_add_uint_hidden(udp_tree, hf_udplite_checksum_coverage, tvb, offset + 4,
+          0, udph->uh_sum_cov);
+      }
    }
  } else {
    udph->uh_ulen = pinfo->iplen - pinfo->iphdrlen;
------------------------------------------------------------------------

Hi Graeme!

Just wanted you to know, that the usage of hidden fields is deprecated for some time, and shouldn't be used in new code.

This is because hidden fields have some serious usability problem.

It's better to use a tree for this, so the user will see the available fields and can build a corresponding filter string even if the field in question is currently not "valid".

Regards, ULFL