Ethereal-dev: Re: [Ethereal-dev] Need an extra bit in the packet-header struct.

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: Ben Greear <greearb@xxxxxxxxxxxxxxx>
Date: Tue, 29 Jun 2004 10:04:01 -0700
Guy Harris wrote:
On Mon, Jun 28, 2004 at 11:44:26PM -0700, Ben Greear wrote:

I have need for an extra bit in the header for each packet.
This is to tell me whether the packet was received or transmitted
on this interface.


To which "packet header structure" are you referring?


Since the length fields are 32-bit, and there is no 4GB packet to be
had, I was thinking I could just use the high-bit there.


If it's "wtap_pkthdr", you might as well just add an entire field -
especially given that "received or transmitted" don't cover all the
possibilities; there's also

	unknown (if you really don't know whether the packet was
	received or transmitted)

How about something like this?  (We could also rob the high 16 bits of
the pkt_encap if we want to keep the structure the same size, this might
make it easier to make programs backwards and forwards compatible.)

diff -u -r1.155 wtap.h
--- wtap.h      7 Jun 2004 20:28:51 -0000       1.155
+++ wtap.h      29 Jun 2004 16:57:42 -0000
@@ -425,10 +425,22 @@
        struct irda_phdr        irda;
 };

+/* Define some flags and enumerations to help determine packet direction
+ * and other things.  The high 8 bits are reserved for third-party apps
+ * and should always be ignored unless the application explicitly understands
+ * the meaning of the bits.
+ */
+#define WTAP_TXRX_UNKNOWN     0x0
+#define WTAP_RECEIVED         0x1
+#define WTAP_TRANSMITTED      0x2
+#define WTAP_3P_BITS          0xFF000000
+
+
 struct wtap_pkthdr {
        struct timeval ts;
        guint32 caplen;
        guint32 len;
+        guint32 flags; /* Defined above, WTAP_*** */
        int pkt_encap;
 };


	received {unicast,broadcast,multicast} (some packet capture
	mechanisms supply this information; current libpcap doesn't pass
	that through, but it might do so in the future)

Can't we deduce all of this by looking at the ethernet frame?  Maybe
it is useful for non-ethernet protocols?

We are writing our own capture mechanism, so we can capture whatever
data is desired.

Thanks,
Ben

--
Ben Greear <greearb@xxxxxxxxxxxxxxx>
Candela Technologies Inc  http://www.candelatech.com