Changeset d3320d1 for lib/format_pcapfile.c

Timestamp:

07/16/10 11:42:23 (12 years ago)

Author:

Shane Alcock <salcock@…>

Branches:

4.0.1-hotfixes, cachetimestamps, develop, dpdk-ndag, etsilive, getfragoff, help, libtrace4, master, ndag_format, pfring, rc-4.0.1, rc-4.0.2, rc-4.0.3, rc-4.0.4, ringdecrementfix, ringperformance, ringtimestampfixes

Children:

53f179f

Parents:

b185327

Message:

• Handle dodgy wire lengths better - this solution tends towards hand-waving, as it tends to just perpetuate the error rather than trying to fix it.

File:

• lib/format_pcapfile.c (modified) (2 diffs)

lib/format_pcapfile.c

@@ -187 +187 @@
 
                 DATA(libtrace)->started = true;
-
-                if (err<1)
+                assert(sizeof(DATA(libtrace)->header) > 0);
+                
+                if (err<1) {
+
                         return -1;
+                }
                 
                 if (swapl(libtrace,DATA(libtrace)->header.magic_number) != 
@@ -457 +460 @@
                 hdr.wirelen = trace_get_wire_length(packet);
 
-        assert(hdr.wirelen < LIBTRACE_PACKET_BUFSIZE);
+        /* Reason for removing this assert:
+         *
+         * There exist some packets, e.g. in IPLS II, where the wire length
+         * is clearly corrupt. When converting to pcap, we *could* try to
+         * adjust the wire length to something sane but for now, I'll just let
+         * the broken length persist through the conversion.
+         *
+         * XXX Is setting the wire length to zero the best solution in such
+         * cases?
+         */
+
+        /* assert(hdr.wirelen < LIBTRACE_PACKET_BUFSIZE); */
 
         /* Ensure we have a valid capture length, especially if we're going