Hi Alexey,
On Sat, Aug 05, 2000 at 06:38:00PM +0400, kuznet@ms2.inr.ac.ru wrote:
> > on older kernels as well. But I think ultimately we should fix the kernel.
>
> Well, if you are cycled on "correctness", you could remove truncation.
> I do not think that someone uses it nowadays. Just delete skb_trim
> from sk_filter, and that's all.
I am not into the correctness which is imposed on me in university. Perhaps
I should prove everything I develop to be correct but I don't have the time
and it's no fun at all.
We could indeed remove the truncation but iirc you mentioned that some
software is still using it. Also we will need it if we want tcpdump to
handle huge pipes like ATM. There were already some complaints that
tcpdump does not show every packet (probably because the receive queue
is overrun) going over a link.
I want tcpdump to use the turbo packet feature and if the filter does
not truncate the packet the full data is copied into user space if I
understand the af_packet code. And copying all data from each packet is
probably way to much to be handled by the user code on a busy router. I
can't say for sure though since I don't have any experience with those
systems.
> > If the mmap interface was guaranteed to be available that would already=20
> > fix it.
>
> Sorry? Is packet socket guaranteed to be present? 8)8)
It's not. But I don't want us to release an updated tcpdump which does not
work on the kernels which are currently in use. But we should be able
to remove the hack at some point in the future when most of the Linux
users have updated their kernels.
> What's about 2.2, I am sorry, but time machine is still not invented,
> so that your "correct" code has to work with not-hacked LPF.
It currently has to work with kernel 2.0.x as well so this is just another
special case. Hmm, we should really add a way to specify the minimal kernel
version in our package managers...
> Read, "correct" BPF generator uses "ret -1". Actually, referring
> to compatibility you immediately prove that there are no reasons
> to change kernel. 8)
That BPF generator is incorrect for the turbo packet interface then :(
Anyway, I will need to implement this in libpcap.
> > differences and the tcpdump.org code is way away from yours. Both implement
> > a lot of new stuff, sometimes the same stuff in different ways. It's not
> > easy to merge that.=20
>
> BTW at that point patch was applied almost cleanly,
> ignoring IPv6 chunks in BPF which had to be removed as whole.
Yes, there were only a handful of conflicts. The resulting code was
messy but seemed to work. I have a copy still lying around which I am
just compiling to check if your code worked correctly ;) And right, it
does.
# ./tcpdump -d
(000) ret #65535
> > If it was that easy why didn't you just do it?
>
> Just because I have some other easy things to do. 8)
We all have.
> > I prefer to have a clean implementation that does not support everything
> > but does the working stuff "correctly".
>
> Wow... First of all it would not be so bad to make it simply working
> and usable i.e. supporting all that required of tcpdump.
> Then it will be "correct" in the first approximation at least. 8)8)
>
> Do you want one very simple example? That sample of BPF code forces
> to suspect, that tcpdump uses default snapsize of 68 until now, right?
It seems so. I did not touch that code since I wanted to mess only with the
Linux specific stuff.
> It means that all the bug reports about TCP made with such tcpdump are useless
> and I will have to requery reports, to teach people how to use -s option
> etc. Well, "incorrectness" consists exactly of such small inconveniences.
Point taken. But those inconveniences can be fixed in small steps instead
of having a huge patch which does everything at once.
I wonder if the default snaplen you are using (144) is right for all
interfaces. Isn't there an interface with a longer header than ethernet?
I would opt for chosing something really big so that we get the most
protocol information and people who want to optimize it to capture
everything on a fast device can still use "-s".
Thanks
Torsten
--
Torsten Landschoff Bluehorn@IRC <torsten@debian.org>
Debian Developer and Quality Assurance Committee Member
Attachment:
pgp00003.pgp
Description: PGP signature
