1. 20 Mar, 2006 2 commits
  2. 12 Mar, 2006 1 commit
  3. 24 Feb, 2006 1 commit
  4. 09 Jan, 2006 1 commit
  5. 03 Jan, 2006 1 commit
  6. 29 Nov, 2005 1 commit
  7. 09 Nov, 2005 1 commit
    • Yasuyuki Kozakai's avatar
      [NETFILTER]: Add nf_conntrack subsystem. · 9fb9cbb1
      Yasuyuki Kozakai authored
      The existing connection tracking subsystem in netfilter can only
      handle ipv4.  There were basically two choices present to add
      connection tracking support for ipv6.  We could either duplicate all
      of the ipv4 connection tracking code into an ipv6 counterpart, or (the
      choice taken by these patches) we could design a generic layer that
      could handle both ipv4 and ipv6 and thus requiring only one sub-protocol
      (TCP, UDP, etc.) connection tracking helper module to be written.
      In fact nf_conntrack is capable of working with any layer 3
      The existing ipv4 specific conntrack code could also not deal
      with the pecularities of doing connection tracking on ipv6,
      which is also cured here.  For example, these issues include:
      1) ICMPv6 handling, which is used for neighbour discovery in
         ipv6 thus some messages such as these should not participate
         in connection tracking since effectively they are like ARP
      2) fragmentation must be handled differently in ipv6, because
         the simplistic "defrag, connection track and NAT, refrag"
         (which the existing ipv4 connection tracking does) approach simply
         isn't feasible in ipv6
      3) ipv6 extension header parsing must occur at the correct spots
         before and after connection tracking decisions, and there were
         no provisions for this in the existing connection tracking
      4) ipv6 has no need for stateful NAT
      The ipv4 specific conntrack layer is kept around, until all of
      the ipv4 specific conntrack helpers are ported over to nf_conntrack
      and it is feature complete.  Once that occurs, the old conntrack
      stuff will get placed into the feature-removal-schedule and we will
      fully kill it off 6 months later.
      Signed-off-by: default avatarYasuyuki Kozakai <yasuyuki.kozakai@toshiba.co.jp>
      Signed-off-by: default avatarHarald Welte <laforge@netfilter.org>
      Signed-off-by: default avatarArnaldo Carvalho de Melo <acme@mandriva.com>
  8. 08 Nov, 2005 1 commit
  9. 28 Oct, 2005 1 commit
    • Ananda Raju's avatar
      [IPv4/IPv6]: UFO Scatter-gather approach · e89e9cf5
      Ananda Raju authored
      Attached is kernel patch for UDP Fragmentation Offload (UFO) feature.
      1. This patch incorporate the review comments by Jeff Garzik.
      2. Renamed USO as UFO (UDP Fragmentation Offload)
      3. udp sendfile support with UFO
      This patches uses scatter-gather feature of skb to generate large UDP
      datagram. Below is a "how-to" on changes required in network device
      driver to use the UFO interface.
      UDP Fragmentation Offload (UFO) Interface:
      UFO is a feature wherein the Linux kernel network stack will offload the
      IP fragmentation functionality of large UDP datagram to hardware. This
      will reduce the overhead of stack in fragmenting the large UDP datagram to
      MTU sized packets
      1) Drivers indicate their capability of UFO using
      dev->features |= NETIF_F_UFO | NETIF_F_HW_CSUM | NETIF_F_SG
      NETIF_F_HW_CSUM is required for UFO over ipv6.
      2) UFO packet will be submitted for transmission using driver xmit routine.
      UFO packet will have a non-zero value for
      skb_shinfo(skb)->ufo_size will indicate the length of data part in each IP
      fragment going out of the adapter after IP fragmentation by hardware.
      skb->data will contain MAC/IP/UDP header and skb_shinfo(skb)->frags[]
      contains the data payload. The skb->ip_summed will be set to CHECKSUM_HW
      indicating that hardware has to do checksum calculation. Hardware should
      compute the UDP checksum of complete datagram and also ip header checksum of
      each fragmented IP packet.
      For IPV6 the UFO provides the fragment identification-id in
      skb_shinfo(skb)->ip6_frag_id. The adapter should use this ID for generating
      IPv6 fragments.
      Signed-off-by: default avatarAnanda Raju <ananda.raju@neterion.com>
      Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> (forwarded)
      Signed-off-by: default avatarArnaldo Carvalho de Melo <acme@mandriva.com>
  10. 03 Oct, 2005 1 commit
  11. 07 Sep, 2005 1 commit
  12. 29 Aug, 2005 4 commits
  13. 27 Jul, 2005 1 commit
  14. 05 Jul, 2005 1 commit
  15. 21 Jun, 2005 1 commit
  16. 18 May, 2005 1 commit
    • Herbert Xu's avatar
      [IPV4/IPV6] Ensure all frag_list members have NULL sk · 2fdba6b0
      Herbert Xu authored
      Having frag_list members which holds wmem of an sk leads to nightmares
      with partially cloned frag skb's.  The reason is that once you unleash
      a skb with a frag_list that has individual sk ownerships into the stack
      you can never undo those ownerships safely as they may have been cloned
      by things like netfilter.  Since we have to undo them in order to make
      skb_linearize happy this approach leads to a dead-end.
      So let's go the other way and make this an invariant:
      	For any skb on a frag_list, skb->sk must be NULL.
      That is, the socket ownership always belongs to the head skb.
      It turns out that the implementation is actually pretty simple.
      The above invariant is actually violated in the following patch
      for a short duration inside ip_fragment.  This is OK because the
      offending frag_list member is either destroyed at the end of the
      slow path without being sent anywhere, or it is detached from
      the frag_list before being sent.
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  17. 19 Apr, 2005 1 commit
  18. 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!