From Chris Maynard:

	Support PPP-over-USB.

	Don't remove the USB pseudo-header from the packet data for
	Linux USB packets, just byte-swap it if necessary and have the
	USB dissector fetch the pseudo-header from the raw packet data.

	Update USB language ID values.

svn path=/trunk/; revision=32534

1 files changed, 51 insertions, 2 deletions

diff --git a/epan/dissectors/packet-ppp.c b/epan/dissectors/packet-ppp.c
index b16c26fb19..91519a0e3e 100644
--- a/epan/dissectors/packet-ppp.c
+++ b/epan/dissectors/packet-ppp.c
@@ -46,8 +46,9 @@
 #include <epan/crc16.h>
 #include <epan/crc32.h>
 #include <epan/ipproto.h>
+#include "packet-usb.h"
 
-#define ppp_min(a, b)  ((a<b) ? a : b)
+#define ppp_min(a, b)  (((a)<(b)) ? (a) : (b))
 
 static int proto_ppp = -1;
 static int hf_ppp_direction = -1;
@@ -3255,7 +3256,7 @@ dissect_lcp_options(tvbuff_t *tvb, packet_info *pinfo, proto_tree *tree)
 }
 
 /*
- * RFC 1661.
+ * RFC's 1661, 2153 and 1570.
  */
 static void
 dissect_lcp(tvbuff_t *tvb, packet_info *pinfo, proto_tree *tree)
@@ -4336,6 +4337,50 @@ dissect_ppp_raw_hdlc( tvbuff_t *tvb, packet_info *pinfo, proto_tree *tree )
   } /* end while */
 }
 
+/*
+ * At least for the PPP/USB captures I've seen, the data either starts with
+ * 0x7eff03 or 0x7eff7d23 or 0xff03, so this function performs that heuristic
+ * matching first before calling dissect_ppp_raw_hdlc().  Otherwise, if we call
+ * it directly for USB captures, some captures like the following will not be
+ * dissected correctly:
+ * http://wiki.wireshark.org/SampleCaptures#head-886e340c31ca977f321c921f81cbec4c21bb7738
+ * 
+ * NOTE: I don't know if these heuristics are sufficient.  Time will tell ...
+ */
+static void
+dissect_ppp_usb( tvbuff_t *tvb, packet_info *pinfo, proto_tree *tree )
+{
+  /* In some cases, the 0x03 normally in byte 3 is escaped so we must look for
+   * the 2 byte sequence of 0x7d23 instead of 0x03.  The 0x23 is generated by
+   * 0x20^0x03 per section 4.2 of: http://tools.ietf.org/html/rfc1662.html. */
+  const guchar buf1[3] = {0x7e, 0xff, 0x03};
+  const guchar buf2[4] = {0x7e, 0xff, 0x7d, 0x23};
+  tvbuff_t *next_tvb;
+
+  if ((tvb_memeql(tvb, 0, buf2, sizeof(buf2)) == 0) || 
+    (tvb_memeql(tvb, 0, buf1, sizeof(buf1)) == 0)) {
+    dissect_ppp_raw_hdlc(tvb, pinfo, tree);
+  }
+  else {
+    /* See if it's missing the 0x7e framing character */
+    if (tvb_memeql(tvb, 0, &buf1[1], 2) == 0) {
+      /* Yup ... what TODO?  Should we try faking it by sticking 0x7e in
+       * front?  Or try telling dissect_ppp_raw_hdlc() NOT to look for the
+       * 0x7e frame deliminator?  Or is this a bug in libpcap (used 1.1.0)?
+       * Or a bug in the Linux kernel (tested with 2.6.24.4)  Or a bug in
+       * usbmon?  Or is the data we're looking at really just part of the
+       * payload and not control data?  Well, at least in my case it's
+       * definitely not, but not sure if this is always the case. Is this
+       * issue applicable only to PPP/USB or PPP/XYZ, in which case a more
+       * general solution should be found?
+       */
+      /* For now, just try skipping the framing I guess??? */
+      next_tvb = tvb_new_subset_remaining(tvb, 2);
+      dissect_ppp(next_tvb, pinfo, tree);
+    }
+  }
+}
+
 void
 proto_register_ppp_raw_hdlc(void)
 {
@@ -4351,10 +4396,14 @@ void
 proto_reg_handoff_ppp_raw_hdlc(void)
 {
   dissector_handle_t ppp_raw_hdlc_handle;
+  dissector_handle_t ppp_usb_handle;
 
   ppp_raw_hdlc_handle = create_dissector_handle(dissect_ppp_raw_hdlc, proto_ppp);
   dissector_add("gre.proto", ETHERTYPE_CDMA2000_A10_UBS, ppp_raw_hdlc_handle);
   dissector_add("gre.proto", ETHERTYPE_3GPP2, ppp_raw_hdlc_handle);
+
+  ppp_usb_handle = create_dissector_handle(dissect_ppp_usb, proto_ppp);
+  dissector_add("usb.bulk", IF_CLASS_UNKNOWN, ppp_usb_handle);
 }
 
 /*