> If you get a chance to read it, and have any comments,
> reactions, opinions, flames, whatever, I'd love to hear
> them.
I might be inclined to make the time stamp be seconds-and-nanoseconds,
instead, even though the packet capture mechanisms on most platforms
currently provide seconds-and-nanoseconds; I suspect AIX's BPF might use
seconds-and-nanoseconds, and this would allow other platforms that use
seconds-and-nanoseconds to supply that and allow other platforms that
adopt it in the future to do so as well.
You might also want to boost the seconds value to 64 bits, to avoid the
Y2.038K problem.
Are there cases where a link-layer frame would be bigger than 64K bytes
(even though IPv4 and IPv6 have 16-bit length fields)?
I'd pad the payload so as to align the packet structure on a 32-bit
boundary, not just a 16-bit boundary; you *might* also provide padding
to put the link-layer payload on a 32-bit boundary (e.g., put 2 bytes of
padding *before* an Ethernet header).
Is "ifIndex" supposed to be the index the interface would have in an
SNMP query (as I infer from the name)?
The platforms I know of that currently supply, in their packet capture
mechanisms, status bits of the sort discussed are:
Linux - there's a "packet type" value which is one of:
PACKET_HOST - packet was unicast to the host that
captured it
PACKET_BROADCAST - packet was broadcast
PACKET_MULTICAST - packet was multicast to a group to
which the host that captured it belongs
PACKET_OTHERHOST - packet was seen by the host that
captured it only because the interface was in
promiscuous mode
PACKET_OUTGOING - packet was *sent* by the host that
captured it and was looped back
Digital UNIX - there are bit flags:
ENSF_BROADCAST - packet was broadcast
ENSF_MULTICAST - packet was multicast to a group to
which the host that captured it belongs
ENSF_PROMISC - packet was seen by the host that captured
it only because the interface was in promiscuous
mode
ENSF_TRAILER - packet was trailer-encapsulated (and the
capture mechanism reformatted it into normal form)
IRIX - there are bit flags:
SN_PROMISC - packet was seen by the host that captured
it only because the interface was in promiscuous
mode
SN_ERROR - receive error, one or more of the following
bits are set:
SNERR_FRAME - framing error
SNERR_CHECKSUM - CRC error
SNERR_TOOBIG - packet was too big for the buffer and was
truncated (referring to the snapshot length?)
SNERR_TOOSMALL - packet not received, size less than
minimum (runt?)
SNERR_NOBUFS - no packet received, out of buffers
SNERR_OVERFLOW - no packet received, input silo overflow
SNERR_MEMORY - no packet received, buffer memory error
Other platforms don't, as far as I know, supply that information,
although they could probably be changed to supply at least some of it.
-
This is the TCPDUMP workers list. It is archived at
http://www.tcpdump.org/lists/workers/index.html
To unsubscribe use mailto:[EMAIL PROTECTED]?body=unsubscribe
