ifconfig dummy0 : Device not found

Bug #1828749 reported by John Denker
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
ifupdown (Ubuntu)
Invalid
Low
Unassigned
kmod (Ubuntu)
Invalid
Undecided
Unassigned
net-tools (Ubuntu)
Invalid
Low
Unassigned
systemd (Ubuntu)
Invalid
Undecided
Unassigned

Bug Description

Desired behavior:
  The ifconfig command should be able to deal with the
  dummy device. This worked fine until recently.

Observed behavior:
  :; ifconfig dummy0
  dummy0: error fetching interface information: Device not found

  This problem appeared when I upgraded to bionic.

Highly informative workaround:
  :; ip link add dummy0 type dummy
  That command works, and makes the problem go away permanently.
  The ifconfig command works fine after that.
  The ifup and ifdown commands also work fine after that.

  For convenient debugging, you can use the command:
  :; ip link del dummy0 type dummy
  which makes the problem come back.
  You can also experiment with dummy1 et cetera.

Package ownership issues:
  Compare: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=909204
  That report was filed against ippusbxd, which is almost certainly
  not the relevant package.

  For that matter, I have no idea whether the root cause is in the
  net-tools package or the kernel networking stack. All I know is
  the ip command plays nicely with the kernel while the ifconfig
  command does not.

Notes:
  The kernel module for the dummy interface is preloaded in
  all situations described here. That's not the issue.

  An apport file is attached, to describe the environment.
  Also, since you asked:

  :; apt-cache policy net-tools
net-tools:
  Installed: 1.60-26ubuntu1
  Candidate: 1.60-26ubuntu1
  Version table:
 *** 1.60-26ubuntu1 500
        500 http://ubuntu.cs.utah.edu/ubuntu xenial/main amd64 Packages
        100 /var/lib/dpkg/status

  :; lsb_release -rd
  Description: Ubuntu 16.04.6 LTS
  Release: 16.04

Revision history for this message
John Denker (lp-8) wrote :
Revision history for this message
John Denker (lp-8) wrote :

I put the attached file in if-pre-up.d/dummy-workaround
to make my system work reliably.

Revision history for this message
John Denker (lp-8) wrote :

Here's the workaround.

Revision history for this message
Robie Basak (racb) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better.

Please could you provide an example of reproduction steps showing the behaviour you're expecting working with "This worked fine until recently"? Perhaps you'll need an older Ubuntu release, older kernel package, or older net-tools package to do this. Once done, please change the bug status back to New.

ifconfig is still maintained but deprecated in favour of ip(8). So while this may well be a valid bug that we should fix, I don't think it is of high importance any more, unless it is a regression caused by an update in an existing stable release (and there's no evidence of that in your report). So I'm setting Importance: Low for now.

Changed in net-tools (Ubuntu):
status: New → Incomplete
importance: Undecided → Low
Revision history for this message
John Denker (lp-8) wrote :

*) As for priority: It's not as low as you might imagine.
The problem affects not just ifconfig but also ifup, which is
indispensable. It also affects the "raise network interface"
target at boot time, as triggered by "auto dummy0" directives
in /etc/network/interfaces.

Symptom:
:; ifup dummy0
Cannot find device "dummy0"
Failed to bring up dummy0.

This was hinted at in the original report but not emphasized.
I emphasize it now. I mentioned ifconfig because it is the
/simplest/ way to exhibit the bug. Feel free to change the
headline of this bug to "ifup" (rather than "ifconfig") and
transfer it to the ifupdown package (rather than net-tools)
if you wish.

This bug means that when I upgraded my machine remotely, it
became unreachable, because the dummy0 interface carried the
stable IP address that I was using. It took a great deal
of work on my part to devise a workaround.

*) In answer to your question: "until recently" means until
I upgraded from xenial to bionic. I have another system still
running xenial where ifconfig, ifup, and "raise network interface"
all continue to work fine. The kernel version is exactly the
same, 4.19.42; this may help you determine whether the
regression is in user space and/or kernel space.

On the other side of the same coin, I have yet another system
with a squeaky clean bionic (installed ab_initio, not upgraded)
that exhibits all the same problems with ifconfig, ifup, and
"raise network interface". So it appears to be a bionic issue.

I have no easy way to test the releases that came between
xenial and bionic. All I know is that bionic is the latest
LTS. It's supposed to be supported, and it's broken in a
way that caused me a lot of grief.

*) FURTHERMORE, there is nothing in the ifconfig man page to
suggest that it is in any way deprecated. What's the deal?
Choose your farce:
-- Is it on double-secret probation? (Animal House)
-- Doesn't it defeat the purpose of a deterrent if
  you keep it a secret? (Dr. Strangelove)
-- Is perhaps the notice on display in the bottom of a
  locked filing cabinet stuck in a disused lavatory with
  a sign on the door saying "Beware of the Leopard"?
  (Hitchhiker's Guide)

If it really is deprecated and unsupported, somebody
should file a separate bug against the documentation.

Revision history for this message
Robie Basak (racb) wrote : Re: [Bug 1828749] Re: ifconfig dummy0 : Device not found

Thank you for the additional information.

If you hit the bug in an upgrade from Xenial to Bionic, then why did you
report version 1.60-26ubuntu1 of net-tools as affected? This version
shipped with Xenial, not Bionic. Please could you confirm the version of
net-tools that affects you with this problem on Bionic?

I accept that an upgrade from Xenial to Bionic that uses ifupdown will
continue to do so. I hadn't considered that. However, use of dummy0 in
the way that you are doing seems to me to be an unusual end-user
configuration, so I think it still qualifies as Importance: Low against
https://wiki.ubuntu.com/Bugs/Importance. In any case the Importance
doesn't really matter; I just want to set the expectation that you
shouldn't expect developers to jump on this for you, since Bionic was
released over a year ago now and you appear to be the only person
affected by this problem.

On Tue, May 14, 2019 at 08:01:16PM -0000, John Denker wrote:
> If it really is deprecated and unsupported, somebody
> should file a separate bug against the documentation.

I didn't say it was unsupported. Patches are welcome. I specifically did
say it is still maintained. However everything that you can do with
ifconfig you can do with ip(8), and there are many modern networking
things that ifconfig does not support. ip(8) was written to replace it.

Changed in net-tools (Ubuntu):
status: Incomplete → New
Revision history for this message
Robie Basak (racb) wrote :

Note that net-tools will no longer be installed by default from Eoan onwards. The default with the primary server installer on Bionic is to use systemd-networkd via netplan, not ifupdown. Both ifconfig and ifupdown are slowly passing through the various levels of deprecation in future releases of Ubuntu, although they are available (and will continue to be available) in Bionic.

tags: added: bionic regression-release
Revision history for this message
John Denker (lp-8) wrote :

Can you please transfer this to the ifupdown package?
Or should I just resubmit it from scratch?
The discussions of the importance of ifconfig are beside the point.
The problem presented itself during boot-up, in connection with
an "auto dummy0" directive in /etc/network/interfaces.

If "auto dummy0" and "ifup dummy0" are not maintained then why
bother to have a dummy device at all? This is the most important
context, although there are MANY others. I reported the ifconfig
context because it is the /simplest/ ... not the only manifestation.

And no, I'm definitely not the first person to encounter the bug.
I'm just the first to report it through this channel. My first
message in this thread linked to a report that came up in another
context.

As for the software versions:
I must have typed the "apt-cache policy net-tools" in the wrong
window at one point. As stated before that and after that, the
fact is that bionic is buggy while xenial is not. Specifically,
the buggy packages are:

:; apt-cache policy net-tools
net-tools:
  Installed: 1.60+git20161116.90da8a0-1ubuntu1
  Candidate: 1.60+git20161116.90da8a0-1ubuntu1
  Version table:
 *** 1.60+git20161116.90da8a0-1ubuntu1 500
        500 http://us.archive.ubuntu.com/ubuntu bionic/main amd64 Packages
        100 /var/lib/dpkg/status

and perhaps more to the point:

:; apt-cache policy ifupdown
ifupdown:
  Installed: 0.8.17ubuntu1.1
  Candidate: 0.8.17ubuntu1.1
  Version table:
 *** 0.8.17ubuntu1.1 500
        500 http://us.archive.ubuntu.com/ubuntu bionic-updates/main amd64 Packages
        100 /var/lib/dpkg/status
     0.8.17ubuntu1 500
        500 http://us.archive.ubuntu.com/ubuntu bionic/main amd64 Packages

Revision history for this message
Robie Basak (racb) wrote :

I'll add an ifupdown bug task for you.

> If "auto dummy0" and "ifup dummy0" are not maintained then why
bother to have a dummy device at all?

We haven't discussed that, since that wasn't the failing use case you presented in your original report! I appreciate that you narrowed down the root cause to your reported change in behaviour in ifconfig, but for judging importance and priority, it is the use case that matters.

Please could you provide full steps to reproduce your ifupdown use case that works in Xenial but fails in Bionic? Including a sample /etc/network/interfaces, details of why you're using dummy0, what documentation directed you to do that, etc. Then we can refer to the same understanding of your situation as a starting point.

Changed in ifupdown (Ubuntu):
status: New → Incomplete
Revision history for this message
John Denker (lp-8) wrote :

Msg 1 of 2: Here is a use-case for ifup dummy0 and ifdown dummy0:

I have multiple laptops. Sally has multiple laptops. Sometimes they are wired (for speed) and sometimes wireless (for portability). Sometimes we are at the same workplace, or at my abode, or her abode, or the local library, or the local cantina. Sometimes I am at some unfamiliar place, tasked with figuring out what's wrong with the local computer setup.

That means many different DHCP servers, most of which I do not control. They do not all perform dynamic DNS in any reasonable way. It would of course be elegant to set up dynamic DNS, but that would be a lot of work in the best case, and would not be reliable in corner cases.

I find it advantageous to bring up a dummy interface with a static address, and match that with a static entry in /etc/hosts. That simplifies the task of contacting this-or-that machine. No routing is required, because the interface will ARP the dummy address as well as the DHCP-assigned address.

See next message for test and usage details.

Revision history for this message
John Denker (lp-8) wrote :

Message 2 of 2: This is easy to use and/or test ifup dummy0 and ifdown dummy0

You don't need to know the complexities of the motivation for why this is important; the test case is very simple.

In the context of the ifupdown package, this requires putting a stanza like this in /etc/network/interfaces or /etc/network/interfaces.d/dummy:
auto dummy0
iface dummy0 inet static
  netmask 255.255.255.255
  address 10.10.2.105

Then the static dummy interface (a) should come up automagically at boot time, and can be further controlled by
:; ifup dummy0
:; ifdown dummy0

Desired behavior: It should just work.

Observed behavior:
:; ifup dummy0
Cannot find device "dummy0"
Failed to bring up dummy0.

Highly informative workaround:
  :; ip link add dummy0 type dummy
  That command works, and makes the problem go away permanently.
  The ifup and ifdown commands work fine after that.

  For convenient debugging, you can use the command:
  :; ip link del dummy0 type dummy
  which makes the problem come back.
  You can also experiment with dummy1 et cetera.

See the detailed workaround script attached previously.

FWIW the ifconfig command exhibits all the same misbehavior; net-tools and ifupdown are affected in the same way, but remarkably enough the ip command (from the iproute2 package) is apparently not affected by this bug.

Revision history for this message
John Denker (lp-8) wrote :

To reiterate and clarify: net-tools and ifupdown both exhibit the bug in bionic, whereas neither exhibits the bug in xenial. The bug is observed in the following package versions:

:; apt-cache policy net-tools
net-tools:
  Installed: 1.60+git20161116.90da8a0-1ubuntu1
  Candidate: 1.60+git20161116.90da8a0-1ubuntu1
  Version table:
 *** 1.60+git20161116.90da8a0-1ubuntu1 500
        500 http://us.archive.ubuntu.com/ubuntu bionic/main amd64 Packages
        100 /var/lib/dpkg/status

and

:; apt-cache policy ifupdown
ifupdown:
  Installed: 0.8.17ubuntu1.1
  Candidate: 0.8.17ubuntu1.1
  Version table:
 *** 0.8.17ubuntu1.1 500
        500 http://us.archive.ubuntu.com/ubuntu bionic-updates/main amd64 Packages
        100 /var/lib/dpkg/status
     0.8.17ubuntu1 500
        500 http://us.archive.ubuntu.com/ubuntu bionic/main amd64 Packages

Revision history for this message
Robie Basak (racb) wrote :

Thank you for the additional information. I think this report is now complete, and I think I understand exactly what you mean and how you are affected.

Unfortunately the use cases you have presented don't change my opinion that this is an unusual end-user configuration that is unlikely to affect the majority of Ubuntu users. Therefore I don't intend to prioritise working on it and don't expect other developers to volunteer their time to do so.

My opinion will of course change if it turns out that there is some other use case that is likely to impact a wider range of Ubuntu users.

Volunteers to investigate this problem deeper are welcome. Please do continue to use this bug to coordinate any efforts.

Changed in ifupdown (Ubuntu):
status: Incomplete → New
importance: Undecided → Low
Revision history for this message
John Denker (lp-8) wrote :

I have conducted more investigation into the cause, resulting in a significant restatement of the issue.

As far as this bug is concerned, it appears there has been no regression, indeed no change in behavior in ifconfig (net-tools package) or ifup (ifupdown package). However it could be argued that all along they have not handled dummy devices very well.

The big change appears to be in modprobe (kmod package). As of xenial it behaved the same is insmode (also kmod package) but as of bionic it behaves differently. In particular, insmod tickles the device in such a way that dummy0 comes into existence (in a down state) whereas bionic modprobe leaves it nonexistent. (Higher-numbered devices such as dummy1 are nonexistent in all cases, when the module is newly installed.)

The "ip link add" command is fully capable of bringing a dummy device into existence, but apparently neither ifconfig nor ifup has ever had this capability. This is a problem for dummy1 (always) and, what's worse, for dummy0 (as of bionic).

You can see the gory details by comparing the typescripts attached to this comment (for xenial) and the next (for bionic).

So ... even though the change in behavior occurred in modprobe, it could be argued that the new modprobe behavior is more logical, because it treats dummy0 and dummy1 the same now. By the same token, since dummy1 was never handled well by ifconfig or ifup, it could be argued that the best way to proceed would be to make those programs more robust. Crib the code from "ip link add" to bring the device into existence when appropriate.

Revision history for this message
John Denker (lp-8) wrote :

Contrasting attachment, as discussed in previous comment.

Revision history for this message
Paride Legovini (paride) wrote :

Thanks for sharing your findings. What you found out is indeed interesting, however I'm not sure you can say the change happened in modprobe, as you are using two different kernel versions. Perhaps insmod and modprobe always behaved differently, and what changed is what the kernel does.

Your suggestion for a more robust handling of dummy interfaces makes sense, however even if this were done I don't think your use case alone would be enough to justify an upgrade in Bionic (a so-called Stable Release Upgrade). On the other side, newer releases of Ubuntu are switching from ifupdown to netplan, so at this point it is unlikely that any active work will be put into ifupdown unless there is a compelling reason to do so.

Should a wider-impact use case come up then we will certainly re-evaluate the importance of this report.

Revision history for this message
John Denker (lp-8) wrote :

Here is better evidence.
Just now I ran the experiment using same kernel version, 4.19.42,
as in the xenial experiment reported above.

My conclusions are unchanged. The newly-introduced incompatible
and inconsistent behavior depends on the modprobe release, not
on the kernel release. I knew this to be true, as stated
previously, but now we have clearer evidence on the record.

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

Hi,
I come by trying to clear old bugs that were dormant for too long either resolving or reviving them.

First of all I can confirm what you have found (insmod vs modprobe changes), but I also found why.

I've found that this makes modprobe work like before:
  modprobe dummy numdummies=1

So I wondered if only the default config changed.

modprobe uses config files and it picks up defaults from /lib/modprobe.d/ and /etc/modprobe.d/.

And in there I found:
root@b:~# cat /lib/modprobe.d/systemd.conf
...
# When bonding module is loaded, it creates bond0 by default due to max_bonds
# option default value 1. This interferes with the network configuration
# management / networkd, as it is not possible to detect whether this bond0 was
# intentionally configured by the user, or should be managed by
# networkd/NM/etc. Therefore disable bond0 creation.
options bonding max_bonds=0
# Do the same for dummy0.
options dummy numdummies=0

That is the reason the new default number of dummies is zero when using modprobe.
You can change via a config file or pass numdummies=1 to modprobe to resolve that.

The default value was discussed upstream (denied) and the same problem but from a "where to configure" POV in Ubuntu (see bug 1937953).
Following that bug 1937953 and marking this one invalid as I think it is explained and not something that will be fixed/changed in the package.
That bug also has some hints on how to overwrite that default config as there are some intricacies in regard to "which overwrites which" for these conffiles.

Changed in net-tools (Ubuntu):
status: New → Invalid
Changed in ifupdown (Ubuntu):
status: New → Invalid
Changed in kmod (Ubuntu):
status: New → Invalid
Changed in systemd (Ubuntu):
status: New → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.