by I get the error message:
SIOCSIFFLAGS: Cannot assign requested address
when doing the command:
ifconfig eth0:0 inet up 192.168.1.19 netmask 255.255.255.0 broadcast 192.168.1.255
I've explored several sequences of executing ifconfig commands and found
the one way to avoid the message (and everything works despite the message)
and found that if I leave off the "up" option, there is no message.
In "man ifconfig" I read:
up This flag causes the interface to be activated. It is
implicitly specified if an address is assigned to the interface.
The reason I was putting in was just to be explicit. But since the message
goes away when I leave it off, it is clear that something _different_ happens
when "up" is included.
I can't find the source to ifconfig at the moment, but I looked around in
the kernel and looked in net/ipv4/devinet.c in function devinet_ioctl() at
line 398 in 2.2.14. Apparently this code is being invoked:
case SIOCSIFFLAGS:
#ifdef CONFIG_IP_ALIAS
if (colon) {
if (ifa == NULL) {
ret = -EADDRNOTAVAIL;
break;
}
if (!(ifr.ifr_flags&IFF_UP))
inet_del_ifa(in_dev, ifap, 1);
break;
}
#endif
ret = dev_change_flags(dev, ifr.ifr_flags);
break;
Earier in the code it searched for something not specifically obvious to
fill in "ifa". So I guess in this case it didn't find it and returned the
EADDRNOTAVAIL status. If I execute the same command again, with the "up"
option, for an alias that exists, the error message does not come out. So
I'm guessing that it then finds whatever it was looking for.
Strange.
Anyone have an explanation for this? Why is an explicit "up" and an
implicit "up" option different? Is the ifconfig command perhaps doing
it wrong?
--
| Phil Howard - KA9WGN | for headlines that | Just say no to absurd patents |
| Dallas - Texas - USA | linuxhomepage.com | Shop http://bn.com/ instead |