path: root/packet-lmi.c
diff options
authorGuy Harris <guy@alum.mit.edu>2001-03-30 10:51:50 +0000
committerGuy Harris <guy@alum.mit.edu>2001-03-30 10:51:50 +0000
commita8cbb073d4db9e6194718dc7f280a629dc42e854 (patch)
treeea1b2b6021449726e2e9fbb2bee9621526b216b3 /packet-lmi.c
parent4f61e8c410c2e68b92bea146a2648e78c6f35f2d (diff)
NLPID's of 0x08 and 0x09 should be labeled as Q.933 and LMI,
respectively, not Q.931 and Q.2931, in Frame Relay. When dissecting Q.933-style multiprotocol encapsulated Frame Relay frames, use the "osinl" dissector table to check for OSI network layer protocols, include the NLPID in the tvbuff you hand to "dissector_try_port()" with that dissector table, and put the NLPID into the protocol tree as an invisible item - the NLPID is considered part of the PDU for those protocols, so you have to include it in the tvbuff, and the dissector will put it into the protocol tree. Also, make sure the top-level entry for the Frame Relay protocol includes all the bytes preceding the payload, and none of the payload bytes. Export a routine to do Q.933-style dissection, and have the WCP dissector call it, rather than duplicating that code in the WCP dissector. Don't register OSI network layer protocols with the "fr.ietf" dissector table; it's now sufficient to register them with the "osinl" dissector table, as the Frame Relay dissector now checks that. Get rid of unnecessary checks for protocols being enabled (if the dissector is always called through handles or dissector tables, the common code for handles and dissector tables will do the checks for you). Get rid of some unnecessary #includes. svn path=/trunk/; revision=3211
Diffstat (limited to 'packet-lmi.c')
1 files changed, 2 insertions, 32 deletions
diff --git a/packet-lmi.c b/packet-lmi.c
index 6e07e878c7..4ccc0a80ee 100644
--- a/packet-lmi.c
+++ b/packet-lmi.c
@@ -2,7 +2,7 @@
* Routines for Frame Relay Local Management Interface (LMI) disassembly
* Copyright 2001, Jeffrey C. Foster <jfoste@woodward.com>
- * $Id: packet-lmi.c,v 1.2 2001/03/29 07:46:08 guy Exp $
+ * $Id: packet-lmi.c,v 1.3 2001/03/30 10:51:50 guy Exp $
* Ethereal - Network traffic analyzer
* By Gerald Combs <gerald@zing.org>
@@ -47,8 +47,7 @@
#include <glib.h>
#include <string.h>
#include "packet.h"
-#include "packet-osi.h"
+#include "nlpid.h"
static int proto_lmi = -1;
static int hf_lmi_call_ref = -1;
@@ -67,35 +66,6 @@ static int hf_lmi_act = -1;
static gint ett_lmi = -1;
static gint ett_lmi_ele = -1;
- * XXX - 0x09 means Q.2931 in some places, and Q.933 says 0x08 is the
- * NLPID for Q.933.
- *
- * However, RFC 2427 also says that an NLPID of 0x08 is used for
- * protocols that have neither an NLPID nor a SNAP encapsulation.
- *
- * What's the deal here? Is 0x08 for Q.933, and 0x09 for LMI, with
- * Q.933 used for full blown "phone call"-style signaling and LMI used
- * only for PVC status information? The IBM reference above says
- * that 0x08 is used for LMI.
- *
- * The Linux 2.2.14 "drivers/net/comx-proto-fr.c" has 0x08 as
- * NLPID_Q933_LMI and 0x09 as NLPID_CISCO_LMI. The page at
- *
- * http://dtool.com/gang.html
- *
- * speaks of "ANSI or ANSI Annex D or ITU-T Annex A" LMI,
- * "Cisco" or "Gang of Four" LMI, and "Q933A (ITU-T)" or "Annex-A"
- * LMI.
- *
- * If 0x08 is for Q.933, how do you distinguish the Q.931-style
- * signaling packets from the RFC 2427 encapsulation? Require a
- * call reference value of 0, which would presumably not be valid
- * for the first octet of an L2 protocol ID? RFC 2427 appears to
- * be silent on this.
- */
-#define NLPID_LMI 0x09 /* NLPID value for LMI */
#ifdef _OLD_
* Bits in the address field.