1. 20 7月, 2019 2 次提交
    • P
      net: openvswitch: rename flow_stats to sw_flow_stats · aef833c5
      Pablo Neira Ayuso 提交于
      There is a flow_stats structure defined in include/net/flow_offload.h
      and a follow up patch adds #include <net/flow_offload.h> to
      net/sch_generic.h.
      
      This breaks compilation since OVS codebase includes net/sock.h which
      pulls in linux/filter.h which includes net/sch_generic.h.
      
      In file included from ./include/net/sch_generic.h:18:0,
                       from ./include/linux/filter.h:25,
                       from ./include/net/sock.h:59,
                       from ./include/linux/tcp.h:19,
                       from net/openvswitch/datapath.c:24
      
      This definition takes precedence on OVS since it is placed in the
      networking core, so rename flow_stats in OVS to sw_flow_stats since
      this structure is contained in sw_flow.
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      Acked-by: NJiri Pirko <jiri@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      aef833c5
    • A
      netfilter: bridge: make NF_TABLES_BRIDGE tristate · dfee0e99
      Arnd Bergmann 提交于
      The new nft_meta_bridge code fails to link as built-in when NF_TABLES
      is a loadable module.
      
      net/bridge/netfilter/nft_meta_bridge.o: In function `nft_meta_bridge_get_eval':
      nft_meta_bridge.c:(.text+0x1e8): undefined reference to `nft_meta_get_eval'
      net/bridge/netfilter/nft_meta_bridge.o: In function `nft_meta_bridge_get_init':
      nft_meta_bridge.c:(.text+0x468): undefined reference to `nft_meta_get_init'
      nft_meta_bridge.c:(.text+0x49c): undefined reference to `nft_parse_register'
      nft_meta_bridge.c:(.text+0x4cc): undefined reference to `nft_validate_register_store'
      net/bridge/netfilter/nft_meta_bridge.o: In function `nft_meta_bridge_module_exit':
      nft_meta_bridge.c:(.exit.text+0x14): undefined reference to `nft_unregister_expr'
      net/bridge/netfilter/nft_meta_bridge.o: In function `nft_meta_bridge_module_init':
      nft_meta_bridge.c:(.init.text+0x14): undefined reference to `nft_register_expr'
      net/bridge/netfilter/nft_meta_bridge.o:(.rodata+0x60): undefined reference to `nft_meta_get_dump'
      net/bridge/netfilter/nft_meta_bridge.o:(.rodata+0x88): undefined reference to `nft_meta_set_eval'
      
      This can happen because the NF_TABLES_BRIDGE dependency itself is just a
      'bool'.  Make the symbol a 'tristate' instead so Kconfig can propagate the
      dependencies correctly.
      
      Fixes: 30e103fe ("netfilter: nft_meta: move bridge meta keys into nft_meta_bridge")
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      dfee0e99
  2. 19 7月, 2019 11 次提交
  3. 18 7月, 2019 15 次提交
  4. 17 7月, 2019 2 次提交
  5. 16 7月, 2019 10 次提交
    • L
      netfilter: nft_hash: fix symhash with modulus one · 28b1d6ef
      Laura Garcia Liebana 提交于
      The rule below doesn't work as the kernel raises -ERANGE.
      
      nft add rule netdev nftlb lb01 ip daddr set \
      	symhash mod 1 map { 0 : 192.168.0.10 } fwd to "eth0"
      
      This patch allows to use the symhash modulus with one
      element, in the same way that the other types of hashes and
      algorithms that uses the modulus parameter.
      Signed-off-by: NLaura Garcia Liebana <nevola@gmail.com>
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      28b1d6ef
    • F
      netfilter: nf_tables: don't fail when updating base chain policy · b717273d
      Florian Westphal 提交于
      The following nftables test case fails on nf-next:
      
      tests/shell/run-tests.sh tests/shell/testcases/transactions/0011chain_0
      
      The test case contains:
      add chain x y { type filter hook input priority 0; }
      add chain x y { policy drop; }"
      
      The new test
      if (chain->flags ^ flags)
      	return -EOPNOTSUPP;
      
      triggers here, because chain->flags has NFT_BASE_CHAIN set, but flags
      is 0 because no flag attribute was present in the policy update.
      
      Just fetch the current flag settings of a pre-existing chain in case
      userspace did not provide any.
      
      Fixes: c9626a2c ("netfilter: nf_tables: add hardware offload support")
      Signed-off-by: NFlorian Westphal <fw@strlen.de>
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      b717273d
    • F
      netfilter: conntrack: always store window size un-scaled · 959b69ef
      Florian Westphal 提交于
      Jakub Jankowski reported following oddity:
      
      After 3 way handshake completes, timeout of new connection is set to
      max_retrans (300s) instead of established (5 days).
      
      shortened excerpt from pcap provided:
      25.070622 IP (flags [DF], proto TCP (6), length 52)
      10.8.5.4.1025 > 10.8.1.2.80: Flags [S], seq 11, win 64240, [wscale 8]
      26.070462 IP (flags [DF], proto TCP (6), length 48)
      10.8.1.2.80 > 10.8.5.4.1025: Flags [S.], seq 82, ack 12, win 65535, [wscale 3]
      27.070449 IP (flags [DF], proto TCP (6), length 40)
      10.8.5.4.1025 > 10.8.1.2.80: Flags [.], ack 83, win 512, length 0
      
      Turns out the last_win is of u16 type, but we store the scaled value:
      512 << 8 (== 0x20000) becomes 0 window.
      
      The Fixes tag is not correct, as the bug has existed forever, but
      without that change all that this causes might cause is to mistake a
      window update (to-nonzero-from-zero) for a retransmit.
      
      Fixes: fbcd253d ("netfilter: conntrack: lower timeout to RETRANS seconds if window is 0")
      Reported-by: NJakub Jankowski <shasta@toxcorp.com>
      Tested-by: NJakub Jankowski <shasta@toxcorp.com>
      Signed-off-by: NFlorian Westphal <fw@strlen.de>
      Acked-by: NJozsef Kadlecsik <kadlec@blackhole.kfki.hu>
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      959b69ef
    • F
      netfilter: synproxy: fix erroneous tcp mss option · b83329fb
      Fernando Fernandez Mancera 提交于
      Now synproxy sends the mss value set by the user on client syn-ack packet
      instead of the mss value that client announced.
      
      Fixes: 48b1de4c ("netfilter: add SYNPROXY core/target")
      Signed-off-by: NFernando Fernandez Mancera <ffmancera@riseup.net>
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      b83329fb
    • C
      netfilter: nf_tables: fix module autoload for redir · f41828ee
      Christian Hesse 提交于
      Fix expression for autoloading.
      
      Fixes: 5142967a ("netfilter: nf_tables: fix module autoload with inet family")
      Signed-off-by: NChristian Hesse <mail@eworm.de>
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      f41828ee
    • Y
      netfilter: Update obsolete comments referring to ip_conntrack · 05ba4c89
      Yonatan Goldschmidt 提交于
      In 9fb9cbb1 ("[NETFILTER]: Add nf_conntrack subsystem.") the new
      generic nf_conntrack was introduced, and it came to supersede the old
      ip_conntrack.
      
      This change updates (some) of the obsolete comments referring to old
      file/function names of the ip_conntrack mechanism, as well as removes a
      few self-referencing comments that we shouldn't maintain anymore.
      
      I did not update any comments referring to historical actions (e.g,
      comments like "this file was derived from ..." were left untouched, even
      if the referenced file is no longer here).
      Signed-off-by: NYonatan Goldschmidt <yon.goldschmidt@gmail.com>
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      05ba4c89
    • X
      netfilter: nf_conntrack_sip: fix expectation clash · 3c00fb0b
      xiao ruizhu 提交于
      When conntracks change during a dialog, SDP messages may be sent from
      different conntracks to establish expects with identical tuples. In this
      case expects conflict may be detected for the 2nd SDP message and end up
      with a process failure.
      
      The fixing here is to reuse an existing expect who has the same tuple for a
      different conntrack if any.
      
      Here are two scenarios for the case.
      
      1)
               SERVER                   CPE
      
                 |      INVITE SDP       |
            5060 |<----------------------|5060
                 |      100 Trying       |
            5060 |---------------------->|5060
                 |      183 SDP          |
            5060 |---------------------->|5060    ===> Conntrack 1
                 |       PRACK           |
           50601 |<----------------------|5060
                 |    200 OK (PRACK)     |
           50601 |---------------------->|5060
                 |    200 OK (INVITE)    |
            5060 |---------------------->|5060
                 |        ACK            |
           50601 |<----------------------|5060
                 |                       |
                 |<--- RTP stream ------>|
                 |                       |
                 |    INVITE SDP (t38)   |
           50601 |---------------------->|5060    ===> Conntrack 2
      
      With a certain configuration in the CPE, SIP messages "183 with SDP" and
      "re-INVITE with SDP t38" will go through the sip helper to create
      expects for RTP and RTCP.
      
      It is okay to create RTP and RTCP expects for "183", whose master
      connection source port is 5060, and destination port is 5060.
      
      In the "183" message, port in Contact header changes to 50601 (from the
      original 5060). So the following requests e.g. PRACK and ACK are sent to
      port 50601. It is a different conntrack (let call Conntrack 2) from the
      original INVITE (let call Conntrack 1) due to the port difference.
      
      In this example, after the call is established, there is RTP stream but no
      RTCP stream for Conntrack 1, so the RTP expect created upon "183" is
      cleared, and RTCP expect created for Conntrack 1 retains.
      
      When "re-INVITE with SDP t38" arrives to create RTP&RTCP expects, current
      ALG implementation will call nf_ct_expect_related() for RTP and RTCP. The
      expects tuples are identical to those for Conntrack 1. RTP expect for
      Conntrack 2 succeeds in creation as the one for Conntrack 1 has been
      removed. RTCP expect for Conntrack 2 fails in creation because it has
      idential tuples and 'conflict' with the one retained for Conntrack 1. And
      then result in a failure in processing of the re-INVITE.
      
      2)
      
          SERVER A                 CPE
      
             |      REGISTER     |
        5060 |<------------------| 5060  ==> CT1
             |       200         |
        5060 |------------------>| 5060
             |                   |
             |   INVITE SDP(1)   |
        5060 |<------------------| 5060
             | 300(multi choice) |
        5060 |------------------>| 5060                    SERVER B
             |       ACK         |
        5060 |<------------------| 5060
                                        |    INVITE SDP(2)    |
                                   5060 |-------------------->| 5060  ==> CT2
                                        |       100           |
                                   5060 |<--------------------| 5060
                                        | 200(contact changes)|
                                   5060 |<--------------------| 5060
                                        |       ACK           |
                                   5060 |-------------------->| 50601 ==> CT3
                                        |                     |
                                        |<--- RTP stream ---->|
                                        |                     |
                                        |       BYE           |
                                   5060 |<--------------------| 50601
                                        |       200           |
                                   5060 |-------------------->| 50601
             |   INVITE SDP(3)   |
        5060 |<------------------| 5060  ==> CT1
      
      CPE sends an INVITE request(1) to Server A, and creates a RTP&RTCP expect
      pair for this Conntrack 1 (CT1). Server A responds 300 to redirect to
      Server B. The RTP&RTCP expect pairs created on CT1 are removed upon 300
      response.
      
      CPE sends the INVITE request(2) to Server B, and creates an expect pair
      for the new conntrack (due to destination address difference), let call
      CT2. Server B changes the port to 50601 in 200 OK response, and the
      following requests ACK and BYE from CPE are sent to 50601. The call is
      established. There is RTP stream and no RTCP stream. So RTP expect is
      removed and RTCP expect for CT2 retains.
      
      As BYE request is sent from port 50601, it is another conntrack, let call
      CT3, different from CT2 due to the port difference. So the BYE request will
      not remove the RTCP expect for CT2.
      
      Then another outgoing call is made, with the same RTP port being used (not
      definitely but possibly). CPE firstly sends the INVITE request(3) to Server
      A, and tries to create a RTP&RTCP expect pairs for this CT1. In current ALG
      implementation, the RTCP expect for CT1 fails in creation because it
      'conflicts' with the residual one for CT2. As a result the INVITE request
      fails to send.
      Signed-off-by: Nxiao ruizhu <katrina.xiaorz@gmail.com>
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      3c00fb0b
    • M
      netfilter: Fix rpfilter dropping vrf packets by mistake · b575b24b
      Miaohe Lin 提交于
      When firewalld is enabled with ipv4/ipv6 rpfilter, vrf
      ipv4/ipv6 packets will be dropped. Vrf device will pass
      through netfilter hook twice. One with enslaved device
      and another one with l3 master device. So in device may
      dismatch witch out device because out device is always
      enslaved device.So failed with the check of the rpfilter
      and drop the packets by mistake.
      Signed-off-by: NMiaohe Lin <linmiaohe@huawei.com>
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      b575b24b
    • T
      SUNRPC: Skip zero-refcount transports · 163f8821
      Trond Myklebust 提交于
      When looking for the next transport to use for an RPC call, skip those
      that are in the process of being destroyed and that have a zero refcount.
      Signed-off-by: NTrond Myklebust <trond.myklebust@hammerspace.com>
      163f8821
    • T
      SUNRPC: Replace division by multiplication in calculation of queue length · 3cf72922
      Trond Myklebust 提交于
      When checking whether or not a particular xprt queue length is shorter
      than the average queue length for all xprts, prefer to use multiplication
      rather than division for performance reasons.
      Signed-off-by: NTrond Myklebust <trond.myklebust@hammerspace.com>
      3cf72922
新手
引导
客服 返回
顶部