Hi Alexey,
On Sat, Aug 05, 2000 at 04:17:32PM +0400, kuznet@ms2.inr.ac.ru wrote:
> > Only after following the packet through the kernel I noticed that=20
> > the packet is trimmed when it is enqueued. How can the kernel know the
> > size of our receive buffer?
>
> You said this size. "ret 68" means: truncate at 68 bytes.
> Yes, original size is forgotten in this case if you use LPF
> on any socket but mmapped PF_PACKET.
That's exactly what I found out.
> I will not say that I like this feature, it creates lots of troubles
> not only for packet socket, but also for TCP/UDP/RAW sockets.
I don't like it either ;)
> However, it has one great merit, it allows to truncate packets "dynamically"
> i.e. depending on their contents. This feature is not used by dumb libpcap
> compiler, however it presents in raw BPF and can be useful both for
> packet and for another kinds of sockets. F.e. pimd receives only packet
> headers for REGISTER messages, and whole packet for all other message
> kinds.
Yep, but there should still be a way to get the original packet size.
> Alas, adding "realsize" to skb is too ugly to be accepted,
> especially taking into account that problem has another trivial solutions.
There is a truesize member which I used in my local kernel tree to check
if that would fix it. Of course reading skbuff.h told me that it holds
the buffer size and not the original size of the packet.
> > I think the kernel is at fault here because there is no way to get=20
> > the original packet size after the packet went through the filter.=20
> ....
> > negative value so that the kernel does not touch the packet. It's kind
> > of a hack though and I do not like hacks ;)
>
> However, it works. 8)
Yep. Anyway when I first got my hands on Linux my first thought was "cool,
this way you won't need any more hacks but you can instead fix the problem
at it's root even if it is inside the kernel".
The work around needs to be implemented anyway because libpcap should work
on older kernels as well. But I think ultimately we should fix the kernel.
If the mmap interface was guaranteed to be available that would already
fix it. In that case libpcap would just always use that interface.
> I have already said you... PLEASE, look into my patch for libpcap,
> when you are in troubles. You did not want to help to merge it
I looked at your code. In fact you are calling recvfrom the same way.
As long as you are using the user level filter it works as my version
worked but I would expect it to break with kernel filter. I have to admit
that I did not try it :(
> to tcpdump.org, OK. But use it at least for references. 8)
I do that. Sorry if I was too dumb to figure it out from your source. And
I did not refuse to merge it with the tcpdump.org version not because
of personal antipathy but because I felt unable to understand all the
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.
If it was that easy why didn't you just do it? I am not in the way. We
can still go that route.
Also if I am to maintain that code I would prefer to understand that as
I would be a lousy maintainer otherwise.
> You can classify some things there as hacks, of course, but these hacks
> have one interesting property: they work.
I prefer to have a clean implementation that does not support everything
but does the working stuff "correctly".
> Well, also you could use mmapped PF_PACKET. It maps to genuine
> BPF more closely.
Yes, but that's not available on plain 2.2 kernels. And it is not guaranteed
to be in the kernel even in newer versions.
cu
Torsten
--
Torsten Landschoff Bluehorn@IRC <torsten@debian.org>
Debian Developer and Quality Assurance Committee Member
Attachment:
pgp00002.pgp
Description: PGP signature
