# Predictable Network Interface Names Not Predictable

## BHReach

I have 2 USB wifi adapters connected to my computer. One of them is fine but the other changes its name on the fly while in use.

Both adapters have RT3072 chipset; however, they are made by different manufacturers.

From lsusb:

```
Bus 002 Device 002: ID 148f:3072 Ralink Technology, Corp. RT3072 Wireless Adapter

Bus 004 Device 002: ID 148f:3072 Ralink Technology, Corp. RT3072 Wireless Adapter
```

From syslog, you can see the original assigned names during boot:

```
Oct 19 03:42:17 localhost kernel[17645]: renamed network interface wlan1 to wlp0s19f2u1

Oct 19 03:42:17 localhost kernel[17639]: renamed network interface wlan0 to wlp0s18f2u5
```

Later on you can see the interface name was reassigned:

```
Oct 19 05:57:34 localhost kernel[7058]: renamed network interface wlan0 to wlp0s18f0u5
```

Here is more details from the syslog so you can see how this happened.

Boot sequence:

```
Oct 19 03:42:17 localhost kernel: ieee80211 phy1: rt2x00lib_request_firmware: Info - Firmware detected - version: 0.29

Oct 19 03:42:25 localhost /etc/init.d/net.wlp0s19f2u1[18304]: WARNING: net.wlp0s19f2u1 has started, but is inactive

Oct 19 03:42:25 localhost /etc/init.d/netmount[18407]: ERROR: cannot start netmount as net.wlp0s18f0u5 would not start

Oct 19 03:42:25 localhost /etc/init.d/sshd[18408]: ERROR: cannot start sshd as net.wlp0s18f0u5 would not start

Oct 19 03:42:25 localhost cron[18420]: (CRON) STARTUP (V5.0)

Oct 19 03:42:25 localhost kernel: NET: Registered protocol family 10

Oct 19 03:42:25 localhost kernel: IPv6: ADDRCONF(NETDEV_UP): wlp0s19f2u1: link is not ready

Oct 19 03:42:27 localhost kernel: wlp0s19f2u1: authenticate with 00:1d:7e:64:9e:27

Oct 19 03:42:27 localhost kernel: wlp0s19f2u1: send auth to 00:1d:7e:64:9e:27 (try 1/3)

Oct 19 03:42:27 localhost kernel: wlp0s19f2u1: send auth to 00:1d:7e:64:9e:27 (try 1/3)

Oct 19 03:42:27 localhost kernel: wlp0s19f2u1: authenticated

Oct 19 03:42:27 localhost kernel: rt2800usb 2-1:1.0 wlp0s19f2u1: disabling HT as WMM/QoS is not supported by the AP

Oct 19 03:42:27 localhost kernel: rt2800usb 2-1:1.0 wlp0s19f2u1: disabling VHT as WMM/QoS is not supported by the AP

Oct 19 03:42:27 localhost kernel: wlp0s19f2u1: associate with 00:1d:7e:64:9e:27 (try 1/3)

Oct 19 03:42:27 localhost kernel: wlp0s19f2u1: RX AssocResp from 00:1d:7e:64:9e:27 (capab=0x401 status=0 aid=2)

Oct 19 03:42:27 localhost kernel: wlp0s19f2u1: associated

Oct 19 03:42:27 localhost kernel: IPv6: ADDRCONF(NETDEV_CHANGE): wlp0s19f2u1: link becomes ready

Oct 19 03:42:27 localhost wpa_cli: interface wlp0s19f2u1 CONNECTED

Oct 19 03:42:33 localhost login[18435]: pam_lastlog(login:session): file /var/log/lastlog created

Oct 19 03:42:33 localhost login[18435]: pam_unix(login:session): session opened for user root by LOGIN(uid=0)

Oct 19 03:42:33 localhost login[18630]: ROOT LOGIN  on '/dev/tty1'

Oct 19 03:45:37 localhost kernel: ieee80211 phy0: rt2x00lib_request_firmware: Info - Loading firmware file 'rt2870.bin'

Oct 19 03:45:37 localhost kernel: ieee80211 phy0: rt2x00lib_request_firmware: Info - Firmware detected - version: 0.29

Oct 19 03:45:37 localhost kernel: IPv6: ADDRCONF(NETDEV_UP): wlp0s18f2u5: link is not ready

Oct 19 03:45:37 localhost /etc/init.d/net.wlp0s18f2u5[18640]: WARNING: net.wlp0s18f2u5 has started, but is inactive

Oct 19 03:45:39 localhost kernel: wlp0s18f2u5: authenticate with 00:26:62:57:28:5a

Oct 19 03:45:39 localhost kernel: wlp0s18f2u5: send auth to 00:26:62:57:28:5a (try 1/3)

Oct 19 03:45:39 localhost kernel: wlp0s18f2u5: authenticated

Oct 19 03:45:39 localhost kernel: rt2800usb 1-5:1.0 wlp0s18f2u5: disabling HT/VHT due to WEP/TKIP use

Oct 19 03:45:39 localhost kernel: wlp0s18f2u5: associate with 00:26:62:57:28:5a (try 1/3)

Oct 19 03:45:39 localhost kernel: wlp0s18f2u5: RX AssocResp from 00:26:62:57:28:5a (capab=0x431 status=0 aid=7)

Oct 19 03:45:39 localhost kernel: wlp0s18f2u5: associated

Oct 19 03:45:39 localhost kernel: IPv6: ADDRCONF(NETDEV_CHANGE): wlp0s18f2u5: link becomes ready

Oct 19 03:45:39 localhost wpa_cli: interface wlp0s18f2u5 CONNECTED
```

Renaming sequence:

```
Oct 19 05:47:45 localhost kernel: ieee80211 phy1: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 11 in queue 2

Oct 19 05:47:45 localhost kernel: ieee80211 phy1: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 11 in queue 2

Oct 19 05:47:45 localhost kernel: ieee80211 phy1: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 11 in queue 2

Oct 19 05:47:45 localhost kernel: ieee80211 phy1: rt2800usb_txdone: Warning - Got TX status for an empty queue 2, dropping

Oct 19 05:47:48 localhost kernel: ieee80211 phy1: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 5 in queue 2

Oct 19 05:47:48 localhost kernel: ieee80211 phy1: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 5 in queue 2

Oct 19 05:47:48 localhost kernel: ieee80211 phy1: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 5 in queue 2

Oct 19 05:47:48 localhost kernel: ieee80211 phy1: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 6 in queue 2

Oct 19 05:47:48 localhost kernel: ieee80211 phy1: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 7 in queue 2

Oct 19 05:47:48 localhost kernel: ieee80211 phy1: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 8 in queue 2

Oct 19 05:47:48 localhost kernel: ieee80211 phy1: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 9 in queue 2

Oct 19 05:47:48 localhost kernel: ieee80211 phy1: rt2800usb_txdone: Warning - Got TX status for an empty queue 2, dropping

Oct 19 05:47:48 localhost kernel: ieee80211 phy1: rt2800usb_txdone: Warning - Got TX status for an empty queue 2, dropping

Oct 19 05:47:48 localhost kernel: ieee80211 phy1: rt2800usb_txdone: Warning - Got TX status for an empty queue 2, dropping

Oct 19 05:47:48 localhost kernel: ieee80211 phy1: rt2800usb_txdone: Warning - Got TX status for an empty queue 2, dropping

Oct 19 05:47:49 localhost kernel: ieee80211 phy1: rt2800usb_txdone: Warning - Got TX status for an empty queue 2, dropping

Oct 19 05:50:01 localhost cron[26489]: (root) CMD (test -x /usr/sbin/run-crons && /usr/sbin/run-crons)

Oct 19 05:51:10 localhost kernel: ieee80211 phy1: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 14 in queue 2

Oct 19 05:51:10 localhost kernel: ieee80211 phy1: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 14 in queue 2

Oct 19 05:51:10 localhost kernel: ieee80211 phy1: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 14 in queue 2

Oct 19 05:51:10 localhost kernel: ieee80211 phy1: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 15 in queue 2

Oct 19 05:51:11 localhost kernel: ieee80211 phy1: rt2800usb_txdone: Warning - Got TX status for an empty queue 2, dropping

Oct 19 05:51:11 localhost kernel: ieee80211 phy1: rt2800usb_txdone: Warning - Got TX status for an empty queue 2, dropping

Oct 19 05:54:13 localhost kernel: ieee80211 phy1: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 12 in queue 2

Oct 19 05:54:13 localhost kernel: ieee80211 phy1: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 12 in queue 2

Oct 19 05:54:13 localhost kernel: ieee80211 phy1: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 12 in queue 2

Oct 19 05:54:13 localhost kernel: ieee80211 phy1: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 13 in queue 2

Oct 19 05:54:13 localhost kernel: ieee80211 phy1: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 14 in queue 2

Oct 19 05:54:14 localhost kernel: ieee80211 phy1: rt2800usb_txdone: Warning - Got TX status for an empty queue 2, dropping

Oct 19 05:54:14 localhost kernel: ieee80211 phy1: rt2800usb_txdone: Warning - Got TX status for an empty queue 2, dropping

Oct 19 05:54:14 localhost kernel: ieee80211 phy1: rt2800usb_txdone: Warning - Got TX status for an empty queue 2, dropping

Oct 19 05:54:37 localhost kernel: ieee80211 phy1: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 8 in queue 2

Oct 19 05:54:37 localhost kernel: ieee80211 phy1: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 8 in queue 2

Oct 19 05:54:37 localhost kernel: ieee80211 phy1: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 8 in queue 2

Oct 19 05:54:37 localhost kernel: ieee80211 phy1: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 9 in queue 2

Oct 19 05:54:37 localhost kernel: ieee80211 phy1: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 10 in queue 2

Oct 19 05:54:37 localhost kernel: ieee80211 phy1: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 12 in queue 2

Oct 19 05:54:37 localhost kernel: ieee80211 phy1: rt2800usb_txdone: Warning - Got TX status for an empty queue 2, dropping

Oct 19 05:54:38 localhost kernel: ieee80211 phy1: rt2800usb_txdone: Warning - Got TX status for an empty queue 2, dropping

Oct 19 05:54:38 localhost kernel: ieee80211 phy1: rt2800usb_txdone: Warning - Got TX status for an empty queue 2, dropping

Oct 19 05:54:38 localhost kernel: ieee80211 phy1: rt2800usb_txdone: Warning - Got TX status for an empty queue 2, dropping

Oct 19 05:57:29 localhost kernel: usb 1-5: USB disconnect, device number 3

Oct 19 05:57:31 localhost wpa_cli: interface wlp0s18f2u5 DISCONNECTED

Oct 19 05:57:31 localhost wpa_cli: executing 'false /etc/init.d/net.wlp0s18f2u5 --quiet stop' failed

Oct 19 05:57:32 localhost kernel: ieee80211 phy0: rt2800_wait_wpdma_ready: Error - WPDMA TX/RX busy [0xffffffff]

Oct 19 05:57:32 localhost kernel: usb 1-5: new high-speed USB device number 7 using ehci-pci

Oct 19 05:57:33 localhost kernel: usb 4-5: new full-speed USB device number 2 using ohci_hcd

Oct 19 05:57:33 localhost kernel: usb 4-5: not running at top speed; connect to a high speed hub

Oct 19 05:57:33 localhost kernel: usb 4-5: New USB device found, idVendor=148f, idProduct=3072

Oct 19 05:57:33 localhost kernel: usb 4-5: New USB device strings: Mfr=1, Product=2, SerialNumber=3

Oct 19 05:57:33 localhost kernel: usb 4-5: Product: 802.11 n WLAN

Oct 19 05:57:33 localhost kernel: usb 4-5: Manufacturer: Ralink

Oct 19 05:57:33 localhost kernel: usb 4-5: SerialNumber: 1.0

Oct 19 05:57:33 localhost kernel: usb 4-5: reset full-speed USB device number 2 using ohci_hcd

Oct 19 05:57:33 localhost kernel: ieee80211 phy2: rt2x00_set_rt: Info - RT chipset 3071, rev 021c detected

Oct 19 05:57:34 localhost kernel: ieee80211 phy2: rt2x00_set_rf: Info - RF chipset 0008 detected

Oct 19 05:57:34 localhost kernel: ieee80211 phy2: Selected rate control algorithm 'minstrel_ht'

Oct 19 05:57:34 localhost mtp-probe: checking bus 4, device 2: "/sys/devices/pci0000:00/0000:00:12.0/usb4/4-5"

Oct 19 05:57:34 localhost mtp-probe: bus: 4, device: 2 was not an MTP device

Oct 19 05:57:34 localhost kernel[7058]: renamed network interface wlan0 to wlp0s18f0u5

Oct 19 05:57:34 localhost /etc/init.d/net.wlp0s18f2u5[7476]: net.wlp0s18f2u5: not allowed to be hotplugged
```

On reboot, the system reverts to using the original names. The device was not unplugged, it just changed name and cause my network to fail. These adapters have been working fine for months with other hardware and Linux OSes. I installed Gentoo on this hardware and this problem surfaced. If I unplug and replug the device, the original name gets assigned to the device and the network comes back up. I have to restart the interface to get it to work.

```
uname -a

Linux date 3.10.7-gentoo-r1 #1 SMP Fri Oct 18 23:05:49 EDT 2013 x86_64 AMD Phenom(tm) II X4 945 Processor AuthenticAMD GNU/Linux
```

Asus M5A97 motherboard.

Anybody know how to fix this problem?

----------

## Jaglover

You could append 

```
net.ifnames=0
```

 to your kernel command line to have wlan0 and wlan1 back.

----------

## Hu

My solution would be the same as the one proposed by Jaglover.

At boot, you get the name wlp0s18f2u5.  The systemd/PredictableNetworkInterfaceNames Wiki page references http://cgit.freedesktop.org/systemd/systemd/tree/src/udev/udev-builtin-net_id.c as the authoritative source for decoding this.  On udev-builtin-net_id.c line 40, we see the format rule.

```
 *   [P<domain>]p<bus>s<slot>[f<function>][u<port>][..][c<config>][i<interface>]

 *                                         -- USB port number chain
```

From this, wlp0s18f2u5 is a wireless domain-less PCI bus 0 slot 18 function 2 USB port 5 card.  After operation, your card drops off the USB bus for several seconds and reappears, at which point a name is assigned again.  The new name is wlp0s18f0u5, a wireless domain-less PCI bus 0 slot 18 function 0 USB port 5 card.  The change in the function number is the cause of your problem.

To fix this, you need either to get the card to stop disconnecting from the USB hub or to get the card to remain a function 2 card when it comes back.  The former would be preferable, since it would not interrupt your network connectivity for the several second window before the card resets.

----------

## BHReach

 *Jaglover wrote:*   

> You could append 
> 
> ```
> net.ifnames=0
> ```
> ...

 

Thanks, I'll use that solution for now.

 *Hu wrote:*   

> My solution would be the same as the one proposed by Jaglover.
> 
> At boot, you get the name wlp0s18f2u5.  The systemd/PredictableNetworkInterfaceNames Wiki page references http://cgit.freedesktop.org/systemd/systemd/tree/src/udev/udev-builtin-net_id.c as the authoritative source for decoding this.  On udev-builtin-net_id.c line 40, we see the format rule.
> 
> ```
> ...

 

It has been my experience that wifi cards drop out from time to time. They are 2 way radios and many things can interfere with radio transmission. If you get an excessive number of time outs, the adapter may reset. Also, some Linux drivers are not that good which makes some adapters less stable than they could be.

I don't think this behavior is intentional. Using the old naming convention is OK until they work all the bugs out of the new naming scheme. The developers need to take all possible hardware behavior into account to get everything to work correctly.

----------

## Hu

Lost radio traffic is acceptable, but your dmesg seems to indicate that the card reset in a way that temporarily removed it from being detected by the kernel.  You may be right that this is caused by a bug in the Linux driver, or by some quirk of the card firmware.  Regardless of the cause, I think that the full USB disconnect is excessive and should be considered a bug in whichever component caused it to happen.

The new naming scheme is not buggy in this situation.  The card is reporting different capabilities in the boot startup versus reset startup cases, which is why it gets different names.

----------

## BHReach

 *Hu wrote:*   

> Lost radio traffic is acceptable, but your dmesg seems to indicate that the card reset in a way that temporarily removed it from being detected by the kernel.  You may be right that this is caused by a bug in the Linux driver, or by some quirk of the card firmware.  Regardless of the cause, I think that the full USB disconnect is excessive and should be considered a bug in whichever component caused it to happen.
> 
> The new naming scheme is not buggy in this situation.  The card is reporting different capabilities in the boot startup versus reset startup cases, which is why it gets different names.

 

The device seems to be malfunctioning. Even with the wlan0 name, it drops the connection and I have to restart it manually to get it back.

It is an Etekcity (SKU: 05-RT3072-SINMAX) max tx power is 1000mw (30 dBm) Ralink RT3072 chipset. I bought 1 a year and a half ago and it is still working fine. 9 months ago, I bought 3 more. One of the 3 died last month and it looks like this one is failing. 2 out of 3 in 9 months is not good. Unfortunately, they only have a 60 day warranty. The original one was labeled with the Sinmax brand name but the three newer ones have only Etekcity labeled on them, maybe they switched manufacturers or got a bad batch.

These 'high gain' adapters seem to have a fairly short life.

I bought 2 TP-Link TL-WN722N, max TX power is 100mw (20dBm) with an Atheros AR9271 chipset almost 3 years ago (2 year warranty). One died last month and I took the other one out of service fearing it would die as well. I think I will replace the Etekcity one with the still functioning TP-Link.

There are a lot of customer reviews of the TL-WN722N on Newegg.com. One complaint was that the device gets hot, heat will definitely shorten an electrical device's life.

The RT3072 and AR9271 chipsets work very well with Linux. They connect to remote APs and maintain a stable connection with excellent data through put compared to other adapters I have tried.

----------

