Hi Guy,
[this Reply-To setting of the tcpdump-workers list really bothers me.
I Cc'ed linux-net for a reason. As Linux 2.4.0 should perhaps be fixed
I am sending this to linux-kernel and Alan Cox as well]
On Fri, Aug 04, 2000 at 08:14:32PM -0700, Guy Harris wrote:
> On Fri, Aug 04, 2000 at 09:47:36PM +0200, Torsten Landschoff wrote:
> > So the kernel code trims the packet
>
> Hmm.
>
> Were it not for the fact that the socket filter code in Linux can be,
> and I think is, used for purposes other than packet capture, I'd say
> that making the Linux packet filter code simply check whether the
> filter's return value is 0 or not, and not truncate the packet, might be
> the right idea, as there's *already* support for a snapshot length in
> Linux - the "recvfrom()" call will copy up only the amount of data
> specified by the third argument, discarding the rest of the data.
After sleeping over it I know it's not as easy to fix. Kernel 2.4.0
has the new turbo packet support which pushes the data directly into a
user space buffer and of course you can only trim the packet using
the filter in this case. The turbo packet code would be pointless if
we are not trimming the packets we receive because copying the
whole packets if not going to improve performance...
> (As the BSD BPF devices can copy up more than one packet, the snapshot
> length has to be specified elsewhere - it can't be inferred from the
> argument to "read()".)
The same applies to the turbo packet code in Linux 2.4...
> However, changing the kernel filter code not to truncate packets might
> break programs that expect it to - or that may pass down BPF programs
> with different snapshot lengths in different "ret" instructions.
>
> > I plan to change the pcap generated BPF code when installing the filter.
>
> I suspsect that's the best solution, as
>
> 1) it works without kernel changes (and thus works on Linux
> systems that are already out there);
>
> 2) it doesn't change the semantics of BPF programs in ways that
> might break software not using libpcap to generate BPF
> expressions or that's using packet filters other than on
> PF_PACKET sockets.
That were my ideas but I missed
3) we will not be able to use the turbo packet interface with that
filter code
> > The easy solution is to just change any RET #xx codes to return a
> > negative value so that the kernel does not touch the packet. It's kind
> > of a hack though and I do not like hacks ;)
>
> It's a bit of a hack, but I think the best solution is to *somehow*
> cause the BPF code stuffed into the packet filter not to truncate the
> packets, which involves changing "ret" instructions.
>
> Unfortunately, given that "pcap_compile()" is done independently of
> "pcap_setfilter()", it appears that, to do that, you would, in fact,
> have to *ex post facto* change the "ret" instructions - "pcap_compile()"
> doesn't know what you plan to do with the generated BPF code, so it
> doesn't know whether "ret" instructions should have a snapshot length or
> not.
Either that or we have to make the compile function aware of the Linux
specifics. But as I said we will run into other problems if we are
using the mmap packet interface which is needed at some point for atm
and the like...
What really bothers me is that this is also my fault because I should
have looked into this earlier. In that case we could have fixed early 2.2.x
kernels and would not have the problem now...
cu
Torsten
--
Torsten Landschoff Bluehorn@IRC <torsten@debian.org>
Debian Developer and Quality Assurance Committee Member
Attachment:
pgp00001.pgp
Description: PGP signature
