> 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);
2) handling the new ARPHRD_ type that 2.4[.x] use for Token
Ring.
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.
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, so
perhaps we should leave the "pcap_compile()" fix in place.)
> Is there anything else that's currently evolving and needs to be looked
> at?
It Might Be Nice to have the BPF compiler generate code, for Token Ring,
that properly handles source-routed packets, by fetching the length of
the routing information from the header of source-routed packets,
computing the link-layer header size from that, stuffing it into the X
register, using indexed accesses to look at the IP header, and computing
the offset of the TCP/UDP header by adding the IP header length to that
value, but
that's a non-trivial task, as far as I can tell;
none of the existing Token Ringified versions of libpcap do it,
as far as I know, so it wouldn't be a regression;
so I wouldn't delay an 0.6/3.6 release for it.
-
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
