Network connection fails after booting

After a reboot, which occurs almost every other day with Tumbleweed I find I have no network connection. If I left click on the Network Manager widget the Networks window opens and shows two wired connections:-

                                                         

Wired connection 1 (eno1)

Wired connection 1 (enp0s26f1u2)                      


On first starting the wired connection starts on the “wrong” one, ie. the one which fails to connect and work. If I select the other connection, I believe eno1, the first connection is disconnected and the other one connected and then it all works. There are two network cards installed but only one is connected and there are several USB ports, one of which is being used.

What is going on, what is “enp0s26f1u2.”

I have posted this earlier on the Install/Boot/login forum and the most likely suggestion is that a USB device is getting involved. I cannot disable this because the device is being used for my remote KVM switch. It does appear that both devices are needed but sadly the USB device always starts first and prevents the network connection.

This seems to be a new Tumbleweed/Network Manager issue as I do not have this problem on my identical backup machine, but this does run Debian!
I am going to try switching to wicked to see if that helps but if anybody has an ideas please help!

Budge

Regards,

I have changed to Wicked and all is now OK. I understand the additional network adaptor is a virtual adaptor. I quote:-

The Remote Network Driver Interface Specification (RNDIS) is a Microsoft proprietary protocol used mostly on top of USB.It provides a virtual Ethernet link to most versions of the Windows, Linux, and FreeBSD operating systems. A partial RNDIS specification is available from Microsoft, but Windows implementations have been observed to issue requests not included in that specification, and to …

It has not been requested by me or configured. Please could somebody tell me how to turn it off until I need it, which will not be soon?

Each interface can be explicitly configured (by NetworkManager or wicked). If you really don’t use/need an interface leave it unconfigured.

Hi deano,
You are far too optimistic. I have tried all the configuration changes I could make but Network Manager consistently fails to ignore my unconfigured device which I didn’t install or ask for in the first place. I have solved my problem by reverting to wicked, which does ignore the unconfigured device but it would be better to know why it was appearing in the first place and be able to stop the unwanted networking behaviour.

If no existing connection definition applies to wired interface, NetworkManager automatically creates volatile run-time only connection which tries to auto-configure interface. You may save (or copy and save) this automatic connection, then it won’t be created any more and you can edit permanent copy to disable auto-connect. Or you can tell NetworkManager to ignore specific interfaces. See no-auto-default in “man NetworkManager.conf”.

Not at all. Remember we’re not in front of your machine to check things for ourselves. Definitive output supporting/demonstrating an issue is key. Even basic info such as the following to show us the IP addresses assigned to interfaces

ip address

…routing info…

ip route

For NetworkManager

nmcli d
nmcli c

This will provide history with setting up of interfaces

sudo journalctl -fu NetworkManager

You can employ some filltering (eg interface-specific)…

sudo journalctl -fu NetworkManager | egrep "enp0s26f1u2|eno1"

I have solved my problem by reverting to wicked, which does ignore the unconfigured device

That is a means to an end that may be sufficient for your needs (only you can know that).

but it would be better to know why it was appearing in the first place and be able to stop the unwanted networking behaviour.

Of course, and it easy enough to leave an interface unmanaged…

From ‘man NetworkManager.conf’…

KEYFILE SECTION
This section contains keyfile-plugin-specific options, and is normally only used when you are not using any other
distro-specific plugin.

   hostname
       This key is deprecated and has no effect since the hostname is now stored in /etc/hostname or other system configuration
       files according to build options.
   path
       The location where keyfiles are read and stored. This defaults to "/etc/NetworkManager/system-connections".
   unmanaged-devices
       Set devices that should be ignored by NetworkManager.
       See the section called “Device List Format” for the syntax how to specify a device.
       Example:
           unmanaged-devices=interface-name:em4
           unmanaged-devices=mac:00:22:68:1c:59:b1;mac:00:1E:65:30:D1:C4;interface-name:eth2

Another method to unmanage…

DEVICE SECTION
Contains per-device persistent configuration.

   Example:
       [device]
       match-device=interface-name:eth3
       managed=1

Supported Properties
The following properties can be configured per-device.

   managed
       Whether the device is managed or not. A device can be marked as managed via udev rules (ENV{NM_UNMANAGED}), or via setting
       plugins (keyfile.unmanaged-devices). This is yet another way. Note that this configuration can be overruled at runtime via
       D-Bus. Also, it has higher priority then udev rules.

Hi Deano,
Many thanks for the magnificent reply. I shall go through it when I can. At least I should have more time now I am not waiting for Network Manager (NM) to resolve the conflict.

I still feel I have a point in that this issue has never before been a problem. Whilst I understand that some folk might expect or hope to obtain a lan connection automatically when plugging in a USB device, I would have expected this facility to have been advertised by the system more clearly.

It has not been a good week for me as I have been working with my laptop all over the site and configuring WiFi AP devices and managed switches. The NM issue was the last straw!

Many thanks once more.
Budge