Dear Opensuse Network Users: Does anyone know of a safe way to create an (otherwise unused) device named eth0 “linked” to wlo1 (or at least it’s MAC address)? I’m trying to install Matlab software which only knows about eth0 when trying to find/send the hostid (MAC address) to it’s license manager.
Thank You!!
Patti
I think there’s a way to rename your ethernet device to “eth0”. Maybe that’s the easier way to solve your problem.
Hi nr - and thanks for the reply. Yes, I thought of that. Then I thought of all the problems in the months to come I might have by changing the OS install default wlo1 to the depricated eth0 and I cringe at making my future life harder. 
http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/
https://forums.opensuse.org/showthread.php/477633-YaST-and-how-to-configure-VLANS-with-quot-Configuration-Name-quot-eth0-X
http://www.softpanorama.org/Net/Linux_networking/Suse_networking/index.shtml
“SuSE stores the configuration of all network interfaces in way too many files,”
So I was hoping for just some way to get hostid-harvesting software the mac address via the name eth0. Maybe a soft-link to some file eth0.xxxx => wlo1.xxxx? But in my googling around I realize that opensuse has about the most complicated network setup files as any distro out there. I’d probably break something and then spend weeks troubleshooting it, and more than likely needing to reinstall…
So I thought I’d ask the Wizards! Using eth0-derived MAC address is a pretty standard way for many commercial software suites to do a hostid register/binding of their software in linux (windows tends to use driveid). You’d think this would have been solved w/o giving up predictable network interface names. But if it has, I have not stumbled across the right search terms yet…
:shame:Patti:)
Hi
Go back to the old naming schema?
http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/
Then you should be able to configure wlo1 as eth0.
You might even be able to do this via YaST Network devices, delete wlo1 if it’s configured and in the hardware tab change it to eth0.
The answer is as Malcolm described, and not surprisingly is what MatLab suggest too
Some newer Linux distributions have adopted the Consistent Network Device Naming convention for naming Network Interface Cards. Traditionally, Network Interface Cards were named using the ethX standard. This standard was known to cause trouble on machines with multiple network devices as the device names would change based on when it was detected by the kernel in the boot sequence.
In an effort to move away from the ethX standard, modern distributions have began implementing naming schemes based on the physical location of the network devices in the computer. The two main new naming standards are:
- em[0-9] for Network Interface Cards embedded in the motherboard
- ens<slot_number>p<port_number> or p<slot_number>p<port_number> for PCI cards
- There may be other naming schemes based on your distribution and type of ethernet device
MathWorks software must be locked and activated to the MAC address of an ethernet device on Linux. We are currently able to activate to the ethX and enX device names. If your machine is using one of the naming conventions listed above, then you will need to rename your device to match one of the naming conventions that we utilize.
Ya - but what software (opensuse or other) am I going to “break” by doing this? 
And… the technique seems kind if iffy, and depends on the distro…
I found this file but I’m not sure it is what I really need for OS 13.1: /etc/udev/rules.d/70-persistent-net.rules
http://www.softpanorama.org/Net/Linux_networking/Suse_networking/index.shtml
None. It’s only an interface name. I did it back with openSUSE 12.3 (when it was first introduced IIRC).
You might need to reconfigure via YaST, or rename /etc/sysconfig/network/ifcfg-<name or interface> (to reflect new device name though).
FWIW, I have /etc/sysconfig/network/ifcfg-eth0 and /etc/sysconfig/network/ifcfg-ens1 definitions present (because I jumped between naming schemes while experimenting a year to two ago).
Assuming your Matlab is being installed into a Guest, you should be configuring eth0(or its equivalent) as your network connection within the Guest no matter anything else. You should never need to change the network interface within the Guest, and rarely how that interface is configured. In other words and repeating myself ad nauseum, it doesn’t matter what the “real world” physical networking is, <within> the Guest it will <always> be the wired connection, whether it’s eth0 or whatever.
On the outside, you have a variety of different ways to configure your bridge and the name of the bridge device isn’t seen by the Guest, so it doesn’t matter what the name is.
If you are running KVM virtualization, then simply create a virtual network within vm manager, or just use the existing “virbr0” device. By default, unless something has changed it should automatically connect to any physical network the HostOS can see, whether it’s wired or wireless. Run “edit” on the virtual network to see see details, like whether it’s configured to bridge, Host Only or NAT (most likely). If you want, just use this default bridge device in your early investigation because at any time you can switch to another bridge device which might be configured a different way with no configuration within the Guest (only outside).
If you continue to have problems, post some details about the virtualization technology used, list existing bridges and properties, eg
brctl show
brctl show <bridge name>
TSU
Oh, I didn’t think of installing it in a guest! That might be a good idea, because the guest is portable between different installs of Opensuse or even windows, and I can do whatever I want with the interfaces, including spoofing a MAC. The only problem I’ve found with VM’s is memory (and sometimes speed) - 8 GB is the usual maximum these days, and a guest hits that fairly significantly. Vbox is probably the simplest and most portable across hosts, KVM requires a linux host. Wine is nice because you don’t have to boot it every time you want to use it. I wonder what the future of Wine is?
Memory ordinarily shouldn’t be an issue if your box has enough of it (Yeah, that’s one big catch).
Your Host will require its own memory. This can be minimized if you run on a Host that’s dedicated to do nothing else than serve Virt Guests. In this case, typically no matter what paravirtualization you select (eg KVM, VBox, VMware any type including ESXi, Workstation, etc) the Host will require about 768MB RAM (probab 1024 recommended). Guests for the virtualization technologies typically require an overhead of <5% over running the install on bare metal but YMMV. Sometimes my Guests perform better than on bare metal.
Yes, virtualization gives you numerous side benefits including portability, simpler backup and restore, cloning new running builds, more.
TSU
I didn’t think about the backupability of a guest! That’s right. Also MAC addresses and other hardware limitations (like disk ID’s) are circumvented. 