1. 30 1月, 2011 1 次提交
    • E
      net: Add compat ioctl support for the ipv4 multicast ioctl SIOCGETSGCNT · 709b46e8
      Eric W. Biederman 提交于
      SIOCGETSGCNT is not a unique ioctl value as it it maps tio SIOCPROTOPRIVATE +1,
      which unfortunately means the existing infrastructure for compat networking
      ioctls is insufficient.  A trivial compact ioctl implementation would conflict
      with:
      
      SIOCAX25ADDUID
      SIOCAIPXPRISLT
      SIOCGETSGCNT_IN6
      SIOCGETSGCNT
      SIOCRSSCAUSE
      SIOCX25SSUBSCRIP
      SIOCX25SDTEFACILITIES
      
      To make this work I have updated the compat_ioctl decode path to mirror the
      the normal ioctl decode path.  I have added an ipv4 inet_compat_ioctl function
      so that I can have ipv4 specific compat ioctls.   I have added a compat_ioctl
      function into struct proto so I can break out ioctls by which kind of ip socket
      I am using.  I have added a compat_raw_ioctl function because SIOCGETSGCNT only
      works on raw sockets.  I have added a ipmr_compat_ioctl that mirrors the normal
      ipmr_ioctl.
      
      This was necessary because unfortunately the struct layout for the SIOCGETSGCNT
      has unsigned longs in it so changes between 32bit and 64bit kernels.
      
      This change was sufficient to run a 32bit ip multicast routing daemon on a
      64bit kernel.
      Reported-by: NBill Fenner <fenner@aristanetworks.com>
      Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      709b46e8
  2. 04 10月, 2010 1 次提交
  3. 14 4月, 2010 3 次提交
    • P
      ipv4: ipmr: support multiple tables · f0ad0860
      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 MRT_TABLE. The table number is
      stored in the raw socket data and affects all following ipmr setsockopt(),
      getsockopt() and ioctl() calls. By default, a single table (RT_TABLE_DEFAULT)
      is created with a default routing rule pointing to it. Newly created pimreg
      devices have the table number appended ("pimregX"), with the exception of
      devices created in the default table, which are named just "pimreg" 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, IPPROTO_IP, MRT_TABLE, &table, sizeof(table));
      
      - create routing rules directing packets to the new table:
      
      # ip mrule add iif eth0 lookup 123
      # ip mrule add oif eth0 lookup 123
      Signed-off-by: NPatrick McHardy <kaber@trash.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f0ad0860
    • P
    • P
      ipv4: ipmr: remove net pointer from struct mfc_cache · d658f8a0
      Patrick McHardy 提交于
      Now that cache entries in unres_queue don't need to be distinguished by their
      network namespace pointer anymore, we can remove it from struct mfc_cache
      add pass the namespace as function argument to the functions that need it.
      Signed-off-by: NPatrick McHardy <kaber@trash.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d658f8a0
  4. 05 11月, 2009 1 次提交
  5. 07 10月, 2009 1 次提交
    • I
      add vif using local interface index instead of IP · ee5e81f0
      Ilia K 提交于
      When routing daemon wants to enable forwarding of multicast traffic it
      performs something like:
      
             struct vifctl vc = {
                     .vifc_vifi  = 1,
                     .vifc_flags = 0,
                     .vifc_threshold = 1,
                     .vifc_rate_limit = 0,
                     .vifc_lcl_addr = ip, /* <--- ip address of physical
      interface, e.g. eth0 */
                     .vifc_rmt_addr.s_addr = htonl(INADDR_ANY),
               };
             setsockopt(fd, IPPROTO_IP, MRT_ADD_VIF, &vc, sizeof(vc));
      
      This leads (in the kernel) to calling  vif_add() function call which
      search the (physical) device using assigned IP address:
             dev = ip_dev_find(net, vifc->vifc_lcl_addr.s_addr);
      
      The current API (struct vifctl) does not allow to specify an
      interface other way than using it's IP, and if there are more than a
      single interface with specified IP only the first one will be found.
      
      The attached patch (against 2.6.30.4) allows to specify an interface
      by its index, instead of IP address:
      
             struct vifctl vc = {
                     .vifc_vifi  = 1,
                     .vifc_flags = VIFF_USE_IFINDEX,   /* NEW */
                     .vifc_threshold = 1,
                     .vifc_rate_limit = 0,
                     .vifc_lcl_ifindex = if_nametoindex("eth0"),   /* NEW */
                     .vifc_rmt_addr.s_addr = htonl(INADDR_ANY),
               };
             setsockopt(fd, IPPROTO_IP, MRT_ADD_VIF, &vc, sizeof(vc));
      Signed-off-by: NIlia K. <mail4ilia@gmail.com>
      
      === modified file 'include/linux/mroute.h'
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ee5e81f0
  6. 01 10月, 2009 1 次提交
  7. 23 1月, 2009 2 次提交
    • B
      netns: ipmr: enable namespace support in ipv4 multicast routing code · 4feb88e5
      Benjamin Thery 提交于
      This last patch makes the appropriate changes to use and propagate the
      network namespace where needed in IPv4 multicast routing code.
      
      This consists mainly in replacing all the remaining init_net occurences
      with current netns pointer retrieved from sockets, net devices or
      mfc_caches depending on the routines' contexts.
      
      Some routines receive a new 'struct net' parameter to propagate the current
      netns:
      * vif_add/vif_delete
      * ipmr_new_tunnel
      * mroute_clean_tables
      * ipmr_cache_find
      * ipmr_cache_report
      * ipmr_cache_unresolved
      * ipmr_mfc_add/ipmr_mfc_delete
      * ipmr_get_route
      * rt_fill_info (in route.c)
      Signed-off-by: NBenjamin Thery <benjamin.thery@bull.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4feb88e5
    • B
      netns: ipmr: store netns in struct mfc_cache · 5c0a66f5
      Benjamin Thery 提交于
      This patch stores into struct mfc_cache the network namespace each
      mfc_cache belongs to. The new member is mfc_net.
      
      mfc_net is assigned at cache allocation and doesn't change during
      the rest of the cache entry life.
      A new net parameter is added to ipmr_cache_alloc/ipmr_cache_alloc_unres.
      
      This will help to retrieve the current netns around the IPv4 multicast
      routing code.
      
      At the moment, all mfc_cache are allocated in init_net.
      Signed-off-by: NBenjamin Thery <benjamin.thery@bull.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5c0a66f5
  8. 30 8月, 2008 1 次提交
    • D
      net: Unbreak userspace usage of linux/mroute.h · 7c19a3d2
      David S. Miller 提交于
      Nothing in linux/pim.h should be exported to userspace.
      
      This should fix the XORP build failure reported by
      Jose Calhariz, the debain package maintainer.
      
      Nothing originally in linux/mroute.h was exported to userspace
      ever, but some of this stuff started to be when it was moved into
      this new linux/pim.h, and that was wrong.  If we didn't provide these
      definitions for 10 years we can reasonably expect that applications
      defined this stuff locally or used GLIBC headers providing the
      protocol definitions.  And as such the only result of this can
      be conflict and userland build breakage.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7c19a3d2
  9. 03 7月, 2008 2 次提交
  10. 04 4月, 2008 2 次提交
  11. 07 11月, 2007 1 次提交
  12. 29 9月, 2006 2 次提交
  13. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      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!
      1da177e4