Re: Multicast group memberships lost if eth0 brought down and up

From: Deron Meranda (deron.meranda_at_gmail.com)
Date: 10/04/04

  • Next message: Tim Bradshaw: "Re: Probelm installing RPMs"
    Date: Mon, 4 Oct 2004 04:39:29 -0400
    To: tedkaz@optonline.net
    
    

    On Sat, 02 Oct 2004 07:49:01 -0400, Ted Kaczmarek <tedkaz@optonline.net> wrote:
    > up/down cycling of what?
    > Most switches will and should flush all tables on a port state change.
    > I am assuming you are in a switch that is doing igmp snooping as well.

    Thanks for the response, but my problem is for a normal application
    running in user-space, not in the kernel. IGMP or snooping is not
    involved (at least that the application directly knows about). The
    application is only using standard RFC 3542 socket API calls.

    What I have is an application program which opens an IPv6 socket,
    binds it to a multicast group address and UDP port, and then adds it
    to the multicast membership (an IPV6_ADD_MEMBERSHIP socket option).
    Binding allows one to send packets to a multicast group, but only by
    setting the socket option can one also receive packets from the group.

    The problem occurs when the interface is brought down and then back
    up. The kernel looses track of all of the multicast memberships that
    used to be associated with that interface. But the application is in
    no way informed that it has lost its membership; the socket descriptor
    is still perfectly valid and will receive no errors. Packets can
    still be sent successfully to the group. However the application is
    now in a state where it can send packets but will never receive them.

    I would have expected the kernel to save group memberships when it
    goes down and to re-establish memberships when it's brought back up.
    It may not even need to save memberships, since all that information
    should be recorded among all the open descriptor structures. When an
    interface comes back up the kernel should do all the IGMP and
    device-level registering automatically. Yes, the network peers will
    (and should) see the host leave and rejoin the group, but it should be
    transparent to the application; and the application should contrinue
    to function correctly once the interface is brought back up.

    Or, as a less desirable workaround, provide a way for an application
    to be notified when an interface goes down or back up (yes, there are
    kernel-level notifications, but nothing available at user-space. that
    I know about).

    -- 
    Deron Meranda
    -- 
    fedora-list mailing list
    fedora-list@redhat.com
    To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-list
    

  • Next message: Tim Bradshaw: "Re: Probelm installing RPMs"

    Relevant Pages

    • Re: [PATCH 0/7] dlm: overview
      ... > aren't just unique within a single cluster (think clusters of clusters, ... How the configuration gets from the config file to kernel is a mystery to me ... By a message over a socket, ... Let's have no magical filesystems in the core interface please. ...
      (Linux-Kernel)
    • Re: Multicast group memberships lost if eth0 brought down and up
      ... > running in user-space, not in the kernel. ... > setting the socket option can one also receive packets from the group. ... > used to be associated with that interface. ... > I would have expected the kernel to save group memberships when it ...
      (Fedora)
    • Re: C program for getting IP address of standlone box - with no sockets
      ... >There may be no socket based connections established on the ... >interface I am interested in. ... >file into a buffer in my program. ... There kernel provides services to ...
      (comp.os.linux.misc)
    • Re: [PATCH] kNFSD - Allowing rpc.nfsd to setting of the port, transport and version the server will
      ... > The 'port' bit I had trouble liking. ... > but it isn't at all obvious from the interface.. ... > require the user-space program to create and bind a socket and then ... > communicate it to the kernel, ...
      (Linux-Kernel)
    • Re: Multicast SSM bug?
      ... you can see above the em0 interface is part of the group. ... Each time a packet is not delivered, I can see this counter being ... memberships, eventually I see the following output: ... group 224.0.0.5 mode exclude ...
      (freebsd-net)