30 Sep, 2015

2 commits


28 Aug, 2015

1 commit

  • When CONFIG_OPENVSWITCH is set, and CONFIG_NETFILTER is not set, the
    openvswitch IPv6 fragmentation handling cannot refer to ipv6_ops because
    it isn't defined. Add a dummy version to avoid #ifdefs in source files.

    Fixes: 7f8a436 "openvswitch: Add conntrack action"
    Signed-off-by: Joe Stringer
    Signed-off-by: David S. Miller

    Joe Stringer
     

12 Jun, 2015

2 commits

  • IPv6 fragmented packets are not forwarded on an ethernet bridge
    with netfilter ip6_tables loaded. e.g. steps to reproduce

    1) create a simple bridge like this

    modprobe br_netfilter
    brctl addbr br0
    brctl addif br0 eth0
    brctl addif br0 eth2
    ifconfig eth0 up
    ifconfig eth2 up
    ifconfig br0 up

    2) place a host with an IPv6 address on each side of the bridge

    set IPv6 address on host A:
    ip -6 addr add fd01:2345:6789:1::1/64 dev eth0

    set IPv6 address on host B:
    ip -6 addr add fd01:2345:6789:1::2/64 dev eth0

    3) run a simple ping command on host A with packets > MTU

    ping6 -s 4000 fd01:2345:6789:1::2

    4) wait some time and run e.g. "ip6tables -t nat -nvL" on the bridge

    IPv6 fragmented packets traverse the bridge cleanly until somebody runs.
    "ip6tables -t nat -nvL". As soon as it is run (and netfilter modules are
    loaded) IPv6 fragmented packets do not traverse the bridge any more (you
    see no more responses in ping's output).

    After applying this patch IPv6 fragmented packets traverse the bridge
    cleanly in above scenario.

    Signed-off-by: Bernhard Thaler
    [pablo@netfilter.org: small changes to br_nf_dev_queue_xmit]
    Signed-off-by: Pablo Neira Ayuso

    Bernhard Thaler
     
  • IPv4 iptables allows to REDIRECT/DNAT/SNAT any traffic over a bridge.

    e.g. REDIRECT
    $ sysctl -w net.bridge.bridge-nf-call-iptables=1
    $ iptables -t nat -A PREROUTING -p tcp -m tcp --dport 8080 \
    -j REDIRECT --to-ports 81

    This does not work with ip6tables on a bridge in NAT66 scenario
    because the REDIRECT/DNAT/SNAT is not correctly detected.

    The bridge pre-routing (finish) netfilter hook has to check for a possible
    redirect and then fix the destination mac address. This allows to use the
    ip6tables rules for local REDIRECT/DNAT/SNAT REDIRECT similar to the IPv4
    iptables version.

    e.g. REDIRECT
    $ sysctl -w net.bridge.bridge-nf-call-ip6tables=1
    $ ip6tables -t nat -A PREROUTING -p tcp -m tcp --dport 8080 \
    -j REDIRECT --to-ports 81

    This patch makes it possible to use IPv6 NAT66 on a bridge. It was tested
    on a bridge with two interfaces using SNAT/DNAT NAT66 rules.

    Reported-by: Artie Hamilton
    Signed-off-by: Sven Eckelmann
    [bernhard.thaler@wvnet.at: rebased, add indirect call to ip6_route_input()]
    [bernhard.thaler@wvnet.at: rebased, split into separate patches]
    Signed-off-by: Bernhard Thaler
    Signed-off-by: Pablo Neira Ayuso

    Bernhard Thaler
     

27 Sep, 2013

1 commit

  • There are a mix of function prototypes with and without extern
    in the kernel sources. Standardize on not using extern for
    function prototypes.

    Function prototypes don't need to be written with extern.
    extern is assumed by the compiler. Its use is as unnecessary as
    using auto to declare automatic/local variables in a block.

    Signed-off-by: Joe Perches

    Joe Perches
     

23 May, 2013

1 commit

  • Quoting https://bugzilla.netfilter.org/show_bug.cgi?id=812:

    [ ip6tables -m addrtype ]
    When I tried to use in the nat/PREROUTING it messes up the
    routing cache even if the rule didn't matched at all.
    [..]
    If I remove the --limit-iface-in from the non-working scenario, so just
    use the -m addrtype --dst-type LOCAL it works!

    This happens when LOCAL type matching is requested with --limit-iface-in,
    and the default ipv6 route is via the interface the packet we test
    arrived on.

    Because xt_addrtype uses ip6_route_output, the ipv6 routing implementation
    creates an unwanted cached entry, and the packet won't make it to the
    real/expected destination.

    Silently ignoring --limit-iface-in makes the routing work but it breaks
    rule matching (--dst-type LOCAL with limit-iface-in is supposed to only
    match if the dst address is configured on the incoming interface;
    without --limit-iface-in it will match if the address is reachable
    via lo).

    The test should call ipv6_chk_addr() instead. However, this would add
    a link-time dependency on ipv6.

    There are two possible solutions:

    1) Revert the commit that moved ipt_addrtype to xt_addrtype,
    and put ipv6 specific code into ip6t_addrtype.
    2) add new "nf_ipv6_ops" struct to register pointers to ipv6 functions.

    While the former might seem preferable, Pablo pointed out that there
    are more xt modules with link-time dependeny issues regarding ipv6,
    so lets go for 2).

    Signed-off-by: Florian Westphal
    Signed-off-by: Pablo Neira Ayuso

    Florian Westphal
     

13 Oct, 2012

1 commit


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