1. 03 3月, 2009 2 次提交
    • D
      netns: fix addrconf_ifdown kernel panic · 176c39af
      Daniel Lezcano 提交于
      When a network namespace is destroyed the network interfaces are
      all unregistered, making addrconf_ifdown called by the netdevice
      notifier. 
      In the other hand, the addrconf exit method does a loop on the network
      devices and does addrconf_ifdown on each of them. But the ordering of 
      the netns subsystem is not right because it uses the register_pernet_device
      instead of register_pernet_subsys. If we handle the loopback as
      any network device, we can safely use register_pernet_subsys.
      
      But if we use register_pernet_subsys, the addrconf exit method will do
      exactly what was already done with the unregistering of the network
      devices. So in definitive, this code is pointless.
      
      I removed the netns addrconf exit method and moved the code to the
      addrconf cleanup function.
      Signed-off-by: NDaniel Lezcano <dlezcano@fr.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      176c39af
    • S
      ipv6: Fix sysctl unregistration deadlock · b325fddb
      Stephen Hemminger 提交于
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b325fddb
  2. 26 2月, 2009 1 次提交
  3. 18 2月, 2009 1 次提交
  4. 10 2月, 2009 3 次提交
  5. 06 2月, 2009 2 次提交
  6. 31 1月, 2009 1 次提交
  7. 28 1月, 2009 3 次提交
    • D
      ipv6: Make mc_forwarding sysctl read-only. · a4e6db07
      David S. Miller 提交于
      The kernel manages this value internally, as necessary, as
      VIFs are added/removed and as multicast routers are registered
      and deregistered.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a4e6db07
    • T
      IPv6: Fix multicast routing bugs. · 1d6e55f1
      Thomas Goff 提交于
      This patch addresses the IPv6 multicast routing issues described
      below.  It was tested with XORP 1.4/1.5 as the IPv6 PIM-SM routing
      daemon against FreeBSD peers.
      
      net/ipv6/ip6_input.c:
      
        - Don't try to forward link-local multicast packets.
      
        - Don't reset skb2->dev before calling ip6_mr_input() so packets can
          be identified as coming from the PIM register vif properly.
      
      net/ipv6/ip6mr.c:
      
        - Fix incoming PIM register messages processing:
      
          * The IPv6 pseudo-header should be included when checksumming PIM
            messages (RFC 4601 section 4.9; RFC 3973 section 4.7.1).
      
          * Packets decapsulated from PIM register messages should have
            skb->protocol ETH_P_IPV6.
      
        - Enable/disable IPv6 multicast forwarding on the corresponding
          interface when a routing daemon adds/removes a multicast virtual
          interface.
      
        - Remove incorrect skb_pull() to fix userspace signaling.
      
        - Enable/disable global IPv6 multicast forwarding when an IPv6
          multicast routing socket is opened/closed.
      
      net/ipv6/route.c:
      
        - Don't use strict routing logic for packets decapsulated from PIM
          register messages (similar to disabling rp_filter for the IPv4
          case).
      Signed-off-by: NThomas Goff <thomas.goff@boeing.com>
      Reviewed-by: NFred Templin <fred.l.templin@boeing.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1d6e55f1
    • J
      net: fix xfrm reverse flow lookup for icmp6 · 6c06a478
      Jiri Pirko 提交于
      This patch fixes the xfrm reverse flow lookup for icmp6 so that icmp6 packets
      don't get lost over ipsec tunnels. Similar patch is in RHEL5 kernel for a quite
      long time and I do not see why it isn't in mainline.
      Signed-off-by: NJiri Pirko <jpirko@redhat.com>
      Acked-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6c06a478
  8. 21 1月, 2009 1 次提交
  9. 14 1月, 2009 1 次提交
  10. 13 1月, 2009 1 次提交
  11. 09 1月, 2009 3 次提交
  12. 07 1月, 2009 1 次提交
  13. 05 1月, 2009 2 次提交
  14. 30 12月, 2008 1 次提交
  15. 16 12月, 2008 3 次提交
    • Y
      ipv6: fix the outgoing interface selection order in udpv6_sendmsg() · 9f690db7
      Yang Hongyang 提交于
      1.When no interface is specified in an IPV6_PKTINFO ancillary data
        item, the interface specified in an IPV6_PKTINFO sticky optionis 
        is used.
      
      RFC3542:
      6.7.  Summary of Outgoing Interface Selection
      
         This document and [RFC-3493] specify various methods that affect the
         selection of the packet's outgoing interface.  This subsection
         summarizes the ordering among those in order to ensure deterministic
         behavior.
      
         For a given outgoing packet on a given socket, the outgoing interface
         is determined in the following order:
      
         1. if an interface is specified in an IPV6_PKTINFO ancillary data
            item, the interface is used.
      
         2. otherwise, if an interface is specified in an IPV6_PKTINFO sticky
            option, the interface is used.
      Signed-off-by: NYang Hongyang <yanghy@cn.fujitsu.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9f690db7
    • Y
      ipv6: fix the return interface index when get it while no message is received · f250dcda
      Yang Hongyang 提交于
      When get receiving interface index while no message is received,
      the the value seted with setsockopt() should be returned.
      
      RFC 3542:
         Issuing getsockopt() for the above options will return the sticky
         option value i.e., the value set with setsockopt().  If no sticky
         option value has been set getsockopt() will return the following
         values:
      
         -  For the IPV6_PKTINFO option, it will return an in6_pktinfo
            structure with ipi6_addr being in6addr_any and ipi6_ifindex being
            zero.
      Signed-off-by: NYang Hongyang <yanghy@cn.fujitsu.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f250dcda
    • Y
      ipv6: Add IPV6_PKTINFO sticky option support to setsockopt() · b24a2516
      Yang Hongyang 提交于
      There are three reasons for me to add this support:
      1.When no interface is specified in an IPV6_PKTINFO ancillary data
        item, the interface specified in an IPV6_PKTINFO sticky optionis 
        is used.
      
      RFC3542:
      6.7.  Summary of Outgoing Interface Selection
      
         This document and [RFC-3493] specify various methods that affect the
         selection of the packet's outgoing interface.  This subsection
         summarizes the ordering among those in order to ensure deterministic
         behavior.
      
         For a given outgoing packet on a given socket, the outgoing interface
         is determined in the following order:
      
         1. if an interface is specified in an IPV6_PKTINFO ancillary data
            item, the interface is used.
      
         2. otherwise, if an interface is specified in an IPV6_PKTINFO sticky
            option, the interface is used.
      
      2.When no IPV6_PKTINFO ancillary data is received,getsockopt() should 
        return the sticky option value which set with setsockopt().
      
      RFC 3542:
         Issuing getsockopt() for the above options will return the sticky
         option value i.e., the value set with setsockopt().  If no sticky
         option value has been set getsockopt() will return the following
         values:
      
      3.Make the setsockopt implementation POSIX compliant.
      Signed-off-by: NYang Hongyang <yanghy@cn.fujitsu.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b24a2516
  16. 15 12月, 2008 3 次提交
  17. 11 12月, 2008 9 次提交
  18. 10 12月, 2008 1 次提交
    • J
      ipv6: silence log messages for locally generated multicast · 24fc7b86
      Jan Sembera 提交于
      This patch fixes minor annoyance during transmission of unsolicited
      neighbor advertisements from userspace to multicast addresses (as
      far as I can see in RFC, this is allowed and the similar functionality
      for IPv4 has been in arping for a long time).
      
      Outgoing multicast packets get reinserted into local processing as if they
      are received from the network. The machine thus sees its own NA and fills
      the logs with error messages. This patch removes the message if NA has been
      generated locally.
      Signed-off-by: NJan Sembera <jsembera@suse.cz>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      24fc7b86
  19. 04 12月, 2008 1 次提交