#include <stdio.h>
#include <stdlib.h>
#include <sys/socket.h>
#include <sys/types.h>
#include <netdb.h>
#include <unistd.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <string.h>
#include <errno.h>

#define PERROR(x)   do { perror(x); exit(1); } while (0)

int main() {
  int output; 
  int sock;
  int len, rv;
  struct sockaddr_in src, dest;

  /* Reproducer brings down all interfaces, so I assume you can only
   * run this in the console.  So I write data to a file rather
   * than stderr/stdout
   */
  output = open("output.txt", O_CREAT | O_WRONLY | O_APPEND, S_IRUSR |
S_IWUSR);
  if (output < 0)
    PERROR("open");

  sock = socket(AF_INET, SOCK_DGRAM, 0);
  if (sock < 0)
    PERROR("socket");

  /* Change this to a local multicast interface IP on your machine */
  rv = inet_pton(AF_INET, "192.168.20.3", &src.sin_addr); 
  if (rv <= 0)
    PERROR("inet_pton");

  rv = setsockopt(sock, IPPROTO_IP, IP_MULTICAST_IF, 
                  (const void *)&src.sin_addr, sizeof(struct in_addr));
  if (rv < 0)
    PERROR("setsockopt");

  /* Make up some multicast destination address */
  memset(&dest, '\0', sizeof(dest));
  dest.sin_family = AF_INET;
  dest.sin_port = htons(9000);  
  rv = inet_pton(AF_INET, "239.2.11.72", &dest.sin_addr); 
  if (rv <= 0)
    PERROR("inet_pton");

  rv = connect(sock, (struct sockaddr *)&dest, sizeof(dest));
  if (rv < 0)
    PERROR("connect");
  
  /* Loop forever, always trying to write to this socket */
  while (1) {
    char data = 0;
    char buffer[1000];

    errno = 0;                  /* just in case */
   
    rv = write(sock, &data, 1);
    len = sprintf(buffer, "rv = %d, errno = %d, str = %s\n",
                  rv, errno, strerror(errno));
    write(output, buffer, len); /* i assume this always works */
    sleep(3);                   /* sleep a bit  */
  }
} 

U1 should have a fix for this bug.

We just retested this with 2.4.21-5EL and it has the same problem.

I asked davem to comment on whether this is a reasonable request, and
he told me to contact David Stevens at IBM.  Here's what he had to say:

      It is a judgement call, since I don't there is any established
practice-- you can't remove an interface on 4.3BSD systems. But I
would have to say, "no", the program is not reasonable. Here's why:

      The bug poster seems to have the idea that multicast group
membership is associated with an IP address and should therefore
be there in the later instance of the interface. But, even on BSD
systems, and certainly on Linux systems, if you join a group on an
interface, then delete the IP address and re-add that IP address on
a different interface, none of the group memberships move with the
IP address. Group membership is associated with the logical device,
and that's particularly clear when using ip_mreqn or IPv6, which
specify an interface by index, not address. You don't even have to
have an IP address to join a group on an interface.
      There isn't any practical way to support what they're after,
because you have cases like: two addresses, IP1 & IP2, on eth0, and
you delete them and then add IP1 to eth1 and IP2 to eth2. I'm guessing
he'd want the groups joined via IP1 to go to eth1 and the groups
joined via IP2 to go to eth2, but there is no context like that
saved, and where would groups joined by index go to?
      I think the way to think of it is that removing the module
logically removes the interface, which is what the groups are
associated with. At that point, they are gone, and even if the
same physical interface is re-added with the same addresses, it
still has a different interface index and is logically not the same
interface as the groups were joined on.
      The reason it doesn't work in Linux is because each device
has its list of group memberships and that is destroyed when the
device is unregistered. The new device, when registered, will have
no memberships until new group joins are done.
      I don't see this as a bug, and I don't believe any other OS
supports anything like it. If they're for a high-availability failover
mechanism, I think they want group member ship in a "parent" logical
device with child physical devices that can come and go. I thought
that's how ethernet bonding works, though I really know nothing about
it. With something like that, the physical devices can come and go
but as long as the parent device doesn't, the multicast group
memberships aren't affected.

Hello, 

Based on your points, I agree that this may be correct behavior. 
However, are the errno values correct??  When I first saw this
problem, errno == EINVAL suggested to me that bringing the network
device back up would "fix" the invalid argument.  

Based on the statements by Dave Stevens, it would seem that errno
should not equal EINVAL at any point in time.  That ENODEV should be
returned after you rmmod the NIC driver.

Al

Created attachment 98755 [details]
A patch to change the returned error

This patch changes the returned EINVAL to ENODEV.  davem, any comments on
whether this is the right thing to do or not?

This code is checking to see if an ipv4 address is local
to the system.  ENODEV is quite an odd error code to return
for that.

EINVAL is a perfectly fine error return, I see no reason to
change it.