1. 28 7月, 2009 1 次提交
    • N
      xfrm: export xfrm garbage collector thresholds via sysctl · a44a4a00
      Neil Horman 提交于
      Export garbage collector thresholds for xfrm[4|6]_dst_ops
      
      Had a problem reported to me recently in which a high volume of ipsec
      connections on a system began reporting ENOBUFS for new connections
      eventually.
      
      It seemed that after about 2000 connections we started being unable to
      create more.  A quick look revealed that the xfrm code used a dst_ops
      structure that limited the gc_thresh value to 1024, and always
      dropped route cache entries after 2x the gc_thresh.
      
      It seems the most direct solution is to export the gc_thresh values in
      the xfrm[4|6] dst_ops as sysctls, like the main routing table does, so
      that higher volumes of connections can be supported.  This patch has
      been tested and allows the reporter to increase their ipsec connection
      volume successfully.
      Reported-by: NJoe Nall <joe@nall.com>
      Signed-off-by: NNeil Horman <nhorman@tuxdriver.com>
      
      ipv4/xfrm4_policy.c |   18 ++++++++++++++++++
      ipv6/xfrm6_policy.c |   18 ++++++++++++++++++
      2 files changed, 36 insertions(+)
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a44a4a00
  2. 04 7月, 2009 1 次提交
  3. 01 2月, 2009 1 次提交
  4. 26 11月, 2008 3 次提交
  5. 12 11月, 2008 1 次提交
  6. 02 11月, 2008 1 次提交
    • N
      xfrm6: handling fragment · 7e3a42a1
      Nicolas Dichtel 提交于
      RFC4301 Section 7.1 says:
      
      "7.1.  Tunnel Mode SAs that Carry Initial and Non-Initial Fragments
      
           All implementations MUST support tunnel mode SAs that are configured
           to pass traffic without regard to port field (or ICMP type/code or
           Mobility Header type) values.  If the SA will carry traffic for
           specified protocols, the selector set for the SA MUST specify the
           port fields (or ICMP type/code or Mobility Header type) as ANY.  An
           SA defined in this fashion will carry all traffic including initial
           and non-initial fragments for the indicated Local/Remote addresses
           and specified Next Layer protocol(s)."
      
      But for IPv6, fragment is treated as a protocol.  This change catches
      protocol transported in fragmented packet.  In IPv4, there is no
      problem.
      Signed-off-by: NNicolas Dichtel <nicolas.dichtel@6wind.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7e3a42a1
  7. 15 8月, 2008 1 次提交
  8. 26 3月, 2008 1 次提交
  9. 25 3月, 2008 1 次提交
  10. 06 3月, 2008 1 次提交
  11. 04 3月, 2008 1 次提交
  12. 01 2月, 2008 1 次提交
  13. 29 1月, 2008 14 次提交
  14. 11 12月, 2007 1 次提交
  15. 18 10月, 2007 3 次提交
    • H
      [IPSEC]: Rename mode to outer_mode and add inner_mode · 13996378
      Herbert Xu 提交于
      This patch adds a new field to xfrm states called inner_mode.  The existing
      mode object is renamed to outer_mode.
      
      This is the first part of an attempt to fix inter-family transforms.  As it
      is we always use the outer family when determining which mode to use.  As a
      result we may end up shoving IPv4 packets into netfilter6 and vice versa.
      
      What we really want is to use the inner family for the first part of outbound
      processing and the outer family for the second part.  For inbound processing
      we'd use the opposite pairing.
      
      I've also added a check to prevent silly combinations such as transport mode
      with inter-family transforms.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      13996378
    • H
      [IPSEC]: Store afinfo pointer in xfrm_mode · 17c2a42a
      Herbert Xu 提交于
      It is convenient to have a pointer from xfrm_state to address-specific
      functions such as the output function for a family.  Currently the
      address-specific policy code calls out to the xfrm state code to get
      those pointers when we could get it in an easier way via the state
      itself.
      
      This patch adds an xfrm_state_afinfo to xfrm_mode (since they're
      address-specific) and changes the policy code to use it.  I've also
      added an owner field to do reference counting on the module providing
      the afinfo even though it isn't strictly necessary today since IPv6
      can't be unloaded yet.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      17c2a42a
    • H
      [IPSEC]: Add missing BEET checks · 1bfcb10f
      Herbert Xu 提交于
      Currently BEET mode does not reinject the packet back into the stack
      like tunnel mode does.  Since BEET should behave just like tunnel mode
      this is incorrect.
      
      This patch fixes this by introducing a flags field to xfrm_mode that
      tells the IPsec code whether it should terminate and reinject the packet
      back into the stack.
      
      It then sets the flag for BEET and tunnel mode.
      
      I've also added a number of missing BEET checks elsewhere where we check
      whether a given mode is a tunnel or not.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1bfcb10f
  16. 11 10月, 2007 2 次提交
  17. 11 7月, 2007 1 次提交
    • M
      [IPV6] MIP6: Loadable module support for MIPv6. · 59fbb3a6
      Masahide NAKAMURA 提交于
      This patch makes MIPv6 loadable module named "mip6".
      
      Here is a modprobe.conf(5) example to load it automatically
      when user application uses XFRM state for MIPv6:
      
      alias xfrm-type-10-43 mip6
      alias xfrm-type-10-60 mip6
      
      Some MIPv6 feature is not included by this modular, however,
      it should not be affected to other features like either IPsec
      or IPv6 with and without the patch.
      We may discuss XFRM, MH (RAW socket) and ancillary data/sockopt
      separately for future work.
      
      Loadable features:
      * MH receiving check (to send ICMP error back)
      * RO header parsing and building (i.e. RH2 and HAO in DSTOPTS)
      * XFRM policy/state database handling for RO
      
      These are NOT covered as loadable:
      * Home Address flags and its rule on source address selection
      * XFRM sub policy (depends on its own kernel option)
      * XFRM functions to receive RO as IPv6 extension header
      * MH sending/receiving through raw socket if user application
        opens it (since raw socket allows to do so)
      * RH2 sending as ancillary data
      * RH2 operation with setsockopt(2)
      Signed-off-by: NMasahide NAKAMURA <nakam@linux-ipv6.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      59fbb3a6
  18. 26 4月, 2007 4 次提交
  19. 27 2月, 2007 1 次提交