On Thu, May 30, 2002 at 05:39:30PM +0800, Iain McAleer wrote:
> it was some bogus header structures i had defined because I couldn't find
> the real ones...if anyone has copys of the structures for less used
> protocols like ipip,
If by "ipip" you mean IP protocol 94, as per "/etc/protocols", a Google
search for
ipip 94
found
http://www.tcpdump.org/lists/workers/2001/05/msg00095.html
in which itojun says
JI6 is for famous ji@att, and there's no refernece to RFC.
I assume that's John Ioannidis. RFC 1853 says
Use of IP in IP encapsulation differs from later tunneling techniques
(for example, protocol numbers 98 [RFC-1241], 94 [IDM91a], 53
[swIPe], and 47 [RFC-1701]) in that it does not insert its own
special glue header between IP headers. Instead, the original
unadorned IP Header is retained, and simply wrapped in another
standard IP header.
...
References
[IDM91a] Ioannidis, J., Duchamp, D., Maguire, G., "IP-based
protocols for mobile internetworking", Proceedings of
SIGCOMM '91, ACM, September 1991.
so if you want structures for that, you'll have to find that paper.
> gre,
Tcpdump's GRE-printing routines in "print-gre.c" don't overlay
structures atop the raw packet data - instead, it uses macros to extract
data directly from the packet. Somebody else might have structures for
GRE headers, but you don't *have* to have structures to analyze packets.
See RFCs 1701, 1702, 2637, 2784, and 2890 for information on GRE.
> idp,
Which protocol is that? The one that's listed as "xns-idp" in
"/etc/protocols" on my FreeBSD 3.4 machine?
> egp,
See "print-egp.c" in tcpdump.
> pup
That's an ancient Xerox protocol. If you *REALLY* care about it, see
Uncle Al's Xerox Alto Archive (for folks familiar with the San Francisco
Bay Area's KFJC, yes, that's Uncle Al) at
http://www.spies.com/~aek/alto/
and look for "PUP Spec" - it's a PDF document. I don't know whether
anybody's cooked up any .h file with structures for it.
> and rsvp.
See RFC 2205 and RFC 2210; there may be other RSVC RFCs.
> as well as the structures for all the device types defined in ngrep
Well, the ngrep man page on the packetfactory.net site
http://www.packetfactory.net/projects/ngrep/ngrep.8.html
lists, in addition to Ethernet and FDDI, PPP, SLIP, and "null
interfaces".
Tcpdump's PPP-printing routines for "standard" PPP don't use structures;
see "print-ppp.c".
Also, see RFC 1661 and RFC 1662.
The routines for BSD/OS PPP use a structure - that structure includes
the PPP header plus driver-supplied information - but, alas, I've never
seen that structure. (A Google search for
"bsd/os ppp"
turned up a bunch of pages, but once I filtered out the mentions of them
in connection with tcpdump and Ethereal with
"bsd/os ppp" -tcpdump -ethereal
as tcpdump depends on the headers that come with BSD/OS, and Ethereal
doesn't dissect them at all, it didn't find anything useful.
I don't know what ngrep means by "null interfaces", but I suspect they
mean mean "BSD loopback interfaces", as the DLT_ type for them is
somewhat bizarrely DLT_NULL.
The header for BSD loopback interfaces with type DLT_NULL is a 4-byte
value, in the byte order of the machine on which the packet was captured
(which, if you're reading a capture file, is *NOT* necessarily the byte
order of the machine on which you're reading the capture!), containing
an AF_ value, from the "/usr/include/sys/socket.h" value of the OS on
which the capture was done, for the protocol being used in that packet.
(NOTE: not all the BSDs have the same value for AF_INET6, so checking
for your OS's AF_INET6 to find IPv6 packets won't necessarily work if
you're reading a capture from a machine with a different OS from the one
on which you did the capture.)
There's also DLT_LOOP in OpenBSD, which is similar to DLT_NULL, but
stores the AF_ value in *network* byte order.
-
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
