[lkml]   [2007]   [Feb]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectMulticast "ipmr.c" misunderstood / bug / new feature.
Hi !

I have been working with multicast routing to build a multicast router.
The target system uses static multicast routers and we have used
smcroute user-space daemon. After some issues with that sofware I have
built a some kind of custom daemon.

This router has support for hotpluggable interfaces like wifi and usb ones.

I think that there is something I don't understand or is not supported
in the net/ipv4/ipmr.c Kernel router. This routing system registers the
function "ipmr_device_event" as a notifier so that when a device is
unregistered from the system the correspondings multicast virtual
interfaces are also unregistered.

This is fine, but the problem is that the function "vif_delete()", used
in the notifier and in the corresponding IOCTL does not release the
active routes (mfc_cache entries). When doing "cat /proc/net/ip_mr_vif"
the unregistered interfaces are no longer available, but when doing "cat
/proc/net/ip_mr_cache" weird entries are displayed. If the unregistered
device was an output vif the route entry is shown with no output vif. If
it was an input vif the entry is shown but not really valid.

I don't know if this is really the expected behaviour of the multicast
routing system or even this is the correct place to ask.

I have coded a small patch for the ipmr.c file that purges all the
routes related to a device when it is unregistered, leaving the tables
in a coherent state always. I am know debugging this feature.

So: Is this the correct behaviour or is a bug? And is this patch
interesting for the Kernel?

Thank you very much,

Iratxo Pichel Ortiz.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2007-02-11 23:25    [W:0.015 / U:0.152 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site