Updated the comment on the MSG_TRUNC problem in connection with the Linux

packet filter. Work around to come.

diff --git a/pcap-linux.c b/pcap-linux.c
index fa83dae01e68c2ee8cc0a0644220dc6eef25dcd9..f1ed22104d3d9a4d5c573ceeeff0e6859e553eb9 100644 (file)
--- a/pcap-linux.c
+++ b/pcap-linux.c
@@ -272,7 +272,29 @@ pcap_read_packet( pcap_t *handle, pcap_handler callback, u_char *userdata )
        /* XXX: According to the kernel source we should get the real 
         * packet len if calling recvfrom with MSG_TRUNC set. It does 
         * not seem to work here :(, but it is supported by this code
-        * anyway. */
+        * anyway. 
+        * To be honest the code RELIES on that feature so this is really
+        * broken with 2.2.x kernels.
+        * I spend a day to figure out what's going on and I found out
+        * that the following is happening: 
+        *
+        * The packet comes from a random interface and the packet_rcv 
+        * hook is called with a clone of the packet. That code inserts
+        * the packet into the receive queue of the packet socket.
+        * If a filter is attached to that socket that filter is run
+        * first - and there lies the problem. The default filter always
+        * cuts the packet at the snaplen:
+        *
+        * # tcpdump -d
+        * (000) ret      #68
+        *
+        * So the packet filter cuts down the packet. The recvfrom call 
+        * says "hey, it's only 68 bytes, it fits into the buffer" with
+        * the result that we don't get the real packet length. This 
+        * is valid at least until kernel 2.2.17pre6. 
+        *
+        * There are two ways to fix this: 1) Fix the kernel or 2) Work
+        * around it in libpcap. I think we should opt for 3) both ;) */
        
        caplen = packet_len;
        if( caplen > handle->snapshot )