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

packet filter. Work around to come.

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 )