Linux and UNIX Man Pages

Linux & Unix Commands - Search Man Pages

l7-filter(1) [debian man page]

l7-filter(1)							   User's Manual						      l7-filter(1)

NAME
l7-filter - classifies packets by their application layer data SYNOPSIS
l7-filter -f configuration_file [options] DESCRIPTION
l7-filter reads packets that are queued by Netfilter/iptables and marks them based on what application layer protocol they appear to be. OPTIONS
-f configuration_file Mandatory option. This file consists of pairs of protocol names and mark numbers. -q queue_number What queue to read packets from. Default is 0. -b bytes Match on up to this many bytes of application layer data. The default is 12000. -n packets Examine up to this many packets in each connection. If no match has been made after this, l7-filter gives up. The number of pack- ets counts all packets, including the TCP handshake and ACK packets (XXX but not any UDP packets that l7-filter didn't manage to get the conntrack for in time XXX). The default is 10. -p path Look for patterns in path instead of the default /etc/l7-protocols. The path and its subdirectories are searched, non-recursively (subsubdirectories are not searched). -m mask Use only the bits of the packet mark specified by the given mask. By default, l7-filter uses the whole 32 bit mark, so this is use- ful if you use other classifiers that set marks. For instance, if you give the mask 0xff000000, l7-filter will only use the first 8 bits of the mark and will completely ignore the rest of it. In this case, the mark numbers given in the configuration file are mapped onto the mask automatically. So if the configuration file says 2 and you've given the mask 0x00ff0000, l7-filter will actu- ally use 0x00020000. The mask must be contiguous (not, for instance, 0x00000f0f) and it must be at least 2 bits long. The number of protocols that l7-filter can handle is 2^(mask length)-3 since it uses the value 0 to detect when a packet has not been examined yet, 1 to mark packets in connections which are unmatched but still being examined, and 2 to mark packets which it has given up trying to identify. -c l7-filter expects its portion of the packet mark (see -m above) to be unmodified by other classifiers. Normally, if it gets a packet whose mark has already been modified (that is, is non-zero) in this region, it will send the packet on with the same mark without trying to classify it and print an error message. This option causes l7-filter instead to clobber the existing mark and classify as if it hadn't been there. -s Be silent (don't print anything) except in the case of warnings or errors. -v Be verbose. Gives more information about what l7-filter is doing. Multiple -v options increase the verbosity, up to a maximum of 4. -d Allow inadvisable configurations. You must give this option before the option which is inadvisable. UPGRADES
The latest version is always at http://sf.net/projects/l7-filter SEE ALSO
iptables(1) COPYRIGHT
Copyright (C) 2006-2007 Ethan Sommer <sommereAusers.sf.net> and Matthew Strait <quadongAusers.sf.net>. This is free software. You may redistribute copies of it under the terms of the GNU General Public License <http://www.gnu.org/licenses/gpl.html>. There is NO WARRANTY, to the extent permitted by law. l7-filter v0.3 January 2007 l7-filter(1)

Check Out this Related Man Page

PCAP_STATS(3PCAP)														 PCAP_STATS(3PCAP)

NAME
pcap_stats - get capture statistics SYNOPSIS
#include <pcap/pcap.h> int pcap_stats(pcap_t *p, struct pcap_stat *ps); DESCRIPTION
pcap_stats() fills in the struct pcap_stat pointed to by its second argument. The values represent packet statistics from the start of the run to the time of the call. pcap_stats() is supported only on live captures, not on ``savefiles''; no statistics are stored in ``savefiles'', so no statistics are available when reading from a ``savefile''. A struct pcap_stat has the following members: ps_recv number of packets received; ps_drop number of packets dropped because there was no room in the operating system's buffer when they arrived, because packets weren't being read fast enough; ps_ifdrop number of packets dropped by the network interface or its driver. The statistics do not behave the same way on all platforms. ps_recv might count packets whether they passed any filter set with pcap_set- filter(3PCAP) or not, or it might count only packets that pass the filter. It also might, or might not, count packets dropped because there was no room in the operating system's buffer when they arrived. ps_drop is not available on all platforms; it is zero on platforms where it's not available. If packet filtering is done in libpcap, rather than in the operating system, it would count packets that don't pass the filter. Both ps_recv and ps_drop might, or might not, count packets not yet read from the operating system and thus not yet seen by the application. ps_ifdrop might, or might not, be implemented; if it's zero, that might mean that no packets were dropped by the interface, or it might mean that the statistic is unavailable, so it should not be treated as an indication that the interface did not drop any packets. RETURN VALUE
pcap_stats() returns 0 on success and returns -1 if there is an error or if p doesn't support packet statistics. If -1 is returned, pcap_geterr() or pcap_perror() may be called with p as an argument to fetch or display the error text. SEE ALSO
pcap(3PCAP), pcap_geterr(3PCAP) 3 January 2014 PCAP_STATS(3PCAP)
Man Page