Development of l7-filter has moved to the Clear Foundation. These pages are out of date, but will remain as a historical record.
Last update 25 Nov 2007
See also the README and the list of supported protocols.
Q: Why is it called "l7-filter"?
A: Layer 7 is the application data layer in the OSI model. Packet classifiers are also known as "filters" in Linux QoS. (The first verison of l7-filter that we wrote, now long obsolete, was a QoS kernel module.)
Q: Could you add support for protocol X?
A: We'll certainly try. E-mail us at l7-filter-developers[AT]lists(D)sf{D}net (you must subscribe first).
Q: What are the differences between the 2.4 and 2.6 kernel patch?
A: The 2.4 patch is not being actively maintained anymore. However, as of l7-filter version 2.10, the only functional difference is that it does not implement the "unset" match.
Q: Why does the kernel version of l7-filter use Henry Spencer's regexp library instead of the GNU library or PCREs?
A: Because we managed to get that one to work in the kernel and not
the others. We agree that it is nice when regexps that work just like
in grep. This is part of the motivation for our new userspace version, which
does use GNU regular expressions.
Q: Why can't patterns match on NULL bytes?
A: This is an artifact of our regular expression libraries. They use C strings, which are NULL terminated. Therefore, we strip NULL bytes out of the data before trying to match it.
Q: Why is the QoS version gone?
A: The QoS version was our first attempt at doing this and it was
pretty awful. The new versions are better. They are easier to maintain
and easier to use. QoS features (which are, indeed, the focus of this
project!) are still available through the MARK target.
Q: How can I use l7-filter to redirect some of my traffic (to a proxy, etc.)?
A: You pretty much can't, at least not in any straightforward way. L7-filter can't possibly identifiy what protocol a connection is using until it sees a packet with data in it. For TCP, this is the third packet, far too late to start redirecting anything. (Convoluted schemes involving duplicating all your packets until you get a match may be possible, but we don't recommend it.) For UDP, it could work, providing that l7-filter gets enough data in the first packet to make a decision. Making sure this works is not our focus, however.
This can be done if you match on some quality that every packet has (such as port or IP number) rather than using l7-filter.
Q: I want to use l7-filter only on traffic from a particular computer
or subnet, but iptables -A FORWARD -p tcp -s 192.168.1.2 -m layer7
--l7proto http (or similar) doesn't work.
A: That's because you aren't letting l7-filter see the whole connection, but only the parts of it that match the first rule. You need to also let it see packets with the destination 192.168.1.2, or the analogous thing for your situation.
Q: I want to ACCEPT several protocols, DROPing the rest, but when I try, it drops (almost) everything!
A: Please don't use l7-filter to do this.
The explaination to this problem is similar to the previous answer. If you try do this, you will block all TCP handshakes and thus all TCP connections. In addition, you will block all UDP connections that can't be identified on the first packet.
Q: How can I use l7-filter for accounting without actually inserting it into my network?
A: See this guide.
Q: Some patterns work and others don't...
A: The most common cause of this is that l7-filter can't see all of the packets it needs to see. Some of our patterns match client messages, some match server messages and some need both to match. We write patterns with the expectation that l7-filter will be able to see both sides of the conversation.
The kernel version of l7-filter can only see packets if they go
through at least one l7-filter iptables rule. The userspace version of
l7-filter can only see the packets that you
(NF)QUEUE to it. The most common error is to
use either the INPUT or OUTPUT chain only.
These only get traffic for the local machine and only one direction
each. Please refer to the
Netfilter documentation for information about how packets traverse
the various chains. Also see this diagram.
Make sure that both incoming and outgoing packets are seen by your
rules.
Q: How do I manage the bandwidth of the computer that l7-filter is running on?
If you wish to do this sort of bandwidth control, l7-filter probably isn't appropriate, because there are better ways to do it. Since you are in control of the programs on your computer, you should be able to use their features to limit their bandwidth (i.e. "wget --limit-rate"). If they have no such features, you should be able to control what ports they use and match by port, which is faster and more reliable.
However, it is possible to use l7-filter to do this. The only adjustment needed is that you will need to use different iptables chains than the case of managing the bandwidth of connections that do not terminate at the l7-filter machine. See the previous answer for details.
Q: Setting up QoS to be useful is hard!
A: Yes, we're quite aware of that. We've tried to make the part of it that we control as easy as possible, but much of it isn't under our control. Look at our HOWTOs for some canned scripts.
If you believe that your difficulty is a general Linux QoS problem, we recommend starting with The Linux Advanced Routing and Traffic Control HOWTO. If you believe it is a l7-filter specific problem, read the rest of this FAQ (and the HOWTOs) before posting to our mailing list.
Q: But wait, this shouldn't work. A packet in the middle of an HTTP session will be indistinguishable from a packet in the middle of a Gnucleus session. They're both just a chunk of some file! And what about the child connections that protocols like FTP and IRC-DCC use, they don't contain any protocol information at all!
A: Linux has connection tracking capabilities which we take advantage of. We classify connections based on their first few packets and then classify packets based on what connection they are in. For more information, see our technical details.
Q: But wait! Can't you do this with X already?
A: Well, on our front page we list some open source projects that are similar, but as far as we know there isn't anything Free that really does the same thing as we do. Chances are that either:
If not, well, let us know. :-)
Q: Isn't this evil? Using this, my ISP could totally prevent me from doing X, when before, they could only make it difficult.
A: Well, first of all, there are already commercial applications that do this, so you haven't been safe for a while. Second, we believe that this is simply another valid tool for administrators to use. Whether they use it for good or evil is up to them, as is the case with virtually any tool. Third, if you tunnel your packets through SSL (or otherwise encrypt/obfuscate them), l7-filter will only be able to classify them as SSL, so you still have a way out. (And if this sounds like it makes the whole concept of application layer filtering useless, see the next question.)
Q: Isn't this just another pointless step in an arms race in which protocols will continually adapt to evade classification?
A: You can look at it like that, but essentially no. Internet standards like HTTP will not do this. Only P2P programs and the like will. This means that, at worst, what you will need to do is to shape the "unknown" classification down, leaving the most bandwidth for known protocols like HTTP, SMTP, and so on.
Q: Won't all SSL tunneled traffic look the same as HTTPS?
A: Yes and no. Information about the certificate is sent unencrypted in the first packet, and we currently have a pattern for SSL sessions signed by the major certificate agencies (Thawte, Verisign, GTE, etc.) Therefore, if someone self-signs a SSL key, their traffic will not be classified as having a valid certificate. (And if some P2P program starts self-signing certificates claiming to be Verisign, then they will be committing fraud and Verisign will have a strong interest to stop them from doing that.) Therefore, while it is probably possible to make "unimportant" SSL traffic look important, they would have to be pretty clever.
Q: Won't P2P programs that use HTTP to transfer files look the same as HTTP?
A: If a P2P program uses HTTP, it will most likely have to use a predictable URL (or the P2P program it is trying to get the file from won't understand.) For example, Kazaa always gets something like "HTTP://10.1.1.1/.hash=LJSDF234" and web sites are unlikely to have important files named ".hash="
Q: [Any snide remark about how real networks don't really use the OSI/ISO 7 layer model]
A: Yes, fine. But they do, actually, more or less. However, we should admit that we really do matching on layers 5 through 7, that is, anything above TCP/UDP. Most applications don't make much of a distinction, of course, and "ls5,6,and7-filter" just doesn't have the same ring to it.
