1. 07 10月, 2009 3 次提交
    • O
      make TLLAO option for NA packets configurable · f7734fdf
      Octavian Purdila 提交于
      On Friday 02 October 2009 20:53:51 you wrote:
      
      > This is good although I would have shortened the name.
      
      Ah, I knew I forgot something :) Here is v4.
      
      tavi
      
      >From 24d96d825b9fa832b22878cc6c990d5711968734 Mon Sep 17 00:00:00 2001
      From: Octavian Purdila <opurdila@ixiacom.com>
      Date: Fri, 2 Oct 2009 00:51:15 +0300
      Subject: [PATCH] ipv6: new sysctl for sending TLLAO with unicast NAs
      
      Neighbor advertisements responding to unicast neighbor solicitations
      did not include the target link-layer address option. This patch adds
      a new sysctl option (disabled by default) which controls whether this
      option should be sent even with unicast NAs.
      
      The need for this arose because certain routers expect the TLLAO in
      some situations even as a response to unicast NS packets.
      
      Moreover, RFC 2461 recommends sending this to avoid a race condition
      (section 4.4, Target link-layer address)
      Signed-off-by: NCosmin Ratiu <cratiu@ixiacom.com>
      Signed-off-by: NOctavian Purdila <opurdila@ixiacom.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f7734fdf
    • B
      Use sk_mark for IPv6 routing lookups · 51953d5b
      Brian Haley 提交于
      Atis Elsts wrote:
      > Not sure if there is need to fill the mark from skb in tunnel xmit functions. In any case, it's not done for GRE or IPIP tunnels at the moment.
      
      Ok, I'll just drop that part, I'm not sure what should be done in this case.
      
      > Also, in this patch you are doing that for SIT (v6-in-v4) tunnels only, and not doing it for v4-in-v6 or v6-in-v6 tunnels. Any reason for that?
      
      I just sent that patch out too quickly, here's a better one with the updates.
      
      Add support for IPv6 route lookups using sk_mark.
      Signed-off-by: NBrian Haley <brian.haley@hp.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      51953d5b
    • Y
      ipv6 sit: 6rd (IPv6 Rapid Deployment) Support. · fa857afc
      YOSHIFUJI Hideaki / 吉藤英明 提交于
      IPv6 Rapid Deployment (6rd; draft-ietf-softwire-ipv6-6rd) builds upon
      mechanisms of 6to4 (RFC3056) to enable a service provider to rapidly
      deploy IPv6 unicast service to IPv4 sites to which it provides
      customer premise equipment.  Like 6to4, it utilizes stateless IPv6 in
      IPv4 encapsulation in order to transit IPv4-only network
      infrastructure.  Unlike 6to4, a 6rd service provider uses an IPv6
      prefix of its own in place of the fixed 6to4 prefix.
      
      With this option enabled, the SIT driver offers 6rd functionality by
      providing additional ioctl API to configure the IPv6 Prefix for in
      stead of static 2002::/16 for 6to4.
      
      Original patch was done by Alexandre Cassen <acassen@freebox.fr>
      based on old Internet-Draft.
      Signed-off-by: NYOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      fa857afc
  2. 05 10月, 2009 1 次提交
    • E
      tunnels: Optimize tx path · 0bfbedb1
      Eric Dumazet 提交于
      We currently dirty a cache line to update tunnel device stats
      (tx_packets/tx_bytes). We better use the txq->tx_bytes/tx_packets
      counters that already are present in cpu cache, in the cache
      line shared with txq->_xmit_lock
      
      This patch extends IPTUNNEL_XMIT() macro to use txq pointer
      provided by the caller.
      
      Also &tunnel->dev->stats can be replaced by &dev->stats
      Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0bfbedb1
  3. 01 10月, 2009 2 次提交
  4. 27 9月, 2009 1 次提交
  5. 25 9月, 2009 1 次提交
  6. 24 9月, 2009 1 次提交
  7. 23 9月, 2009 1 次提交
  8. 18 9月, 2009 1 次提交
  9. 17 9月, 2009 1 次提交
  10. 15 9月, 2009 3 次提交
  11. 12 9月, 2009 1 次提交
  12. 09 9月, 2009 1 次提交
  13. 04 9月, 2009 1 次提交
    • C
      ipv6: Fix tcp_v6_send_response(): it didn't set skb transport header · a8fdf2b3
      Cosmin Ratiu 提交于
      Here is a patch which fixes an issue observed when using TCP over IPv6
      and AH from IPsec.
      
      When a connection gets closed the 4-way method and the last ACK from
      the server gets dropped, the subsequent FINs from the client do not
      get ACKed because tcp_v6_send_response does not set the transport
      header pointer. This causes ah6_output to try to allocate a lot of
      memory, which typically fails, so the ACKs never make it out of the
      stack.
      
      I have reproduced the problem on kernel 2.6.7, but after looking at
      the latest kernel it seems the problem is still there.
      Signed-off-by: NCosmin Ratiu <cratiu@ixiacom.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a8fdf2b3
  14. 03 9月, 2009 2 次提交
    • W
      tcp: replace hard coded GFP_KERNEL with sk_allocation · aa133076
      Wu Fengguang 提交于
      This fixed a lockdep warning which appeared when doing stress
      memory tests over NFS:
      
      	inconsistent {RECLAIM_FS-ON-W} -> {IN-RECLAIM_FS-W} usage.
      
      	page reclaim => nfs_writepage => tcp_sendmsg => lock sk_lock
      
      	mount_root => nfs_root_data => tcp_close => lock sk_lock =>
      			tcp_send_fin => alloc_skb_fclone => page reclaim
      
      David raised a concern that if the allocation fails in tcp_send_fin(), and it's
      GFP_ATOMIC, we are going to yield() (which sleeps) and loop endlessly waiting
      for the allocation to succeed.
      
      But fact is, the original GFP_KERNEL also sleeps. GFP_ATOMIC+yield() looks
      weird, but it is no worse the implicit sleep inside GFP_KERNEL. Both could
      loop endlessly under memory pressure.
      
      CC: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
      CC: David S. Miller <davem@davemloft.net>
      CC: Herbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NWu Fengguang <fengguang.wu@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      aa133076
    • E
      ip: Report qdisc packet drops · 6ce9e7b5
      Eric Dumazet 提交于
      Christoph Lameter pointed out that packet drops at qdisc level where not
      accounted in SNMP counters. Only if application sets IP_RECVERR, drops
      are reported to user (-ENOBUFS errors) and SNMP counters updated.
      
      IP_RECVERR is used to enable extended reliable error message passing,
      but these are not needed to update system wide SNMP stats.
      
      This patch changes things a bit to allow SNMP counters to be updated,
      regardless of IP_RECVERR being set or not on the socket.
      
      Example after an UDP tx flood
      # netstat -s 
      ...
      IP:
          1487048 outgoing packets dropped
      ...
      Udp:
      ...
          SndbufErrors: 1487048
      
      
      send() syscalls, do however still return an OK status, to not
      break applications.
      
      Note : send() manual page explicitly says for -ENOBUFS error :
      
       "The output queue for a network interface was full.
        This generally indicates that the interface has stopped sending,
        but may be caused by transient congestion.
        (Normally, this does not occur in Linux. Packets are just silently
        dropped when a device queue overflows.) "
      
      This is not true for IP_RECVERR enabled sockets : a send() syscall
      that hit a qdisc drop returns an ENOBUFS error.
      
      Many thanks to Christoph, David, and last but not least, Alexey !
      Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6ce9e7b5
  15. 02 9月, 2009 7 次提交
  16. 01 9月, 2009 1 次提交
  17. 31 8月, 2009 1 次提交
  18. 29 8月, 2009 2 次提交
    • D
      ipv6: Update Neighbor Cache when IPv6 RA is received on a router · 31ce8c71
      David Ward 提交于
      When processing a received IPv6 Router Advertisement, the kernel
      creates or updates an IPv6 Neighbor Cache entry for the sender --
      but presently this does not occur if IPv6 forwarding is enabled
      (net.ipv6.conf.*.forwarding = 1), or if IPv6 Router Advertisements
      are not accepted (net.ipv6.conf.*.accept_ra = 0), because in these
      cases processing of the Router Advertisement has already halted.
      
      This patch allows the Neighbor Cache to be updated in these cases,
      while still avoiding any modification to routes or link parameters.
      
      This continues to satisfy RFC 4861, since any entry created in the
      Neighbor Cache as the result of a received Router Advertisement is
      still placed in the STALE state.
      Signed-off-by: NDavid Ward <david.ward@ll.mit.edu>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      31ce8c71
    • S
      sit: allow ip fragmentation when using nopmtudisc to fix package loss · 8945a808
      Sascha Hlusiak 提交于
      if tunnel parameters have frag_off set to IP_DF, pmtudisc on the ipv4 link
      will be performed by deriving the mtu from the ipv4 link and setting the
      DF-Flag of the encapsulating IPv4 Header. If fragmentation is needed on the
      way, the IPv4 pmtu gets adjusted, the ipv6 package will be resent eventually,
      using the new and lower mtu and everyone is happy.
      
      If the frag_off parameter is unset, the mtu for the tunnel will be derived
      from the tunnel device or the ipv6 pmtu, which might be higher than the ipv4
      pmtu. In that case we must allow the fragmentation of the IPv4 packet because
      the IPv6 mtu wouldn't 'learn' from the adjusted IPv4 pmtu, resulting in
      frequent icmp_frag_needed and package loss on the IPv6 layer.
      
      This patch allows fragmentation when tunnel was created with parameter
      nopmtudisc, like in ipip/gre tunnels.
      Signed-off-by: NSascha Hlusiak <contact@saschahlusiak.de>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8945a808
  19. 25 8月, 2009 1 次提交
  20. 24 8月, 2009 2 次提交
    • J
      netfilter: xtables: mark initial tables constant · 35aad0ff
      Jan Engelhardt 提交于
      The inputted table is never modified, so should be considered const.
      Signed-off-by: NJan Engelhardt <jengelh@medozas.de>
      Signed-off-by: NPatrick McHardy <kaber@trash.net>
      35aad0ff
    • B
      ipv6: Fix commit 63d9950b (ipv6: Make... · ca6982b8
      Bruno Prémont 提交于
      ipv6: Fix commit 63d9950b (ipv6: Make v4-mapped bindings consistent with IPv4)
      
      Commit 63d9950b
        (ipv6: Make v4-mapped bindings consistent with IPv4)
      changes behavior of inet6_bind() for v4-mapped addresses so it should
      behave the same way as inet_bind().
      
      During this change setting of err to -EADDRNOTAVAIL got lost:
      
      af_inet.c:469 inet_bind()
      	err = -EADDRNOTAVAIL;
      	if (!sysctl_ip_nonlocal_bind &&
      	    !(inet->freebind || inet->transparent) &&
      	    addr->sin_addr.s_addr != htonl(INADDR_ANY) &&
      	    chk_addr_ret != RTN_LOCAL &&
      	    chk_addr_ret != RTN_MULTICAST &&
      	    chk_addr_ret != RTN_BROADCAST)
      		goto out;
      
      
      af_inet6.c:463 inet6_bind()
      	if (addr_type == IPV6_ADDR_MAPPED) {
      		int chk_addr_ret;
      
      		/* Binding to v4-mapped address on a v6-only socket                         
      		 * makes no sense                                                           
      		 */
      		if (np->ipv6only) {
      			err = -EINVAL;
      			goto out; 
      		}
      
      		/* Reproduce AF_INET checks to make the bindings consitant */               
      		v4addr = addr->sin6_addr.s6_addr32[3];                                      
      		chk_addr_ret = inet_addr_type(net, v4addr);                                 
      		if (!sysctl_ip_nonlocal_bind &&                                             
      		    !(inet->freebind || inet->transparent) &&                               
      		    v4addr != htonl(INADDR_ANY) &&
      		    chk_addr_ret != RTN_LOCAL &&                                            
      		    chk_addr_ret != RTN_MULTICAST &&                                        
      		    chk_addr_ret != RTN_BROADCAST)
      			goto out;
      	} else {
      
      
      Signed-off-by Bruno Prémont <bonbons@linux-vserver.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ca6982b8
  21. 14 8月, 2009 3 次提交
  22. 10 8月, 2009 3 次提交
    • J
      netfilter: xtables: check for standard verdicts in policies · e2fe35c1
      Jan Engelhardt 提交于
      This adds the second check that Rusty wanted to have a long time ago. :-)
      
      Base chain policies must have absolute verdicts that cease processing
      in the table, otherwise rule execution may continue in an unexpected
      spurious fashion (e.g. next chain that follows in memory).
      Signed-off-by: NJan Engelhardt <jengelh@medozas.de>
      e2fe35c1
    • J
      netfilter: xtables: check for unconditionality of policies · 90e7d4ab
      Jan Engelhardt 提交于
      This adds a check that iptables's original author Rusty set forth in
      a FIXME comment.
      
      Underflows in iptables are better known as chain policies, and are
      required to be unconditional or there would be a stochastical chance
      for the policy rule to be skipped if it does not match. If that were
      to happen, rule execution would continue in an unexpected spurious
      fashion.
      Signed-off-by: NJan Engelhardt <jengelh@medozas.de>
      90e7d4ab
    • J
      netfilter: xtables: ignore unassigned hooks in check_entry_size_and_hooks · a7d51738
      Jan Engelhardt 提交于
      The "hook_entry" and "underflow" array contains values even for hooks
      not provided, such as PREROUTING in conjunction with the "filter"
      table. Usually, the values point to whatever the next rule is. For
      the upcoming unconditionality and underflow checking patches however,
      we must not inspect that arbitrary rule.
      
      Skipping unassigned hooks seems like a good idea, also because
      newinfo->hook_entry and newinfo->underflow will then continue to have
      the poison value for detecting abnormalities.
      Signed-off-by: NJan Engelhardt <jengelh@medozas.de>
      a7d51738