mldonkey-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Mldonkey-users] Re: OT: donitor question


From: Goswin Brederlow
Subject: Re: [Mldonkey-users] Re: OT: donitor question
Date: 06 Feb 2003 03:17:10 +0100
User-agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Military Intelligence)

Hi there everyone.

I'm adding a CC to the hopefully author of donitor assuming that
everyone is fine with that.

The initial Question was why donitor uses so many iptables rules (2
per connection). There are some new questions at the end too.

Sven Hartge <address@hidden> writes:

> Um 14:47 Uhr am 04.02.03 schrieb Goswin Brederlow:
> > Sven Hartge <address@hidden> writes:
> >> Um 14:29 Uhr am 31.01.03 schrieb Goswin Brederlow:
> 
> >>> Why not just make two rules matching the PID of mldonkey, one
> >>> incoming, one outgoing?
> >> Because the match for PIDs is only valid in OUTPUT, not in INPUT.
> > Ok, but there are patches for that. :)
> 
> Not everyone likes to patch the kernel for just one tool. ;)
> 
> > With the current method all connections that are in use less than 2
> > minutes are not counted, right?
> 
> No. Since there are several "rounds", where update_rrd.pl checks for the
> amount of connections, every connection, which is in use less than
> ((120/$number_of_rounds)) seconds is not counted.
> 
> > At least for outgoing traffic a match with the PID would prevent that
> > and reduce the number of rules to a half.
> 
> Right.
> 
> Being able to match the PID would also allow to count the UDP-Traffic and
> draw it in a different colour.

I played around a bit with the iptables rules and now have the
following setup:

eth0  : 192.168.0.3 (my normal IP)
eth0.1: 192.168.0.6 (IP for mldonkey)

# enforce the use of the mldonkey IP for the mldonkey user (1003)
# alternatively the pid can be used but the user never changes here
iptables -t nat -A POSTROUTING -m owner --uid-owner 1003 -j SNAT --to-source 
192.168.0.6

# chains for donitor
iptables -N DKY_DWN
iptables -N DKY_UP

# download traffic minus the GUI on localhost
iptables -A DKY_DWN -s 127.0.0.1 -j RETURN                          
iptables -A DKY_DWN -j ACCEPT

# upload traffic minus the GUI on localhost
iptables -A DKY_UP -s 127.0.0.1 -j RETURN                          
iptables -A DKY_UP  -j ACCEPT

# everything the mldonkey user sends is DKY_UP
iptables -A OUTPUT -m owner --uid-owner 1003 -j DKY_UP

# everything for the mldonkey IP is DKY_DWN
iptables -A INPUT -d 192.168.0.6 -j DKY_DWN



In the donitor script I commented out rem_rules() and add_rules()
altogether since all rules are static. Comments are welcome. Heres
the effect on the runtime:

Before:
INFO: the execution of this script may take up to 100 seconds.
ROUND 0: processing took 24 seconds. sleeping for -4 seconds...
ROUND 1: processing took 4 seconds. sleeping for 16 seconds...
ROUND 2: processing took 4 seconds. sleeping for 16 seconds...
ROUND 3: processing took 4 seconds. sleeping for 16 seconds...
ROUND 4: processing took 5 seconds. sleeping for 15 seconds...
ROUND 5: processing took 5 seconds. commiting collected data...
1044487430:7637858:1427829:U:U:462.666666666667:U:U
9239.56786060367:2410.56807136543:0:0
INFO: the execution of this script may take up to 100 seconds.
ROUND 0: processing took 23 seconds. sleeping for -3 seconds...
ROUND 1: processing took 4 seconds. sleeping for 16 seconds...
ROUND 2: processing took 2 seconds. sleeping for 18 seconds...
ROUND 3: processing took 3 seconds. sleeping for 17 seconds...
ROUND 4: processing took 5 seconds. sleeping for 15 seconds...
ROUND 5: processing took 5 seconds. commiting collected data...
1044487549:3778865:674401:U:U:398.833333333333:U:U
9243.17166709934:2411.21123027809:0:0

After:
INFO: the execution of this script may take up to 100 seconds.
ROUND 0: processing took 0 seconds. sleeping for 20 seconds...
ROUND 1: processing took 1 seconds. sleeping for 19 seconds...
ROUND 2: processing took 1 seconds. sleeping for 19 seconds...
ROUND 3: processing took 1 seconds. sleeping for 19 seconds...
ROUND 4: processing took 0 seconds. sleeping for 20 seconds...
ROUND 5: processing took 1 seconds. commiting collected data...
1044492703:3913721:2120874:U:U:477.666666666667:U:U
9334.4576702122:2467.86152553565:0:0
INFO: the execution of this script may take up to 100 seconds.
ROUND 0: processing took 1 seconds. sleeping for 19 seconds...
ROUND 1: processing took 1 seconds. sleeping for 19 seconds...
ROUND 2: processing took 0 seconds. sleeping for 20 seconds...
ROUND 3: processing took 1 seconds. sleeping for 19 seconds...
ROUND 4: processing took 1 seconds. sleeping for 19 seconds...
ROUND 5: processing took 1 seconds. commiting collected data...
1044492822:3870195:2111147:U:U:476.333333333333:U:U
9338.14857578318:2469.87487220771:0:0

Both logs are with 400-500 connections and I had gaps before.

In the Before log, shouldn't rounds 1-5 be shorter than 20 seconds if
the first round takes longer than 20 second to make up for the lost
time?

Could we make more diagrams with total traffic, tcp and udp and gui?
Maybe even add an option to seperate local lan and internet. Using
static iptables rules would allow for matching of the ports and
networks easily.

And last, I noticed some big spikes (200-300K) that hapen when my
dialup disconnects and redials or when I flush the routers firewall
rules. An option to filter out unreasonable spikes would be nice.
Or limit for the actual bandwith so a "% bandwith used" could be drawn.

MfG
        Goswin




reply via email to

[Prev in Thread] Current Thread [Next in Thread]