16 Jun, 2012

1 commit

  • There are good reasons to supports helpers in user-space instead:

    * Rapid connection tracking helper development, as developing code
    in user-space is usually faster.

    * Reliability: A buggy helper does not crash the kernel. Moreover,
    we can monitor the helper process and restart it in case of problems.

    * Security: Avoid complex string matching and mangling in kernel-space
    running in privileged mode. Going further, we can even think about
    running user-space helpers as a non-root process.

    * Extensibility: It allows the development of very specific helpers (most
    likely non-standard proprietary protocols) that are very likely not to be
    accepted for mainline inclusion in the form of kernel-space connection
    tracking helpers.

    This patch adds the infrastructure to allow the implementation of
    user-space conntrack helpers by means of the new nfnetlink subsystem
    `nfnetlink_cthelper' and the existing queueing infrastructure
    (nfnetlink_queue).

    I had to add the new hook NF_IP6_PRI_CONNTRACK_HELPER to register
    ipv[4|6]_helper which results from splitting ipv[4|6]_confirm into
    two pieces. This change is required not to break NAT sequence
    adjustment and conntrack confirmation for traffic that is enqueued
    to our user-space conntrack helpers.

    Basic operation, in a few steps:

    1) Register user-space helper by means of `nfct':

    nfct helper add ftp inet tcp

    [ It must be a valid existing helper supported by conntrack-tools ]

    2) Add rules to enable the FTP user-space helper which is
    used to track traffic going to TCP port 21.

    For locally generated packets:

    iptables -I OUTPUT -t raw -p tcp --dport 21 -j CT --helper ftp

    For non-locally generated packets:

    iptables -I PREROUTING -t raw -p tcp --dport 21 -j CT --helper ftp

    3) Run the test conntrackd in helper mode (see example files under
    doc/helper/conntrackd.conf

    conntrackd

    4) Generate FTP traffic going, if everything is OK, then conntrackd
    should create expectations (you can check that with `conntrack':

    conntrack -E expect

    [NEW] 301 proto=6 src=192.168.1.136 dst=130.89.148.12 sport=0 dport=54037 mask-src=255.255.255.255 mask-dst=255.255.255.255 sport=0 dport=65535 master-src=192.168.1.136 master-dst=130.89.148.12 sport=57127 dport=21 class=0 helper=ftp
    [DESTROY] 301 proto=6 src=192.168.1.136 dst=130.89.148.12 sport=0 dport=54037 mask-src=255.255.255.255 mask-dst=255.255.255.255 sport=0 dport=65535 master-src=192.168.1.136 master-dst=130.89.148.12 sport=57127 dport=21 class=0 helper=ftp

    This confirms that our test helper is receiving packets including the
    conntrack information, and adding expectations in kernel-space.

    The user-space helper can also store its private tracking information
    in the conntrack structure in the kernel via the CTA_HELP_INFO. The
    kernel will consider this a binary blob whose layout is unknown. This
    information will be included in the information that is transfered
    to user-space via glue code that integrates nfnetlink_queue and
    ctnetlink.

    Signed-off-by: Pablo Neira Ayuso

    Pablo Neira Ayuso
     

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