| Message ID | 1b9338490908111626j55b49177q71b8a373b6e6381b@mail.gmail.com |
|---|---|
| State | Changes Requested, archived |
| Delegated to: | David Miller |
| Headers | show |
On Wednesday 12 August 2009 02:26:21 Ilia K. wrote: > Hi All, > 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 call to vif_add() function call which > search the (physical) device using assigned IP address: > dev = ip_dev_find(net, vifc->vifc_lcl_addr.s_addr); > > It seems like 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 > (for example it makes problems when tunnel is configured using the > same IP as underlying interface). > > Am I correct in identifying the problem? > I can propose the attached patch against 2.6.30.4. > Hi Ilia, I don't have context on multicast routing, but this caught my attention: >@@ -61,11 +61,13 @@ > unsigned int vifc_rate_limit; /* Rate limiter values (NI) */ > struct in_addr vifc_lcl_addr; /* Our address */ > struct in_addr vifc_rmt_addr; /* IPIP tunnel addr */ >+ int ifindex; /* Local interface index */ > }; > Wouldn't this break userspace ABI? Perhaps you could use a union between vifc_lcl_addr and vifc_ifindex, they seem to be exclusive. tavi -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Octavian Purdila <opurdila@ixiacom.com> Date: Thu, 27 Aug 2009 02:53:18 +0300 > I don't have context on multicast routing, but this caught my attention: > >>@@ -61,11 +61,13 @@ >> unsigned int vifc_rate_limit; /* Rate limiter values (NI) */ >> struct in_addr vifc_lcl_addr; /* Our address */ >> struct in_addr vifc_rmt_addr; /* IPIP tunnel addr */ >>+ int ifindex; /* Local interface index */ >> }; >> > > Wouldn't this break userspace ABI? > > Perhaps you could use a union between vifc_lcl_addr and vifc_ifindex, they seem > to be exclusive. Indeed, this will need to be fixed up. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
=== modified file 'include/linux/mroute.h' --- old/include/linux/mroute.h 2009-08-10 11:17:32 +0000 +++ new/include/linux/mroute.h 2009-08-11 20:39:14 +0000 @@ -61,11 +61,13 @@ unsigned int vifc_rate_limit; /* Rate limiter values (NI) */ struct in_addr vifc_lcl_addr; /* Our address */ struct in_addr vifc_rmt_addr; /* IPIP tunnel addr */ + int ifindex; /* Local interface index */ }; #define VIFF_TUNNEL 0x1 /* IPIP tunnel */ #define VIFF_SRCRT 0x2 /* NI */ #define VIFF_REGISTER 0x4 /* register vif */ +#define VIFF_USE_IFINDEX 0x8 /* use ifindex to find an interface */ /* * Cache manipulation structures for mrouted and PIMd === modified file 'net/ipv4/ipmr.c' --- old/net/ipv4/ipmr.c 2009-08-10 11:17:32 +0000 +++ new/net/ipv4/ipmr.c 2009-08-11 22:15:24 +0000 @@ -470,6 +470,18 @@ return err; } break; + case VIFF_USE_IFINDEX: + dev = dev_get_by_index(net, vifc->ifindex); + if (!dev) + return -ENODEV; + if (dev->ip_ptr == NULL) + return -EADDRNOTAVAIL; + err = dev_set_allmulti(dev, 1); + if (err) { + dev_put(dev); + return err; + } + break; case 0: dev = ip_dev_find(net, vifc->vifc_lcl_addr.s_addr); if (!dev)
Hi All, 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 call to vif_add() function call which search the (physical) device using assigned IP address: dev = ip_dev_find(net, vifc->vifc_lcl_addr.s_addr); It seems like 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 (for example it makes problems when tunnel is configured using the same IP as underlying interface). Am I correct in identifying the problem? I can propose the attached patch against 2.6.30.4. Regards, Ilia.