Hi Everyone,  Today I added a 2.5G USB Nic Card.  Upon first boot after adding the card, Unraid marked it as eth0, and my built in nic as eth1.  Easy enough, I went to the Network Settings and set them up how I want them, in the reverse order, where the built in is eth0 and the new usb nic is eth1.  

 

I just want to say before I explain further I already removed the /boot/config/network.cfg and network-rules.cfg and rebooted, and the same issue persists.  

So after rebooting and setting the nics how I want them, my built-in nic is now eth0, awesome!  But the new nic that I want to be eth1 so I can make br1, comes in as eth123, I found it strange but decided to just go with it.  Created br123, had my VM use it, and it worked... briefly... then while still powered on, the nic changed to eth115, so I went ahead and re-created br115 and thought maybe it was a one time fluke.   Well after working for a while, all of this within an hour it had changed to eth69, eth71  without a shutdown/reboot, while powered up and while VMs are actively using it.  Then I did notice though not as quick after a few hours eth64 (with the nic now inactive since I had given up)

 

I just want the nic to be eth1, so it can be perpetually br1 so I can pass it on to the VM, and whatever dockers I may wish to assign to that NIC.   That was my goal to begin with, but I was defiinitely not expecting it to change names on me continuously. 

 

As one can see, the NICs are properly marked with the names they should have:

 

/boot/config/network.cfg shows this, but I have even tried modifying to only have 2 devices and force the eth1 name, but it still ends up adding eth123, eth115 and so on.  

Even right now, after being at eth71, it went to eth64, its strange 

 

For now I have stopped fighting against it and using it, but I would love to have the nic usable and use it as eth1 with br1 to assign to the VM and dockers I wish.  

I hope this was enough information to diagnose the system.  I have not reset my original network settings (static IP) yet after deleting the network.cfg file, but I will once I get everything stabilized.  

tower-diagnostics-20250412-1729.zip

Just in case it helps I am attaching a new diagnostics few hours after the first one, with a name change even while not using the nic and remaining inactive.

tower-diagnostics-20250412-2336.zip

I've seen this happen before with USB NICs, but I'm afraid I don't know of a solution.

Do you know if it would stay put if I would have allowed it to stay as eth0? 

The eth{0:9} naming convention is deprecated AFAIK just FYI... This is precisely why USB NIC's are advised against for firewalls and disks for active arrays.... USB is intended to be hot pluggable without interruption of peripheral function. You could potentially trace the windows power setting to stop USB from disconnecting as frequently - this is the veil that Windows would provide user protection from but linux knows it's in everyone's interests to be upfront from the start, It potentially is set in the BOS, but i've never attempted to change a default this... default nor this specific one. But all those times you've heard old timers tell people not to do it, is not without reason.

The best solution is to stop trying to move mountains and traverse the ravenes and gullies instead. That is, if you need to provide a network interface between a device and your server, throw in the USB NIC. If you intend to pernanently utilise the interface and are reliant upon it's availability (something USB cannot give) then install another adapter. Yes, you can do things to increase compliance and tame unruly behaviour, but it will fail in the end and numerous times between now and then. TCP/IP doesn't do so well when you insert USB into it's stack as layer 2 mega-latency, The time it takes to initialise a USB NIC from offline state likely exceeds the TCP failure timeout and then packet fragmentation, itll come online send the packets that nobody asked for and it's just a mess. This is what you're dealing with right now.... The mess that comes with using a USB NIC.

Sorry but you wont have me offer up bandaids to make it work for you, and likely why you'll not resolve this issue or receive much input other than "don't use USB NIC's" because that's ultimately what it boils down to. It's not laziness on the part of the respondent that brings that response,
I've ponswews on whether USB 3.21 or USB4 spec would potentially alleviate the flaws, but I've not performed a white paper deep dive because that's more work than resolving anu/all USB NIC issues by cutting the connecter off all your adapters (I was trained by an old skool kinda guy, cut every cord he ever binned).

 

17 hours ago, manolodf said:

Do you know if it would stay put if I would have allowed it to stay as eth0? 

IIRC it can still change.