Guy Harris wrote:
On Tue, Jun 24, 2003 at 05:14:56PM +0530, Navin Anand wrote:
The modified files are:
libpcap.c
407,413d406
<
< /*
< * 20 Added for the fake link type, required to dissect packets
< * containing higher layer protocol payload without the lower layer
< * protocol headers, e.g. pure TCP data without underlying IP.
< */
< { 20, WTAP_ENCAP_FAKE_LINK },
There is no guarantee that a DLT_ value of 20 isn't being used
somewhere; it's best to request a DLT_ value from tcpdump.org - or to
define your own capture file format for your application, with its own
magic number, rather than using libpcap format.
Having just used libwiretap to dump packets to a PCAP file, I must admit
that I like using that format (just for ease of use).
However, I could imagine that the libpcap people might not be interested
in "wasting" a file format on something that only Ethereal will
understand anyway. Since only Ethereal would use this file format,
maybe it makes sense to add a wiretap file format for this instead?
Unfortunately (for me) libwiretap is under GPL instead of LGPL--which
prevents using it in binary-only applications. So unless the license
changes, I wouldn't be able to use it (though I suppose I could write my
own routines to write a PCAP or other file format). :(
(The format could be
the same as libpcap format, except for the file header, which could, for
example, contain a value specifying the lowest-level protocol layer, if
that's the same for all packets in the capture, and which would have a
differrent magic number.
What he's got now is a PCAP file format where each packet has a "fake
link" header on it that specifies the lowest-level protocol. This seems
quite flexible to me--although I suppose that the format of the header
needs to be stable before the file type is allocated.
Or... Maybe it makes sense to version the "fake link" header.
Note that, of course, there are places where the TCP dissector expects
to have an IP address for each packet, and thus expects there to be an
IP header; other protocols, such as SCCP, might make similar
assumptions. They might have to be modified to handle, for example, the
source and destination addresses being AT_NONE rather than, say, AT_IPv4
or AT_IPv6.
None of the SS7 dissectors I've written need any info about what was
above them (AFAIK). I suppose this is because they don't do any
kind of advanced analysis and/or reassembly?
TCP and other dissectors could be modified on an as-needed (as they are
added to "fake link") basis.