1. 09 1月, 2018 4 次提交
  2. 01 8月, 2017 1 次提交
  3. 08 2月, 2017 2 次提交
  4. 16 1月, 2017 1 次提交
  5. 05 1月, 2017 1 次提交
  6. 07 12月, 2016 1 次提交
  7. 05 12月, 2016 6 次提交
  8. 02 11月, 2016 4 次提交
    • A
      netfilter: nf_tables: introduce routing expression · 2fa84193
      Anders K. Pedersen 提交于
      Introduces an nftables rt expression for routing related data with support
      for nexthop (i.e. the directly connected IP address that an outgoing packet
      is sent to), which can be used either for matching or accounting, eg.
      
       # nft add rule filter postrouting \
      	ip daddr 192.168.1.0/24 rt nexthop != 192.168.0.1 drop
      
      This will drop any traffic to 192.168.1.0/24 that is not routed via
      192.168.0.1.
      
       # nft add rule filter postrouting \
      	flow table acct { rt nexthop timeout 600s counter }
       # nft add rule ip6 filter postrouting \
      	flow table acct { rt nexthop timeout 600s counter }
      
      These rules count outgoing traffic per nexthop. Note that the timeout
      releases an entry if no traffic is seen for this nexthop within 10 minutes.
      
       # nft add rule inet filter postrouting \
      	ether type ip \
      	flow table acct { rt nexthop timeout 600s counter }
       # nft add rule inet filter postrouting \
      	ether type ip6 \
      	flow table acct { rt nexthop timeout 600s counter }
      
      Same as above, but via the inet family, where the ether type must be
      specified explicitly.
      
      "rt classid" is also implemented identical to "meta rtclassid", since it
      is more logical to have this match in the routing expression going forward.
      Signed-off-by: NAnders K. Pedersen <akp@cohaesio.com>
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      2fa84193
    • P
      netfilter: move socket lookup infrastructure to nf_socket_ipv{4,6}.c · 8db4c5be
      Pablo Neira Ayuso 提交于
      We need this split to reuse existing codebase for the upcoming nf_tables
      socket expression.
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      8db4c5be
    • P
      netfilter: nf_log: add packet logging for netdev family · 1fddf4ba
      Pablo Neira Ayuso 提交于
      Move layer 2 packet logging into nf_log_l2packet() that resides in
      nf_log_common.c, so this can be shared by both bridge and netdev
      families.
      
      This patch adds the boiler plate code to register the netdev logging
      family.
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      1fddf4ba
    • F
      netfilter: nf_tables: add fib expression · f6d0cbcf
      Florian Westphal 提交于
      Add FIB expression, supported for ipv4, ipv6 and inet family (the latter
      just dispatches to ipv4 or ipv6 one based on nfproto).
      
      Currently supports fetching output interface index/name and the
      rtm_type associated with an address.
      
      This can be used for adding path filtering. rtm_type is useful
      to e.g. enforce a strong-end host model where packets
      are only accepted if daddr is configured on the interface the
      packet arrived on.
      
      The fib expression is a native nftables alternative to the
      xtables addrtype and rp_filter matches.
      
      FIB result order for oif/oifname retrieval is as follows:
       - if packet is local (skb has rtable, RTF_LOCAL set, this
         will also catch looped-back multicast packets), set oif to
         the loopback interface.
       - if fib lookup returns an error, or result points to local,
         store zero result.  This means '--local' option of -m rpfilter
         is not supported. It is possible to use 'fib type local' or add
         explicit saddr/daddr matching rules to create exceptions if this
         is really needed.
       - store result in the destination register.
         In case of multiple routes, search set for desired oif in case
         strict matching is requested.
      
      ipv4 and ipv6 behave fib expressions are supposed to behave the same.
      
      [ I have collapsed Arnd Bergmann's ("netfilter: nf_tables: fib warnings")
      
      	http://patchwork.ozlabs.org/patch/688615/
      
        to address fallout from this patch after rebasing nf-next, that was
        posted to address compilation warnings. --pablo ]
      Signed-off-by: NFlorian Westphal <fw@strlen.de>
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      f6d0cbcf
  9. 22 8月, 2016 2 次提交
    • L
      netfilter: nf_tables: add number generator expression · 91dbc6be
      Laura Garcia Liebana 提交于
      This patch adds the numgen expression that allows us to generated
      incremental and random numbers, this generator is bound to a upper limit
      that is specified by userspace.
      
      This expression is useful to distribute packets in a round-robin fashion
      as well as randomly.
      Signed-off-by: NLaura Garcia Liebana <nevola@gmail.com>
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      91dbc6be
    • P
      netfilter: nf_tables: add quota expression · 3d2f30a1
      Pablo Neira Ayuso 提交于
      This patch adds the quota expression. This new stateful expression
      integrate easily into the dynset expression to build 'hashquota' flow
      tables.
      
      Arguably, we could use instead "counter bytes > 1000" instead, but this
      approach has several problems:
      
      1) We only support for one single stateful expression in dynamic set
         definitions, and the expression above is a composite of two
         expressions: get counter + comparison.
      
      2) We would need to restore the packed counter representation (that we
         used to have) based on seqlock to synchronize this, since per-cpu is
         not suitable for this.
      
      So instead of bloating the counter expression back with the seqlock
      representation and extending the existing set infrastructure to make it
      more complex for the composite described above, let's follow the more
      simple approach of adding a quota expression that we can plug into our
      existing infrastructure.
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      3d2f30a1
  10. 12 8月, 2016 2 次提交
  11. 01 7月, 2016 1 次提交
  12. 08 2月, 2016 1 次提交
    • A
      netfilter: tee: select NF_DUP_IPV6 unconditionally · 08a7f5d3
      Arnd Bergmann 提交于
      The NETFILTER_XT_TARGET_TEE option selects NF_DUP_IPV6 whenever
      IP6_NF_IPTABLES is enabled, and it ensures that it cannot be
      builtin itself if NF_CONNTRACK is a loadable module, as that
      is a dependency for NF_DUP_IPV6.
      
      However, NF_DUP_IPV6 can be enabled even if IP6_NF_IPTABLES is
      turned off, and it only really depends on IPV6. With the current
      check in tee_tg6, we call nf_dup_ipv6() whenever NF_DUP_IPV6
      is enabled. This can however be a loadable module which is
      unreachable from a built-in xt_TEE:
      
      net/built-in.o: In function `tee_tg6':
      :(.text+0x67728): undefined reference to `nf_dup_ipv6'
      
      The bug was originally introduced in the split of the xt_TEE module
      into separate modules for ipv4 and ipv6, and two patches tried
      to fix it unsuccessfully afterwards.
      
      This is a revert of the the first incorrect attempt to fix it,
      going back to depending on IPV6 as the dependency, and we
      adapt the 'select' condition accordingly.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Fixes: bbde9fc1 ("netfilter: factor out packet duplication for IPv4/IPv6")
      Fixes: 116984a3 ("netfilter: xt_TEE: use IS_ENABLED(CONFIG_NF_DUP_IPV6)")
      Fixes: 74ec4d55 ("netfilter: fix xt_TEE and xt_TPROXY dependencies")
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      08a7f5d3
  13. 05 1月, 2016 1 次提交
  14. 04 1月, 2016 1 次提交
  15. 11 11月, 2015 1 次提交
    • A
      netfilter: fix xt_TEE and xt_TPROXY dependencies · 74ec4d55
      Arnd Bergmann 提交于
      Kconfig is too smart for its own good: a Kconfig line that states
      
      	select NF_DEFRAG_IPV6 if IP6_NF_IPTABLES
      
      means that if IP6_NF_IPTABLES is set to 'm', then NF_DEFRAG_IPV6 will
      also be set to 'm', regardless of the state of the symbol from which
      it is selected. When the xt_TEE driver is built-in and nothing else
      forces NF_DEFRAG_IPV6 to be built-in, this causes a link-time error:
      
      net/built-in.o: In function `tee_tg6':
      net/netfilter/xt_TEE.c:46: undefined reference to `nf_dup_ipv6'
      
      This works around that behavior by changing the dependency to
      'if IP6_NF_IPTABLES != n', which is interpreted as boolean expression
      rather than a tristate and causes the NF_DEFRAG_IPV6 symbol to
      be built-in as well.
      
      The bug only occurs once in thousands of 'randconfig' builds and
      does not really impact real users. From inspecting the other
      surrounding Kconfig symbols, I am guessing that NETFILTER_XT_TARGET_TPROXY
      and NETFILTER_XT_MATCH_SOCKET have the same issue. If not, this
      change should still be harmless.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      74ec4d55
  16. 05 10月, 2015 2 次提交
  17. 07 8月, 2015 1 次提交
  18. 15 6月, 2015 1 次提交
  19. 27 5月, 2015 2 次提交
  20. 16 5月, 2015 1 次提交
  21. 14 5月, 2015 1 次提交
    • P
      netfilter: add netfilter ingress hook after handle_ing() under unique static key · e687ad60
      Pablo Neira 提交于
      This patch adds the Netfilter ingress hook just after the existing tc ingress
      hook, that seems to be the consensus solution for this.
      
      Note that the Netfilter hook resides under the global static key that enables
      ingress filtering. Nonetheless, Netfilter still also has its own static key for
      minimal impact on the existing handle_ing().
      
      * Without this patch:
      
      Result: OK: 6216490(c6216338+d152) usec, 100000000 (60byte,0frags)
        16086246pps 7721Mb/sec (7721398080bps) errors: 100000000
      
          42.46%  kpktgend_0   [kernel.kallsyms]   [k] __netif_receive_skb_core
          25.92%  kpktgend_0   [kernel.kallsyms]   [k] kfree_skb
           7.81%  kpktgend_0   [pktgen]            [k] pktgen_thread_worker
           5.62%  kpktgend_0   [kernel.kallsyms]   [k] ip_rcv
           2.70%  kpktgend_0   [kernel.kallsyms]   [k] netif_receive_skb_internal
           2.34%  kpktgend_0   [kernel.kallsyms]   [k] netif_receive_skb_sk
           1.44%  kpktgend_0   [kernel.kallsyms]   [k] __build_skb
      
      * With this patch:
      
      Result: OK: 6214833(c6214731+d101) usec, 100000000 (60byte,0frags)
        16090536pps 7723Mb/sec (7723457280bps) errors: 100000000
      
          41.23%  kpktgend_0      [kernel.kallsyms]  [k] __netif_receive_skb_core
          26.57%  kpktgend_0      [kernel.kallsyms]  [k] kfree_skb
           7.72%  kpktgend_0      [pktgen]           [k] pktgen_thread_worker
           5.55%  kpktgend_0      [kernel.kallsyms]  [k] ip_rcv
           2.78%  kpktgend_0      [kernel.kallsyms]  [k] netif_receive_skb_internal
           2.06%  kpktgend_0      [kernel.kallsyms]  [k] netif_receive_skb_sk
           1.43%  kpktgend_0      [kernel.kallsyms]  [k] __build_skb
      
      * Without this patch + tc ingress:
      
              tc filter add dev eth4 parent ffff: protocol ip prio 1 \
                      u32 match ip dst 4.3.2.1/32
      
      Result: OK: 9269001(c9268821+d179) usec, 100000000 (60byte,0frags)
        10788648pps 5178Mb/sec (5178551040bps) errors: 100000000
      
          40.99%  kpktgend_0   [kernel.kallsyms]  [k] __netif_receive_skb_core
          17.50%  kpktgend_0   [kernel.kallsyms]  [k] kfree_skb
          11.77%  kpktgend_0   [cls_u32]          [k] u32_classify
           5.62%  kpktgend_0   [kernel.kallsyms]  [k] tc_classify_compat
           5.18%  kpktgend_0   [pktgen]           [k] pktgen_thread_worker
           3.23%  kpktgend_0   [kernel.kallsyms]  [k] tc_classify
           2.97%  kpktgend_0   [kernel.kallsyms]  [k] ip_rcv
           1.83%  kpktgend_0   [kernel.kallsyms]  [k] netif_receive_skb_internal
           1.50%  kpktgend_0   [kernel.kallsyms]  [k] netif_receive_skb_sk
           0.99%  kpktgend_0   [kernel.kallsyms]  [k] __build_skb
      
      * With this patch + tc ingress:
      
              tc filter add dev eth4 parent ffff: protocol ip prio 1 \
                      u32 match ip dst 4.3.2.1/32
      
      Result: OK: 9308218(c9308091+d126) usec, 100000000 (60byte,0frags)
        10743194pps 5156Mb/sec (5156733120bps) errors: 100000000
      
          42.01%  kpktgend_0   [kernel.kallsyms]   [k] __netif_receive_skb_core
          17.78%  kpktgend_0   [kernel.kallsyms]   [k] kfree_skb
          11.70%  kpktgend_0   [cls_u32]           [k] u32_classify
           5.46%  kpktgend_0   [kernel.kallsyms]   [k] tc_classify_compat
           5.16%  kpktgend_0   [pktgen]            [k] pktgen_thread_worker
           2.98%  kpktgend_0   [kernel.kallsyms]   [k] ip_rcv
           2.84%  kpktgend_0   [kernel.kallsyms]   [k] tc_classify
           1.96%  kpktgend_0   [kernel.kallsyms]   [k] netif_receive_skb_internal
           1.57%  kpktgend_0   [kernel.kallsyms]   [k] netif_receive_skb_sk
      
      Note that the results are very similar before and after.
      
      I can see gcc gets the code under the ingress static key out of the hot path.
      Then, on that cold branch, it generates the code to accomodate the netfilter
      ingress static key. My explanation for this is that this reduces the pressure
      on the instruction cache for non-users as the new code is out of the hot path,
      and it comes with minimal impact for tc ingress users.
      
      Using gcc version 4.8.4 on:
      
      Architecture:          x86_64
      CPU op-mode(s):        32-bit, 64-bit
      Byte Order:            Little Endian
      CPU(s):                8
      [...]
      L1d cache:             16K
      L1i cache:             64K
      L2 cache:              2048K
      L3 cache:              8192K
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      Acked-by: NAlexei Starovoitov <ast@plumgrid.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e687ad60
  22. 25 3月, 2015 1 次提交
  23. 06 3月, 2015 1 次提交
  24. 11 2月, 2015 1 次提交