On Fri, Dec 08, 2000 at 01:40:01PM +0100, Olaf Kirch wrote:
> Hi all,
>
> First, let me say: Great work! It really makes me happy that
> there are people working on tcpdump again.
>
> Attached you'll find some patches relative to tcpdump 3.5.2.
> I hope you find them useful
...
> tcpdump-3.5.2-icmp.patch
> This is a security fix that makes sure an attacker
> cannot overflow a 256 byte buffer on the stack.
The patch in question doesn't guarantee that - it keeps more than 256
bytes of IP address string from being put into the buffer, but the stuff
after it could overflow the buffer.
The current main CVS branch of tcpdump uses "snprintf()", which limits
the total number of characters put in the buffer to the size of the
buffer. We hope to produce a libpcap 0.6/tcpdump 3.6 release from that
branch this month or perhaps January.
> tcpdump-3.5.2-tr.patch
> Adds token ring support for Linux.
The current CVS tree has token ring support; the code came from a
combination of the FreeBSD and NetBSD code (each of which had something
the other didn't do as well), plus some stuff from Alexey Kuznetzov's
libpcap/tcpdump patches to generate packet filter expressions for token
ring (it doesn't handle source-routed packets, but doing so could
considerably complicate the BPF code generator - it'd have to handle
variable-length link-layer *and* IP headers, and doing that right might
involve adding a pile of dataflow analysis to the code generator).
> This one has a minor wart. tcpdump 3.4 used to have
> a global "extracted_ethertype" variable which is now
> static. When parsing the 802.5 header, I have to call
> print_llc, and need to know whether it recognized
> the ethertype, so that I can do a raw print if it
> didn't. This variable has now become static.
Hmm. That also breaks FDDI, I suspect, as it does the same thing.
I'll look at that.
The patch adds a new DLT_IEEE802_5 DLT_ type, but I think some other
Linux patches used DLT_IEEE802, and that's what FreeBSD and NetBSD used
(it doesn't make sense to have a link-layer type for generic "IEEE 802",
as the MAC header differs between the various 802.x types), so the
current CVS tree just uses DLT_IEEE802 for token ring.
We also don't throw out the MAC (as opposed to LLC) packets in libpcap -
the current CVS dissector doesn't do much with them, but it does check
for them, and Ethereal, which also uses libpcap, can dissect them.
We handle both ARPHRD_IEEE802_TR and ARPHRD_IEEE802 as meaning "token
ring" in pcap-linux.c - 2.2[.x] kernels used ARPHRD_IEEE802.
> tcpdump-3.5.2-isdn.patch
> Adds support for various Linux ISDN encapsulations.
In some mail to tcpdump-workers, Andi Kleen said, when I asked whether
there was any way to determine what the ISDN encapsulation was:
I don't know of any (except for maybe relying on the unstable
/dev/isdnctrl ioctls)
Your patch does an IIOCNETGCF on "/dev/isdnctrl" - is that, in fact,
reasonably stable, so that one can rely on it working with a wide
variety of Linux kernels and versions of the ISDN4Linux code?
-
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
