Re: request for LINKTYPE_

[Jeff Morriss <jeff.morriss () ulticom com>]

Thanks!

>     Jeff> This file type will contain a header:
>
>     Jeff> typedef struct _rawss7_hdr { /* NOTE: These are in network-byte
>     Jeff> order. */ guint16 type; guint16 length; } rawss7_hdr;
>
>   If you'd like to provide a header file containing that, we could include
> it in libpcap, I guess, as informational.
>
>   The next number for LINKTYPE_ is 139.
>   I don't see a reason, given 32 bits of link type not to allocate the
> additional three LINKTYPE_s you wanted. 

When you mention that, I realized that the 'type' in the "rawss7_hdr" 
wasn't big enough...  Attached is a patch to update it (along with 
updating the documentation a bit).

BTW, the file is currently named "rawssw7.h"--it should probably be 
"rawss7.h".

Index: rawssw7.h
===================================================================
RCS file: /tcpdump/master/libpcap/rawssw7.h,v
retrieving revision 1.1
diff -u -r1.1 rawssw7.h
--- rawssw7.h   9 Sep 2003 17:10:15 -0000       1.1
+++ rawssw7.h   10 Sep 2003 18:26:56 -0000
@@ -31,12 +31,12 @@
 
 /*
  * This file is never used in libpcap or tcpdump. It is provided as
- * documentation linktypes 139 through 143 only.
+ * documentation linktypes 139 through 142 only.
  */
 
 /*
  * Date: Tue, 09 Sep 2003 09:41:04 -0400
- * From: Jeff Morriss <jeff.morriss () ulticom com>
+ * From: Jeff Morriss <jeff.morriss[AT]ulticom.com>
  * To: tcpdump-workers () tcpdump org
  * Subject: [tcpdump-workers] request for LINKTYPE_
  *
@@ -46,6 +46,12 @@
  * common example has been dumping MTP3 into a file without, well, MTP2 or
  * M2PA.
  *
+ * We want to store these protocols directly in PCAP file format because
+ * it's well defined and there isn't another (popular) file format for
+ * capturing SS7 messages that we can reverse engineer (and we want to read
+ * these files into Ethereal).  Rather than creating a new file format, it's
+ * a lot easier to just allocate a LINKTYPE_.
+ *
  * Here is the original post thread:
  *
  * http://ethereal.com/lists/ethereal-dev/200306/threads.html#00200
@@ -67,49 +73,33 @@
  * Based on the message in the last URL, I'd like to request a new
  * LINKTYPE_:  LINKTYPE_RAWSS7.
  *
- * This file type will contain a header:
+ * This packets in this file type will contain a header:
  */
 
 typedef struct _rawss7_hdr {
          /* NOTE: These are in network-byte order. */
-         guint16 type;
+         guint32 type;
          guint16 length;
+        guint16 spare;
 } rawss7_hdr;
 
 /*
  *
- * followed by protocol data for whatever protocol 'type' indicates.  E.g.:
+ * followed by protocol data for whatever protocol 'type' indicates.
  *
+ * There was some discussion about these protocol 'type's being allocated by
+ * tcpdump-workers as well.  In fact it would be handy to have one place to
+ * allocate such numbers, so what do you think about allocating 3 more (for
+ * now) LINKTYPE_'s:
  */
 
-/*  The list of protocols understood by the rawss7 dissector.
-  *  When adding a protocol here, be sure to add a value_string entry for
-  *  the protocol in "packet-rawss7.c"
-  */
-#define RAWSS7_MTP2           0x0001
-#define RAWSS7_MTP3           0x0002
-#define RAWSS7_SCCP           0x0003
+#define LINKTYPE_RAWSS7_MTP2   140
+#define LINKTYPE_RAWSS7_MTP3   141
+#define LINKTYPE_RAWSS7_SCCP   142
 
 /*
  *
- * There was some discussion about these protocol values being allocated by
- * tcpdump-workers as well.  In fact it would be handy to have one place to
- * allocate such numbers, so what do you think about allocating 3 more (for
- * now) LINKTYPE_'s:
- *
- * LINKTYPE_RAWSS7_MTP2
- * LINKTYPE_RAWSS7_MTP3
- * LINKTYPE_RAWSS7_SCCP
- *
- *  If not, just the LINKTYPE_RAWSS7 will be fine (Ethereal can maintain
- * the RAWSS7 types).
- *
- *
- *
- * ps. The reason we want to use the PCAP file format here is because it's
- * well defined and there isn't another (popular) file format for capturing 
- * SS7 messages that we can reverse engineer.  Rather than creating a new 
- * file format, it's a lot easier to just allocate a LINKTYPE_.
+ *  There is no reason this can't be used to store non-SS7 protocols, but
+ *  it's what we need to use it for now...
  *
  */
-