'SIOCSIFFLAGS: Cannot assign requested address' when setting up ip alias

[Jamie Strandboge]

Binary package hint: ifupdown

Add the following to /etc/network/interfaces on Feisty:
auto eth0
iface eth0 inet static
        address 192.168.3.50
        netmask 255.255.255.0
        gateway 192.168.3.1

auto eth0:0
iface eth0:0 inet static
        address 192.168.3.51
        netmask 255.255.255.0

Then do:
$ sudo ifup eth0 (works fine)
$ sudo ifup eth0:0
SIOCSIFFLAGS: Cannot assign requested address

However, though ifup (and ifdown) will give that error, the interface comes up fine, and is pingable:
$ ifconfig
...
eth0:0 Link encap:Ethernet HWaddr 00:04:5A:7D:4C:73
          inet addr:192.168.3.51 Bcast:192.168.3.255 Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
          Interrupt:9 Base address:0xf800
...
$ ping -c 1 192.168.3.51
PING 192.168.3.51 (192.168.3.51) 56(84) bytes of data.
64 bytes from 192.168.3.51: icmp_seq=1 ttl=64 time=0.079 ms

--- 192.168.3.51 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.079/0.079/0.079/0.000 ms

This configuration works fine in Dapper. Also, using ifconfig on its own works too:
$ sudo ifconfig eth0:0 192.168.3.51 up

If nothing else, the message is confusing to the user (it was to me, since I thought something was wrong when it seems to work fine).

[Patrick Li (patrickli)]

I am experiencing the same symptom.

Could anyone provide some explanations?

[Steffen (steffen-kernelguy)]

Same here.
I was adding an extra static ip address to an ubuntu server installation. The error message really had me going until I found this report.
It seems to work, so why the message?

[mevdschee (mevdschee)]

I can confirm this issue. Why is it happening?

[Alvin Cura (alvinc)]

I can also confirm this.

This error does not appear during ifdown.

ifup shows this in strace:

read(3, "lo=lo\neth0=eth0\neth1=eth1\n", 4096) = 26
fstat64(4, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f33000
read(3, "", 4096) = 0
write(4, "lo=lo\neth0=eth0\neth1=eth1\neth1:1"..., 40) = 40
close(4) = 0
munmap(0xb7f33000, 4096) = 0
rename("/var/run/network/.ifstate.tmp", "/var/run/network/ifstate") = 0
close(3) = 0
munmap(0xb7f34000, 4096) = 0
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0xb7df0708) = 15673
waitpid(15673, SIOCSIFFLAGS: Cannot assign requested address
[{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0) = 15673
--- SIGCHLD (Child exited) @ 0 (0) ---

I see a child exit, but I don't see where it forked. Perhaps I am being blind here? I don't really know what the child was, and didn't catch PID 15673 in the act.....

[Alvin Cura (alvinc)]

Ah ha! "strace -ff -F -o out ifup eth1:1" does the trick.

[Thilo-Alexander Ginkel (thilo.ginkel)]

I can confirm that the issue still exists in Ubuntu Gutsy.

[PetyrRahl (petyr)]

I can also confirm that this is the case on AMD64 for Gutsy. This bug (or it's like) has been around since Feisty. It's pretty annoying because I run a computer at home with one ip address for my internal clients to access my site from and one for my external clients. If for some reason the network goes down, I have to remember to manually bring up eth0:0 otherwise my site is unaccessible for my external clients.

[Simone Marzona (marzona)]

Hi all

this happens also in ubuntu server 7.10. It's very annoyng..

in Debian Lenny this does not happen.. has someone tried to use the deb package of lenny over an ubuntu installation?

what the hell are doing those ubuntu develoers?

[Joachim Nilsson (troglobit)]

Yep, I see it here too. Very annoying buglet.

[tinodj (tinodj)]

Same here

2.6.22-14-server
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=7.10
DISTRIB_CODENAME=gutsy
DISTRIB_DESCRIPTION="Ubuntu 7.10"

Also, to note:
Commenting auto eth0:0 in interfaces and trying

ifconfig eth0:0 up
SIOCSIFFLAGS: Cannot assign requested address

and ping is not working after this.

[behemot (vlad-seliverstov)]

I've figured out, that removing package wireless-tools in Ubuntu Server Gutsy (x86_64) helps.

[Alessandro Lo Forte (aloforte)]

Same problem on ubuntu server 7.10
Tanks to behemot I have located the problem in the file /etc/if-pre-up.d/wireless-tools (that is installed by the wireless-tools package).
In fact the error code is generated when /sbin/ifconfig is invoked to bring up an alias (like eth0:0) interface.
In debian "lenny"'s wireless-tools package this problem has been solved by removing some lines of code from /etc/if-pre-up.d/wireless-tools.
I did the same and it worked well for me, but I cannot test it on a wireless system.

[Alessandro Lo Forte (aloforte)]

Sorry, I posted the entire file, not the patch.
Here is the patch alone

[Noel J. Bergman (noeljb)]

Confirmed in Hardy 8.04 server install. Pretty annoying bug, when you consider the vast number of servers that need wireless-tools. In any event, the patch (above) did the trick. I'll play later on a non-server with wireless to make sure that the change is benign there.

[ñull (erniecom)]

There must still be something else wrong. When you remove wireless-tools on Hardy 8.04 the error messages changes to:
SIOCADDRT: File exists
Failed to bring up eth0.

But both IP addresses ping OK.

[Sylvain Filteau (cidsphere)]

Removing wireless-tools on Hardy 8.04 amd64 solves the problem

[gumptravels (pml-dtbb)]

Using Hardy updated to latest updates as of today, 32-bit, on a Quad Xeon machine with an Intel 10/100 2-port NIC, the following /etc/network/interfaces still causes such errors:

/etc/network/interfaces:
auto eth1 eth1:0 eth1:1
iface eth1 inet static
        address 192.168.0.109
        netmask 255.255.255.0
        network 192.168.0.0
        broadcast 192.168.0.255

iface eth1:0 inet static
       address 192.168.10.109
       netmask 255.255.255.0
       network 192.168.10.0
       broadcast 192.168.10.255

iface eth1:1 inet dhcp

# /etc/init.d/networking restart
 * Reconfiguring network interfaces...
There is already a pid file /var/run/dhclient.eth1:1.pid with pid 134519072
Internet Systems Consortium DHCP Client V3.0.6
Copyright 2004-2007 Internet Systems Consortium.
All rights reserved.
For info, please visit http://www.isc.org/sw/dhcp/

SIOCSIFFLAGS: Cannot assign requested address
SIOCSIFFLAGS: Cannot assign requested address
Bind socket to interface: No such device
Failed to bring up eth1:1.
   ...done.

eth1 Link encap:Ethernet HWaddr 00:02:a5:5c:d9:35
          inet addr:192.168.0.109 Bcast:192.168.0.255 Mask:255.255.255.0
          inet6 addr: fe80::202:a5ff:fe5c:d935/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
          RX packets:607 errors:0 dropped:0 overruns:0 frame:0
          TX packets:437 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:55066 (53.7 KB) TX bytes:66634 (65.0 KB)

eth1:0 Link encap:Ethernet HWaddr 00:02:a5:5c:d9:35
          inet addr:192.168.10.109 Bcast:192.168.10.255 Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1

It does however work with the non-dhcp virtual interface, which I couldn't get working until I figured out to put all the virtual devices on the same 'auto' line as their parent device, many examples on the net (debian docs) don't include that little note.

# uname -a
Linux www 2.6.13-15.18-smp #1 SMP Tue Oct 2 17:36:20 UTC 2007 i686 i686 i386 GNU/Linux

Other note: I removed the wireless-tools package (which also took ubuntu-minimal package with it), it didn't make any difference.

Other note2: So to sum up, it works for me with static virtual interfaces, but not dhcp interfaces. Writing this note right now, makes me think that you may not be able use dhcp on virtual interfaces since the mac address would be the same as all the other virtual interfaces on that same parent, and the same as the parent itself. However, allowing DHCP on a virtual interface still makes sense, as long as its the only virtual interfaces using dhcp, and the parent is not using dhcp. Otherwise, I guess one could make sure to use the parent device as the dhcp interface, and then static virtual interfaces for the rest, not sure if this is by design or not.

[gumptravels (pml-dtbb)]

I decided to try my theory of using dhcp on the parent interface only. It works and sends out dhcp requests as expected, if it doesn't get any responses, the virtual interfaces have to wait for it to be backgrounded before they are brought up (not a big deal.. 10-15 seconds or something I think), but the downside, is that if you ifdown eth1 (the parent interface with dhcp on it), you down all of the virtual interfaces.

I'm guessing the downing of all virtual interfaces is intentional.. and makes sense, however, this limits us to not being able to shutdown the dhcp side of the nic without killing the rest of the virtual interfaces. If the dhcp could run on a virtual interface (assuming the parent and the other virtual interfaces are not using dhcp, since the mac address is shared), one could ifup/ifdown the dhcp virtual interface without affecting the parent or other virtual interfaces on the card.

Thankfully this bug/design is not hindering roll-out, and is more of an observation showing usability issues.

Regards,
Tyler.

[The Devil Is A Squirrel (justanotheradress)]

I can confirm that on my 8.04 Server. However, ping is fine.

/etc/init.d/networking restart
 * Reconfiguring network interfaces...
SIOCSIFFLAGS: Cannot assign requested address
SIOCSIFFLAGS: Cannot assign requested address
SIOCSIFFLAGS: Cannot assign requested address
SIOCSIFFLAGS: Cannot assign requested address
SIOCSIFFLAGS: Cannot assign requested address

Pardon me, but why is there even a wireless package on a server by default (you can install it, fine, but not by default!)??

BTW: This is not an issue on Debian Etch.

[Bigmac (bigmac)]

Got this problem on an Ubuntu Server 8.04 recently.

I don't have any Wireless network adapters, so I just did this:

    chmod a-x /etc/network/if-pre-up.d/wireless-tools

This removes the execute permission from the wireless-tools file which disables it from being called and causing the error (SIOCSIFFLAGS: Cannot assign requested address)

I did not remove the wireless-tools package, because it is a part of ubuntu-minimal which definitely should not be removed!

>>Bigmac

[Ingo Baab (ingo-baab)]

I installed Ubuntu on a typical webserver-maschine, is
there any reason:

  Why I should *don't* remove the wireless-tools on a server?

Thank you. (I am using Ubuntu-Minimal 8.04)

[Juuso Tähkäpää (jupet)]

I happened to upgrade my firewall+webserver and now the firewall part is bust...

in Feisty I used to bring up my external ip-addresses using commands like

dhcpcd -I someid eth0:1
dhcpcd -I someotherid eth0:2

but after upgrading to Gutsy today an to Hardy shortly after I found out dhcp stopped working in the previous upgrade, dhcpcd, ifup with dhcp or dhclient can't any more do anything to eth0:*. I get

SIOCSIFFLAGS: Cannot assign requested address

and similar error messages. Removing wireless-tools has no effect.

BUT!!

If I do the following:

sudo ifconfig eth0:1 1.2.3.4
dhcpcd -I someid eth0:1

I get

dhcpcd -I someid eth0:1

as I normally should, but still ifconfig shows no eth0:1. Manually assigned aliases (ifconfig eth0:2 $ip) do show up in ifconfig listings just as they should.

So, something is broken in the two newest releases. No apparent reason why dhcp:ing aliases shouldn't work any more.

[Juuso Tähkäpää (jupet)]

Just can't figure out what actually is wrong, but downgrading manually to

dhcpcd_2.0.3-1
net-tools_1.60-17ubuntu1
ifupdown_0.6.8ubuntu6

(from Feisty) gets things working in Hardy as they should.

[Mrts (mrts)]

This is really important, can we please up the importance? Hardy is LTS, so a fix should be definitely released for it.

[gumptravels (pml-dtbb)]

Maybe if all the bug reporters try the nomination feature we can get this looked at, or maybe someone needs to look up the maintainer info and try and get someone working/looking at this bug.

But for now, maybe people can nominate this for hardy... I didn't see an option for intrepid in the list it gave me.. so not sure if it only shows a list of "remaining" versions that haven't already been nominated for the bug.

[gumptravels (pml-dtbb)]

add maintainer to it

[gumptravels (pml-dtbb)]

add maintainer to bug

[Tormod Volden (tormodvolden)]

You don't have to nominate it for the current development version. The nominations are for backporting released fixes (see https://wiki.ubuntu.com/StableReleaseUpdates). And a developer will assign it to himself when he is working on it.

Is this still an issue in Intrepid Alpha 6?

If there is a patch that is confirmed to fix the issue and to not cause regressions for other people, please prepare a debdiff and subscribe ubuntu-main-sponsors when it's ready.

[Tormod Volden (tormodvolden)]

BTW, this doesn't look like an error at all, it's just a harmless warning.

[gumptravels (pml-dtbb)]

Its a bug, if you read more of the bug reports, you'll see that things actually don't work, and actually are a regression from older versions.

Specifically, DHCP doesn't work on virtual ethernet interfaces (such as eth0:0), and if DHCP is on the parent interface (eth0), that when you stop the DHCP client/tools, it takes down the parent interface along with all/any virtual interfaces.

Tyler.

[Tormod Volden (tormodvolden)]

Tyles, does this problem that you describe have anything to do with the original bug report about the appearance of this warning message? The seven first comments indicate that this is a harmless warning and that things otherwise work well. Later some people join in with various problems that are not necessarily due the warning.

Please file new bugs for these different problems. It's easier to merge duplicate reports later, than to try to debug several different issues in the same report.

[mmo (m-mizzaro)]

I can confirm that manually installing old versions (from Feisty) of dhcpcd, net-tools and ifupdown fixes the problem of assigning IP-addresses using DHCP to virtual interfaces.
Has a separate bug been written for this problem?

//MM

[Nick Homolibere (homolibere)]

>I can confirm that manually installing old versions (from Feisty) of dhcpcd, net-tools and ifupdown
> fixes the problem of assigning IP-addresses using DHCP to virtual interfaces.

it didn't helps me on 8.10

[Richard Laager (rlaager)]

I can confirm that the wireless-tools script is causing this issue for me. Why is /etc/network/if-pre-up.d/wireless-tools doing ifconfig up when it's clearly being done somewhere else already (since this interface comes up)?

[Alessandro Lo Forte (aloforte)]

@Richard: Can you please test if the patch I posted some time ago solves the issue for you?

[Richard Laager (rlaager)]

Yes, the patch works.

[Steve Langasek (vorlon)]

Thank you for reporting this bug and helping to improve Ubuntu.

The justification for the extra 'ifconfig' call in wireless-tools does not apply in jaunty, so I've reverted that change for Ubuntu 9.04. Changelog follows:

wireless-tools (29-1.1ubuntu2) jaunty; urgency=low

  * Revert change to bring up the interface before changing wireless
    settings; the softmac driver this was implemented for is now
    obsolete, no other drivers are reported to need it, and it
    introduces other problems such as breaking PPP interfaces
    (LP: #268519) and preventing configuration of some settings such as
    hardware addresses (LP: #219520).

Unfortunately, the justification for this change *does* apply to Ubuntu 8.04, so simply reverting the patch is inappropriate for an SRU as it would cause regressions for anyone using wireless with the softmac driver.

For Ubuntu 8.10, wireless-tools is no longer a dependency of ubuntu-minimal, which mitigates the severity of this problem for any server users running Ubuntu 8.10. But changing the dependencies of ubuntu-minimal is also not a fix that I think would be appropriate for inclusion in an Ubuntu 8.04 SRU.

So I don't have any good suggestions on how to resolve this for Ubuntu 8.04 LTS, but given the significant impact it's reported to have for server users in certain configurations, I'm accepting the hardy nomination for the bug for further consideration.

[Richard Laager (rlaager)]

For Hardy, could you just change that line as follows, checking to see if the interface is up already?
    $IFCONFIG "$IFACE" | grep -q " UP " || $IFCONFIG "$IFACE" up

[Kzin (wmkzin)]

Present in 8.10, 2.6.27-7-server.

[Jonathan Stewart (reaper-fudo)]

I want to chime in with my experience. I have 2 machines, one 8.10, one 8.04.1. I have the same problem on both machines.

On both of them, I have DHCP working on eth0, and a static alias on eth0:0. They are connected via an ethernet switch.

When I start networking, Internet Systems Consortium DHCP Client V3.0.6 starts up, broadcasts, gets a DCHP address, and then:

SIOCSIFFLAGS: Cannot assign requested address

This is NOT a harmless error: the IP address is never assigned to eth0. However, eth0:0 comes up correctly, properly configured as i expect.

I do not know why it cannot assign the requested address with the scripts, when there is no problem assigning the same address via ifconfig. I will continue to investigate the source of the problem.

[Jonathan Stewart (reaper-fudo)]

Update: I have found the source of my problem.

I had a custom script (related to dynamic DNS) in /etc/network/if-up.d/

The script was failing, and as a result, the DCHP aquired address was not getting assigned to the interface. It appears that if any of the if-up.d scripts fail, this will interrupt the correct operation of DCHP.

Additionally, i still get the error "SIOCSIFFLAGS: Cannot assign requested address". I do not know why... this indicates some kind of failure, but all IP configuration is completed as normal. I have DCHP on eth0, and a static IP addr on eth0:0.

I apologize for the noise, as it now seems my trouble report is not related to the problems described by other contributors.

[Tom Metro (tmetro+ubuntu)]

Tormod Volden wrote:
> The seven first comments indicate that this is a harmless warning and that things otherwise
> work well. Later some people join in with various problems that are not necessarily due the
> warning.
>
> Please file new bugs for these different problems.

This seems like a good suggestion.

This bug deals with virtual interfaces triggering a "SIOCSIFFLAGS: Cannot assign requested address" warning, while still succeeding, and can be remedied by removing or patching the /etc/network/if-pre-up.d/wireless-tools file.

I've created Bug #351378 to track the issue where DHCP fails to work for a virtual interface, when a DHCP client is used directly, or indirectly via the /etc/network/interfaces config file, and is unaffected by the /etc/network/if-pre-up.d/wireless-tools file.

The two bugs may have a common underlying cause, but superficially they have different symptoms.

[Tom Metro (tmetro+ubuntu)]

PetyrRahl wrote:
> If for some reason the network goes down, I have to remember to manually bring up
> eth0:0 otherwise my site is unaccessible for my external clients.

I believe that symptom is addressed in Bug #95968.

[Alex Wiechert (wiechert)]

>This bug deals with virtual interfaces triggering a "SIOCSIFFLAGS: Cannot assign requested address" warning, while still succeeding, >and can be remedied by removing or patching the /etc/network/if-pre-up.d/wireless-tools file.

I can say that it is still not fixed with any of the above workarounds. On my servers there is no one of the virtual interfaces working.
I have no DHCP activated or wireless tool. I defenitly can not work with virtual IPAdresses.

[rdark (7-launchpad-fohnet-co-uk)]

Found workaround for jaunty:
apt-get purge wireless-tools: doesn't actually clear out wireless-tools (why is it installed on a server anyway?)
rm /etc/network/if-pre-up.d/wireless-tools: still doesn't fix the problem:

Remaining problematic script seems to be a symlink to ../../wpa_supplicant/ipupdown.sh at /etc/if-up.d/wapsupplicant. removing this allowed the aliases to come up at boot.

on a test VM, apt-get purge wpasupplicant seemed to remove this script entirely and had the same affect.

[Slim Amamou (slim-amamou)]

I have the same problem in 9.10 Karmic. My /etc/network/if-pre-up.d/wireless-tools is already patched. But it does not seem to solve the problem. Removing wireless-tools is not an option since gnome desktop depends on it.

[Slim Amamou (slim-amamou)]

Oh, I meant ubuntu-desktop package depends on wireless-tools. But it seems that ubuntu-desktop is a metapackage, so it's ok to remove it.

[Slim Amamou (slim-amamou)]

removing wireless-tools did not solve the problem for me. note: removing the package did not actually remove /etc/network/if-pre-up.d/wireless-tools I had to remove it by hand. Nevertheless this did not solve the problem.

[Mikael Sjöberg (misjob)]

remove: auto eth0:0

[DinkyDogg (dinkydogg)]

Problem still exists in Ubuntu 10.04 server. Removing package wireless-tools did not help. Neither did removing "auto eth0:0".

root@dinkydogg:~# ifup eth0:0
udhcpc (v0.9.9-pre) started
SIOCSIFFLAGS: Cannot assign requested address
Sending discover...
Sending select for 128.12.130.93...
Lease of 128.12.130.93 obtained, lease time 172800
Resetting default routes
SIOCADDRT: No such device
adding dns 171.64.7.121
adding dns 171.64.7.55
adding dns 171.64.7.77
ssh stop/waiting
ssh start/running, process 6143

After doing this, eth0:0 does NOT show up in ifconfig. However, trying ifup again results in:

root@dinkydogg:~# ifup eth0:0
ifup: interface eth0:0 already configured

Doing ifdown results in:

root@dinkydogg:~# ifdown eth0:0
SIOCSIFFLAGS: Cannot assign requested address

But then I'm able to bring it back up with ifup.

What the heck... Any ideas?

[kfsone (kfsone)]

/etc/lsb-release
8x--- snip ---x8
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=10.04
DISTRIB_CODENAME=lucid
DISTRIB_DESCRIPTION="Ubuntu 10.04.2 LTS"
8x--- snip ---x8

/etc/network/interfaces
8x--- snip ---x8
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto eth0
iface eth0 inet static
        address 66.28.224.182
        netmask 255.255.255.192
        network 66.28.224.128
        broadcast 66.28.224.191
        gateway 66.28.224.222
        # dns-* options are implemented by the resolvconf package, if installed
        dns-nameservers 66.28.224.129
        dns-search wwiionline.com

auto eth0:0
iface eth0:0 inet static
        address 66.28.224.181
        netmask 255.255.255.192
        network 66.28.224.128
        broadcast 66.28.224.191
8x--- snip ---x8

root# ifconfig eth0:0 up
SIOCSIFFLAGS: Cannot assign requested address
root# ifup eth0:0
stop: Unknown instance:
ssh start/running, process 2074
root#

[Rolf Leggewie (r0lf)]

Hardy has seen the end of its life and is no longer receiving any updates. Marking the Hardy task for this ticket as "Won't Fix".