Hi Stephen,
here is the promised resend of the redback dissector update. For
me it fixes all issues of non decoded packets for me.

On Fri, May 18, 2007 at 08:52:07PM -0700, Stephen Fisher wrote:
> Subject: Re: [Wireshark-dev] redback dissector update #2
> 
> On Thu, May 17, 2007 at 12:40:35PM +0200, Florian Lohoff wrote:
> > On Tue, May 08, 2007 at 01:10:04PM -0700, Stephen Fisher wrote:
> > > Subject: Re: [Wireshark-dev] redback dissector update #2
> > > 
> > > On Tue, Apr 17, 2007 at 03:18:25PM +0200, Florian Lohoff wrote:
> > > > 
> > > > Hi,
> > > > here is another round - Now we see ISIS again correctly together with
> > > > PPPoE PPP handshakes handed from the Packet Forwarding Asic.
> > > 
> > > Do you want this patch, dated the 17th, applied instea of the one dated 
> > > the 13th or in addition to?
> > 
> > Instead - its a patch against svn current. Sorry it took so long. 
> > Should i resend the patch ?
> 
> Please do, I have my e-mail setup to delete mail older than a month so 
> it must have just deleted it today since the original was April 17th 
> :(.

Flo
-- 
Florian Lohoff                  [EMAIL PROTECTED]             +49-171-2280134
        Those who would give up a little freedom to get a little 
          security shall soon have neither - Benjamin Franklin
Index: epan/dissectors/packet-redback.c
===================================================================
--- epan/dissectors/packet-redback.c	(revision 21951)
+++ epan/dissectors/packet-redback.c	(working copy)
@@ -6,7 +6,7 @@
  * By Gerald Combs <[EMAIL PROTECTED]>
  *
  * Start of RedBack SE400/800 tcpdump trace disassembly
- * Copyright 2005,2006 Florian Lohoff <[EMAIL PROTECTED]>
+ * Copyright 2005-2007 Florian Lohoff <[EMAIL PROTECTED]>
  *
  * This program is free software; you can redistribute it and/or
  * modify it under the terms of the GNU General Public License
@@ -41,6 +41,7 @@
 static dissector_handle_t eth_handle;
 static dissector_handle_t clnp_handle;
 static dissector_handle_t arp_handle;
+static dissector_handle_t ppp_handle;
 
 /* wrapper for passing the PIC type to the generic ATM dissector */
 static void
@@ -81,47 +82,69 @@
                             "Layer3 Offset: %u", l3off);
   tisub = proto_tree_add_text (subtree, tvb, 22, 2,
                             "Data Offset: %u", dataoff);
-  next_tvb = tvb_new_subset(tvb, l3off, -1, -1);
 
   /* Mark the gap as "Data" for now */
   if (dataoff > l3off) {
 	proto_tree_add_text (subtree, tvb, 24, l3off-24, "Data (%d bytes)", l3off-24);	
   }
 
-  /*
-   * Just a guess - In case we see a difference in dataoff vs l3off
-   * we assume there is an ethernet header. Traces from an OC12 didnt
-   * show any header in here
-   */
-  if (dataoff > l3off) {
-    call_dissector(eth_handle, next_tvb, pinfo, tree);
-  } else {
-    switch(proto) {
-      case 0x01:
+  switch(proto) {
+    case 0x01:
         /*
 	 * IP - We assume IPv6 has a different protocol although
 	 * i might be wrong - Havent seen any traces
 	 */
-        call_dissector(ipv4_handle, next_tvb, pinfo, tree);
-        break;
-      case 0x02:
+      next_tvb = tvb_new_subset(tvb, dataoff, -1, -1);
+      call_dissector(ipv4_handle, next_tvb, pinfo, tree);
+      break;
+    case 0x02:
 	/*
-	 * It is CLNP although it seem the Packet Asic fills
-	 * some data in the packet so we have a "broken" packet in
-	 * the trace
+	 * Most of the time i have seen this protocol type
+	 * as 802.3 Ethernet containing CLNP for ISIS.
+	 *
+	 * Sometimes the 802.3 header is missing and the packet
+	 * seems to be CLNP anyway. Dissecting this shows
+	 * a broken packet for an unknown reason.
+	 *
 	 */
-        call_dissector(clnp_handle, next_tvb, pinfo, tree);
-        break;
-      case 0x03: /* Unicast Ethernet tx - Seen with PPPoE PADO */
-      case 0x04: /* Unicast Ethernet rx - Seen with ARP  */
-      case 0x08: /* Broadcast Ethernet rx - Seen with PPPoE PADI */
+      next_tvb = tvb_new_subset(tvb, l3off, -1, -1);
+      if (dataoff > l3off) {
+	      call_dissector(eth_handle, next_tvb, pinfo, tree);
+      } else {
+	      call_dissector(clnp_handle, next_tvb, pinfo, tree);
+      }
+      break;
+    case 0x06:
+
+      /* HACK This is a guess - i dont know what this flag means
+       * but my best guess is that it means "incoming" e.g.
+       * the direction of the packet. In case of incoming PPP
+       * packets there seems to be some padding which does
+       * not get reflected in the l3off/dataoff
+       */
+      if (flags & 0x00400000) {
+        next_tvb = tvb_new_subset(tvb, l3off, -1, -1);
+      } else {
+        proto_tree_add_text (subtree, tvb, l3off, 4, "Unknown Data (%d bytes)", 4);
+        next_tvb = tvb_new_subset(tvb, l3off+4, -1, -1);
+      }
+
+      if (l3off == dataoff) {
+        call_dissector(ppp_handle, next_tvb, pinfo, tree);
+      } else {
         call_dissector(eth_handle, next_tvb, pinfo, tree);
-        break;
-      default:
-	tisub = proto_tree_add_text (subtree, tvb, 24, length-24,
+      }
+      break;
+    case 0x03: /* Unicast Ethernet tx - Seen with PPPoE PADO */
+    case 0x04: /* Unicast Ethernet rx - Seen with ARP  */
+    case 0x08: /* Broadcast Ethernet rx - Seen with PPPoE PADI */
+      next_tvb = tvb_new_subset(tvb, l3off, -1, -1);
+      call_dissector(eth_handle, next_tvb, pinfo, tree);
+      break;
+    default:
+      tisub = proto_tree_add_text (subtree, tvb, 24, length-24,
 				"Unknown Protocol Data %u", proto);
-        break;
-    }
+      break;
   }
   return;
 }
@@ -147,6 +170,7 @@
   eth_handle = find_dissector("eth_withoutfcs");
   clnp_handle = find_dissector("clnp");
   arp_handle = find_dissector("arp");
+  ppp_handle = find_dissector("ppp");
 
   redback_handle = create_dissector_handle(dissect_redback, proto_redback);
   dissector_add("wtap_encap", WTAP_ENCAP_REDBACK, redback_handle);

Attachment: signature.asc
Description: Digital signature

_______________________________________________
Wireshark-dev mailing list
[email protected]
http://www.wireshark.org/mailman/listinfo/wireshark-dev

Reply via email to