12 May, 2010

2 commits


25 Mar, 2010

3 commits

  • When extended status codes are available, such as ENOMEM on failed
    allocations, or subsequent functions (e.g. nf_ct_get_l3proto), passing
    them up to userspace seems like a good idea compared to just always
    EINVAL.

    Signed-off-by: Jan Engelhardt

    Jan Engelhardt
     
  • The following semantic patch does part of the transformation:
    //
    @ rule1 @
    struct xt_match ops;
    identifier check;
    @@
    ops.checkentry = check;

    @@
    identifier rule1.check;
    @@
    check(...) { }

    @@
    identifier rule1.check;
    @@
    check(...) { }
    //

    Signed-off-by: Jan Engelhardt

    Jan Engelhardt
     
  • Restore function signatures from bool to int so that we can report
    memory allocation failures or similar using -ENOMEM rather than
    always having to pass -EINVAL back.

    This semantic patch may not be too precise (checking for functions
    that use xt_mtchk_param rather than functions referenced by
    xt_match.checkentry), but reviewed, it produced the intended result.

    //
    @@
    type bool;
    identifier check, par;
    @@
    -bool check
    +int check
    (struct xt_mtchk_param *par) { ... }
    //

    Signed-off-by: Jan Engelhardt

    Jan Engelhardt
     

22 Jun, 2009

1 commit

  • As noticed by Török Edwin :

    Compiling the kernel with clang has shown this warning:

    net/netfilter/xt_rateest.c:69:16: warning: self-comparison always results in a
    constant value
    ret &= pps2 == pps2;
    ^
    Looking at the code:
    if (info->flags & XT_RATEEST_MATCH_BPS)
    ret &= bps1 == bps2;
    if (info->flags & XT_RATEEST_MATCH_PPS)
    ret &= pps2 == pps2;

    Judging from the MATCH_BPS case it seems to be a typo, with the intention of
    comparing pps1 with pps2.

    http://bugzilla.kernel.org/show_bug.cgi?id=13535

    Signed-off-by: Patrick McHardy

    Patrick McHardy
     

08 Oct, 2008

5 commits


14 Apr, 2008

1 commit


29 Jan, 2008

1 commit

  • Add rate estimator match. The rate estimator match can match on
    estimated rates by the RATEEST target. It supports matching on
    absolute bps/pps values, comparing two rate estimators and matching
    on the difference between two rate estimators.

    This is what I use to route outgoing data connections from a FTP
    server over two lines based on the available bandwidth:

    # estimate outgoing rates
    iptables -t mangle -A POSTROUTING -o eth0 -j RATEEST --rateest-name eth0 \
    --rateest-interval 250ms \
    --rateest-ewma 0.5s
    iptables -t mangle -A POSTROUTING -o ppp0 -j RATEEST --rateest-name ppp0 \
    --rateest-interval 250ms \
    --rateest-ewma 0.5s

    # mark based on available bandwidth
    iptables -t mangle -A BALANCE -m state --state NEW \
    -m helper --helper ftp \
    -m rateest --rateest-delta \
    --rateest1 eth0 \
    --rateest-bps1 2.5mbit \
    --rateest-gt \
    --rateest2 ppp0 \
    --rateest-bps2 2mbit \
    -j CONNMARK --set-mark 0x1

    iptables -t mangle -A BALANCE -m state --state NEW \
    -m helper --helper ftp \
    -m rateest --rateest-delta \
    --rateest1 ppp0 \
    --rateest-bps1 2mbit \
    --rateest-gt \
    --rateest2 eth0 \
    --rateest-bps2 2.5mbit \
    -j CONNMARK --set-mark 0x2

    iptables -t mangle -A BALANCE -j CONNMARK --restore-mark

    Signed-off-by: Patrick McHardy
    Signed-off-by: David S. Miller

    Patrick McHardy