1. 14 9月, 2012 16 次提交
  2. 13 9月, 2012 3 次提交
  3. 12 9月, 2012 2 次提交
    • J
      netfilter: log: Fix log-level processing · 16af511a
      Joe Perches 提交于
      auto75914331@hushmail.com reports that iptables does not correctly
      output the KERN_<level>.
      
      $IPTABLES -A RULE_0_in  -j LOG  --log-level notice --log-prefix "DENY  in: "
      
      result with linux 3.6-rc5
      Sep 12 06:37:29 xxxxx kernel: <5>DENY  in: IN=eth0 OUT= MAC=.......
      
      result with linux 3.5.3 and older:
      Sep  9 10:43:01 xxxxx kernel: DENY  in: IN=eth0 OUT= MAC......
      
      commit 04d2c8c8
      ("printk: convert the format for KERN_<LEVEL> to a 2 byte pattern")
      updated the syslog header style but did not update netfilter uses.
      
      Do so.
      
      Use KERN_SOH and string concatenation instead of "%c" KERN_SOH_ASCII
      as suggested by Eric Dumazet.
      Signed-off-by: NJoe Perches <joe@perches.com>
      cc: auto75914331@hushmail.com
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      16af511a
    • E
      net-sched: sch_cbq: avoid infinite loop · bdfc87f7
      Eric Dumazet 提交于
      Its possible to setup a bad cbq configuration leading to
      an infinite loop in cbq_classify()
      
      DEV_OUT=eth0
      ICMP="match ip protocol 1 0xff"
      U32="protocol ip u32"
      DST="match ip dst"
      tc qdisc add dev $DEV_OUT root handle 1: cbq avpkt 1000 \
      	bandwidth 100mbit
      tc class add dev $DEV_OUT parent 1: classid 1:1 cbq \
      	rate 512kbit allot 1500 prio 5 bounded isolated
      tc filter add dev $DEV_OUT parent 1: prio 3 $U32 \
      	$ICMP $DST 192.168.3.234 flowid 1:
      Reported-by: NDenys Fedoryschenko <denys@visp.net.lb>
      Tested-by: NDenys Fedoryschenko <denys@visp.net.lb>
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      bdfc87f7
  4. 11 9月, 2012 8 次提交
  5. 10 9月, 2012 2 次提交
  6. 09 9月, 2012 1 次提交
    • C
      net: small bug on rxhash calculation · 68622342
      Chema Gonzalez 提交于
      In the current rxhash calculation function, while the
      sorting of the ports/addrs is coherent (you get the
      same rxhash for packets sharing the same 4-tuple, in
      both directions), ports and addrs are sorted
      independently. This implies packets from a connection
      between the same addresses but crossed ports hash to
      the same rxhash.
      
      For example, traffic between A=S:l and B=L:s is hashed
      (in both directions) from {L, S, {s, l}}. The same
      rxhash is obtained for packets between C=S:s and D=L:l.
      
      This patch ensures that you either swap both addrs and ports,
      or you swap none. Traffic between A and B, and traffic
      between C and D, get their rxhash from different sources
      ({L, S, {l, s}} for A<->B, and {L, S, {s, l}} for C<->D)
      
      The patch is co-written with Eric Dumazet <edumazet@google.com>
      Signed-off-by: NChema Gonzalez <chema@google.com>
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      68622342
  7. 08 9月, 2012 8 次提交