27 Aug, 2011

1 commit


25 Mar, 2010

1 commit

  • The order of the IPv6 raw table is currently reversed, that makes impossible
    to use the NOTRACK target in IPv6: for example if someone enters

    ip6tables -t raw -A PREROUTING -p tcp --dport 80 -j NOTRACK

    and if we receive fragmented packets then the first fragment will be
    untracked and thus skip nf_ct_frag6_gather (and conntrack), while all
    subsequent fragments enter nf_ct_frag6_gather and reassembly will never
    successfully be finished.

    Singed-off-by: Jozsef Kadlecsik
    Signed-off-by: Patrick McHardy

    Jozsef Kadlecsik
     

08 Jul, 2008

1 commit


10 Jun, 2008

1 commit


29 Jan, 2008

1 commit

  • The IPv4 and IPv6 hook values are identical, yet some code tries to figure
    out the "correct" value by looking at the address family. Introduce NF_INET_*
    values for both IPv4 and IPv6. The old values are kept in a #ifndef __KERNEL__
    section for userspace compatibility.

    Signed-off-by: Patrick McHardy
    Acked-by: Herbert Xu
    Signed-off-by: David S. Miller

    Patrick McHardy
     

14 Dec, 2006

1 commit


03 Dec, 2006

1 commit


23 Sep, 2006

1 commit


10 Apr, 2006

1 commit


11 Jan, 2006

1 commit


10 Nov, 2005

1 commit

  • 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
    protocol.

    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
    messages

    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
    design

    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: Yasuyuki Kozakai
    Signed-off-by: Harald Welte
    Signed-off-by: Arnaldo Carvalho de Melo

    Yasuyuki Kozakai
     

30 Aug, 2005

3 commits

  • Of this type, mostly:

    CHECK net/ipv6/netfilter.c
    net/ipv6/netfilter.c:96:12: warning: symbol 'ipv6_netfilter_init' was not declared. Should it be static?
    net/ipv6/netfilter.c:101:6: warning: symbol 'ipv6_netfilter_fini' was not declared. Should it be static?

    Signed-off-by: Arnaldo Carvalho de Melo
    Signed-off-by: David S. Miller

    Arnaldo Carvalho de Melo
     
  • The rerouting functionality is required by the core, therefore it has
    to be implemented by the core and not in individual queue handlers.

    Signed-off-by: Harald Welte
    Signed-off-by: David S. Miller

    Harald Welte
     
  • As discussed at netconf'05, we're trying to save every bit in sk_buff.
    The patch below makes sk_buff 8 bytes smaller. I did some basic
    testing on my notebook and it seems to work.

    The only real in-tree user of nfcache was IPVS, who only needs a
    single bit. Unfortunately I couldn't find some other free bit in
    sk_buff to stuff that bit into, so I introduced a separate field for
    them. Maybe the IPVS guys can resolve that to further save space.

    Initially I wanted to shrink pkt_type to three bits (PACKET_HOST and
    alike are only 6 values defined), but unfortunately the bluetooth code
    overloads pkt_type :(

    The conntrack-event-api (out-of-tree) uses nfcache, but Rusty just
    came up with a way how to do it without any skb fields, so it's safe
    to remove it.

    - remove all never-implemented 'nfcache' code
    - don't have ipvs code abuse 'nfcache' field. currently get's their own
    compile-conditional skb->ipvs_property field. IPVS maintainers can
    decide to move this bit elswhere, but nfcache needs to die.
    - remove skb->nfcache field to save 4 bytes
    - move skb->nfctinfo into three unused bits to save further 4 bytes

    Signed-off-by: Harald Welte
    Signed-off-by: David S. Miller

    Harald Welte
     

17 Apr, 2005

1 commit

  • 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!

    Linus Torvalds