Ethereal-dev: [Ethereal-dev] (possible) patch for SCTP

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

From: Jeff Morriss <jeff.morriss@xxxxxxxxxxx>
Date: Thu, 21 Jun 2001 16:55:13 -0400
Hello list,

Here's a (potential) patch for the SCTP dissector. It still has one
problem, but I think it's the best that can be done (more below).

Two things are fixed:

1.  When calling a sub-dissector on a DATA chunk, dissect the padding on
that chunk as part of the DATA chunk (since it's not part of the
payload;  this avoids confusing sub-dissectors).

The problem with this fix is that the padding on the SCTP DATA chunk is
at the end of the chunk.  The data that goes to the sub-dissector is
fine and the padding shows up where one *might* expect it (that is,
attached to the DATA chunk tree), BUT it is NOT highlighted as part of
the SCTP protocol tree when you select that tree in the GUI.  :(

I can find no better way of doing this, though...  (I really don't think
sub-dissectors should have to think about SCTP's padding.)  Any
thoughts/suggestions?

2.  Change the text name of the 'hf_sctp_data_chunk_payload_proto_id'
field to be "sctp.ppi" instead of "sctp.payload_proto_id"--to be
consistent with how SCTP is advertised to sub-dissectors.

Another option would be to change SCTP, M3UA, IUA, and SUAL (and the
M2PA dissector I will submit shortly) to use "sctp.payload_proto_id"
instead of "sctp.ppi".  I'm willing to go that way (will re-submit
patch) if you think it's better.

Regards,
-Jeff
Index: packet-sctp.c
===================================================================
RCS file: /cvsroot/ethereal/packet-sctp.c,v
retrieving revision 1.17
diff -u -r1.17 packet-sctp.c
--- packet-sctp.c	2001/06/18 02:17:52	1.17
+++ packet-sctp.c	2001/06/21 20:53:21
@@ -985,24 +985,34 @@
 dissect_payload(tvbuff_t *payload_tvb, packet_info *pinfo, proto_tree *tree,
 		proto_tree *chunk_tree, guint32 ppi, guint16 payload_length, guint16 padding_length)
 {
+  gboolean ret = FALSE;
+  tvbuff_t *user_tvb;
+
+  if (padding_length > 0)
+    /* create a tvb without padding (to pass to sub-dissector) */
+    user_tvb = tvb_new_subset(payload_tvb, 0, payload_length, payload_length);
+  else
+    user_tvb = payload_tvb;
+
   /* do lookup with the subdissector table */
-  if (dissector_try_port (sctp_ppi_dissector_table, ppi,  payload_tvb, pinfo, tree) ||
-      dissector_try_port(sctp_port_dissector_table, pi.srcport,  payload_tvb, pinfo, tree) ||
-      dissector_try_port(sctp_port_dissector_table, pi.destport, payload_tvb, pinfo, tree)){
-    return TRUE;
+  if (dissector_try_port (sctp_ppi_dissector_table, ppi,  user_tvb, pinfo, tree) ||
+      dissector_try_port(sctp_port_dissector_table, pi.srcport,  user_tvb, pinfo, tree) ||
+      dissector_try_port(sctp_port_dissector_table, pi.destport, user_tvb, pinfo, tree)){
+    ret = TRUE;
   }
   else {
     if (check_col(pinfo->fd, COL_INFO))
       col_append_str(pinfo->fd, COL_INFO, "DATA ");
     proto_tree_add_text(chunk_tree, payload_tvb, 0, payload_length,
 			"Payload (%u byte%s)",
-			payload_length, plurality(payload_length, "", "s")); 
-    if (padding_length > 0)
-      proto_tree_add_text(chunk_tree, payload_tvb, payload_length, padding_length,
-			  "Padding: %u byte%s",
-			  padding_length, plurality(padding_length, "", "s"));
-    return FALSE;
+			payload_length, plurality(payload_length, "", "s"));
+    ret = FALSE;
   }
+  if (padding_length > 0)
+    proto_tree_add_text(chunk_tree, payload_tvb, payload_length, padding_length,
+			"Padding: %u byte%s",
+			padding_length, plurality(padding_length, "", "s"));
+  return ret;
 }
 
 static gboolean
@@ -1768,7 +1778,7 @@
        "", HFILL }
     },
     {&hf_sctp_data_chunk_payload_proto_id,
-     { "Payload Protocol identifier", "sctp.payload_proto_id",
+     { "Payload Protocol identifier", "sctp.ppi",
 	FT_UINT32, BASE_HEX, NULL, 0x0,          
 	"", HFILL }
     },
begin:vcard 
n:Morriss;Jeff
tel;fax:+1-856-222-9947
tel;work:+1-856-787-2824
x-mozilla-html:FALSE
url:http://www.ulticom.com
org:Ulticom, Inc.;Customer Support
version:2.1
email;internet:jeff.morriss@xxxxxxxxxxx
title:Product Support Engineer
adr;quoted-printable:;;Ulticom, Inc.=0D=0A1020 Briggs Rd.=0D=0A;Mount Laurel;NJ;08054;USA
fn:Jeff Morriss
end:vcard