Julian Elischer escreveu:
Patrick Tracanelli wrote:
Mike Makonnen escreveu:
Hi,
An Internet Cafe I do some work for was recently having problems with
very slow internet access. It turns out customers were running P2P
file sharing applications which were hogging all the bandwidth. I
looked for programs that would allow me to shape traffic according
to the application layer protocol, but couldn't find any for FreeBSD.
I found a couple: l7-filter and ipp2p, but these are Linux specific.
So, I decided to write one. The result is ipfw-classifyd :
http://people.freebsd.org/~mtm/ipfw-classifyd.tar.bz2
As the name implies it uses ipfw(4) to implement a userland daemon
that classifies TCP and UDP packets according to regular expression
patterns for various protocols. It's intended to be used with
divert(4) sockets and dummynet(4) so you can do traffic shaping
depending on the application level protocol. The protocol patterns
are from the l7-filter project.
Basically, you use ipfw(8) to divert tcp/udp packets to the damon. It
reads its configuration file for a list of protocols and ipfw(8)
rules. Then, when it detects a matching session it re-injects the
packet back at the specified rule number. The tarball has a sample
configuration file and firewall script to get you started.
While I have not done extensive testing, preliminary tests are
encouraging and it seems to work, so I thought I'd announce it to the
rest of the world in case anyone else is interested in this kind of
application.
Comments and suggestions highly appreciated.
Cheers.
Wont compile on RELENG_6 but is working perfectly on REL_7. I am
trying hard with ssh, soulseek and msn. Its working like a charm with
the suggested rc.firewall.
I have configured ipfw-classfyd.conf changing the rules, for a number
of L7 patterns, and now I try to understand why the "diverted" rules
only match if the rule number is 1 after the configured, ie, I put
soulseek to 65530 and a rule wont match there, but the very same rule
matches 65531. I will read the code, but it seems that reinjection of
the packet is made +1, correct?
yes,
the idea is:
If you get the sockaddr for the received packet, and use it unmodified
when reinjecting the packet,
then it will continue on at the next rule.
so since the rule number is "unchanged" we need to add 1 to it
to say where to start from..
hope that helps..
Perfect. Thanks.
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
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%.
So far, this is what I have in real world enviroments.
--
Patrick Tracanelli
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"