1. 16 12月, 2008 2 次提交
    • 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
  2. 13 11月, 2008 1 次提交
    • B
      ipv6: routing header fixes · 6e093d9d
      Brian Haley 提交于
      This patch fixes two bugs:
      
      1. setsockopt() of anything but a Type 2 routing header should return
      EINVAL instead of EPERM.  Noticed by Shan Wei
      (shanwei@cn.fujitsu.com).
      
      2. setsockopt()/sendmsg() of a Type 2 routing header with invalid
      length or segments should return EINVAL.  These values are statically
      fixed in RFC 3775, unlike the variable Type 0 was.
      Signed-off-by: NBrian Haley <brian.haley@hp.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6e093d9d
  3. 18 8月, 2008 1 次提交
  4. 04 8月, 2008 1 次提交
  5. 20 7月, 2008 1 次提交
  6. 19 7月, 2008 1 次提交
  7. 20 6月, 2008 1 次提交
  8. 12 6月, 2008 4 次提交
  9. 05 6月, 2008 5 次提交
  10. 01 5月, 2008 1 次提交
  11. 29 4月, 2008 1 次提交
  12. 28 4月, 2008 1 次提交
  13. 14 4月, 2008 1 次提交
  14. 12 4月, 2008 2 次提交
  15. 11 4月, 2008 1 次提交
    • Y
      [IPV6]: Sparse: Reuse previous delaration where appropriate. · a9f83bf3
      YOSHIFUJI Hideaki 提交于
      | net/ipv6/ipv6_sockglue.c:162:16: warning: symbol 'net' shadows an earlier one
      | net/ipv6/ipv6_sockglue.c:111:13: originally declared here
      | net/ipv6/ipv6_sockglue.c:175:16: warning: symbol 'net' shadows an earlier one
      | net/ipv6/ipv6_sockglue.c:111:13: originally declared here
      | net/ipv6/ip6mr.c:1241:10: warning: symbol 'ret' shadows an earlier one
      | net/ipv6/ip6mr.c:1163:6: originally declared here
      Signed-off-by: NYOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
      a9f83bf3
  16. 05 4月, 2008 1 次提交
  17. 01 4月, 2008 1 次提交
  18. 26 3月, 2008 1 次提交
  19. 25 3月, 2008 2 次提交
  20. 08 3月, 2008 1 次提交
  21. 07 3月, 2008 1 次提交
    • D
      [UDP]: Revert udplite and code split. · db8dac20
      David S. Miller 提交于
      This reverts commit db1ed684 ("[IPV6]
      UDP: Rename IPv6 UDP files."), commit
      8be8af8f ("[IPV4] UDP: Move
      IPv4-specific bits to other file.") and commit
      e898d4db ("[UDP]: Allow users to
      configure UDP-Lite.").
      
      First, udplite is of such small cost, and it is a core protocol just
      like TCP and normal UDP are.
      
      We spent enormous amounts of effort to make udplite share as much code
      with core UDP as possible.  All of that work is less valuable if we're
      just going to slap a config option on udplite support.
      
      It is also causing build failures, as reported on linux-next, showing
      that the changeset was not tested very well.  In fact, this is the
      second build failure resulting from the udplite change.
      
      Finally, the config options provided was a bool, instead of a modular
      option.  Meaning the udplite code does not even get build tested
      by allmodconfig builds, and furthermore the user is not presented
      with a reasonable modular build option which is particularly needed
      by distribution vendors.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      db8dac20
  22. 04 3月, 2008 2 次提交
  23. 29 1月, 2008 2 次提交
  24. 17 12月, 2007 1 次提交
  25. 12 10月, 2007 1 次提交
  26. 11 10月, 2007 3 次提交
    • S
      [NET]: sparse warning fixes · cfcabdcc
      Stephen Hemminger 提交于
      Fix a bunch of sparse warnings. Mostly about 0 used as
      NULL pointer, and shadowed variable declarations.
      One notable case was that hash size should have been unsigned.
      Signed-off-by: NStephen Hemminger <shemminger@linux-foundation.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      cfcabdcc
    • E
      [NET]: Make the device list and device lookups per namespace. · 881d966b
      Eric W. Biederman 提交于
      This patch makes most of the generic device layer network
      namespace safe.  This patch makes dev_base_head a
      network namespace variable, and then it picks up
      a few associated variables.  The functions:
      dev_getbyhwaddr
      dev_getfirsthwbytype
      dev_get_by_flags
      dev_get_by_name
      __dev_get_by_name
      dev_get_by_index
      __dev_get_by_index
      dev_ioctl
      dev_ethtool
      dev_load
      wireless_process_ioctl
      
      were modified to take a network namespace argument, and
      deal with it.
      
      vlan_ioctl_set and brioctl_set were modified so their
      hooks will receive a network namespace argument.
      
      So basically anthing in the core of the network stack that was
      affected to by the change of dev_base was modified to handle
      multiple network namespaces.  The rest of the network stack was
      simply modified to explicitly use &init_net the initial network
      namespace.  This can be fixed when those components of the network
      stack are modified to handle multiple network namespaces.
      
      For now the ifindex generator is left global.
      
      Fundametally ifindex numbers are per namespace, or else
      we will have corner case problems with migration when
      we get that far.
      
      At the same time there are assumptions in the network stack
      that the ifindex of a network device won't change.  Making
      the ifindex number global seems a good compromise until
      the network stack can cope with ifindex changes when
      you change namespaces, and the like.
      Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      881d966b
    • B
      [IPV6]: Add v4mapped address inline · e773e4fa
      Brian Haley 提交于
      Add v4mapped address inline to avoid calls to ipv6_addr_type().
      Signed-off-by: NBrian Haley <brian.haley@hp.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e773e4fa