tcpdump mailing list archives

Re: Suggestions for extra libpcap functions


From: Darren Reed <darrenr () reed wattle id au>
Date: Tue, 8 Apr 2003 09:17:11 +1000 (EST)

In some email I received from Guy Harris, sie wrote:
On Tue, Apr 08, 2003 at 01:01:32AM +1000, Darren Reed wrote:
int pcap_llheadersize(int dlt)

The link-layer header size isn't solely a function of the link-layer
type; it's also a function of the packet data for Token Ring and 802.11,
for example.

It could, I guess, return -1 if the application has to look at the
packet to determine it, or there could be a routine that takes both a
DLT_ value and a "const u_char *" and gets the link-layer header size
*for that packet*.

Yes, that would be perfect.

Of course, once you have the link-layer header size, you now can skip
that many bytes and have a pointer to a bunch of uninterpretable data,
unless you also have code to determine the payload type (IP, IPv6, ARP,
IPX, etc.).  At this point, you're starting to go down the path of
constructing packet parsing code; perhaps that sort of code belongs in a
packet parsing library, rather than in libpcap.

Technically, from a software engineering perspective, you may be right
here.  But from where I sit when it comes to using libpcap, it makes
perfect sense for it to be included as pcap already seems to know about
the DLT type for the connection/dump file.

int pcap_get_datalink(pcap_t *pd)

      hostname$ man pcap

              ...

           pcap_datalink() returns the  link  layer  type;  link  layer
           types it can return include:

                      ...

Or did you mean that "pcap_get_datalink()" should return something other
than the DLT_ value for the pcap_t?

No, I must have missed that function.  I'm used to Java and co. where the
pair to a "set" function is a "get" function.

Darren
-
This is the TCPDUMP workers list. It is archived at
http://www.tcpdump.org/lists/workers/index.html
To unsubscribe use mailto:tcpdump-workers-request () tcpdump org?body=unsubscribe


Current thread: