[gelöst] Netzwerkverlust

[habakug]

Hallo!

Verwirrenderweise gibt es den Address-Tag in der [Network]-Sektion als auch in der [Address]-Sektion. Allerdings ist der in der [Address]-Sektion zwingend vorgeschrieben.

[Address] Section Options
An "[Address]" section accepts the following keys. Specify several "[Address]" sections to configure several addresses.
Address=
As in the "[Network]" section. This key is mandatory.

Gruss, habakug

[1] https://www.freedesktop.org/software/sy ... %20Options

[gambit]

Dann versuch mal erneut als Test, nur mit folgender geänderter eth0.network-Datei:

Code: Alles auswählen

[Match]
Name=eth0

[Network]
DHCP=none
IPv4LL=false
Address=192.168.178.9/24
Gateway=192.168.178.1
DNS=192.168.178.1
NTP=192.168.178.1

D. h., ohne DHCP und mit statischer IP-Adresse.

Das hat (mit NWM 'disabled')

Code: Alles auswählen

# systemctl disable NetworkManager.service
Removed symlink /etc/systemd/system/multi-user.target.wants/NetworkManager.service.
Removed symlink /etc/systemd/system/dbus-org.freedesktop.nm-dispatcher.service.

keine Veränderung gebracht, im Vergleich zu dem Ansatz von TomL:

Code: Alles auswählen

ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
    link/ether 10:60:4b:81:76:38 brd ff:ff:ff:ff:ff:ff
root@seneca:~# systemctl start systemd-networkd.servie
Failed to start systemd-networkd.servie.service: Unit systemd-networkd.servie.service failed to load: No such file or directory.
root@seneca:~# systemctl start systemd-networkd.service
root@seneca:~# systemctl start systemd-networkd-wait-online.service
^C
root@seneca:~# systemctl status systemd-networkd systemd-resolved systemd-networkd-wait-online
● systemd-networkd.service - Network Service
   Loaded: loaded (/lib/systemd/system/systemd-networkd.service; disabled)
   Active: active (running) since Sa 2016-05-14 12:22:57 CEST; 4min 25s ago
     Docs: man:systemd-networkd.service(8)
 Main PID: 1357 (systemd-network)
   Status: "Processing requests..."
   CGroup: /system.slice/systemd-networkd.service
           └─1357 /lib/systemd/systemd-networkd

Mai 14 12:22:57 seneca systemd-networkd[1357]: lo              : gained carrier
Mai 14 12:22:57 seneca systemd-networkd[1357]: eth0            : link configured

● systemd-resolved.service - Network Name Resolution
   Loaded: loaded (/lib/systemd/system/systemd-resolved.service; disabled)
   Active: active (running) since Sa 2016-05-14 12:20:32 CEST; 6min ago
     Docs: man:systemd-resolved.service(8)
 Main PID: 1349 (systemd-resolve)
   Status: "Processing requests..."
   CGroup: /system.slice/systemd-resolved.service
           └─1349 /lib/systemd/systemd-resolved

● systemd-networkd-wait-online.service - Wait for Network to be Configured
   Loaded: loaded (/lib/systemd/system/systemd-networkd-wait-online.service; disabled)
   Active: activating (start) since Sa 2016-05-14 12:23:44 CEST; 3min 38s ago
     Docs: man:systemd-networkd-wait-online.service(8)
 Main PID: 1360 (systemd-network)
   CGroup: /system.slice/systemd-networkd-wait-online.service
           └─1360 /lib/systemd/systemd-networkd-wait-online

[TomL]

Ich habe hier an diesem Punkt doch noch mal eine Frage.... und zwar hinsichtlich Eindeutigkeit: Nach diesem Befehl....:

Das hat (mit NWM 'disabled')

Code: Alles auswählen

# systemctl disable NetworkManager.service

...also der Außerbetriebnahme des NWM und dem darauffolgendenen Kaltstart ist es mit keiner Maßnahme möglich, das Interface zu öffnen und via DHCP eine IP-Adresse anzufordern oder alternativ mit einer Static-IP zu verbinden? Ist das so richtig dargestellt? In Kurzform:
Deaktivieren NWM -> dann Kaltstart PC -> sämtliche Maßnahmen zum Aufbau der Netzwerkverbindung schlagen fehl, bis der Router neu gestartet wurde.

Ich frage deshalb noch mal nach, weil mit dem "disable" allein der NWM nicht beendet wird.... der läuft nämlich (ohne zusätzliche Eingriffe) bis zum Shutdown einfach weiter und handhabt trotz "disable" weiterhin das Netzwerk-Geschäft. Erst nach dem Reboot ist er wirklich weg.

[gambit]

Ich habe hier an diesem Punkt doch noch mal eine Frage.... und zwar hinsichtlich Eindeutigkeit: Nach diesem Befehl....:

Das hat (mit NWM 'disabled')

Code: Alles auswählen

# systemctl disable NetworkManager.service

...also der Außerbetriebnahme des NWM und dem darauffolgendenen Kaltstart ist es mit keiner Maßnahme möglich, das Interface zu öffnen und via DHCP eine IP-Adresse anzufordern oder alternativ mit einer Static-IP zu verbinden? Ist das so richtig dargestellt? In Kurzerform:
Deaktivieren NWM -> dann Kaltstart PC -> sämtliche Maßnahmen zum Aufbau der Netzwerkverbindung schlagen fehl, bis der Router neu gestartet wurde.

Ich frage deshalb noch mal nach, weil mit dem "disable" allein der NWM nicht beendet wird.... der läuft nämlich (ohne zusätzliche Eingriffe) bis zum Shutdown einfach weiter und handhabt trotz "disable" weiterhin das Netzwerk-Geschäft. Erst nach dem Reboot ist er wirklich weg.

ich hatte vor 'disable' den NWM gestoppt:

Code: Alles auswählen

# systemctl stop NetworkManager.service
# systemctl disable NetworkManager.service
Removed symlink /etc/systemd/system/multi-user.target.wants/NetworkManager.service.
Removed symlink /etc/systemd/system/dbus-org.freedesktop.nm-dispatcher.service.

[gambit]

In Kurzerform:
Deaktivieren NWM -> dann Kaltstart PC -> sämtliche Maßnahmen zum Aufbau der Netzwerkverbindung schlagen fehl, bis der Router neu gestartet wurde.

Ergänzend:
Ich habe wegen der nicht endenden Aktivierung

Code: Alles auswählen

● systemd-networkd-wait-online.service - Wait for Network to be Configured
   Loaded: loaded (/lib/systemd/system/systemd-networkd-wait-online.service; disabled)
   Active: activating (start) since Sa 2016-05-14 12:23:44 CEST; 3min 38s ago
     Docs: man:systemd-networkd-wait-online.service(8)
 Main PID: 1360 (systemd-network)
   CGroup: /system.slice/systemd-networkd-wait-online.service
           └─1360 /lib/systemd/systemd-networkd-wait-online

nichts Weiteres veranlasst, bzw. den Router neu gestartet, um hier zu posten.

[TomL]

ich hatte vor 'disable' den NWM gestoppt:

Code: Alles auswählen

# systemctl stop NetworkManager.service
# systemctl disable NetworkManager.service
Removed symlink /etc/systemd/system/multi-user.target.wants/NetworkManager.service.
Removed symlink /etc/systemd/system/dbus-org.freedesktop.nm-dispatcher.service.

War dann diese Feststellung (in gänze) richtig oder falsch....
Deaktivierter NWM -> dann Kaltstart PC -> sämtliche Maßnahmen zum Aufbau der Netzwerkverbindung schlagen fehl, bis der Router neu gestartet wurde.

Ich frage deshalb, weil m.M. nach erst der Reboot absolut und zweifelsfrei sicherstellt, dass alle IRQ's, Ressourcen (was weiss ich, was da noch so im PC rumgammelt und sich langweilt) wirklich weg, geschlossen oder freigegeben ist.... z.B. auch dieser dispatcher-daemon....(?). Und möglicherweise kann eine hängende Aktivierung auch einfach damit zusammenhängen, dass noch irgendeine Komponente von irgendeinem Job blockiert wird, der der Meinung ist "ist meins" und damit anderes blockiert.

[gambit]

Hallo!

Verwirrenderweise gibt es den Address-Tag in der [Network]-Sektion als auch in der [Address]-Sektion. Allerdings ist der in der [Address]-Sektion zwingend vorgeschrieben.

[Address] Section Options
An "[Address]" section accepts the following keys. Specify several "[Address]" sections to configure several addresses.
Address=
As in the "[Network]" section. This key is mandatory.

Gruss, habakug

[1] https://www.freedesktop.org/software/sy ... %20Options

Hallo habakug,
danke fürs reinspringen.
Deinen Hinweis verstehe ich z. Zt. noch nicht. Ich werde zu systemd-network lesen und komme darauf zurück

[gambit]

ich hatte vor 'disable' den NWM gestoppt:

Code: Alles auswählen

# systemctl stop NetworkManager.service
# systemctl disable NetworkManager.service
Removed symlink /etc/systemd/system/multi-user.target.wants/NetworkManager.service.
Removed symlink /etc/systemd/system/dbus-org.freedesktop.nm-dispatcher.service.

War dann diese Feststellung (in gänze) richtig oder falsch....
Deaktivierter NWM -> dann Kaltstart PC -> sämtliche Maßnahmen zum Aufbau der Netzwerkverbindung schlagen fehl, bis der Router neu gestartet wurde.

Ich frage deshalb, weil m.M. nach erst der Reboot absolut und zweifelsfrei sicherstellt, dass alle IRQ's, Ressourcen (was weiss ich, was da noch so im PC rumgammelt und sich langweilt) wirklich weg, geschlossen oder freigegeben ist.... z.B. auch dieser dispatcher-daemon....(?). Und möglicherweise kann eine hängende Aktivierung auch einfach damit zusammenhängen, dass noch irgendeine Komponente von irgendeinem Job blockiert wird, der der Meinung "ist meins" und damit anderes blockiert.

Ok, verstehe. Dann probiere ich das nochmal mit reboot. Das wird etwas dauern, wegen der leidigen Notwendigkeit, NWM wieder aktivieren zu müssen, um hier zu posten.

Apropos, vielleicht kann man dem nachfolgenden Log etwas entnehmen, was weiterhilft:

Code: Alles auswählen

cat /var/log/syslog | grep -E  '^May 14' | grep -i -E 'network|dhc'

Code: Alles auswählen

May 14 14:28:27 seneca networking[418]: Configuring network interfaces...done.
May 14 14:28:27 seneca avahi-daemon[618]: Network interface enumeration completed.
May 14 14:28:27 seneca kernel: [    0.533635] e1000e: Intel(R) PRO/1000 Network Driver - 2.3.2-k
May 14 14:28:27 seneca kernel: [    0.784121] e1000e 0000:00:19.0 eth0: Intel(R) PRO/1000 Network Connection
May 14 14:30:05 seneca NetworkManager[1283]: <info> NetworkManager (version 0.9.10.0) is starting...
May 14 14:30:05 seneca NetworkManager[1283]: <info> Read config: /etc/NetworkManager/NetworkManager.conf
May 14 14:30:05 seneca NetworkManager[1283]: <info> WEXT support is enabled
May 14 14:30:05 seneca NetworkManager[1283]: <info> init!
May 14 14:30:05 seneca NetworkManager[1283]: <info> update_system_hostname
May 14 14:30:05 seneca NetworkManager[1283]: <info>       interface-parser: parsing file /etc/network/interfaces
May 14 14:30:05 seneca NetworkManager[1283]: <info>       interface-parser: source line includes interfaces file(s) /etc/network/interfaces.d/*
May 14 14:30:05 seneca NetworkManager[1283]: <warn> interfaces file /etc/network/interfaces.d/* doesn't exist
May 14 14:30:05 seneca NetworkManager[1283]: <info>       interface-parser: finished parsing file /etc/network/interfaces
May 14 14:30:05 seneca NetworkManager[1283]: <info> management mode: unmanaged
May 14 14:30:05 seneca NetworkManager[1283]: <info> devices added (path: /sys/devices/pci0000:00/0000:00:19.0/net/eth0, iface: eth0)
May 14 14:30:05 seneca NetworkManager[1283]: <info> device added (path: /sys/devices/pci0000:00/0000:00:19.0/net/eth0, iface: eth0): no ifupdown configuration found.
May 14 14:30:05 seneca NetworkManager[1283]: <info> devices added (path: /sys/devices/virtual/net/lo, iface: lo)
May 14 14:30:05 seneca NetworkManager[1283]: <info> device added (path: /sys/devices/virtual/net/lo, iface: lo): no ifupdown configuration found.
May 14 14:30:05 seneca NetworkManager[1283]: <info> end _init.
May 14 14:30:05 seneca NetworkManager[1283]: <info> Loaded plugin ifupdown: (C) 2008 Canonical Ltd.  To report bugs please use the NetworkManager mailing list.
May 14 14:30:05 seneca NetworkManager[1283]: <info> Loaded plugin keyfile: (c) 2007 - 2013 Red Hat, Inc.  To report bugs please use the NetworkManager mailing list.
May 14 14:30:05 seneca NetworkManager[1283]: <info> (13990528) ... get_connections.
May 14 14:30:05 seneca NetworkManager[1283]: <info> (13990528) ... get_connections (managed=false): return empty list.
May 14 14:30:05 seneca NetworkManager[1283]: <info> new connection /etc/NetworkManager/system-connections/Wired connection 1
May 14 14:30:05 seneca NetworkManager[1283]: <info> get unmanaged devices count: 0
May 14 14:30:05 seneca NetworkManager[1283]: <info> monitoring kernel firmware directory '/lib/firmware'.
May 14 14:30:05 seneca NetworkManager[1283]: <info> monitoring ifupdown state file '/run/network/ifstate'.
May 14 14:30:05 seneca NetworkManager[1283]: <info> WiFi hardware radio set enabled
May 14 14:30:05 seneca NetworkManager[1283]: <info> WWAN hardware radio set enabled
May 14 14:30:05 seneca NetworkManager[1283]: <info> Loaded device plugin: /usr/lib/x86_64-linux-gnu/NetworkManager/libnm-device-plugin-adsl.so
May 14 14:30:05 seneca NetworkManager[1283]: <info> Loaded device plugin: /usr/lib/x86_64-linux-gnu/NetworkManager/libnm-device-plugin-wwan.so
May 14 14:30:05 seneca NetworkManager[1283]: <info> Loaded device plugin: /usr/lib/x86_64-linux-gnu/NetworkManager/libnm-device-plugin-bluetooth.so
May 14 14:30:05 seneca NetworkManager[1283]: <info> Loaded device plugin: /usr/lib/x86_64-linux-gnu/NetworkManager/libnm-device-plugin-wifi.so
May 14 14:30:05 seneca NetworkManager[1283]: <info> WiFi enabled by radio killswitch; enabled by state file
May 14 14:30:05 seneca NetworkManager[1283]: <info> WWAN enabled by radio killswitch; enabled by state file
May 14 14:30:05 seneca NetworkManager[1283]: <info> WiMAX enabled by radio killswitch; enabled by state file
May 14 14:30:05 seneca NetworkManager[1283]: <info> Networking is enabled by state file
May 14 14:30:05 seneca NetworkManager[1283]: <info> (lo): link connected
May 14 14:30:05 seneca NetworkManager[1283]: <info> (lo): carrier is ON
May 14 14:30:05 seneca NetworkManager[1283]: <info> (lo): new Generic device (driver: 'unknown' ifindex: 1)
May 14 14:30:05 seneca NetworkManager[1283]: <info> (lo): exported as /org/freedesktop/NetworkManager/Devices/0
May 14 14:30:05 seneca NetworkManager[1283]: <info> (eth0): carrier is OFF
May 14 14:30:05 seneca NetworkManager[1283]: <info> (eth0): new Ethernet device (driver: 'e1000e' ifindex: 2)
May 14 14:30:05 seneca NetworkManager[1283]: <info> (eth0): exported as /org/freedesktop/NetworkManager/Devices/1
May 14 14:30:05 seneca NetworkManager[1283]: <info> (eth0): device state change: unmanaged -> unavailable (reason 'managed') [10 20 2]
May 14 14:30:06 seneca NetworkManager[1283]: <info> (eth0): preparing device
May 14 14:30:06 seneca NetworkManager[1283]: <info> ModemManager available in the bus
May 14 14:30:10 seneca NetworkManager[1283]: <info> startup complete
May 14 14:31:54 seneca NetworkManager[1283]: <info> (eth0): link connected
May 14 14:31:54 seneca NetworkManager[1283]: <info> (eth0): device state change: unavailable -> disconnected (reason 'carrier-changed') [20 30 40]
May 14 14:31:54 seneca NetworkManager[1283]: <info> Auto-activating connection 'Wired connection 1'.
May 14 14:31:54 seneca NetworkManager[1283]: <info> Activation (eth0) starting connection 'Wired connection 1'
May 14 14:31:54 seneca NetworkManager[1283]: <info> Activation (eth0) Stage 1 of 5 (Device Prepare) scheduled...
May 14 14:31:54 seneca NetworkManager[1283]: <info> Activation (eth0) Stage 1 of 5 (Device Prepare) started...
May 14 14:31:54 seneca NetworkManager[1283]: <info> (eth0): device state change: disconnected -> prepare (reason 'none') [30 40 0]
May 14 14:31:54 seneca NetworkManager[1283]: <info> NetworkManager state is now CONNECTING
May 14 14:31:54 seneca NetworkManager[1283]: <info> Activation (eth0) Stage 2 of 5 (Device Configure) scheduled...
May 14 14:31:54 seneca NetworkManager[1283]: <info> Activation (eth0) Stage 1 of 5 (Device Prepare) complete.
May 14 14:31:54 seneca NetworkManager[1283]: <info> Activation (eth0) Stage 2 of 5 (Device Configure) starting...
May 14 14:31:54 seneca NetworkManager[1283]: <info> (eth0): device state change: prepare -> config (reason 'none') [40 50 0]
May 14 14:31:54 seneca NetworkManager[1283]: <info> Activation (eth0) Stage 2 of 5 (Device Configure) successful.
May 14 14:31:54 seneca NetworkManager[1283]: <info> Activation (eth0) Stage 3 of 5 (IP Configure Start) scheduled.
May 14 14:31:54 seneca NetworkManager[1283]: <info> Activation (eth0) Stage 2 of 5 (Device Configure) complete.
May 14 14:31:54 seneca NetworkManager[1283]: <info> Activation (eth0) Stage 3 of 5 (IP Configure Start) started...
May 14 14:31:54 seneca NetworkManager[1283]: <info> (eth0): device state change: config -> ip-config (reason 'none') [50 70 0]
May 14 14:31:54 seneca NetworkManager[1283]: <info> Activation (eth0) Beginning DHCPv4 transaction (timeout in 45 seconds)
May 14 14:31:54 seneca NetworkManager[1283]: <info> dhclient started with pid 1348
May 14 14:31:54 seneca NetworkManager[1283]: <info> Activation (eth0) Stage 3 of 5 (IP Configure Start) complete.
May 14 14:31:54 seneca NetworkManager[1283]: <info> (eth0): DHCPv4 state changed nbi -> preinit
May 14 14:31:54 seneca dhclient: DHCPREQUEST on eth0 to 255.255.255.255 port 67
May 14 14:32:00 seneca dhclient: DHCPREQUEST on eth0 to 255.255.255.255 port 67
May 14 14:32:01 seneca NetworkManager[1283]: <info> (eth0): link disconnected (deferring action for 4 seconds)
May 14 14:32:04 seneca NetworkManager[1283]: <info> (eth0): link disconnected (calling deferred action)
May 14 14:32:04 seneca NetworkManager[1283]: <info> (eth0): device state change: ip-config -> unavailable (reason 'carrier-changed') [70 20 40]
May 14 14:32:04 seneca NetworkManager[1283]: <info> (eth0): deactivating device (reason 'carrier-changed') [40]
May 14 14:32:05 seneca NetworkManager[1283]: <info> (eth0): canceled DHCP transaction, DHCP client pid 1348
May 14 14:32:05 seneca NetworkManager[1283]: <info> NetworkManager state is now DISCONNECTED
May 14 14:32:28 seneca NetworkManager[1283]: <info> (eth0): link connected
May 14 14:32:28 seneca NetworkManager[1283]: <info> (eth0): device state change: unavailable -> disconnected (reason 'carrier-changed') [20 30 40]
May 14 14:32:28 seneca NetworkManager[1283]: <info> Auto-activating connection 'Wired connection 1'.
May 14 14:32:28 seneca NetworkManager[1283]: <info> Activation (eth0) starting connection 'Wired connection 1'
May 14 14:32:28 seneca NetworkManager[1283]: <info> Activation (eth0) Stage 1 of 5 (Device Prepare) scheduled...
May 14 14:32:28 seneca NetworkManager[1283]: <info> Activation (eth0) Stage 1 of 5 (Device Prepare) started...
May 14 14:32:28 seneca NetworkManager[1283]: <info> (eth0): device state change: disconnected -> prepare (reason 'none') [30 40 0]
May 14 14:32:28 seneca NetworkManager[1283]: <info> NetworkManager state is now CONNECTING
May 14 14:32:28 seneca NetworkManager[1283]: <info> Activation (eth0) Stage 2 of 5 (Device Configure) scheduled...
May 14 14:32:28 seneca NetworkManager[1283]: <info> Activation (eth0) Stage 1 of 5 (Device Prepare) complete.
May 14 14:32:28 seneca NetworkManager[1283]: <info> Activation (eth0) Stage 2 of 5 (Device Configure) starting...
May 14 14:32:28 seneca NetworkManager[1283]: <info> (eth0): device state change: prepare -> config (reason 'none') [40 50 0]
May 14 14:32:28 seneca NetworkManager[1283]: <info> Activation (eth0) Stage 2 of 5 (Device Configure) successful.
May 14 14:32:28 seneca NetworkManager[1283]: <info> Activation (eth0) Stage 3 of 5 (IP Configure Start) scheduled.
May 14 14:32:28 seneca NetworkManager[1283]: <info> Activation (eth0) Stage 2 of 5 (Device Configure) complete.
May 14 14:32:28 seneca NetworkManager[1283]: <info> Activation (eth0) Stage 3 of 5 (IP Configure Start) started...
May 14 14:32:28 seneca NetworkManager[1283]: <info> (eth0): device state change: config -> ip-config (reason 'none') [50 70 0]
May 14 14:32:28 seneca NetworkManager[1283]: <info> Activation (eth0) Beginning DHCPv4 transaction (timeout in 45 seconds)
May 14 14:32:28 seneca NetworkManager[1283]: <info> dhclient started with pid 1350
May 14 14:32:28 seneca NetworkManager[1283]: <info> Activation (eth0) Stage 3 of 5 (IP Configure Start) complete.
May 14 14:32:28 seneca NetworkManager[1283]: <info> (eth0): DHCPv4 state changed nbi -> preinit
May 14 14:32:28 seneca dhclient: DHCPREQUEST on eth0 to 255.255.255.255 port 67
May 14 14:32:32 seneca dhclient: DHCPREQUEST on eth0 to 255.255.255.255 port 67
May 14 14:32:32 seneca dhclient: DHCPACK from 192.168.178.1
May 14 14:32:32 seneca NetworkManager[1283]: <info> (eth0): DHCPv4 state changed preinit -> reboot
May 14 14:32:32 seneca NetworkManager[1283]: <info>   address 192.168.178.21
May 14 14:32:32 seneca NetworkManager[1283]: <info>   plen 24 (255.255.255.0)
May 14 14:32:32 seneca NetworkManager[1283]: <info>   gateway 192.168.178.1
May 14 14:32:32 seneca NetworkManager[1283]: <info>   server identifier 192.168.178.1
May 14 14:32:32 seneca NetworkManager[1283]: <info>   lease time 864000
May 14 14:32:32 seneca NetworkManager[1283]: <info>   nameserver '192.168.178.1'
May 14 14:32:32 seneca NetworkManager[1283]: <info>   domain name 'fritz.box'
May 14 14:32:32 seneca NetworkManager[1283]: <info> Activation (eth0) Stage 5 of 5 (IPv4 Configure Commit) scheduled...
May 14 14:32:32 seneca NetworkManager[1283]: <info> Activation (eth0) Stage 5 of 5 (IPv4 Commit) started...
May 14 14:32:32 seneca NetworkManager[1283]: <info> (eth0): device state change: ip-config -> ip-check (reason 'none') [70 80 0]
May 14 14:32:32 seneca NetworkManager[1283]: <info> Activation (eth0) Stage 5 of 5 (IPv4 Commit) complete.
May 14 14:32:32 seneca NetworkManager[1283]: <info> (eth0): device state change: ip-check -> secondaries (reason 'none') [80 90 0]
May 14 14:32:32 seneca NetworkManager[1283]: <info> (eth0): device state change: secondaries -> activated (reason 'none') [90 100 0]
May 14 14:32:32 seneca NetworkManager[1283]: <info> NetworkManager state is now CONNECTED_LOCAL
May 14 14:32:32 seneca dhclient: bound to 192.168.178.21 -- renewal in 351006 seconds.
May 14 14:32:32 seneca NetworkManager[1283]: <info> NetworkManager state is now CONNECTED_GLOBAL
May 14 14:32:32 seneca NetworkManager[1283]: <info> Policy set 'Wired connection 1' (eth0) as default for IPv4 routing and DNS.
May 14 14:32:32 seneca NetworkManager[1283]: <info> Activation (eth0) successful, device activated.

[NAB]

gambit, das Log sieht völlig richtig aus ... er erreicht den DHCP-Server und kriegt die IP "address 192.168.178.21" zugewiesen mit der Fritzbox als "gateway 192.168.178.1".

[TomL]

Im Protokoll steht u.A.

Code: Alles auswählen

May 14 14:31:54 seneca NetworkManager[1283]: <info> (eth0): DHCPv4 state changed nbi -> preinit
May 14 14:31:54 seneca dhclient: DHCPREQUEST on eth0 to 255.255.255.255 port 67
May 14 14:32:00 seneca dhclient: DHCPREQUEST on eth0 to 255.255.255.255 port 67
May 14 14:32:01 seneca NetworkManager[1283]: <info> (eth0): link disconnected (deferring action for 4 seconds)
May 14 14:32:04 seneca NetworkManager[1283]: <info> (eth0): link disconnected (calling deferred action)
May 14 14:32:04 seneca NetworkManager[1283]: <info> (eth0): device state change: ip-config -> unavailable (reason 'carrier-changed') [70 20 40]

Ich habe mal nach diesen beiden Zeilen gegoogelt und finde dazu (ohne das vertieft zu haben) haufenweise Störungsmeldungen mit diesem NWM

NetworkManager[1283]: <info> (eth0): link disconnected (deferring action for 4 seconds)
NetworkManager[1283]: <info> (eth0): device state change: unavailable -> disconnected (reason 'carrier-changed'

Ich persönlich halte die ganze Situation für ziemlich unübersichtlich. Da werden vom NWM etliche Komponenten "bedient", wo ich immer für möglich halte, dass sich da etwas gegenseitig beharkt.

Code: Alles auswählen

May 14 14:30:05 seneca NetworkManager[1283]: <info> WiFi hardware radio set enabled
May 14 14:30:05 seneca NetworkManager[1283]: <info> WWAN hardware radio set enabled
::::
May 14 14:30:05 seneca NetworkManager[1283]: <info> WiFi enabled by radio killswitch; enabled by state file
May 14 14:30:05 seneca NetworkManager[1283]: <info> WWAN enabled by radio killswitch; enabled by state file
May 14 14:30:05 seneca NetworkManager[1283]: <info> WiMAX enabled by radio killswitch; enabled by state file

Meine Vorgehensweise wäre, zuerst konsequent alles zu deaktivieren, was sich bisher mit dem Handling der Netzwerk-Hardware beschäftigt hat.... einschließlich des Abschaltens des WLAN-Funks. An unseren Dell-Laptop gibts dafür extra Schalter. Und dann jede Komponente nach dem Kaltstart für sich ausgiebig testen, um festzulegen, was definitiv geht oder nicht geht. Und ich würde auch mal gegenprüfen, ob das DHCP-Verhalten bei WIFI anderes ist, wenn eth0 ausgeschaltet bleibt. Das ergibt vielleicht Rückschlüsse, wenn das eine geht, das andere aber nicht. Aber wenn ich das testen würde, dann immer "exklusiv"... das bedeutet: "alle anderen Komponenten sind ausgeschaltet", damit es nicht zu verwirrendem Störfeuer kommen kann.

BTW, haben wir eigentlich schon mal geprüft, ob du überhaupt die richten Treiber (Kernel-Module) für Deine Hardware geladen hast?

[TomL]

gambit, das Log sieht völlig richtig aus ... er erreicht den DHCP-Server und kriegt die IP "address 192.168.178.21" zugewiesen mit der Fritzbox als "gateway 192.168.178.1".

Aber erst im zweiten Versuch... oder verstehe ich da was falsch?

[NAB]

Aber erst im zweiten Versuch... oder verstehe ich da was falsch?

Doch, richtig. Erst findet er keinen Carrier ... das ist ja das eigentliche Problem.

[TomL]

Doch, richtig. Erst findet er keinen Carrier ... das ist ja das eigentliche Problem.

Und das ist genau das, was ich nicht begreife..... für mich deutet das immer noch auf einen Konflikt hin.... als wenn sich 2 beharken und der NWM erst dann erfolgreich ist, wenn systemd den anderen Job (vielleicht wegen diesem Timeout (den wir in 'nem anderen Thread festgestellt haben)) gekillt hat. Als erstes habe ich an den NWM gedacht, aber dann läuft ja auch noch dieser dispatcher-service... und dann noch WLAN .... und alles will ran ans Netz oder tut irgendwas mit der Netzhardware.

Ich bin immer noch der Meinung, wenn wirklich alles an Netzwerk-Programmen und Daemons rigoros deaktiviert ist, müssen sich die Interfaces eth0 und auch wlan0 nach einem Kaltstart zuverlässig von Hand öffnen lassen, entweder mit DHCP oder via Static-IP. Und wenns das nicht tut, ist es vielleicht ein Treiber-Problem, oder vielleicht hat es sogar eine echte "physische" Ursache.... Kabel, Port, Interface, Router. Aber wenn die Hardware ok ist, muss das imho manuell gehen, allerdings erst, wenn sichergestellt ist, dass Konkurrenz und Konflikte ausgeräumt sind.

Ich würde auch mal testen, wie sich das z.B. mit einer Linux-Mint-Live-CD (LMDE) verhält. Wenn die das bei 2-3 Kaltstarts regelmäßig hinkriegt und die Logs ordentlich aussehen, dann ist die Ursache doch klar und man kann das ermitteln.

[gambit]

ich hatte vor 'disable' den NWM gestoppt:

Code: Alles auswählen

# systemctl stop NetworkManager.service
# systemctl disable NetworkManager.service
Removed symlink /etc/systemd/system/multi-user.target.wants/NetworkManager.service.
Removed symlink /etc/systemd/system/dbus-org.freedesktop.nm-dispatcher.service.

War dann diese Feststellung (in gänze) richtig oder falsch....
Deaktivierter NWM -> dann Kaltstart PC -> sämtliche Maßnahmen zum Aufbau der Netzwerkverbindung schlagen fehl, bis der Router neu gestartet wurde.

Ich frage deshalb, weil m.M. nach erst der Reboot absolut und zweifelsfrei sicherstellt, dass alle IRQ's, Ressourcen (was weiss ich, was da noch so im PC rumgammelt und sich langweilt) wirklich weg, geschlossen oder freigegeben ist.... z.B. auch dieser dispatcher-daemon....(?). Und möglicherweise kann eine hängende Aktivierung auch einfach damit zusammenhängen, dass noch irgendeine Komponente von irgendeinem Job blockiert wird, der der Meinung "ist meins" und damit anderes blockiert.

Ok, verstehe. Dann probiere ich das nochmal mit reboot. Das wird etwas dauern, wegen der leidigen Notwendigkeit, NWM wieder aktivieren zu müssen, um hier zu posten.

Nach Deaktivierung NWM und anschließendem reboot wars diesmal anders:

Ich habe in '/etc/systemd/network/eth0.network' DHCP deaktiviert und eingegeben:

Code: Alles auswählen

[Match]
Name=eth0

[Network]
DHCP=none
Address=192.168.178.9/24
Gateway=192.168.178.1
DNS=192.168.178.1
NTP=192.168.178.1

Danach:

Code: Alles auswählen

root@seneca:/home/rmb# chmod 644 /etc/systemd/network/eth0.network
root@seneca:/home/rmb# chown root:root /etc/systemd/network/eth0.network
root@seneca:/home/rmb# nano /etc/systemd/resolved.conf
root@seneca:/home/rmb# systemctl start systemd-resolved.service; systemctl status systemd-resolved.service
● systemd-resolved.service - Network Name Resolution
   Loaded: loaded (/lib/systemd/system/systemd-resolved.service; disabled)
   Active: active (running) since Sa 2016-05-14 15:49:09 CEST; 5ms ago
     Docs: man:systemd-resolved.service(8)
 Main PID: 1284 (systemd-resolve)
   Status: "Processing requests..."
   CGroup: /system.slice/systemd-resolved.service
           └─1284 /lib/systemd/systemd-resolved
root@seneca:/home/rmb# [ -f /etc/resolv.conf ] && rm /etc/resolv.conf
root@seneca:/home/rmb# ln -sf /run/systemd/resolve/resolv.conf /etc/resolv.conf
root@seneca:/home/rmb# systemctl restart systemd-resolved.service
root@seneca:/home/rmb# ls /etc/resolv.conf
/etc/resolv.conf
root@seneca:/home/rmb# cat /etc/resolv.conf
# This file is managed by systemd-resolved(8). Do not edit.
#
# Third party programs must not access this file directly, but
# only through the symlink at /etc/resolv.conf. To manage
# resolv.conf(5) in a different way, replace the symlink by a
# static file or a different symlink.

nameserver 192.168.178.1
root@seneca:/home/rmb# ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00                                                                                                                    
    inet 127.0.0.1/8 scope host lo                                                                                                                                           
       valid_lft forever preferred_lft forever                                                                                                                               
    inet6 ::1/128 scope host                                                                                                                                                 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 10:60:4b:81:76:38 brd ff:ff:ff:ff:ff:ff
root@seneca:/home/rmb# systemctl start systemd-networkd.service
root@seneca:/home/rmb# systemctl start systemd-networkd-wait-online.service
root@seneca:/home/rmb# ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 10:60:4b:81:76:38 brd ff:ff:ff:ff:ff:ff
    inet 192.168.178.9/24 brd 192.168.178.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::1260:4bff:fe81:7638/64 scope link 
       valid_lft forever preferred_lft forever
root@seneca:/home/rmb# systemctl status systemd-networkd systemd-resolved systemd-networkd-wait-online
● systemd-networkd.service - Network Service
   Loaded: loaded (/lib/systemd/system/systemd-networkd.service; disabled)
   Active: active (running) since Sa 2016-05-14 15:54:43 CEST; 3min 20s ago
     Docs: man:systemd-networkd.service(8)
 Main PID: 1300 (systemd-network)
   Status: "Processing requests..."
   CGroup: /system.slice/systemd-networkd.service
           └─1300 /lib/systemd/systemd-networkd

Mai 14 15:54:43 seneca systemd-networkd[1300]: lo              : gained carrier
Mai 14 15:54:43 seneca systemd-networkd[1300]: eth0            : link configured
Mai 14 15:54:44 seneca systemd-networkd[1300]: eth0            : gained carrier

● systemd-resolved.service - Network Name Resolution
   Loaded: loaded (/lib/systemd/system/systemd-resolved.service; disabled)
   Active: active (running) since Sa 2016-05-14 15:52:16 CEST; 5min ago
     Docs: man:systemd-resolved.service(8)
 Main PID: 1293 (systemd-resolve)
   Status: "Processing requests..."
   CGroup: /system.slice/systemd-resolved.service
           └─1293 /lib/systemd/systemd-resolved

● systemd-networkd-wait-online.service - Wait for Network to be Configured
   Loaded: loaded (/lib/systemd/system/systemd-networkd-wait-online.service; disabled)
   Active: active (exited) since Sa 2016-05-14 15:55:28 CEST; 2min 35s ago
     Docs: man:systemd-networkd-wait-online.service(8)
  Process: 1303 ExecStart=/lib/systemd/systemd-networkd-wait-online (code=exited, status=0/SUCCESS)
 Main PID: 1303 (code=exited, status=0/SUCCESS)
   CGroup: /system.slice/systemd-networkd-wait-online.service

Beachte:

Code: Alles auswählen

● systemd-networkd-wait-online.service - Wait for Network to be Configured
   Loaded: loaded (/lib/systemd/system/systemd-networkd-wait-online.service; disabled)
   Active: active (exited) since Sa 2016-05-14 15:55:28 CEST; 2min 35s ago

Eine Verbindung zum Netzwerk bestand nicht (LAN-LED aus).

Nach Reboot erneute Statusabfrage:

Code: Alles auswählen

systemctl status systemd-networkd systemd-resolved systemd-networkd-wait-online● systemd-networkd.service - Network Service
   Loaded: loaded (/lib/systemd/system/systemd-networkd.service; enabled)
   Active: active (running) since Sa 2016-05-14 16:03:37 CEST; 19min ago
     Docs: man:systemd-networkd.service(8)
 Main PID: 636 (systemd-network)
   Status: "Processing requests..."
   CGroup: /system.slice/systemd-networkd.service
           └─636 /lib/systemd/systemd-networkd

Mai 14 16:03:37 seneca systemd-networkd[636]: lo              : gained carrier
Mai 14 16:03:37 seneca systemd-networkd[636]: eth0            : link configured

● systemd-resolved.service - Network Name Resolution
   Loaded: loaded (/lib/systemd/system/systemd-resolved.service; enabled)
   Active: active (running) since Sa 2016-05-14 16:03:37 CEST; 19min ago
     Docs: man:systemd-resolved.service(8)
 Main PID: 658 (systemd-resolve)
   Status: "Processing requests..."
   CGroup: /system.slice/systemd-resolved.service
           └─658 /lib/systemd/systemd-resolved

● systemd-networkd-wait-online.service - Wait for Network to be Configured
   Loaded: loaded (/lib/systemd/system/systemd-networkd-wait-online.service; enabled)
   Active: activating (start) since Sa 2016-05-14 16:03:37 CEST; 19min ago
     Docs: man:systemd-networkd-wait-online.service(8)
 Main PID: 661 (systemd-network)
   CGroup: /system.slice/systemd-networkd-wait-online.service
           └─661 /lib/systemd/systemd-networkd-wait-online

also wieder "activating" anstatt "active" beim letztgenannten Service.

Dann wieder Router/aus/an:

Verbindung zwischen der zuvor vergebenen festen IP 192.168.178.9 zum Router (192.168.178.1) kommt zustande.

Erneute Statusabfrage:

Code: Alles auswählen

systemctl status systemd-networkd systemd-resolved systemd-networkd-wait-online
● systemd-networkd.service - Network Service
   Loaded: loaded (/lib/systemd/system/systemd-networkd.service; enabled)
   Active: active (running) since Sa 2016-05-14 16:03:37 CEST; 26min ago
     Docs: man:systemd-networkd.service(8)
 Main PID: 636 (systemd-network)
   Status: "Processing requests..."
   CGroup: /system.slice/systemd-networkd.service
           └─636 /lib/systemd/systemd-networkd

Mai 14 16:03:37 seneca systemd-networkd[636]: lo              : gained carrier
Mai 14 16:03:37 seneca systemd-networkd[636]: eth0            : link configured
Mai 14 16:25:52 seneca systemd-networkd[636]: eth0            : gained carrier
Mai 14 16:25:59 seneca systemd-networkd[636]: eth0            : lost carrier
Mai 14 16:26:27 seneca systemd-networkd[636]: eth0            : gained carrier

● systemd-resolved.service - Network Name Resolution
   Loaded: loaded (/lib/systemd/system/systemd-resolved.service; enabled)
   Active: active (running) since Sa 2016-05-14 16:03:37 CEST; 26min ago
     Docs: man:systemd-resolved.service(8)
 Main PID: 658 (systemd-resolve)
   Status: "Processing requests..."
   CGroup: /system.slice/systemd-resolved.service
           └─658 /lib/systemd/systemd-resolved

● systemd-networkd-wait-online.service - Wait for Network to be Configured
   Loaded: loaded (/lib/systemd/system/systemd-networkd-wait-online.service; enabled)
   Active: active (exited) since Sa 2016-05-14 16:25:52 CEST; 3min 53s ago
     Docs: man:systemd-networkd-wait-online.service(8)
  Process: 661 ExecStart=/lib/systemd/systemd-networkd-wait-online (code=exited, status=0/SUCCESS)
 Main PID: 661 (code=exited, status=0/SUCCESS)
   CGroup: /system.slice/systemd-networkd-wait-online.service

[gambit]

Doch, richtig. Erst findet er keinen Carrier ... das ist ja das eigentliche Problem.

Und das ist genau das, was ich nicht begreife..... für mich deutet das immer noch auf einen Konflikt hin.... als wenn sich 2 beharken und der NWM erst dann erfolgreich ist, wenn systemd den anderen Job (vielleicht wegen diesem Timeout (den wir in 'nem anderen Thread festgestellt haben)) gekillt hat. Als erstes habe ich an den NWM gedacht, aber dann läuft ja auch noch dieser dispatcher-service... und dann noch WLAN .... und alles will ran ans Netz oder tut irgendwas mit der Netzhardware.

Wlan benutze ich gar nicht, aber für Deine Vermutung eines Konflikts spricht vielleicht:

Code: Alles auswählen

May 14 15:41:50 seneca NetworkManager[1283]: <info> caught signal 15, shutting down normally.
May 14 15:41:50 seneca NetworkManager[1283]: (NetworkManager:1283): GLib-CRITICAL **: Source ID 21 was not found when attempting to remove it
May 14 15:41:50 seneca NetworkManager[1283]: <info> exiting (success)
May 14 15:42:44 seneca networking[405]: Configuring network interfaces...done.
May 14 15:42:44 seneca avahi-daemon[625]: Network interface enumeration completed.
May 14 15:42:44 seneca kernel: [    0.536817] e1000e: Intel(R) PRO/1000 Network Driver - 2.3.2-k
May 14 15:42:44 seneca kernel: [    0.759362] e1000e 0000:00:19.0 eth0: Intel(R) PRO/1000 Network Connection
May 14 15:54:43 seneca systemd-networkd[1300]: lo              : gained carrier
May 14 15:54:43 seneca systemd-networkd[1300]: eth0            : link configured
May 14 15:54:44 seneca systemd-networkd[1300]: eth0            : gained carrier
May 14 16:03:37 seneca kernel: [    0.531912] e1000e: Intel(R) PRO/1000 Network Driver - 2.3.2-k
May 14 16:03:37 seneca kernel: [    0.754604] e1000e 0000:00:19.0 eth0: Intel(R) PRO/1000 Network Connection
May 14 16:03:37 seneca networking[419]: Configuring network interfaces...done.
May 14 16:03:37 seneca avahi-daemon[613]: Network interface enumeration completed.
May 14 16:03:37 seneca systemd-networkd[636]: lo              : gained carrier
May 14 16:03:37 seneca systemd-networkd[636]: eth0            : link configured
May 14 16:25:52 seneca systemd-networkd[636]: eth0            : gained carrier
May 14 16:25:59 seneca systemd-networkd[636]: eth0            : lost carrier
May 14 16:26:27 seneca systemd-networkd[636]: eth0            : gained carrier

Den NetworkManger.service hatte ich aber nicht wieder aktiviert:

Code: Alles auswählen

# systemctl status NetworkManager.service

systemctl status NetworkManager.service
● NetworkManager.service - Network Manager
   Loaded: loaded (/lib/systemd/system/NetworkManager.service; disabled)
   Active: inactive (dead)

[gambit]

Den NetworkManger.service hatte ich aber nicht wieder aktiviert:

Code: Alles auswählen

# systemctl status NetworkManager.service

systemctl status NetworkManager.service
● NetworkManager.service - Network Manager
   Loaded: loaded (/lib/systemd/system/NetworkManager.service; disabled)
   Active: inactive (dead)

Könnte das sein, dass da ein "override" distributionsseitig (Bunsenlabs) stattfindet?
Ich bin über den link von habakug https://www.freedesktop.org/software/sy ... %20Options auf die Idee gekommen:

The .network files are read from the files located in the system network directory /usr/lib/systemd/network, the volatile runtime network directory /run/systemd/network and the local administration network directory /etc/systemd/network. All configuration files are collectively sorted and processed in lexical order, regardless of the directories in which they live. However, files with identical filenames replace each other. Files in /etc have the highest priority, files in /run take precedence over files with the same name in /usr/lib. This can be used to override a system-supplied configuration file with a local file if needed. As a special case, an empty file (file size 0) or symlink with the same name pointing to /dev/null disables the configuration file entirely (it is "masked").

[gambit]

BTW, haben wir eigentlich schon mal geprüft, ob du überhaupt die richten Treiber (Kernel-Module) für Deine Hardware geladen hast?

Ich glaube nicht.

[TomL]

Nach Reboot erneute Statusabfrage:

Code: Alles auswählen

● systemd-networkd-wait-online.service - Wait for Network to be Configured
   Loaded: loaded (/lib/systemd/system/systemd-networkd-wait-online.service; enabled)
   Active: activating (start) since Sa 2016-05-14 16:03:37 CEST; 19min ago
     Docs: man:systemd-networkd-wait-online.service(8)
 Main PID: 661 (systemd-network)
   CGroup: /system.slice/systemd-networkd-wait-online.service
           └─661 /lib/systemd/systemd-networkd-wait-online

also wieder "activating" anstatt "active" beim letztgenannten Service.

Genau hier ist die Stelle (unmittelbar nach dem Systemstart und der Tatsache, dass das Netz nicht verbunden ist), wo man ins Log reinschaut. Das Log sieht bei mir nach dem Boot so aus.... also deutlich überschaubarer... einfach nur das Netzwerk mit systemd gestartet... und keine Spur eines NWM:

Code: Alles auswählen

journalctl -b | grep "network\|eth0" -i
Mai 14 16:19:14 thomaspc kernel: r8169 0000:03:00.0 eth0: RTL8168evl/8111evl at 0xffffc90010f24000, 74:d4:35:ba:37:1f, XID 0c900800 IRQ 43
Mai 14 16:19:14 thomaspc kernel: r8169 0000:03:00.0 eth0: jumbo features [frames: 9200 bytes, tx checksumming: ko]
Mai 14 16:19:22 thomaspc avahi-daemon[473]: Network interface enumeration completed.
Mai 14 16:19:22 thomaspc systemd-networkd[486]: lo              : gained carrier
Mai 14 16:19:22 thomaspc systemd-networkd[486]: eth0            : could not set route: Network is unreachable
Mai 14 16:19:22 thomaspc systemd-networkd[486]: eth0            : link configured
Mai 14 16:19:22 thomaspc kernel: r8169 0000:03:00.0 eth0: link down
Mai 14 16:19:22 thomaspc kernel: r8169 0000:03:00.0 eth0: link down
Mai 14 16:19:22 thomaspc kernel: IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
Mai 14 16:19:24 thomaspc systemd-networkd[486]: eth0            : gained carrier
Mai 14 16:19:24 thomaspc kernel: r8169 0000:03:00.0 eth0: link up
Mai 14 16:19:24 thomaspc kernel: IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
Mai 14 16:19:24 thomaspc thlu:network_wait_online[528]: Waiting to Network comes online!
Mai 14 16:19:25 thomaspc systemd-networkd[486]: eth0            : DHCPv4 address 10.20.10.37/24 via 10.20.10.1
Mai 14 16:19:25 thomaspc systemd-timesyncd[384]: Network configuration changed, trying to establish connection.
Mai 14 16:19:25 thomaspc systemd-networkd[486]: eth0            : link configured

BTW, du solltest jetzt bei der Fehlersuche am besten auf die Service-Unit "systemd-networkd-wait-online.service" verzichten. An diesem Punkt ist die eigentlich völlig überflüssig und hat erst später, wenns läuft einen Sinn. Man braucht diese Unit dann, wenn z.B. ein bestimmter Jobs erst dann gestartet werden darf, wenn das Netzwerk verfügbar ist. Damit erreicht man, dass dieser Job eben solange wartet. Aber zum jetzigen Zeitpunkt ist das natürlich Quatsch und man muss sich nicht damit befassen.

[TomL]

BTW, haben wir eigentlich schon mal geprüft, ob du überhaupt die richten Treiber (Kernel-Module) für Deine Hardware geladen hast?

Ich glaube nicht.

Zeig mal, was dabei rauskommt:

Code: Alles auswählen

lspci -nnk | grep net -i -A 2       

Code: Alles auswählen

03:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev 06)
	Subsystem: Gigabyte Technology Co., Ltd Motherboard [1458:e000]
	Kernel driver in use: r8169

[gambit]

BTW, haben wir eigentlich schon mal geprüft, ob du überhaupt die richten Treiber (Kernel-Module) für Deine Hardware geladen hast?

Ich glaube nicht.

Zeig mal, was dabei rauskommt:

Code: Alles auswählen

lspci -nnk | grep net -i -A 2       

Das zeigt

Code: Alles auswählen

00:19.0 Ethernet controller [0200]: Intel Corporation 82579LM Gigabit Network Connection [8086:1502] (rev 04)
	Subsystem: Hewlett-Packard Company Device [103c:3396]
	Kernel driver in use: e1000e

[TomL]

Meiner Meinung nach passt der Treiber. Ich habe auch nix anderes dazu gefunden. Übrigens, verlass Dich nicht allein auf die grüne LED, ich würde immer auch testen, ob ich Google anpingen kann.

Code: Alles auswählen

ping 8.8.8.8

[gambit]

Und da tat sich dann minutenlang nichts. Ich habe

Code: Alles auswählen

systemctl start systemd-networkd-wait-online.service[

dann mit Strg+C abgebrochen und den Status-befehl eingegeben.

Dann versuch mal erneut als Test, nur mit folgender geänderter eth0.network-Datei:

Code: Alles auswählen

[Match]
Name=eth0

[Network]
DHCP=none
IPv4LL=false
Address=192.168.178.9/24
Gateway=192.168.178.1
DNS=192.168.178.1
NTP=192.168.178.1

D. h., ohne DHCP und mit statischer IP-Adresse.

Vielleicht hast Du den Thread ja noch verfolgen können. Zusammengefasst: Mit der Vergabe der statischen IP funktioniert eine Verbindung, aber nicht ohne Routermanipulation. Ich muss erstmal viel lesen, vor allem auch zu systemd - so verstehe ich den Beitrag von habakug jedenfalls.

Vielen Dank an Dich und die anderen, die hier ihre Zeit investiert haben. Lösung oder Kapitulation werde ich jedenfalls berichten.

[mat6937]

Zusammengefasst: Mit der Vergabe der statischen IP funktioniert eine Verbindung, aber nicht ohne Routermanipulation.

OK. Mich würde interessieren, was Du mit "Routermanipulation" genau meinst? Denn ich habe auch eine FritzBox bzw. diverse Geräte mit statischer IP-Adresse konfiguriert, und muss am Router (FritzBox) nichts "manipulieren".

EDIT:

Wenn die Zuweisung der IP-Adresse per DHCP, die 1. Wahl bleiben soll, könntest Du z. B. statt der eth0.network-Datei den dhcpcd-Daemon (mit dhcpcd.service) nutzen und am Ende der dhcpcd.conf-Datei Folgendes eintragen:

Code: Alles auswählen

# define static profile
profile static_eth0
static ip_address=192.168.178.9/24
static routers=192.168.178.1
static domain_name_servers=192.168.178.1
static ntp_servers=192.168.178.1

# fallback to static profile on eth0
interface eth0
fallback static_eth0

D. h., eine statische Zuweisung der IP-Adresse erfolgt nur dann, wenn das Zuweisen per DHCP fehlschlägt (fallback).

[gambit]

Zusammengefasst: Mit der Vergabe der statischen IP funktioniert eine Verbindung, aber nicht ohne Routermanipulation.

OK. Mich würde interessieren, was Du mit "Routermanipulation" genau meinst? Denn ich habe auch eine FritzBox bzw. diverse Geräte mit statischer IP-Adresse konfiguriert, und muss am Router (FritzBox) nichts "manipulieren".

Der Ausdruck "Routermanipulation" ist dem Threadkontext geschuldet und sollte lediglich das zigfach wiederholte "Router stromlos machen/Router wieder mit Strom versorgen" ersetzen.

Wenn die Zuweisung der IP-Adresse per DHCP, die 1. Wahl bleiben soll ...

Nein, die erste Wahl ist das nicht. Vor der Installation von Debian hatte ich bei Suse ebenfalls eine statische IP eingerichtet. Ich benutze nur einen Rechner und nutze Wlan nicht. Aber zurzeit ist das für mich ein sekundärer Punkt, da die statische IP die fehlende Verbindung nach Kaltstart (sc. Rechnerstart nach Zustand "Rechner stromlos") nicht beeinflusst hatte. Aber auch das werde ich weiter untersuchen, vielleicht habe ich ja nur einen Fehler gemacht.

[Prosa]
Wie gesagt, ich muss erstmal viel lesen, weil ich immer wieder merke, dass ich eigentlich überhaupt keine Ahnung habe und bei jedem auftauchenden Stichwort "ab ovo" anfangen muss.
Außerdem muss ich den Rechner ja auch "produktiv" (wenn das auch nur privat bedeutet) nutzen und ich habe zudem eine Reihe anderer Baustellen (Übertragung der Daten von der Suse /home auf mein jetziges System) und mit openbox habe ich mir ja auch nicht gerade eine bequeme Oberfläche ausgesucht.
Außerdem habe ich den Zusammenhang zwischen '/etc/network/interfaces' und systemd bzw. NWM noch nicht komplett verstanden.
Fazit:
Die Fehlersuche wird dauern.
[/Prosa]

Diese Fallback-Konstruktion finde ich interessant. Vielen Dank für die Info. Es wäre nett, wenn ich Dich im Bedarfsfall hierauf nochmal ansprechen könnte.

[NAB]

gambit, klappt es eigentlich, einfach den LAN-Stecker zu ziehen und wieder einzustecken, statt die gesamte Fritzbox neu zu starten? (ja, das darfst du im laufenden Betrieb machen)