2

When i create a dummy network interface and then bring it up it show up being in UNKNOWN state:

root@5b8dd2855a9c:# ip l a boom type dummy
root@5b8dd2855a9c:# ip l show boom
58: boom: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN mode DEFAULT
    link/ether 1e:f6:4b:60:ff:1a brd ff:ff:ff:ff:ff:ff
root@5b8dd2855a9c:# ip l set boom up
root@5b8dd2855a9c:# ip l show boom
58: boom: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state **UNKNOWN** mode DEFAULT
    link/ether 1e:f6:4b:60:ff:1a brd ff:ff:ff:ff:ff:ff
root@5b8dd2855a9c:#

Anyone knows why ? I tried assigning an IP address to it, but that did not resolve the issue.

I tested this on the following machine:

root@5b8dd2855a9c:# uname -a
Linux 5b8dd2855a9c 3.16.1-tinycore64 #1 SMP Fri Aug 22 05:53:09 UTC 2014 x86_64 GNU/Linux
root@5b8dd2855a9c:#

Update:

So it seems that this does not make the interface inoperable. After some slavish Googling I came across this info

Improve this question
3
  • It would be helpful if you would explain what the real problem is.
    – Michael Hampton
    Sep 18, 2014 at 23:27
  • The behavior appears normal. I see the same thing on a the tun interfaces that OpenVPN creates that are active and functioning properly. I also see state unknown on dummy interfaces I use for other purposes. Is something actually not working?
    – Zoredache
    Sep 18, 2014 at 23:43
  • No, this is a question out of curiosity, as I would expect the interface to be in the state UP as oppose to UNKNOWN. It's not that something is working or not. It's that it does not make much sense to me. Would you expect this behavior ?
    – milosgajdos
    Sep 19, 2014 at 0:03

1 Answer 1

Reset to default
5

Looking at the drivers/net/dummy.c and include/linux/netdevice.h, it seems that dummy network interface driver only implements a small subset of network device operations:

From line 112 of drivers/net/dummy.c we learn that:

static const struct net_device_ops dummy_netdev_ops = {
    .ndo_init       = dummy_dev_init,
    .ndo_uninit     = dummy_dev_uninit,
    .ndo_start_xmit     = dummy_xmit,
    .ndo_validate_addr  = eth_validate_addr,
    .ndo_set_rx_mode    = set_multicast_list,
    .ndo_set_mac_address    = eth_mac_addr,
    .ndo_get_stats64    = dummy_get_stats64,
    .ndo_change_carrier = dummy_change_carrier,
};

While when looking at include/linux/netdevice.h, where struct net_device_ops is defined, there seems to be (on line 1057 to be exact):

int         (*ndo_set_vf_link_state)(struct net_device *dev,
                         int vf, int link_state);

Where does this leave us in terms of giving an answer to your question, instead of just putting a wall of text here and hoping to score +10? Well, the answer is kind of yes and no.

The source reveals that yes, the state UNKNOWN is expected behaviour because there is nothing that would ever set the state, thus it definitely should be UNKNOWN. On the other hand it is reasonable to expect that a user bringing a dummy interface up should see the state to change. A classical example of reasonable expectations from the user perspective not met by a piece of kernel.

Next question might then be: Is this a bug? Should it be fixed? That is beyond the scope if this answer, though it certainly is possible to fix this, should one desire to do so. However, it might be worth noting that the dummy interface has been in the kernel for quite some time, 20 years to be exact. Back in 1994 presenting a correct link state for the dummy interface to the userland wasn't much of a priority, I guess.

Improve this answer
0

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .