1. 11 7月, 2007 2 次提交
    • J
      [NETFILTER]: x_tables: add TRACE target · ba9dda3a
      Jozsef Kadlecsik 提交于
      The TRACE target can be used to follow IP and IPv6 packets through
      the ruleset.
      Signed-off-by: NJozsef Kadlecsik <kadlec@blackhole.kfki.hu>
      Signed-off-by: NPatrick NcHardy <kaber@trash.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ba9dda3a
    • 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
  2. 11 5月, 2007 1 次提交
  3. 26 4月, 2007 19 次提交
  4. 11 2月, 2007 1 次提交
  5. 09 12月, 2006 1 次提交
  6. 07 12月, 2006 1 次提交
  7. 03 12月, 2006 5 次提交
  8. 23 9月, 2006 8 次提交
  9. 14 8月, 2006 1 次提交
    • H
      [INET]: Use pskb_trim_unique when trimming paged unique skbs · e9fa4f7b
      Herbert Xu 提交于
      The IPv4/IPv6 datagram output path was using skb_trim to trim paged
      packets because they know that the packet has not been cloned yet
      (since the packet hasn't been given to anything else in the system).
      
      This broke because skb_trim no longer allows paged packets to be
      trimmed.  Paged packets must be given to one of the pskb_trim functions
      instead.
      
      This patch adds a new pskb_trim_unique function to cover the IPv4/IPv6
      datagram output path scenario and replaces the corresponding skb_trim
      calls with it.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e9fa4f7b
  10. 03 8月, 2006 1 次提交
    • W
      [IPV6]: SNMPv2 "ipv6IfStatsOutFragCreates" counter error · dafee490
      Wei Dong 提交于
        When I tested linux kernel 2.6.71.7 about statistics
      "ipv6IfStatsOutFragCreates", and found that it couldn't increase
      correctly. The criteria is RFC 2465:
      
        ipv6IfStatsOutFragCreates OBJECT-TYPE
            SYNTAX      Counter32
            MAX-ACCESS  read-only
            STATUS      current
            DESCRIPTION
               "The number of output datagram fragments that have
               been generated as a result of fragmentation at
               this output interface."
            ::= { ipv6IfStatsEntry 15 }
      
      I think there are two issues in Linux kernel. 
      1st:
      RFC2465 specifies the counter is "The number of output datagram
      fragments...". I think increasing this counter after output a fragment
      successfully is better. And it should not be increased even though a
      fragment is created but failed to output.
      
      2nd:
      If we send a big ICMP/ICMPv6 echo request to a host, and receive
      ICMP/ICMPv6 echo reply consisted of some fragments. As we know that in
      Linux kernel first fragmentation occurs in ICMP layer(maybe saying
      transport layer is better), but this is not the "real"
      fragmentation,just do some "pre-fragment" -- allocate space for date,
      and form a frag_list, etc. The "real" fragmentation happens in IP layer
      -- set offset and MF flag and so on. So I think in "fast path" for
      ip_fragment/ip6_fragment, if we send a fragment which "pre-fragment" by
      upper layer we should also increase "ipv6IfStatsOutFragCreates".
      Signed-off-by: NWei Dong <weid@nanjing-fnst.com>
      Acked-by: NYOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      dafee490