# Create a dummy network device

## mathfeel

Because of this bug https://bugs.gentoo.org/show_bug.cgi?id=455896 in media-sound/google-musicmanager, I can no longer login, unless I am not using predictable network interface names. This computer has two ethernet cards on it, so having easily distinguishable name seems like a good idea (not that I had issue with it before...). Now I am wondering if I can tell udev to make a dummy eth0 device so that GMM uses its MAC (generated) address for verification?

----------

## khayyam

mathfeel ...

Not sure it will help but CONFIG_DUMMY is under:

Device Drivers -> Network device support -> Network core driver support

From the bug report I'm inclined to think this won't work as dummy is only used to link local apps to an interface, or as a general bitbucket, and the bug suggested it wasn't the local app but the fact that the interface is not the same interface that the client is speaking to (hence the warnings re bridges).

As for udev, its not involved in the process of managing interfaces, just naming (and breaking things).

HTH & best ... khay

----------

## mathfeel

 *khayyam wrote:*   

> mathfeel ...
> 
> Not sure it will help but CONFIG_DUMMY is under:
> 
> Device Drivers -> Network device support -> Network core driver support
> ...

 

Actually the device name is the whole issue. Basically GMM is looking for a network device's MAC address, but is hard-coded to only search for eth0, eth1... etc. So with the new udev's predictable name, GMM chocks because it can't find eth0. The problem is worked-around by setting udev not to name the network device:

```
ln -s /dev/null /etc/udev/rules.d/80-net-name-slot.rules
```

You are correct that dummy is not the correct approach. Something like this: http://openvz.org/Virtual_network_device, but it requires patched kernel.

How about: is it possible to have multiple named device pointing to the same physical device? That the same card can be both identified as enp0s25 and eth0?

----------

## Hu

I am not aware of a way to assign aliases like this.  However, perhaps you could arrange for udev to give a "predictable" name to one NIC and let the other NIC retain its kernel assigned name.

----------

## s4e8

disable the new predictable name. The name actually un-predictable. If I disable some onboard devices, the pci-e bus number will be re-assigned, the net name changed unpredictable.

----------

## SamuliSuominen

 *s4e8 wrote:*   

> disable the new predictable name. The name actually un-predictable. If I disable some onboard devices, the pci-e bus number will be re-assigned, the net name changed unpredictable.

 

You reconfigured your hardware, or rather how the kernel is seeing your hardware and are suprised udev is reacting to it? You really shouldn't be, and you wouldn't be if you had

read the documentation how the names get calculated.

For those cases the new predictable scheme offers more possibilities, like using enx* based MAC names.

As in, lack of understanding doesn't make them unpredictable.

----------

## s4e8

The good old persistent net udev rules (MAC base) work well. No bug, no changes.

pci bus-dev-fn id based naming is silly predictable idea. These ids is volatiles in modern hardware. eg: thuberbolt interface.

----------

