1. 22 Feb, 2009 1 commit
  2. 25 Nov, 2008 1 commit
  3. 04 Nov, 2008 1 commit
  4. 26 Mar, 2008 1 commit
    • Herbert Xu's avatar
      [IPSEC]: Fix BEET output · 732c8bd5
      Herbert Xu authored
      
      The IPv6 BEET output function is incorrectly including the inner
      header in the payload to be protected.  This causes a crash as
      the packet doesn't actually have that many bytes for a second
      header.
      
      The IPv4 BEET output on the other hand is broken when it comes
      to handling an inner IPv6 header since it always assumes an
      inner IPv4 header.
      
      This patch fixes both by making sure that neither BEET output
      function touches the inner header at all.  All access is now
      done through the protocol-independent cb structure.  Two new
      attributes are added to make this work, the IP header length
      and the IPv4 option length.  They're filled in by the inner
      mode's output function.
      
      Thanks to Joakim Koskela for finding this problem.
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      732c8bd5
  5. 24 Mar, 2008 1 commit
  6. 28 Jan, 2008 8 commits
  7. 18 Oct, 2007 2 commits
    • Herbert Xu's avatar
      [IPSEC]: Store afinfo pointer in xfrm_mode · 17c2a42a
      Herbert Xu authored
      
      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: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      17c2a42a
    • Herbert Xu's avatar
      [IPSEC]: Add missing BEET checks · 1bfcb10f
      Herbert Xu authored
      
      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: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1bfcb10f
  8. 11 Jul, 2007 1 commit
    • Masahide NAKAMURA's avatar
      [IPV6] MIP6: Loadable module support for MIPv6. · 59fbb3a6
      Masahide NAKAMURA authored
      
      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: default avatarMasahide NAKAMURA <nakam@linux-ipv6.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      59fbb3a6
  9. 11 Feb, 2007 1 commit
  10. 08 Feb, 2007 1 commit
  11. 28 Sep, 2006 1 commit
  12. 22 Sep, 2006 8 commits
  13. 18 Jun, 2006 1 commit
    • Herbert Xu's avatar
      [IPSEC] xfrm: Undo afinfo lock proliferation · 546be240
      Herbert Xu authored
      
      The number of locks used to manage afinfo structures can easily be reduced
      down to one each for policy and state respectively.  This is based on the
      observation that the write locks are only held by module insertion/removal
      which are very rare events so there is no need to further differentiate
      between the insertion of modules like ipv6 versus esp6.
      
      The removal of the read locks in xfrm4_policy.c/xfrm6_policy.c might look
      suspicious at first.  However, after you realise that nobody ever takes
      the corresponding write lock you'll feel better :)
      
      As far as I can gather it's an attempt to guard against the removal of
      the corresponding modules.  Since neither module can be unloaded at all
      we can leave it to whoever fixes up IPv6 unloading :)
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      546be240
  14. 13 Jan, 2006 1 commit
  15. 16 Apr, 2005 1 commit
    • Linus Torvalds's avatar
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds authored
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4