The patch for pfil.c seems to have reversed the intention of Matthew's earlier patch (revision 1.7).  He changed the LIST's to TAILQ's to allow output filters to be processed in the opposite order to input filters (as mentioned in the history section of the pfil.9 man page).

I haven't tested it, but I think the following patch (against revision 1.11) will restore this behaviour.  If I have confused something, please correct me ;o)

Thanks!  Mike.

---
A man without a religon is like a fish without a bicycle.


--- pfil.c.orig	Mon Feb 21 21:56:48 2000
+++ pfil.c	Mon Feb 21 22:05:05 2000
@@ -76,9 +76,9 @@
 		pfil_init(ph);
 
 	if (flags & PFIL_IN)
-		pfil_list_add(&ph->ph_in, func, flags);
+		pfil_list_add(&ph->ph_in, func, PFIL_IN);
 	if (flags & PFIL_OUT)
-		pfil_list_add(&ph->ph_out, func, flags);
+		pfil_list_add(&ph->ph_out, func, PFIL_OUT);
 }
 
 static void
@@ -99,7 +99,10 @@
 	 * insert the input list in reverse order of the output list
 	 * so that the same path is followed in or out of the kernel.
 	 */
-	TAILQ_INSERT_TAIL(list, pfh, pfil_link);
+	if (flags & PFIL_IN)
+		TAILQ_INSERT_HEAD(list, pfh, pfil_link);
+	else
+		TAILQ_INSERT_TAIL(list, pfh, pfil_link);
 }
 
 /*