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
