Two network interfaces - problem during boot

English Network/Internet
1

Hello,

I need advise with following problem.

I did upgrade 42.3 -> 15.0

HW setup:
Notebook in docking station
Two network interfaces:
eth0 - standard notebook network interface with plugged in cable connected to main network
eth1 - USB2Ethernet adapter. It does not matter, if ethernet cable is plugged into adapter or how is plugged other end of ethernet cable (disconnected or connected somewhere). It is just enough, that such adapter is plugged in docking station.

In docking station are connected headset (analog), keyboard (USB), mouse (USB), cooler (USB), USB2Ethernet adapter, eth0 ethernet cable and two external monitors (DP)

Problem:
System starts up and shows login screen on graphical console. When you login via graphical console, system freezes and all screens are black.

Symptoms:
After system starts, login as root to system console and then:

  1. ‘ip a’ - not finished, no output
  2. /etc/resolv.conf not refreshed
  3. “netconfig update -f” removes nameservers from /etc/resolv.conf (only “search …” is preserved)

Graphical console login as standard user

  1. rtkit-daemon timeouts; rtkit-daemon cannot be started

Workaround:
Disconnect USB2Ethernet adapter from USB before boot. System starts normally, no problems with login via graphical console and system runs as expected. If USB2Ethernet adapter is connected during runtime, everything works as expected.

Other tests:
USB2Ethernet removed, cable plugged in eth0 but other end of cable not connected - system starts normally and runs as expected

My USB2Ethernet adapter is D-Link DUB-E100 HW version C1

With mentioned HW setup there was no problem in 42.3 .

Bug or feature? Which component logs should I focus to?

2

You give no information about how you have configured the network – either via Wicked or NetworkManager. In fact there is very little actual technical detail. Not even whether static or dynamic addressing, IP4 and/or IP6, etc.

My first guess would be a routing problem.

3

Inspect your bootlog from your previous boot, eg the following displays the last previous boot (you can specify older my incrementing the number)

journalctl -b -1

I also suspect that you are not using Network Manager to manage your networking… (I recommend doing so)
The diff is that Wicked will set up your networking on system boot by default whereas Network Manger sets up networking only after your User credentials have been entered by default (After User login even if autologin is enabled). USB devices like what you are using for your second NIC may take a long time to set up and the timing may be important.

TSU

4

I’m using NetworkManager for network configuration. Is NetworkManager already active, when login as root on console?

Here NetworkManager configurations:
eth0:
[connection]
id=[filtered]
uuid=[filtered]
type=ethernet
autoconnect-priority=50
permissions=
zone=public

[ethernet]
auto-negotiate=true
mac-address=[filtered]
mac-address-blacklist=

[ipv4]
dns-search=
method=auto

[ipv6]
addr-gen-mode=stable-privacy
dns-search=
method=auto

eth1:
[connection]
id=[filtered]
uuid=[filtered]
type=ethernet
permissions=
zone=trusted

[ethernet]
auto-negotiate=true
mac-address=[filtered]
mac-address-blacklist=

[ipv4]
address1=192.168.200.5/24
dns-search=
method=manual
never-default=true
route1=192.168.250.0/24,192.168.200.1

[ipv6]
addr-gen-mode=stable-privacy
dns-search=
method=ignore

5

When you describe a system freezing or similar, I generally suspect a hardware issue possibly related to detection or some other similar “core functionality” of the OS.
Also if you’re unable to obtain complete output from your network related commands, that suggests a real system malfunction of some type, not merely a component not working properly that creates a localized problem.

By default,
Network Manager should set up your network connections shortly after you login to your graphical environment (aka Plymouth, aka when you have autologin disabled and you enter your credentials)

In each connection setting, you can over-ride and configure the connection to be enabled during boot but you have to go out of your way to do that.
Because USB device connection can take a long time and might happen a few different ways, I recommended you use Network Manger so that you can be more certain your network setup would happen well after your USB devices are fully identified and enumerated by your system… And from what you say, I assume that’s the case.

If you display your bootlog from any previous boot where your system crashed, you should be able to read the last lines in the log to see what was happening at that time… Your system might have failed quickly or only finally after numerous cumulative errors. You can redirect your output to a file if you wish so that the log can be read in a different application. And, if you’re not able to interpret your log, you can upload to a pastebin for others to inspect

The following for example reads the log from the last previous boot and appends (not over-writes if a file by that name already exists) the output to the file “logfile” in the current working directory

journalctl -b -1 >> logfile

TSU

6

OK, I’ve set NetworkManager to logging TRACE level and analyzed journal im problem case. I’ve found following:
Both eth0 and eth1 startups are similar, but there is difference:

eth0 configuration ends with:


Jul 13 21:33:27 [filtered] NetworkManager[1726]: <debug> [1531510407.2692] device[0x56530891e8e0] (eth0): bringing up device 2
Jul 13 21:33:27 [filtered] NetworkManager[1726]: <debug> [1531510407.2692] platform: link: setting up "eth0" (2)
Jul 13 21:33:27 [filtered] NetworkManager[1726]: <debug> [1531510407.2692] platform-linux: link: change 2: flags: set 0x1/0x1 ([up] / [up])
Jul 13 21:33:27 [filtered] NetworkManager[1726]: <debug> [1531510407.4874] platform-linux: do-request-link: 2 
Jul 13 21:33:27 [filtered] NetworkManager[1726]: <trace> [1531510407.4874] platform-linux: event-notification: RTM_NEWLINK, flags 0, seq 0: 2: eth0 <UP;broadcast,multicast,up> mtu 1500 arp 1 ethernet? not-init addrgenmode none addr **[FILTERED]** rx:0,0 tx:0,0
Jul 13 21:33:27 [filtered] NetworkManager[1726]: <debug> [1531510407.4875] platform: signal: link changed: 2: eth0 <UP;broadcast,multicast,up> mtu 1500 arp 1 ethernet? init addrgenmode none addr **[FILTERED]** driver e1000e rx:0,0 tx:0,0
Jul 13 21:33:27 [filtered] NetworkManager[1726]: <trace> [1531510407.4875] platform-linux: event-notification: RTM_NEWLINK, flags 0, seq 11: 2: eth0 <UP;broadcast,multicast,up> mtu 1500 arp 1 ethernet? not-init addrgenmode none addr **[FILTERED]** rx:0,0 tx:0,0
Jul 13 21:33:27 [filtered] NetworkManager[1726]: <debug> [1531510407.4876] platform-linux: do-change-link[2]: success changing link: success
Jul 13 21:33:27 [filtered] NetworkManager[1726]: <trace> [1531510407.4876] ethtool[2]: ETHTOOL_GLINK, eth0: success
Jul 13 21:33:27 [filtered] NetworkManager[1726]: <debug> [1531510407.4876] device[0x56530891e8e0] (eth0): add_pending_action (1): 'carrier-wait'
Jul 13 21:33:27 [filtered] NetworkManager[1726]: <debug> [1531510407.4876] device[0x56530891e8e0] (eth0): preparing device
Jul 13 21:33:27 [filtered] NetworkManager[1726]: <debug> [1531510407.4876] device[0x56530891e8e0] (eth0): clearing queued IP4 config change
Jul 13 21:33:27 [filtered] NetworkManager[1726]: <debug> [1531510407.4877] device[0x56530891e8e0] (eth0): clearing queued IP6 config change
Jul 13 21:33:27 [filtered] NetworkManager[1726]: <trace> [1531510407.4877] device[0x56530891e8e0] (eth0): remove_pending_action (1): 'dhcp6' not pending (expected)
Jul 13 21:33:27 [filtered] NetworkManager[1726]: <trace> [1531510407.4877] device[0x56530891e8e0] (eth0): remove_pending_action (1): 'autoconf6' not pending (expected)
Jul 13 21:33:27 [filtered] NetworkManager[1726]: <debug> [1531510407.4877] platform-linux: sysctl: setting '/proc/sys/net/ipv6/conf/eth0/accept_ra' to '0' (current value is '1')
Jul 13 21:33:27 [filtered] NetworkManager[1726]: <debug> [1531510407.4878] platform-linux: sysctl: setting '/proc/sys/net/ipv6/conf/eth0/use_tempaddr' to '0' (current value is identical)
Jul 13 21:33:27 [filtered] NetworkManager[1726]: <debug> [1531510407.4878] device[0x56530891e8e0] (eth0): ip4-config: update (commit=1, new-config=(nil))
Jul 13 21:33:27 [filtered] NetworkManager[1726]: <debug> [1531510407.4878] device[0x56530891e8e0] (eth0): ip4-config: clear IP4Config instance (/org/freedesktop/NetworkManager/IP4Config/1)
Jul 13 21:33:27 [filtered] NetworkManager[1726]: <debug> [1531510407.4878] dns-mgr: (device_ip4_config_changed): queueing DNS updates (1)
Jul 13 21:33:27 [filtered] NetworkManager[1726]: <debug> [1531510407.4878] dns-mgr: (device_ip4_config_changed): DNS configuration did not change
Jul 13 21:33:27 [filtered] NetworkManager[1726]: <debug> [1531510407.4879] dns-mgr: (device_ip4_config_changed): no DNS changes to commit (0)
Jul 13 21:33:27 [filtered] NetworkManager[1726]: <trace> [1531510407.4879] exported-object[0x56530892c1c0]: unexport: "/org/freedesktop/NetworkManager/IP4Config/1"
Jul 13 21:33:27 [filtered] NetworkManager[1726]: <debug> [1531510407.4880] device[0x56530891e8e0] (eth0): ip6-config: update (commit=1, new-config=(nil))
Jul 13 21:33:27 [filtered] NetworkManager[1726]: <debug> [1531510407.4880] device[0x56530891e8e0] (eth0): ip6-config: clear IP6Config instance (/org/freedesktop/NetworkManager/IP6Config/1)
Jul 13 21:33:27 [filtered] NetworkManager[1726]: <debug> [1531510407.4880] dns-mgr: (device_ip6_config_changed): queueing DNS updates (1)
Jul 13 21:33:27 [filtered] NetworkManager[1726]: <debug> [1531510407.4881] dns-mgr: (device_ip6_config_changed): DNS configuration did not change
Jul 13 21:33:27 [filtered] NetworkManager[1726]: <debug> [1531510407.4881] dns-mgr: (device_ip6_config_changed): no DNS changes to commit (0)
Jul 13 21:33:27 [filtered] NetworkManager[1726]: <trace> [1531510407.4881] exported-object[0x565308935280]: unexport: "/org/freedesktop/NetworkManager/IP6Config/1"
Jul 13 21:33:27 [filtered] NetworkManager[1726]: <debug> [1531510407.4883] device[0x56530891e8e0] (eth0): device not yet available for transition to DISCONNECTED
Jul 13 21:33:27 [filtered] NetworkManager[1726]: <trace> [1531510407.4885] ethtool[4]: ETHTOOL_GLINK, eth1: success
Jul 13 21:33:27 [filtered] NetworkManager[1726]: <debug> [1531510407.4885] device[0x56530892bea0] (eth1): constructed (NMDeviceEthernet)
Jul 13 21:33:27 [filtered] NetworkManager[1726]: <debug> [1531510407.4885] device[0x56530892bea0] (eth1): start setup of NMDeviceEthernet, kernel ifindex 4

Black lines are only for eth0 (probably it has something with detected link for eth0)
Green lines show eth1 configuration startup

eth1 configuration ends with:


Jul 13 21:33:27 [filtered] NetworkManager[1726]: <debug> [1531510407.4914] device[0x56530892bea0] (eth1): bringing up device 4
Jul 13 21:33:27 [filtered] NetworkManager[1726]: <debug> [1531510407.4914] platform: link: setting up "eth1" (4)
Jul 13 21:33:27 [filtered] NetworkManager[1726]: <debug> [1531510407.4915] platform-linux: link: change 4: flags: set 0x1/0x1 ([up] / [up])

That’s fine.

What is interesting, NetworkManager log in problem case ends with these three red lines for eth1 and in journal are no other entries from NetworkManager. But in “normal” case (USB2Ethernet disconnected), NetworkManager continues with wlan0 interface setup (same journal timestamp).


Jul 13 21:37:29 [filtered] NetworkManager[1626]: <debug> [1531510649.5590] wifi-nl80211: genl_ctrl_resolve: resolved "nl80211" as 0x1c
Jul 13 21:37:29 [filtered] NetworkManager[1626]: <info>  [1531510649.5592] wifi-nl80211: (wlan0): using nl80211 for WiFi device control
Jul 13 21:37:29 [filtered] NetworkManager[1626]: <debug> [1531510649.5598] device[0x5583a07d1c50] (wlan0): constructed (NMDeviceWifi)

This step is not not done in problem case. Do you have some explanation?

7

Provide a) full log after you booted with USB adapter plugged in (journalctl -b) and b) full log after you booted without USB adapter and plugged it in later (journalctl -b). This may provide some hints.

8

There is a dearth of basic information to help us understand what is happening and what you want to happen.
We do not know what model of notebook and docking station are involved. What happens if you remove the docking station from the mix?
What networks are the two ethernet ports connected to – IP addresses, gateways, any DHCP servers and their configuration? Do other devices on these networks work as expected?

You list some network settings, but there is no indication where they came from. Could you please use the code tags (selected with the # icon) and include(paste) the command line as well as the output?

This looks like it may be a mangled concatenation of multiple files produced with something like:

$USER@$HOST:~> sudo cat /etc/NetworkManager/system-connections/*
[connection]
id=wiredethernet0
...
[connection]
id=wiredethernet1
...

Is wiredethernet0 meant to be 192.168.250.0/24 configured by a DHCP server?
And is wiredethernet1 meant to be 192.168.200.0/24 cconfigured statically?
If so route1 might to be directing traffic intended for 192.168.250.0/24 to the wrong port(device).

9

Anonymized full logs are prepared, but I do not know, how to attach them. What is pastebin? Can you please explain me, how to attach full logs?

In the problem log you can find USB2Ethernet device as:

Jul 13 21:33:09 <HOSTNAME> kernel: usb 1-5.1: New USB device found, idVendor=2001, idProduct=1a02
Jul 13 21:33:09 <HOSTNAME> kernel: usb 1-5.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Jul 13 21:33:09 <HOSTNAME> kernel: usb 1-5.1: Product: DUB-E100
Jul 13 21:33:09 <HOSTNAME> kernel: usb 1-5.1: Manufacturer: D-Link          
Jul 13 21:33:09 <HOSTNAME> kernel: usb 1-5.1: SerialNumber: 033E9B

If you need test without docking station, let me know.

Ethernet eth0 is connected to network 192.168.0.0/24, DHCP
USB2Ethernet eth1has manual IP and netmask configuration for network 192.168.200.0/24 with route to reach network 192.168.250.0/24 via 192.168.200.1

eth0 - /etc/NetworkManager/system-connections/<SYSCON_ETHERNET_1_ID>


[connection]
id=<SYSCON_ETHERNET_1_ID>
uuid=<SYSCON_ETHERNET_1_UUID> 
type=ethernet
autoconnect-priority=50
permissions=
zone=public

[ethernet]
auto-negotiate=true
mac-address=<ETHERNET_MAC> 
mac-address-blacklist=

[ipv4]
dns-search=
method=auto

[ipv6]
addr-gen-mode=stable-privacy
dns-search=
method=auto

eth1 - /etc/NetworkManager/system-connections/<SYSCON_USB2ETHERNET_1_ID>


[connection]
id=<SYSCON_USB2ETHERNET_1_ID> 
uuid=<SYSCON_USB2ETHERNET_1_UUID> 
type=ethernet
permissions=
zone=trusted

[ethernet]
auto-negotiate=true
mac-address=<USB2ETHERNET_MAC>
mac-address-blacklist=

[ipv4]
address1=192.168.200.5/24
dns-search=
method=manual
never-default=true
route1=192.168.250.0/24,192.168.200.1

[ipv6]
addr-gen-mode=stable-privacy
dns-search=
method=ignore
10
  • In “Posting permissions” I can see “You may not
    post attachments” - how to enable it?
11

Here are links for download full logs:https://www.dropbox.com/s/z7ukttai53piq26/FullJournal.OK?dl=0
https://www.dropbox.com/s/edsu3pdiqdtkqpr/FullJournal.PROBLEM?dl=0

12

http://paste.opensuse.org/
If you are logged into the forum you are logged into paste.
Random third-party file-sharing sites are not recommended.

13

Hm, there is probably something with my account. I’m logged into forum, but in http://paste.opensuse.org/ I’m not logged in and it wants from me some OpenID to log in. Any hint?

14

It looks like kernel problem. After NM sets eth1 (USB interface) up, no more netdev notifications are generated, so NM never gets information that eth0 link state is up. The last notification:

Jul 13 21:33:27 <HOSTNAME> NetworkManager[1726]: <trace> [1531510407.4911] platform-linux: event-notification: RTM_NEWLINK, flags 0, seq 13: 4: eth1 <DOWN;broadcast,multicast> mtu 1500 arp 1 ethernet? not-init addrgenmode none addr <USB2ETHERNET_MAC> rx:0,0 tx:0,0

after which it brings eth1 up

Jul 13 21:33:27 <HOSTNAME> NetworkManager[1726]: <debug> [1531510407.4914] device[0x56530892bea0] (eth1): bringing up device 4
Jul 13 21:33:27 <HOSTNAME> NetworkManager[1726]: <debug> [1531510407.4914] platform: link: setting up "eth1" (4)

and after that not even notification that eth1 is UP appears.

You should open bug report.

P.S. there is no trace of eth1 in your “OK” log, so we still have no idea whether it actually works or not.

15

In OK log is no eth1 presence, because OK log can be provided only in case USB2Ethernet (eth1) is disconnected from notebook. When USB2Ethernet is connected during boot to notebook, system does not work correctly. You can see it by logs comparison. In PROBLEM log eth0 connection is not activated, resolv.conf is not updated … that everything is done only in OK log.

I open new bug in opensuse bugzilla. As a component should I choose Kernel or Network? I propose Network.

16

No, you ARE logged in as a user. Clicking on “Login” is for Administrators.
Below the Login menu, there is the choice of pasting either code (text) or an image.
For Code you choose the script language then enter (paste) the text into the large pane.
For Image you use the browse dialogue to select the file on your machine that you wish to upload.
Then you select an expiry time and click on the Create button.

There’s more stuff at:
https://forums.opensuse.org/forumdisplay.php/690-How-to-use-the-forums

17

You said earlier:

If USB2Ethernet adapter is connected during runtime, everything works as expected.
and that is exactly what I asked you to do before collecting log.
As a component should I choose Kernel or Network? I propose Network.
Based on evidences so far this is kernel issue.

18

If USB2Ethernet adapter is connected during runtime, everything works as expected.

Yes, this is valid but it looks like it was misunderstood. It is part of workaround, how to enable work with with USB2Ethernet. I’ll try to explain it a little more - you must boot notebook without connected USB2Ethernet. When everything is up and you are logged in (runtime), you can connect USB2Ethernet to notebook and it behaves as expected - no problems, everything works as expected, you can work with it. The only problem is, when it is connected when notebook is off, you switch on notebook and system starts boot procedure.

19

Pastebin ia s type of place where you can post a variety of things for public viewing.

Although used by many for many purposes,
For our purposes, it’s used to post anything that can’t be included in a Forum post… eg a log that’s too large.

The main, general purpose pastebin used by many for all things
https://pastebin.com/

We also have a openSUSE/SUSE pastebin
https://paste.opensuse.org/

Sometimes,
It’s just better to post something enormous in a pastebin… If you embedded something enormous in a Forum post, it could interrupt the train of thought for anyone who is rapidly skimming your post. Publishing a link to a pastebin allows the reader to read the overall post and understand what is described before digging into the details of your pastebin content.

TSU

20

To me,
This sounds like a problem related to detection, and then mounting and configuration.

As I briefly mentioned in my earlier post, USB devices can be detected and mounted several different ways, and it seems that you’re having problems when the device is set up during system boot… but not when detected after you’ve logged in. The method of USB mounting is just a starting point… You’ll need to collect specific bootlog entries specific to what happened when the USB NIC was connected during boot. And, that was why I suggested if you weren’t able to analyze the bootlog yourself that you should post the bootlog to a pastebin in its entirety and then someone else can take a look at it.

Using a Pastebin shouldn’t be difficult…

  • Open the pastebin in your web browser
  • Paste your content into the page
  • Fill out the required fields
  • Save.
  • After saving, the web page will change, and now you can copy and paste the address of that page into your Forum post.

TSU