Hello! > 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. 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. 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. Alas, adding "realsize" to skb is too ugly to be accepted, especially taking into account that problem has another trivial solutions. > 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) 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 to tcpdump.org, OK. But use it at least for references. 8) You can classify some things there as hacks, of course, but these hacks have one interesting property: they work. Well, also you could use mmapped PF_PACKET. It maps to genuine BPF more closely. And revisit the suggestion to merge this patch to tcpdump.org yet. You are inventing bicycle, solving problems which have been solved long ago. Alexey - : send the line "unsubscribe linux-net" in the body of a message to majordomo@vger.rutgers.edu
