Application layer classifier for ipfw

[Mike Makonnen]

Patrick Tracanelli wrote:
>
> To let you know of my current (real world) tests:
>
> - Wireless Internet Provider 1:
>     - 4Mbit/s of Internet Traffic
>     - Classifying default protocols + soulseek + ssh
>     - Classifying 100Mbit/s of dump over ssh
>
> Results in:
>     No latency added, very low CPU usage, no packets dropping.
>
> - Wireless ISP 2:
>     - 21 Mbit/s of Internet Traffic
>     - Classifying default protocols + soulseek + ssh
>
> Results in:
>     No tcp or udp traffic at all; everything that gets diverted never 
> comes out of the divert socket, and ipfw-classifyd logs
>
> Aug  1 12:07:35 ourofino last message repeated 58 times
> Aug  1 12:17:54 ourofino ipfw-classifyd: Loaded Protocol: bittorrent 
> (rule 50000)
> Aug  1 12:17:54 ourofino ipfw-classifyd: Loaded Protocol: edonkey 
> (rule 50000)
> Aug  1 12:17:54 ourofino ipfw-classifyd: Loaded Protocol: fasttrack 
> (rule 50000)
> Aug  1 12:17:54 ourofino ipfw-classifyd: Loaded Protocol: gnutella 
> (rule 1000)
> Aug  1 12:17:54 ourofino ipfw-classifyd: Loaded Protocol: soulseek 
> (rule 50000)
> Aug  1 12:17:54 ourofino ipfw-classifyd: Loaded Protocol: ssh   (rule 
> 50000)
> Aug  1 12:18:28 ourofino ipfw-classifyd: unable to write to divert 
> socket: Operation not permitted
> Aug  1 12:18:50 ourofino last message repeated 90 times

Hmmm... this part means that the call to sendto(2) to write the packet 
back into network stack failed.  This explains why you are not seein g 
any traffic comming back out of the divert socket, but I don't see why 
it would suddenly fail with a permission error. Could this be a kernel bug?
> Aug  1 12:18:51 ourofino ipfw-classifyd: packet dropped: input queue full
> Aug  1 12:19:11 ourofino last message repeated 94 times
>
> Raised queue len a lot (up to 40960), when the application starts it 
> uses up to 25% CPU and a second after that, CPU usage gets lower the 
> 0.1%.

This looks like a deadlock. If it weren't able to process packets fast 
enough the cpu usage should be high even as it's spewing "packet 
dropped" messages. Can you send me some more information like memory 
usage and the firewall script you are using? How much of the 21Mbits/s 
of traffic is P2P? If you reduce the number of protocols you are trying 
to match against does the behavior change? Using netstat -w1 
-I<interface> can you tell me how many packets per second we're talking 
about for 4Mbits/s and 21Mbit/s? Also, the timestamps from the log file 
seem to show that the daemon is running for approx. 34 sec. before the 
first "unable to write to write to divert socket" message. Is it passing 
traffic during this time? Thanks.

I've uploaded a newer version. Can you try that also please. It includes:
   o SIGHUP forces it to re-read its configuration file
   o rc.d script
   o minor optimization (calls pthread_cond_signal with the mutex unlocked)
   o code cleanup

Also, for your convenience I have attached a patch against the earlier 
version that removes a debugging printf that should remove spammage to 
your log files (the current version has it removed already).

Cheers.

-- 
Mike Makonnen       | GPG-KEY: http://people.freebsd.org/~mtm/mtm.asc
mtm @ FreeBSD.Org   | AC7B 5672 2D11 F4D0 EBF8  5279 5359 2B82 7CD4 1F55
FreeBSD             | http://www.freebsd.org

-------------- next part --------------
--- classifyd.c.orig	2008-08-02 11:11:33.000000000 +0300
+++ classifyd.c	2008-08-02 11:10:52.000000000 +0300
@@ -334,10 +334,6 @@
 			if ((error) == 0) {					\
 				(flow)->if_fwrule = (proto)->p_fwrule;		\
 				(pkt)->fp_saddr.sin_port = (flow)->if_fwrule; 	\
-				syslog(LOG_NOTICE, "MATCH %s(%d): %s:%d -> %s:%d\n",	\
-					(proto)->p_name, (flow)->if_fwrule,	\
-					inet_ntoa((key)->ik_src), ntohs((key)->ik_sport), \
-					inet_ntoa((key)->ik_dst), ntohs((key)->ik_dport)); \
 			} else if ((error) != REG_NOMATCH) {			\
 				regerror((error), &(proto)->p_preg, (regerr), sizeof((regerr))); \
 				syslog(LOG_WARNING, "error matching %s:%d -> %s:%d against %s: %s", \