1. 11 5月, 2010 1 次提交
    • P
      ipv6: ip6mr: support multiple tables · d1db275d
      Patrick McHardy 提交于
      This patch adds support for multiple independant multicast routing instances,
      named "tables".
      
      Userspace multicast routing daemons can bind to a specific table instance by
      issuing a setsockopt call using a new option MRT6_TABLE. The table number is
      stored in the raw socket data and affects all following ip6mr setsockopt(),
      getsockopt() and ioctl() calls. By default, a single table (RT6_TABLE_DFLT)
      is created with a default routing rule pointing to it. Newly created pim6reg
      devices have the table number appended ("pim6regX"), with the exception of
      devices created in the default table, which are named just "pim6reg" for
      compatibility reasons.
      
      Packets are directed to a specific table instance using routing rules,
      similar to how regular routing rules work. Currently iif, oif and mark
      are supported as keys, source and destination addresses could be supported
      additionally.
      
      Example usage:
      
      - bind pimd/xorp/... to a specific table:
      
      uint32_t table = 123;
      setsockopt(fd, SOL_IPV6, MRT6_TABLE, &table, sizeof(table));
      
      - create routing rules directing packets to the new table:
      
      # ip -6 mrule add iif eth0 lookup 123
      # ip -6 mrule add oif eth0 lookup 123
      Signed-off-by: NPatrick McHardy <kaber@trash.net>
      d1db275d
  2. 24 4月, 2010 2 次提交
  3. 23 4月, 2010 1 次提交
    • S
      IPv6: Generic TTL Security Mechanism (final version) · e802af9c
      Stephen Hemminger 提交于
      This patch adds IPv6 support for RFC5082 Generalized TTL Security Mechanism.  
      
      Not to users of mapped address; the IPV6 and IPV4 socket options are seperate.
      The server does have to deal with both IPv4 and IPv6 socket options
      and the client has to handle the different for each family.
      
      On client:
      	int ttl = 255;
      	getaddrinfo(argv[1], argv[2], &hint, &result);
      
      	for (rp = result; rp != NULL; rp = rp->ai_next) {
      		s = socket(rp->ai_family, rp->ai_socktype, rp->ai_protocol);
      		if (s < 0) continue;
      
      		if (rp->ai_family == AF_INET) {
      			setsockopt(s, IPPROTO_IP, IP_TTL, &ttl, sizeof(ttl));
      		} else if (rp->ai_family == AF_INET6) {
      			setsockopt(s, IPPROTO_IPV6,  IPV6_UNICAST_HOPS, 
      					&ttl, sizeof(ttl)))
      		}
      			
      		if (connect(s, rp->ai_addr, rp->ai_addrlen) == 0) {
      		   ...
      
      On server:
      	int minttl = 255 - maxhops;
         
      	getaddrinfo(NULL, port, &hints, &result);
      	for (rp = result; rp != NULL; rp = rp->ai_next) {
      		s = socket(rp->ai_family, rp->ai_socktype, rp->ai_protocol);
      		if (s < 0) continue;
      
      		if (rp->ai_family == AF_INET6)
      			setsockopt(s, IPPROTO_IPV6,  IPV6_MINHOPCOUNT,
      					&minttl, sizeof(minttl));
      		setsockopt(s, IPPROTO_IP, IP_MINTTL, &minttl, sizeof(minttl));
      			
      		if (bind(s, rp->ai_addr, rp->ai_addrlen) == 0)
      			break
      ...
      Signed-off-by: NStephen Hemminger <shemminger@vyatta.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e802af9c
  4. 13 4月, 2010 1 次提交
  5. 19 10月, 2009 1 次提交
    • E
      inet: rename some inet_sock fields · c720c7e8
      Eric Dumazet 提交于
      In order to have better cache layouts of struct sock (separate zones
      for rx/tx paths), we need this preliminary patch.
      
      Goal is to transfert fields used at lookup time in the first
      read-mostly cache line (inside struct sock_common) and move sk_refcnt
      to a separate cache line (only written by rx path)
      
      This patch adds inet_ prefix to daddr, rcv_saddr, dport, num, saddr,
      sport and id fields. This allows a future patch to define these
      fields as macros, like sk_refcnt, without name clashes.
      Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c720c7e8
  6. 09 10月, 2009 1 次提交
    • J
      ipv6: Fix the size overflow of addrconf_sysctl array · e0e6f55d
      Jin Dongming 提交于
      (This patch fixes bug of commit f7734fdf
       title "make TLLAO option for NA packets configurable")
      
      When the IPV6 conf is used, the function sysctl_set_parent is called and the
      array addrconf_sysctl is used as a parameter of the function.
      
      The above patch added new conf "force_tllao" into the array addrconf_sysctl,
      but the size of the array was not modified, the static allocated size is
      DEVCONF_MAX + 1 but the real size is DEVCONF_MAX + 2, so the problem is
      that the function sysctl_set_parent accessed wrong address.
      
      I got the following information.
      Call Trace:
          [<ffffffff8106085d>] sysctl_set_parent+0x29/0x3e
          [<ffffffff8106085d>] sysctl_set_parent+0x29/0x3e
          [<ffffffff8106085d>] sysctl_set_parent+0x29/0x3e
          [<ffffffff8106085d>] sysctl_set_parent+0x29/0x3e
          [<ffffffff8106085d>] sysctl_set_parent+0x29/0x3e
          [<ffffffff810622d5>] __register_sysctl_paths+0xde/0x272
          [<ffffffff8110892d>] ? __kmalloc_track_caller+0x16e/0x180
          [<ffffffffa00cfac3>] ? __addrconf_sysctl_register+0xc5/0x144 [ipv6]
          [<ffffffff8141f2c9>] register_net_sysctl_table+0x48/0x4b
          [<ffffffffa00cfaf5>] __addrconf_sysctl_register+0xf7/0x144 [ipv6]
          [<ffffffffa00cfc16>] addrconf_init_net+0xd4/0x104 [ipv6]
          [<ffffffff8139195f>] setup_net+0x35/0x82
          [<ffffffff81391f6c>] copy_net_ns+0x76/0xe0
          [<ffffffff8107ad60>] create_new_namespaces+0xf0/0x16e
          [<ffffffff8107afee>] copy_namespaces+0x65/0x9f
          [<ffffffff81056dff>] copy_process+0xb2c/0x12c3
          [<ffffffff810576e1>] do_fork+0x14b/0x2d2
          [<ffffffff8107ac4e>] ? up_read+0xe/0x10
          [<ffffffff81438e73>] ? do_page_fault+0x27a/0x2aa
          [<ffffffff8101044b>] sys_clone+0x28/0x2a
          [<ffffffff81011fb3>] stub_clone+0x13/0x20
          [<ffffffff81011c72>] ? system_call_fastpath+0x16/0x1b
      
      And the information of IPV6 in .config is as following.
      IPV6 in .config:
          CONFIG_IPV6=m
          CONFIG_IPV6_PRIVACY=y
          CONFIG_IPV6_ROUTER_PREF=y
          CONFIG_IPV6_ROUTE_INFO=y
          CONFIG_IPV6_OPTIMISTIC_DAD=y
          CONFIG_IPV6_MIP6=m
          CONFIG_IPV6_SIT=m
          # CONFIG_IPV6_SIT_6RD is not set
          CONFIG_IPV6_NDISC_NODETYPE=y
          CONFIG_IPV6_TUNNEL=m
          CONFIG_IPV6_MULTIPLE_TABLES=y
          CONFIG_IPV6_SUBTREES=y
          CONFIG_IPV6_MROUTE=y
          CONFIG_IPV6_PIMSM_V2=y
          # CONFIG_IP_VS_IPV6 is not set
          CONFIG_NF_CONNTRACK_IPV6=m
          CONFIG_IP6_NF_MATCH_IPV6HEADER=m
      
      I confirmed this patch fixes this problem.
      Signed-off-by: NJin Dongming <jin.dongming@np.css.fujitsu.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e0e6f55d
  7. 07 10月, 2009 1 次提交
    • 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
  8. 01 6月, 2009 1 次提交
  9. 31 1月, 2009 1 次提交
  10. 16 12月, 2008 1 次提交
    • 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
  11. 22 7月, 2008 1 次提交
  12. 03 7月, 2008 2 次提交
  13. 11 6月, 2008 1 次提交
  14. 14 4月, 2008 1 次提交
  15. 05 4月, 2008 1 次提交
  16. 26 3月, 2008 1 次提交
  17. 25 3月, 2008 4 次提交
  18. 01 2月, 2008 2 次提交
  19. 11 10月, 2007 1 次提交
  20. 31 7月, 2007 1 次提交
  21. 11 7月, 2007 3 次提交
  22. 31 5月, 2007 1 次提交
  23. 26 4月, 2007 4 次提交
  24. 25 4月, 2007 1 次提交
  25. 03 12月, 2006 1 次提交
  26. 29 9月, 2006 2 次提交
  27. 23 9月, 2006 2 次提交