On Fri, Dec 01, 2000 at 12:39:32PM -0800, Guy Harris wrote:
> > Let's think hard about doing a release in December. Lots has changed
> > since 3.5 (especially security-wise...) and it'd be nice to get something
> > out. What's the progress on pcap-linux, is it in OK shape?
>
> At this point, the two things I think should go into it before we do a
> release are
>
> 1) a new DLT_LINUX_COOKED (or whatever) link-layer type, for use
> when using PF_PACKET/SOCK_DGRAM rather than
> PF_PACKET/SOCK_RAW - it'd provide a link-layer header that
> includes an Ethernet type and, perhaps the one link-layer
> address you get, plus a flag indicating whether it's the
> sender or recipient link-layer address (the flag should *NOT*
> be a #define from a Linux header - the code to handle it
> should compile and run on non-Linux systems, so that captures
> done on Linux systems can be read on non-Linux systems);
I now have that working; it's DLT_LINUX_SLL, as per mail from Torsten,
and the link-layer header is:
a 2-byte "packet type" which is one of:
LINUX_SLL_HOST packet was sent to us
LINUX_SLL_BROADCAST packet was broadcast
LINUX_SLL_MULTICAST packet was multicast
LINUX_SLL_OTHERHOST packet was sent to somebody else
LINUX_SLL_OUTGOING packet was sent *by* us;
a 2-byte Ethernet protocol field;
a 2-byte link-layer type;
a 2-byte link-layer address length;
an 8-byte link-layer address, whose actual length is specified
by the previous value.
All fields except for the link-layer address are in network byte order.
The LINUX_SLL_ values are given the same values as the corresponding
PACKET_ values in the Linux kernel; libpcap and tcpdump, when built on
non-Linux systems (or Linux 2.0[.x] systems), can read these capture
files.
The values in question come from the information supplied in the
"sockaddr_ll" by the kernel.
Note that the link-layer address is always the source address of the
packet, even for LINUX_SLL_OUTGOING/PACKET_OUTGOING packets (that's the
way the 2.2[.x] kernel works, at least).
> 2) handling the new ARPHRD_ type that 2.4[.x] use for Token
> Ring.
I've checked that in already.
> Torsten was working on the former; I don't know how far he's gotten.
> (It involves both libpcap and tcpdump work. The libpcap work includes
> generating BPF code that can look at the fake link-layer header inside
> the kernel, which is, I suspsect, a bit complicated, as I have the
> impression that:
>
> in the kernel, an offset of 0 from the beginning of the frame
> refers to the first byte of the link-layer payload, and
> *negative* offsets are used to refer to fake link-layer header
> fields;
>
> in userland - e.g., when reading a saved capture, or when
> running on a Linux kernel that doesn't have socket filters
> enabled - an offset of 0 from the beginning of the frame would
> refer to the first byte of the fake link-layer header;
>
> so the BPF code run in userland would be different from the BPF code
> handed to the kernel.
>
> This might have to be done by, for example, generating BPF code under
> the assumption that it's intended for userland, and fixing it up before
> handing it to the kernel; as the attempt to hand it to may fail if, for
> example, socket filters aren't supported by the kernel, either a copy
> would have to be made of the filter and that copy fixed up, or the
> fixed-up copy would have to be unfixed if the attempt to hand it to the
> kernel failed.
That's the way the code I have works.
> The one bit of good news there is that we could probably get rid of the
> hack in "pcap_compile()" where we set the snapshot length to 65535 on
> Linux, so that the kernel doesn't forget the actual packet length -
> instead, the code to fix up filters to be handed to the kernel could
> also fix up RET instructions with non-zero operands, although, unlike
> the fixup for SOCK_RAW, that fixup would always have to be done,
It does that as well.
I've tested the code on a 2.0[.x] system, and on a couple of 2.2[.x]
systems, one with socket filtering in the kernel and one without socket
filtering in the kernel. I think it's ready to check in; I can send it
out if anybody's interested.
Once that's checked in, I think that's probably the last bit of code I
know of that I'd want to get into 0.6/3.6, with the possible exception
of the results of the packet bounds checking audit that Bill Fenner
suggested. Ohers may have other things they want in.
We should also update the CHANGES files.
-
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
