Answered in post below

I have a network interface I don't recognize or understand.

ip a s provides the following (sanitized) output:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: wlp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
    inet 192.xxx.xx.xxx/xx brd 192.xxx.xx. scope global dynamic noprefixroute wlp2s0
       valid_lft 2347sec preferred_lft 2347sec
    inet6 xxxx::xxxx:xxxx:xxxx:xxxx/xx scope link noprefixroute 
       valid_lft forever preferred_lft forever
4: enx9cebe80718e1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
    link/ether xx:xx:xx:xx:xx:x brd ff:ff:ff:ff:ff:ff

The relevant output from ifconfig (which I installed for familiarity) is:

enx9cebe80718e1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        ether xx:xx:xx:xx:xx:xx  txqueuelen 1000  (Ethernet)
        RX packets 138  bytes 30067 (30.0 KB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 573  bytes 98070 (98.0 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Traffic is happening, but small.

My understanding of networks is next to nothing, but nevertheless, all the interfaces I have seen are short, e.g. wlp2s0.

My question is, what is enx9cebe80718e1? And where is the entry for 3:?

system and background:

  • Lubuntu 18.04 (recent reinstallation due to confirmed hack) on a Dell XPS13 L321x.
  • Internet connection via a) Android phone's hotspot (now), b) wireless 4G dongle (last fornight)
  • wireguard is usually on, but was not for the info provided in this post
  • rkhunter a short time ago gave clean bill of health, but I don't update that regularly.
  • ufw is enabled. (So too is fail2ban)

marked as duplicate by Ipor Sircer, GAD3R, sam, RalfFriedl, elbarna Nov 20 '18 at 17:57

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • 1
    Related unix.stackexchange.com/questions/479094/… – GAD3R Nov 19 '18 at 8:11
  • sudo udevadm info -q all -p /sys/class/net/enx9cebe80718e1 might be helpful in identifying it. ID_BUS will indicate the bus type (PCI(e), USB or something else), ID_NET_DRIVER identifies the driver module running the NIC, and so on. – telcoM Nov 19 '18 at 11:12

Conclusion Seems that this is my system's interface for a usb3 hub I have, using the device's MAC address.

sudo udevadm info -q all -p /sys/class/net/enx9cebe80718e1 was very useful (thanks @telcoM).

I believe this confusion has something to do with systemd/udev. (Previous installations (Lubuntu) did not present like this.)

Following reference in @Debian_yadav's answer, Naming convention standard for Ethernet and Wi-Fi interfaces on Linux machines I found freedesktop.org's entry on systemd and Predictable Network Interface Names.

With systemd 197 we have added native support for a number of different naming policies into systemd/udevd proper and made a scheme similar to biosdevname's (but generally more powerful, and closer to kernel-internal device identification schemes) the default. The following different naming schemes for network interfaces are now supported by udev natively:

  1. Names incorporating Firmware/BIOS provided index numbers for on-board devices (example: eno1)
  2. Names incorporating Firmware/BIOS provided PCI Express hotplug slot index numbers (example: ens1)
  3. Names incorporating physical/geographical location of the connector of the hardware (example: enp2s0)
  4. Names incorporating the interfaces's MAC address (example: enx78e7d1ea46da)
  5. Classic, unpredictable kernel-native ethX naming (example: eth0)

By default, systemd v197 will now name interfaces following policy 1) if that information from the firmware is applicable and available, falling back to 2) if that information from the firmware is applicable and available, falling back to 3) if applicable, falling back to 5) in all other cases. Policy 4) is not used by default, but is available if the user chooses so.

Oddly, my hub triggers rule 4. I don't know why - I don't remember doing it (I don't know how!).

EDIT it turns out its not the usb hub, its the USB/ethernet adapter plugged in to it (whether or not it has a network cable attached).

Same reference claims that these address/names are stable across reboots (mine handled an un-/re-plugging of the hub), but note some complain of lingering instability.

Thanks all.


That interface is named using new feature called "consistent interface naming". There is nothing wrong with that interface. It doesn't have an IP address, maybe it's not even plugged in. Don't worry about it.

Not the answer you're looking for? Browse other questions tagged or ask your own question.