• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

Kein Netz auch wenn der Nertwermanager sagt alles OK

josef-wien schrieb:
Das meine ich nicht, ich vermisse:
josef-wien schrieb:
Führe das Skript mit denselben Einstellungen einmal mit dem XEN-Kernel und jetzt noch einmal mit dem "normalen" Kernel aus
[/quote
Das habe ich!
mit dem XEN-Kernel <=> Mit Xen

mit dem "normalen" Kernel <=> ohne Xen

ob ich es als root ausführe oder nicht hat für mich kein unterschied gezeigt.

Die ausgabe ist soweit ich es gesehen bis auf ein teil (BOOT_IMAGE=/boot/vmlinuz-3.7.10-1.1-desktop ) gleich.

Das Netzwerk funktioniert mit normalen Kernel nicht aber mit dem XEN kernel.

Bis dann
Roemer
 
Du stehst auf der Leitung! Es geht nicht um meinen einsamen Konsol-Befehl. Du sollst das Skript collectNWData.sh in beiden Umgebungen ausführen.
 
Ich stand wirklich auf der Leitung

Hier ist das Ergebnis mit XEN Kernel

Code:
collectNWData.sh V0.7.5.1

--- Welcher Netzwerkverbindungtyp soll getestet werden?
--- (2) Kabelgebundene Verbindung

--- Welche Netzwerktopologie liegt vor?
--- (2) DSL HW router <---> LinuxClient

--- Auf welchem Rechner wird das Script ausgeführt?
--- (1) LinuxClient

--- NWCollect sammelt Netzwerkkonfigurationsinformationen in Datei ...

--- NWEliza untersucht das System nach häufigen Netzwerkkonfigurationsfehlern ...
!!! CND0310W: Klassische Netzwerkkonfiguration mit ifup wurde entdeckt. Die Konfiguration mit networkmanager ist einfacher

--- Gehe zu http://www.linux-tips-and-tricks.de/CND um detailliertere Hinweise 
--- zu den Fehlermeldungen/Warnungen zu bekommen und wie die Fehler selbst beseitigt werden können.

--- Wenn eigene Lösungsversuche erfolglos waren dann den Inhalt der Datei collectNWData.txt im Netz ablegen
--- (Links siehe http://www.linux-tips-and-tricks.de/CND_UPL) 
--- und dann der nopaste Link im bevorzugten Linux Forum posten.

==================================================================================================================
===== cat /etc/*[-_]release || cat /etc/*[-_]version =============================================================
/etc/os-release
/etc/SuSE-release
NAME=openSUSE
VERSION="12.3 (Dartmouth)"
VERSION_ID="12.3"
PRETTY_NAME="openSUSE 12.3 (Dartmouth) (x86_64)"
ID=opensuse
ANSI_COLOR="0;32"
CPE_NAME="cpe:/o:opensuse:opensuse:12.3"
openSUSE 12.3 (x86_64)
VERSION = 12.3
CODENAME = Dartmouth
===== uname -a ===================================================================================================
Linux RoemersServer-II 3.7.10-1.1-xen #1 SMP Thu Feb 28 15:06:29 UTC 2013 (82d3f21) x86_64 x86_64 x86_64 GNU/Linux
===== cat /etc/sysconfig/network/ifcfg-[earwd]* | grep -v "^#|^$" | grep -v "=''" ================================
--- /etc/sysconfig/network/ifcfg-eth0
BOOTPROTO='static'
IPADDR='0.0.0.0/32'
NAME='RTL8111/8168B PCI Express Gigabit Ethernet controller'
STARTMODE='auto'
USERCONTROL='no'
===== ping tests =================================================================================================
Ping of 8.8.8.8 OK
Ping of www.google.com OK
===== cat /etc/resolv | grep -i "nameserver" =====================================================================
nameserver 192.168.2.95
===== cat /etc/hosts =============================================================================================
127.0.0.1	localhost
192.168.2.33	RoemersServer-II
===== (route -n && route -A inet6 -n) | egrep "(en|wl|eth|ath|ra|wlan|dsl|ppp)" ==================================
Kernel IP Routentabelle
Ziel            Router          Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.2.95    0.0.0.0         UG    0      0        0 eth0
192.168.2.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
Kernel IPv6 Routentabelle
Ziel                                        Nächster Hop                                 Flags Metric Ref    Benutzer Iface
===== ifconfig (filtered for en|wl|eth|wlan|ra|ath|dsl|ppp) ======================================================
eth0      Link encap:Ethernet  Hardware Adresse ##:##:##:##:##:#1  
          inet Adresse:192.168.2.33  Bcast:192.168.2.255  Maske:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:79456 errors:0 dropped:0 overruns:0 frame:0
          TX packets:52735 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 Sendewarteschlangenlänge:1000 
          RX bytes:31938325 (30.4 Mb)  TX bytes:5750644 (5.4 Mb)
===== lspci ======================================================================================================
05:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168 PCI Express Gigabit Ethernet controller [10ec:8168] (rev 06)
	Subsystem: Giga-byte Technology Motherboard [1458:e000]
	Kernel driver in use: r8169
===== lsusb | grep -v "root hub" =================================================================================
Bus 001 Device 002: ID 2109:3431  
Bus 001 Device 006: ID 05e3:0608 Genesys Logic, Inc. USB-2.0 4-Port HUB
Bus 001 Device 003: ID 05e3:0608 Genesys Logic, Inc. USB-2.0 4-Port HUB
Bus 001 Device 007: ID 03f0:1017 Hewlett-Packard LaserJet 1300
Bus 001 Device 008: ID 0557:2221 ATEN International Co., Ltd Winbond Hermon
Bus 001 Device 004: ID 05e3:0608 Genesys Logic, Inc. USB-2.0 4-Port HUB
Bus 001 Device 005: ID 10d5:000d Uni Class Technology Co., Ltd 
===== hwinfo (filtered) ==========================================================================================
37: PCI 500.0: 0200 Ethernet controller
  Model: "Realtek RTL8111/8168B PCI Express Gigabit Ethernet controller"
  Vendor: pci 0x10ec "Realtek Semiconductor Co., Ltd."
  Device: pci 0x8168 "RTL8111/8168B PCI Express Gigabit Ethernet controller"
  SubVendor: pci 0x1458 "Giga-byte Technology"
  SubDevice: pci 0xe000 "GA-EP45-DS5 Motherboard"
  Driver: "r8169"
  Driver Modules: "r8169"
  Device File: eth0
  Link detected: yes
    Driver Status: r8169 is active
    Driver Activation Cmd: "modprobe r8169"
===== lsmod (filtered) ===========================================================================================
| 8250_core       | ablk_helper     | aesni_intel     | aes_x86_64      | blkback_pagemap  |
| blkbk           | blktap2         | bnep            | domctl          | drm              |
| drm_kms_helper  | ebtable_nat     | ebtables        | ehci_hcd        | evtchn           |
| fam15h_power    | gf128mul        | ghash_clmulni_intel| gntdev          | hfs              |
| hfsplus         | hid             | hid_generic     | hwmon           | i2c_algo_bit     |
| i2c_core        | i2c_piix4       | ip_tables       | jfs             | k10temp          |
| llc             | lp              | lrw             | minix           | msdos            |
| mxm_wmi         | nbd             | netbk           | ohci_hcd        | pciback          |
| ppdev           | qnx4            | r8169           | rfkill          | scsi_dh          |
| scsi_dh_alua    | scsi_dh_emc     | scsi_dh_hp_sw   | scsi_dh_rdac    | serial_core      |
| serio_raw       | sg              | sp5100_tco      | sr_mod          | stp              |
| ttm             | tun             | ufs             | usbbk           | usb_common       |
| usblp           | wmi             | xenblk          | xenbus_be       | xennet           |
| xen_scsibk      | xfs             | xhci_hcd        | xts             | zlib_deflate     |
===== egrep 'en|wl|eth|ath|wlan|ra|ppp' /etc/udev/rules.d/*net_persistent* /etc/udev/rules.d/*persistent-net* ====
==================================================================================================================
*** NWElizaStates V0.7.5.1
PNIN:1 CFR:1 IF:eth0 IM:2 DI:1 FALON:1 NIC:0 cNiC:1:0 NI:0 cNI:0 PNG:0 DNS:0 MTU:0 NISS:0 IP6:0 KM:0 1 WLW:0 RTDT:SuSE GUI:0 UID:0


und Hier mit den normalen Kernel

Code:
collectNWData.sh V0.7.5.1

--- Welcher Netzwerkverbindungtyp soll getestet werden?
--- (2) Kabelgebundene Verbindung

--- Welche Netzwerktopologie liegt vor?
--- (2) DSL HW router <---> LinuxClient

--- Auf welchem Rechner wird das Script ausgeführt?
--- (1) LinuxClient

--- NWCollect sammelt Netzwerkkonfigurationsinformationen in Datei ...

--- NWEliza untersucht das System nach häufigen Netzwerkkonfigurationsfehlern ...
!!! CND0180I: Das System kann die externe IP 8.8.8.8 nicht pingen
!!! CND0150E: Es kann ein Problem mit der default gateway definition 192.168.2.95 am Interface eth0 vorliegen
!!! CND0310W: Klassische Netzwerkkonfiguration mit ifup wurde entdeckt. Die Konfiguration mit networkmanager ist einfacher

--- Gehe zu http://www.linux-tips-and-tricks.de/CND um detailliertere Hinweise 
--- zu den Fehlermeldungen/Warnungen zu bekommen und wie die Fehler selbst beseitigt werden können.

--- Wenn eigene Lösungsversuche erfolglos waren dann den Inhalt der Datei collectNWData.txt im Netz ablegen
--- (Links siehe http://www.linux-tips-and-tricks.de/CND_UPL) 
--- und dann der nopaste Link im bevorzugten Linux Forum posten.

==================================================================================================================
===== cat /etc/*[-_]release || cat /etc/*[-_]version =============================================================
/etc/os-release
/etc/SuSE-release
NAME=openSUSE
VERSION="12.3 (Dartmouth)"
VERSION_ID="12.3"
PRETTY_NAME="openSUSE 12.3 (Dartmouth) (x86_64)"
ID=opensuse
ANSI_COLOR="0;32"
CPE_NAME="cpe:/o:opensuse:opensuse:12.3"
openSUSE 12.3 (x86_64)
VERSION = 12.3
CODENAME = Dartmouth
===== uname -a ===================================================================================================
Linux RoemersServer-II 3.7.10-1.1-desktop #1 SMP PREEMPT Thu Feb 28 15:06:29 UTC 2013 (82d3f21) x86_64 x86_64 x86_64 GNU/Linux
===== cat /etc/sysconfig/network/ifcfg-[earwd]* | grep -v "^#|^$" | grep -v "=''" ================================
--- /etc/sysconfig/network/ifcfg-eth0
BOOTPROTO='static'
IPADDR='0.0.0.0/32'
NAME='RTL8111/8168B PCI Express Gigabit Ethernet controller'
STARTMODE='auto'
USERCONTROL='no'
===== ping tests =================================================================================================
Ping of 8.8.8.8 failed
ping: unknown host www.google.com
Ping of www.google.com failed
===== cat /etc/resolv | grep -i "nameserver" =====================================================================
nameserver 192.168.2.95
===== cat /etc/hosts =============================================================================================
127.0.0.1	localhost
192.168.2.33	RoemersServer-II
===== (route -n && route -A inet6 -n) | egrep "(en|wl|eth|ath|ra|wlan|dsl|ppp)" ==================================
Kernel IP Routentabelle
Ziel            Router          Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.2.95    0.0.0.0         UG    0      0        0 eth0
192.168.2.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
Kernel IPv6 Routentabelle
Ziel                                        Nächster Hop                                 Flags Metric Ref    Benutzer Iface
===== ifconfig (filtered for en|wl|eth|wlan|ra|ath|dsl|ppp) ======================================================
eth0      Link encap:Ethernet  Hardware Adresse ##:##:##:##:##:#1  
          inet Adresse:192.168.2.33  Bcast:192.168.2.255  Maske:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:67 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:47 overruns:0 carrier:0
          collisions:0 Sendewarteschlangenlänge:1000 
          RX bytes:10810 (10.5 Kb)  TX bytes:0 (0.0 b)
===== lspci ======================================================================================================
05:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168 PCI Express Gigabit Ethernet controller [10ec:8168] (rev 06)
	Subsystem: Giga-byte Technology Motherboard [1458:e000]
	Kernel driver in use: r8169
===== lsusb | grep -v "root hub" =================================================================================
Bus 008 Device 002: ID 2109:3431  
Bus 008 Device 003: ID 05e3:0608 Genesys Logic, Inc. USB-2.0 4-Port HUB
Bus 008 Device 004: ID 05e3:0608 Genesys Logic, Inc. USB-2.0 4-Port HUB
Bus 008 Device 005: ID 10d5:000d Uni Class Technology Co., Ltd 
Bus 008 Device 007: ID 03f0:1017 Hewlett-Packard LaserJet 1300
Bus 008 Device 008: ID 0557:2221 ATEN International Co., Ltd Winbond Hermon
Bus 008 Device 006: ID 05e3:0608 Genesys Logic, Inc. USB-2.0 4-Port HUB
===== hwinfo (filtered) ==========================================================================================
37: PCI 500.0: 0200 Ethernet controller
  Model: "Realtek RTL8111/8168B PCI Express Gigabit Ethernet controller"
  Vendor: pci 0x10ec "Realtek Semiconductor Co., Ltd."
  Device: pci 0x8168 "RTL8111/8168B PCI Express Gigabit Ethernet controller"
  SubVendor: pci 0x1458 "Giga-byte Technology"
  SubDevice: pci 0xe000 "GA-EP45-DS5 Motherboard"
  Driver: "r8169"
  Driver Modules: "r8169"
  Device File: eth0
  Link detected: yes
    Driver Status: r8169 is active
    Driver Activation Cmd: "modprobe r8169"
===== lsmod (filtered) ===========================================================================================
| ablk_helper     | aesni_intel     | aes_x86_64      | bnep            | drm              |
| drm_kms_helper  | ebtable_nat     | ebtables        | edac_core       | edac_mce_amd     |
| fam15h_power    | gf128mul        | ghash_clmulni_intel| i2c_algo_bit    | i2c_piix4        |
| ip_tables       | k10temp         | kvm             | kvm_amd         | lrw              |
| microcode       | mperf           | mxm_wmi         | r8169           | rfkill           |
| scsi_dh         | scsi_dh_alua    | scsi_dh_emc     | scsi_dh_hp_sw   | scsi_dh_rdac     |
| serio_raw       | sg              | sp5100_tco      | sr_mod          | ttm              |
| usblp           | wmi             | xhci_hcd        | xts             |
===== egrep 'en|wl|eth|ath|wlan|ra|ppp' /etc/udev/rules.d/*net_persistent* /etc/udev/rules.d/*persistent-net* ====
==================================================================================================================
*** NWElizaStates V0.7.5.1
PNIN:1 CFR:1 IF:eth0 IM:2 DI:1 FALON:1 NIC:0 cNiC:1:0 NI:0 cNI:0 PNG:1 DR:1 NISS:0 IP6:0 KM:0 1 WLW:0 RTDT:SuSE GUI:0 UID:0
 

susejunky

Moderator
Teammitglied
Hallo Roemer,

ich habe mir die Beiträge zu Deinem Problem "Kein Netz auch wenn der Nertwermanager sagt alles OK" durchgelesen und zu der von Dir geschilderte Fehlersituation folgende Fragen:

31. Mär 2015, 16:18
Roemer schrieb:
... Nach dem 2 Versuch habe ich es geschaft die Klassische Netzwerkkonfiguration mit ifup zu löschen.
Die Ergebnisse des Scripts "collectNWData.sh" belegen, dass anschließend auf Deinem System keine "klassische" Netzwerkkonfiguration (keine Dateien "/etc/sysconfig/network/ifcfg-*") mehr vorhanden war.
Hast Du dann eine Konfiguration für den NetworkManager durchgeführt und wenn ja, hast Du dazu ein Werkzeug (z.B. nmcli, plasma-nm, ...) genutzt oder hast Du die erforderlichen Daten manuell erzeugt (z.B. unter "/etc/NetworkManager/system-connections" eine Verbindungskonfigurationsdatei manuell erstellt)?

7. Apr 2015, 13:56
Roemer schrieb:
... In Yast stand es bereits auf Netzwerkmanager
Ich habe ihn nicht extra abgeschaltet und wieder eingeschaltet um die zweite Kon
figuration nicht wieder zu bekommen.
Ich habe die Neitzwerkeinstellungen gelöscht.
Was hast Du konkret getan, um die Einstellungen zu löschen (z.B. alle Dateien unter "/etc/NetworkManager/system-connections" gelöscht)?

7. Apr 2015, 13:56
Roemer schrieb:
... Netzwerkeinstellungen wieder eingetragen.
Wo hast Du was konkret eingetragen? Welche Dateien hast Du dabei ggf. manuell geändert oder erzeugt? Welche Werkzeug (z.B. nmcli, plasma-nm, ...) hast Du ggf. eingesetzt?

Beide von Dir am 14.04.2015, 08:45 hier gezeigten Ergebnisse des Scripts "collectNWData.sh" legen nahe, dass Dein System zu diesem Zeitpunkt wieder eine "klassische" Netzwerkkonfiguration verwendet (zumindest existieren wieder Dateien "/etc/sysconfig/network/ifcfg-*" mit Inhalt). Ist das so von Dir gewollt?

Mein Verständnis war, dass Du
  • NetworkManager nutzen willst,
  • die IP-Adresse auf 192.168.2.33 manuell (d.h. kein DHCP) festlegen willst,
  • den Rechner per Kabel an Deinen Router angeschlossen hast,
  • Dein Router die IP-Adresse 192.168.2.95 hat
  • in Deinem Netz kein DHCP-Server aktiv ist
Ist das so korrekt oder habe ich etwas falsch verstanden?

Um Dir weiterhelfen zu können, wäre, neben den Antworten zu obigen Fragen, auch noch hilfreich, wenn Du
  • den aktuellen Inhalt der Datei "/etc/NetworkManager/NetworkManager.conf"
  • die Liste der Dateien unter "/etc/NetworkManager/system-connections" (und ggf. den Inhalt der Dateien)
  • den aktuellen Inhalt der Datei "/etc/sysconfig/network/config"
  • den aktuellen Inhalt der Datei "/etc/sysconfig/network/dhcp"
  • den aktuellen Inhalt der Datei "/etc/sysconfig/network/routes"
hier zeigen könntest.

Hier ein paar Informationen zum Thema "NetworkManager"; vielleicht helfen sie Dir bei der weiteren Fehleranalyse:

Viele Grüße

susejunky
 
Mir fällt nichts auf, warum es mit dem Kernel 3.7.10-1.1-xen funktioniert und mit dem Kernel 3.7.10-1.1-desktop nicht (aber was sagt das schon?). Da openSUSE 12.3 und somit auch die genannten Kernel seit 29. Jänner 2015 nicht mehr unterstützt werden, halte ich es für zweckmäßig, auf eine aktuelle openSUSE-Version umzusteigen und allfällige Probleme dann dort zu klären.
 
Hallo susejunky

susejunky schrieb:
Hallo Roemer,

ich habe mir die Beiträge zu Deinem Problem "Kein Netz auch wenn der Nertwermanager sagt alles OK" durchgelesen und zu der von Dir geschilderte Fehlersituation folgende Fragen:

31. Mär 2015, 16:18
Roemer schrieb:
... Nach dem 2 Versuch habe ich es geschaft die Klassische Netzwerkkonfiguration mit ifup zu löschen.
Die Ergebnisse des Scripts "collectNWData.sh" belegen, dass anschließend auf Deinem System keine "klassische" Netzwerkkonfiguration (keine Dateien "/etc/sysconfig/network/ifcfg-*") mehr vorhanden war.
Hast Du dann eine Konfiguration für den NetworkManager durchgeführt und wenn ja, hast Du dazu ein Werkzeug (z.B. nmcli, plasma-nm, ...) genutzt oder hast Du die erforderlichen Daten manuell erzeugt (z.B. unter "/etc/NetworkManager/system-connections" eine Verbindungskonfigurationsdatei manuell erstellt)?
Ich bin kein Konsolen Type sondern eher ein Windowsoberflächen Anhänger. Damit ist nicht Microsoft gemeint! Das kommt daher das ich Legastheniker bin und ich die befehle zu oft schreiben muss weil jedes mal etwas anderes raus kommt. Aus dem Grund Kopiere ich mir die Variablennamen beim Programmieren immer und tippe sie nicht jedes mal neu ein. Dann hätte ich eine Menge Variablen die eigentlich eine Variable ist und das Programm etwas zögerlich tut was es soll. :D
Das einige was ich im Verzeichnis /etc mit dem vi verändert habe war der Nameserver der mit der 33 und nicht die 95 hinten stand und die Befehlszeile um die Klassische Netzwerkkonfiguration zu löschen.
Den Rest habe ich über Yast, Webmin und Netzwerkmanager gemacht.
susejunky schrieb:
7. Apr 2015, 13:56
Roemer schrieb:
... In Yast stand es bereits auf Netzwerkmanager
Ich habe ihn nicht extra abgeschaltet und wieder eingeschaltet um die zweite Konfiguration nicht wieder zu bekommen.
Ich habe die Netzwerkeinstellungen gelöscht.
Was hast Du konkret getan, um die Einstellungen zu löschen (z.B. alle Dateien unter "/etc/NetworkManager/system-connections" gelöscht)?
In Yast die Netzwerkarten gelöscht um die Klassische Konfiguration zu löschen und dann im Netzwerkmanager (Windowsoberfläche in der Task leiste) Verbindungen Verwalten Kabelgebunden. Den existierenden Eintrag gelöscht.

Da hätte ich noch eine Frage:
Der Wunsch den Netzwerkmanager zu nutzen kommt aus der Ausgabe des Skriptes um Netzwerkprobleme zu lösen.
Code:
!!! CND0310W: Klassische Netzwerkkonfiguration mit ifup wurde entdeckt. Die Konfiguration mit Networkmanager ist einfacher
Da ich aber Webmin (Windowsoberfläche) Nuten will könnte ich mir vorstellen das es damit Probleme gibt.
Ist es für mich sinnvoller die Traditionelle Variante zu nutzen? Hätte ich damit dann weniger Probleme?
susejunky schrieb:
7. Apr 2015, 13:56
Roemer schrieb:
... Netzwerkeinstellungen wieder eingetragen.
Wo hast Du was konkret eingetragen? Welche Dateien hast Du dabei ggf. manuell geändert oder erzeugt? Welche Werkzeug (z.B. nmcli, plasma-nm, ...) hast Du ggf. eingesetzt?
Wie oben beschrieben keine weiteren Werkzeuge und nur die Nameserveradresse mit vi und die kopierte komandozeile um die traditionellen Einträge schnell zu löschen.
susejunky schrieb:
Beide von Dir am 14.04.2015, 08:45 hier gezeigten Ergebnisse des Scripts "collectNWData.sh" legen nahe, dass Dein System zu diesem Zeitpunkt wieder eine "klassische" Netzwerkkonfiguration verwendet (zumindest existieren wieder Dateien "/etc/sysconfig/network/ifcfg-*" mit Inhalt). Ist das so von Dir gewollt?
Das war zu dem Zeitpunkt von mir nicht gewollt, kann sie nach eurem Ratschlag ob ich den Netzwerkmanager nehmen soll oder die "klassische" Netzwerkkonfiguration ändern.
Das sie wieder aufgetaucht ist kann ich mir nur so vorstellen das ich parallel versucht habe eine Virtuelle Maschine (Windows 7) aufzusetzen. Das Tool dazu eine Netzwerkbride (br0) angelegt hat. Dies allerdings mit der klassischen Methode wie ich annehme.
Ich weiss es ist nicht gut an mereren Baustellen zu Arbeiten die sich gegenseitig beeinflussen können. Das lasse ich jetzt auch.
Es scheint mir das der Netzwerkmanager eine extra locke ist die nur Probleme bereitet.
susejunky schrieb:
Mein Verständnis war, dass Du
  • NetworkManager nutzen willst,

  • Die Frage wirst Du mir so wie ich denke Beantworten was am sinnvollsten ist. Ich hänge nicht am Netzwerkmanager, habe ihn nur wegen der oben gezeigten Empfehlung genutzt.
    susejunky schrieb:
    [*]die IP-Adresse auf 192.168.2.33 manuell (d.h. kein DHCP) festlegen willst,
    Ja , da sie auserhalb des vom DHCP verwalteten Adressbereich (100 - 200 im letzten Oktett) liegt.
    susejunky schrieb:
    [*]den Rechner per Kabel an Deinen Router angeschlossen hast,
    Ja
    susejunky schrieb:
    [*]Dein Router die IP-Adresse 192.168.2.95 hat
    Ja
    susejunky schrieb:
    [*]in Deinem Netz kein DHCP-Server aktiv ist
Nein Bei der Fritzbox ist ein DHCP Server eingeschaltet aber die IP Adresse des Rechners liegt ausserhalb des Adressbereiches des DHCP Servers.
susejunky schrieb:
Ist das so korrekt oder habe ich etwas falsch verstanden?

Um Dir weiterhelfen zu können, wäre, neben den Antworten zu obigen Fragen, auch noch hilfreich, wenn Du
  • den aktuellen Inhalt der Datei "/etc/NetworkManager/NetworkManager.conf"

  • Code:
    [main]
    plugins=ifcfg-suse,keyfile
    no-auto-default=C4:6E:1F:04:A8:B6,0E:E0:9E:0A:9C:6F,88:00:53:11:CD:7B,
    susejunky schrieb:
    [*]die Liste der Dateien unter "/etc/NetworkManager/system-connections" (und ggf. den Inhalt der Dateien)
    Code:
    roemer@RoemersServer-II:/etc/NetworkManager/system-connections> ls -all
    insgesamt 12
    drwxr-xr-x 2 root root 4096 15. Apr 15:01 .
    drwxr-xr-x 5 root root 4096 31. Mär 15:20 ..
    -rw------- 1 root root  266 15. Apr 15:01 LAN
    roemer@RoemersServer-II:/etc/NetworkManager/system-connections>
    Der Inhalt von LAN
    Code:
    RoemersServer-II:/etc/NetworkManager/system-connections # more LAN
    [802-3-ethernet]
    port=mii
    
    [connection]
    id=LAN
    uuid=cacc3250-78fd-405e-b9be-611c57fcd6d4
    type=802-3-ethernet
    timestamp=1429102781
    zone=
    
    [ipv6]
    method=ignore
    ip6-privacy=0
    
    [ipv4]
    method=auto
    dns=192.168.2.95;
    addresses1=192.168.2.33;24;192.168.2.95;
    may-fail=false
    RoemersServer-II:/etc/NetworkManager/system-connections #
    susejunky schrieb:
    [*]den aktuellen Inhalt der Datei "/etc/sysconfig/network/config"
    Code:
    ## Path:	Network/General
    ## Description:	Set some general network configuration
    ## Type:	string("","-","+")
    ## Default:	"+"
    ## ServiceRestart: network
    #
    # DEFAULT_BROADCAST is used when no individual BROADCAST is set. It can get one
    # of the following values:
    # ""  : don't set a broadcast address
    # "-" : use IPADDR with all host bits deleted
    # "+" : use IPADDR with all host bits set
    DEFAULT_BROADCAST="+"
    
    ## Type:	yesno
    ## Default:	yes
    # sometimes we want some script to be executed after an interface has been
    # brought up, or before an interface is taken down. 
    # default dir is /etc/sysconfig/network/if-up.d for POST_UP and
    # /etc/sysconfig/network/if-down.d for PRE_DOWN
    GLOBAL_POST_UP_EXEC="yes"
    GLOBAL_PRE_DOWN_EXEC="yes"
    
    ## Type:        yesno
    ## Default:     no
    # If ifup should check if an ip address is already in use, set this to yes.
    # Make sure that packet sockets (CONFIG_PACKET) are supported in the kernel,
    # since this feature uses arping, which depends on that.
    # Also be aware that this takes one second per interface; consider that when
    # setting up a lot of interfaces. 
    CHECK_DUPLICATE_IP="no"
    
    ## Type:        yesno
    ## Default:     no
    # If ifup should send a gratuitous ARP to inform the receivers about its
    # static IP addresses and perhaps also a link-layer (MAC) address change.
    # Make sure that packet sockets (CONFIG_PACKET) are supported in the kernel,
    # since this feature uses arping, which depends on that.
    SEND_GRATUITOUS_ARP="no"
    
    ## Type:        yesno
    ## Default:     no
    # Switch on/off debug messages for all network configuration stuff. If set to no
    # most scripts can enable it locally with "-o debug".
    DEBUG="no"
    
    ## Type:        yesno
    ## Default:     yes
    # All error and info messages from network and hardware configuration scripts go
    # to stderr. Most tools that call sysconfig scripts (udev, rcnetwork, scpm,
    # YaST) catch these messages and can log them. So some messages appear twice in
    # syslog. If you don't like that, then set USE_SYSLOG=no.
    USE_SYSLOG="yes"
    
    # Handling of network connections
    # ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    # These features are designed for the convenience of the experienced
    # user. If you encounter problems you don't understand then switch
    # them off. That is the default.
    # Please do not complain if you get troubles. But if you want help to
    # make them smarter write to <http://www.suse.de/feedback>.
    
    ## Type:	yesno
    ## Default:	no
    #
    # If you are interested in the connections and nfs mounts that use a
    # network interface, you can set CONNECTION_SHOW_WHEN_IFSTATUS="yes".
    # Then you will see them with 'ifstatus <interface>' (or 'ifstatus
    # <config>')
    # This one _should_ never harm ;)
    #
    CONNECTION_SHOW_WHEN_IFSTATUS="no"
    
    ## Type:	yesno
    ## Default:	no
    #
    # If an interface should be set down only if there are no active
    # connections, then use CONNECTION_CHECK_BEFORE_IFDOWN="yes"
    #
    CONNECTION_CHECK_BEFORE_IFDOWN="no"
    
    ## Type:	yesno
    ## Default:	no
    #
    # If these connetions (without the nfs mounts) should be closed when
    # shutting down an interface, set CONNECTION_CLOSE_BEFORE_IFDOWN="yes".
    # WARNING: Be aware that this may terminate applications which need
    # one of these connections!
    #
    CONNECTION_CLOSE_BEFORE_IFDOWN="no"
    
    ## Type:	yesno
    ## Default:	no
    #
    # If you are a mobile laptop user and like even nfs mounts to be
    # closed when you leave your current workplace, then set
    # CONNECTION_UMOUNT_NFS_BEFORE_IFDOWN="yes". This does only work
    # if CONNECTION_CLOSE_BEFORE_IFDOWN="yes", too.
    # WARNING: Be aware that this may terminate applications which use
    # these nfs mounts as working directory. Be very carefull if your home
    # is mounted via nfs!!!
    # WARNING: This may even lead to hanging ifdown processes if there are
    # processes that could not be terminated. If you are using
    # hotpluggable devices (pcmcia, usb, firewire), first shut them down
    # before unplugging!
    #
    CONNECTION_UMOUNT_NFS_BEFORE_IFDOWN="no"
    
    ## Type:	yesno
    ## Default:	no
    #
    # If terminating processes that use a connection or nfs mount is not
    # enough, then they can be killed after an unsuccesfull termination.
    # If you want that set CONNECTION_SEND_KILL_SIGNAL="yes"
    #
    CONNECTION_SEND_KILL_SIGNAL="no"
    
    ## Type:        string
    ## Default:     ""
    #
    # Here you may specify which interfaces have to be up and configured properly
    # after 'rcnetwork start'. rcconfig will return 'failed' if any of these
    # interfaces is not up. You may use interface names as well but better use
    # hardware descriptions of the devices (eth-id-<macaddress> or eth-bus-...  See
    # man ifup for 'hardware description'). The network start script will wait for
    # these interfaces, but not longer as set in WAIT_FOR_INTERFACES.
    # You need not to add dialup or tunnel interfaces here, only physical devices.
    # The interface 'lo' is always considered to be mandatory and can be omitted.
    #
    # If this variable is empty, rcnetwork tries to derive the list of mandatory
    # devices automatically from the list of existing configurations. Configurations
    # with names bus-pcmcia or bus-usb or with STARTMODE=hotplug are skipped. (try
    # '/etc/init.d/rc5.d/S*network start -o debug fake | grep MANDAT')
    MANDATORY_DEVICES=""
    
    ## Type:	integer
    ## Default:	30
    #
    # Some interfaces need some time to come up or come asynchronously via hotplug.
    # WAIT_FOR_INTERFACES is a global wait for all mandatory interfaces in
    # seconds. If empty no wait occurs.
    #
    WAIT_FOR_INTERFACES="30"
    
    ## Type:        list("",yes,no)
    ## Default:     ""
    #
    # Forces all interfaces eth* ath* wlan* and ra* to be persistent via udev
    # or disables the persistent rename flag check. Default is to check if udev
    # is running -- it may be not used, e.g. inside of LXC containers.
    #
    FORCE_PERSISTENT_NAMES=""
    
    ## Type:        integer
    ## Default:     0
    #
    # The number of seconds to wait for link to become useable / ready.
    # Default is 0, causing to not wait for a ready link (0), because link
    # detection can't be enabled in all cases (e.g. bridges without ports).
    # Please use per interface settings to enable it.
    #
    LINK_READY_WAIT="0"
    
    ## Type:        integer
    ## Default:     ""
    #
    # The number of seconds to wait for the end of IPv6 duplicate address
    # detection in ifup.
    # Default is to use WAIT_FOR_INTERFACES/2 seconds in normal ifup runs.
    # When ifup is called by /etc/init.d/network at boot time, the check
    # is done, but /etc/init.d/network waits WAIT_FOR_INTERFACES seconds
    # for all interfaces togerther. Set to 0 to disable it.
    #
    IPV6_DAD_WAIT=""
    
    ## Type:	yesno
    ## Default:	yes
    #
    # With this variable you can determine if the SuSEfirewall when enabled
    # should get started when network interfaces are started.
    FIREWALL="yes"
    
    ## Type:	yesno
    ## Default:	no
    #
    # This variable is used to disable the Zero Configuration Networking
    # (zeroconf) route (169.254.0.0) on local interfaces, which match
    # the pattern in LINKLOCAL_INTERFACES variable.
    #
    NOZEROCONF="no"
    
    ## Type:        string
    ## Default:     "eth*[0-9]|tr*[0-9]|wlan[0-9]|ath[0-9]"
    #
    # When is not disabled using the NOZEROCONF variable, automatically
    # add a IPv4 linklocal route to the matching interfaces.
    # This string is used in a bash "case" statement, so it may contain
    # '*', '[', ']'  and '|' meta-characters.
    #
    LINKLOCAL_INTERFACES="eth*[0-9]|tr*[0-9]|wlan[0-9]|ath[0-9]"
    
    ## Type:        string
    ## Default:     "-f -I"
    #
    # Set default options for ifplugd. You may also set them in an ifcfg-* file
    # individually. Have a look at 'man ifplug' for details. We let ifplugd set the
    # interface UP when starting, because there are many interfaces where link beat
    # cannot be detected otherwise. If you want the interface to stay down then add
    # the option '-a'. If you like ifplugd to beep on cable (un)plug, remove '-b'.
    #
    IFPLUGD_OPTIONS="-f -I -b"
    
    ## Type:	int
    ## Default:	0
    #
    # When using NetworkManager you may define a timeout to wait for NetworkManager
    # to connect in /etc/init.d/network(-remotefs) script.  Other network services
    # may require the system to have a valid network setup in order to succeed.
    # 
    # This variable has no effect if NetworkManager is disabled.
    #
    NM_ONLINE_TIMEOUT="0"
    
    ## Type:        string
    ## Default:     "dns-resolver dns-bind ntp-runtime nis"
    #
    # This variable defines the start order of netconfig modules installed
    # in the /etc/netconfig.d/ directory.
    #
    # To disable the execution of a module, don't remove it from the list
    # but prepend it with a minus sign, "-ntp-runtime".
    #
    NETCONFIG_MODULES_ORDER="dns-resolver dns-bind dns-dnsmasq nis ntp-runtime"
    
    ## Type:        string
    ## Default:     "auto"
    #
    # Defines the DNS merge policy as documented in netconfig(8) manual page.
    # Set to "" to disable DNS configuration.
    #
    NETCONFIG_DNS_POLICY="auto"
    
    ## Type:        string(resolver,bind,dnsmasq,)
    ## Default:     "resolver"
    #
    # Defines the name of the DNS forwarder that has to be configured.
    # Currently implemented are "bind", "dnsmasq" and "resolver", that
    # causes to write the name server IP addresses to /etc/resolv.conf
    # only (no forwarder). Empty string defaults to "resolver".
    #
    NETCONFIG_DNS_FORWARDER="resolver"
    
    ## Type:        yesno
    ## Default:     yes
    #
    # When enabled (default) in forwarder mode ("bind", "dnsmasq"),
    # netconfig writes an explicit localhost nameserver address to the
    # /etc/resolv.conf, followed by the policy resolved name server list
    # as fallback for the moments, when the local forwarder is stopped.
    #
    NETCONFIG_DNS_FORWARDER_FALLBACK="yes"
    
    ## Type:        string
    ## Default:     ""
    #
    # List of DNS domain names used for host-name lookup.
    # It is written as search list into the /etc/resolv.conf file.
    #
    NETCONFIG_DNS_STATIC_SEARCHLIST=""
    
    ## Type:        string
    ## Default:     ""
    #
    # List of DNS nameserver IP addresses to use for host-name lookup.
    # When the NETCONFIG_DNS_FORWARDER variable is set to "resolver",
    # the name servers are written directly to /etc/resolv.conf.
    # Otherwise, the nameserver are written into a forwarder specific
    # configuration file and the /etc/resolv.conf does not contain any
    # nameservers causing the glibc to use the name server on the local
    # machine (the forwarder). See also netconfig(8) manual page.
    #
    NETCONFIG_DNS_STATIC_SERVERS=""
    
    ## Type:        string
    ## Default:     "auto"
    #
    # Allows to specify a custom DNS service ranking list, that is which
    # services provide preferred (e.g. vpn services), and which services
    # fallback settings (e.g. avahi).
    # Preferred service names have to be prepended with a "+", fallback
    # service names with a "-" character. The special default value
    # "auto" enables the current build-in service ranking list -- see the
    # netconfig(8) manual page -- "none" or "" disables the ranking.
    #
    NETCONFIG_DNS_RANKING="auto"
    
    ## Type:        string
    ## Default:     "auto"
    #
    # Defines the NTP merge policy as documented in netconfig(8) manual page.
    # Set to "" to disable NTP configuration.
    #
    NETCONFIG_NTP_POLICY="auto"
    
    ## Type:        string
    ## Default:     ""
    #
    # List of NTP servers.
    #
    NETCONFIG_NTP_STATIC_SERVERS=""
    
    ## Type:        string
    ## Default:     "auto"
    #
    # Defines the NIS merge policy as documented in netconfig(8) manual page.
    # Set to "" to disable NIS configuration.
    #
    NETCONFIG_NIS_POLICY="auto"
    
    ## Type:        string(yes,no,)
    ## Default:     "yes"
    #
    # Defines whether to set the default NIS domain. When enabled and no domain
    # is provided dynamically or in static settings, /etc/defaultdomain is used.
    # Valid values are:
    #  - "no" or ""         netconfig does not set the domainname
    #  - "yes"              netconfig sets the domainname according to the
    #                       NIS policy using settings provided by the first
    #                       iterface and service that provided it.
    #  - "<interface name>" as yes, but only using settings from interface.
    #
    NETCONFIG_NIS_SETDOMAINNAME="yes"
    
    ## Type:        string
    ## Default:     ""
    #
    # Defines a default NIS domain.
    #
    # Further domain can be specified by adding a "_<number>" suffix to
    # the NETCONFIG_NIS_STATIC_DOMAIN and NETCONFIG_NIS_STATIC_SERVERS
    # variables, e.g.: NETCONFIG_NIS_STATIC_DOMAIN_1="second".
    #
    NETCONFIG_NIS_STATIC_DOMAIN=""
    
    ## Type:        string
    ## Default:     ""
    #
    # Defines a list of NIS servers for the default NIS domain or the
    # domain specified with same "_<number>" suffix.
    #
    NETCONFIG_NIS_STATIC_SERVERS=""
    
    ## Type:	string
    ## Default:	''
    #
    # Set this variable global variable to the ISO / IEC 3166 alpha2
    # country code specifying the wireless regulatory domain to set.
    # When not empty, ifup-wireless will be set in the wpa_supplicant
    # config or via 'iw reg set' command.
    #
    # Note: This option requires a wpa driver supporting it, like
    # the 'nl80211' driver used by default since openSUSE 11.3.
    # When you notice problems with your hardware, please file a
    # bug report and set e.g. WIRELESS_WPA_DRIVER='wext' (the old
    # default driver) in the ifcfg file.
    # See also "/usr/sbin/wpa_supplicant --help" for the list of
    # available wpa drivers.
    #
    WIRELESS_REGULATORY_DOMAIN=''
    susejunky schrieb:
    [*]den aktuellen Inhalt der Datei "/etc/sysconfig/network/dhcp"
    Code:
    ## Path:	Network/DHCP/DHCP client
    ## Description:	DHCP configuration tweaking
    #
    # Note: 
    # To configure one or more interfaces for DHCP configuration, you have to
    # change the BOOTPROTO variable in /etc/sysconfig/network/ifcfg-<interface>
    # to 'dhcp' (and possibly set STARTMODE='onboot'). 
    #
    # Most of these options are used only by dhcpcd, not by the ISC dhclient
    # (which uses a config file).
    #
    # Most of the options can be overridden by setting them in the ifcfg-* files,
    # too.
    #
    # Note: The ISC dhclient started by the NetworkManager is not using any
    # of these options -- NetworkManager is not using any sysconfig settings.
    #
    
    ## Type:	list(dhcpcd,dhclient,)
    ## Default:	""
    ## ServiceRestart: network
    #
    # Which DHCPv4 client should be used? 
    # Currently the following client are supported:
    # 	dhcpcd   (DHCP client daemon)
    # 	dhclient (ISC dhclient)
    # If empty, dhcpcd is tried, then dhclient 
    DHCLIENT_BIN=""
    
    ## Type:	list(dhclient6,)
    ## Default:	""
    ## ServiceRestart: network
    #
    # Which DHCPv6 client should be used? 
    # Currently the following client are supported:
    #       dhclient6  (ISC dhcp 4.x client)
    #       dhcp6c     (dhcpv6 client -- deprecated, package dropped)
    # If empty, dhclient6 is tried, then dhcp6c
    #
    DHCLIENT6_BIN=""
    
    ## Type:        string
    ## Default:     ""
    ## ServiceRestart: network
    #
    # Additional user start options to use when the 'dhcpcd' DHCPv4 client
    # is enabled in the DHCLIENT_BIN variable (default).
    #
    DHCPCD_USER_OPTIONS=""
    
    ## Type:        string
    ## Default:     ""
    ## ServiceRestart: network
    #
    # Additional user start options to use when the 'dhclient' ISC DHCPv4
    # client is enabled in the DHCLIENT_BIN variable.
    #
    DHCLIENT_USER_OPTIONS=""
    
    ## Type:        string
    ## Default:     ""
    ## ServiceRestart: network
    #
    # Additional user start options to use when the 'dhcp6c' DHCPv6 client
    # is enabled in the DHCLIENT6_BIN variable (default).
    #
    DHCP6C_USER_OPTIONS=""
    
    ## Type:	yesno
    ## Default:	no
    #
    # Start in debug mode? (yes|no)
    # (debug info will be logged to /var/log/messages for dhcpcd, or to
    # /var/log/dhclient-script for ISC dhclient)
    #
    DHCLIENT_DEBUG="no"
    
    ## Type: list("",yes,no,first)
    ## Default: ""
    #
    # Multiple DHCP clients:
    #
    # With two or more DHCP clients running, they would concurrently try to replace
    # the default route or set the hostname. There are several ways of dealing with
    # this conflict (and it is a conflict, because you can have only one default
    # route even though routes are stackable and the dhcp clients would change it
    # while every lease renew):
    #
    #  1) Allow both clients to do that stuff. This would work in many cases if
    #     only one of the interfaces is used at a time. However, it would lead to
    #     undefined behaviour such as changing default route e.g. on dhcp renew.
    #
    #  2) When both interfaces are connected to the same network, you may configure
    #     a bonding interface in active-backup mode (or another, e.g. 802.3ad, when
    #     supported and configured by the switch) and configure dhcp on the bonding
    #     instead.
    #
    #  3) When only one of the interfaces is used at time, you may set STARTMODE to
    #     ifplugd and specify the priority of the interfaces in IFPLUGD_PRIORITY.
    #     This is a common scenario for notebooks to use the wired interface when
    #     connected, wireless otherwise.
    #
    #  4) allow only one of the DHCP clients to do that stuff.
    #     This implies that there would be a "primary" interface and a "secondary".
    #     This is the assumption the default configuration is based on. But since
    #     the system often can't guess which interface is "more important", we
    #     simply choose one depending on related configuration or take the first
    #     interface that is started with DHCP to be primary ("authoritative").
    #     This can be configured by setting DHCLIENT_PRIMARY_DEVICE=yes in one of
    #     the /etc/sysconfig/network/ifcfg-* files and DHCLIENT_PRIMARY_DEVICE=no
    #     in /etc/sysconfig/network/dhcp (or in all other ifcfg files using DHCP).
    #
    # When DHCLIENT_PRIMARY_DEVICE is not explicitly configured to yes/no, the
    # "primary" interface is choosed as follows:
    #
    # - On systems with iSCSI Boot Firmare Table, the iBFT primary interface
    #   is used as the primary DHCP interface by default.
    # - On systems booting via PXE, the interface specified by the BOOTIF kernel
    #   parameter is used as primary DHCP interface. Set the global "ipappend 2"
    #   parameter in pxelinux.cfg/* files, so the BOOTIF kernel parameter is set.
    # - Otherwise, the DHCP client that is started first will be "primary" and
    #   allowed the set the default route and hostname ("first up wins" mode,
    #   the only one before openSUSE 11.4). To force this "first up wins" mode,
    #   set DHCLIENT_PRIMARY_DEVICE="first" in /etc/sysconfig/network/dhcp.
    #
    # All other running dhcp clients will only configure the interface with an
    # address and network routes, but not change the "global" default route or
    # hostname.
    # See also DHCLIENT_SET_DEFAULT_ROUTE and DHCLIENT_SET_HOSTNAME variables,
    # that allow to modify the DHCLIENT_PRIMARY_DEVICE parameter behaviour once
    # again.
    #
    # Thus, to specifically allow an interface's DHCP client to change "global"
    # configuration, set the following variable to "yes". Or you can make an
    # interface's DHCP client never change these settings if you set it to "no".
    # If you leave it empty then ifup-dhcp will decide.
    #
    DHCLIENT_PRIMARY_DEVICE=""
    
    ## Type:	yesno
    ## Default:	no
    #
    # Should the DHCP client set the hostname? (yes|no)
    # 
    # When it is likely that this would occur during a running X session, 
    # your DISPLAY variable could be screwed up and you won't be able to open
    # new windows anymore, then this should be "no". 
    #
    # If it happens during booting it won't be a problem and you can 
    # safely say "yes" here. For a roaming notebook with X kept running, "no"
    # makes more sense. 
    #
    DHCLIENT_SET_HOSTNAME="yes"
    
    ## Type:	yesno
    ## Default:	yes
    #
    # Should the DHCP client set a default route (default Gateway) (yes|no)
    #
    # When multiple copies of dhcpcd run, it would make sense that only one
    # of them does it. 
    #
    DHCLIENT_SET_DEFAULT_ROUTE="yes"
    
    ## Type:	integer
    ## Default:	""
    #
    # Lease time to request ( -l option)
    #
    # Specifies (in seconds) the lease that is suggested to the server. 
    # The default is 1 hour, use -1 to request infinite lease time.
    #
    DHCLIENT_LEASE_TIME=""
    
    ## Type:        yesno
    ## Default:     yes
    #
    # dhcpcd -E/--lastlease option
    #
    # This setting controls whether dhcpcd should try to use DHCP settings
    # provided in its last lease when the dhcp-server is not reachable and
    # the lease hasn't expired yet.
    # Set this variable to "no" to disable the fallback to the last lease.
    #
    DHCLIENT_USE_LAST_LEASE="yes"
    
    ## Type:	integer
    ## Default:	"0"
    #
    # dhcpcd -t/--timeout option
    #
    # You can set the timeout - dhcpcd will terminate after this time when
    # does not get a reply from the dhcp server. The dhcpcd default timeout
    # is 20 seconds, we set it to 0 to and wait forever to get a lease.
    #
    # Note: In the past, this setting was set to a much higher value (999999)
    # by default, because the dhcpcd < 3.2.3 didn't provided a infinite one.
    #
    DHCLIENT_TIMEOUT="0"
    
    ## Type:	string
    ## Default:	AUTO
    #
    # specify a hostname to send ( -h option)
    #
    # specifies a string used for the hostname option field when dhcpcd sends DHCP
    # messages. Some DHCP servers will update nameserver entries (dynamic DNS).
    # Also, some DHCP servers, notably those used by @Home Networks, require the
    # hostname option field containing a specific string in the DHCP messages from
    # clients.
    #
    # By default the current hostname is sent ("AUTO"), if one is defined in 
    # /etc/HOSTNAME. 
    # Use this variable to override this with another hostname, or leave empty
    # to not send a hostname.
    #
    DHCLIENT_HOSTNAME_OPTION="AUTO"
    
    ## Type:	string
    ## Default:	""
    #
    # specify a client ID ( -I option)
    #
    # Specifies a client identifier string. By default the hardware address of the
    # network interface is sent as client identifier string, if none is specified
    # here.
    #
    # Note that dhcpcd will prepend a zero to what it sends to the server. In the
    # server configuration, you need to write the following to match on it:
    #  option dhcp-client-identifier "\0foo";
    #
    DHCLIENT_CLIENT_ID=""
    
    ## Type:	string("dhcpcd dhclient")
    ## Default:	""
    #
    # specify a vendor class ID ( -i option)
    #
    # Specifies the vendor class identifier string. The default is dhcpcd-<version>.
    #
    DHCLIENT_VENDOR_CLASS_ID=""
    
    ## Type:	yesno
    ## Default:	no
    #
    # Send a DHCPRELEASE to the server (sign off the address)? (yes|no)
    # This may lead to getting a different address/hostname next time an address
    # is requested. But some servers require it.
    #
    DHCLIENT_RELEASE_BEFORE_QUIT="no"
    
    ## Type:	yesno
    ## Default:	no
    #
    # Send a DHCPv6 RELEASE to the server (sign off the address)? (yes|no)
    # This may lead to getting a different address/hostname next time an address
    # is requested. But some servers require it.
    #
    DHCLIENT6_RELEASE_BEFORE_QUIT="no"
    
    ## Type:        integer
    ## Default:     ""
    #
    # Before ifup-dhcp is going to start dhcp clients, it will set up the link
    # when needed. Then it has to wait until the link is ready. This setting
    # allows to specify the time how long to wait. Default is half of the time
    # in the DHCLIENT_WAIT_AT_BOOT variable.
    #
    DHCLIENT_WAIT_LINK=""
    
    ## Type:	integer
    ## Default:	0
    #
    # Some interfaces need time to initialize and/or do not report correct status.
    # Add the latency time in seconds so these can be handled properly. Should
    # probably set per interface rather than here.
    # This setting causes a sleep time before dhcp clients are started regardless
    # of the link status (wait time in DHCLIENT_WAIT_LINK).
    #
    DHCLIENT_SLEEP="0"
    
    ## Type:	integer
    ## Default:	15
    #
    # When the DHCP client is started at boot time, the boot process will stop
    # until the interface is successfully configured, but at most for
    # DHCLIENT_WAIT_AT_BOOT seconds. Do not set this variable higher than the
    # WAIT_FOR_INTERFACES variable -- it is adjusted to WAIT_FOR_INTERFACES/2
    # as default.
    #
    # Note: RFC 2131 specifies, that the dhcp client should wait a random time
    # between one and ten seconds to desynchronize the use of DHCP at startup.
    #
    DHCLIENT_WAIT_AT_BOOT="15"
    
    ## Type:        yesno
    ## Default:     no
    ## ServiceRestart: yast2
    #
    # This option is read by YaST during network configuration.
    #
    # If set, then the hostname is added to /etc/hosts with IP address
    # 127.0.0.2. This allows the hostname to be resolved (and thus, the
    # host to be reached), if the real network is not reachable.
    #
    # If unset, YaST will not touch /etc/hosts.
    WRITE_HOSTNAME_TO_HOSTS="no"
    ## Path:	Network/DHCP/DHCP client
    ## Description:	DHCP client configuration
    ## Type:	yesno
    ## Default:	yes
    #
    # Should the DHCP client modify /etc/samba/dhcp.conf? 
    #
    DHCLIENT_MODIFY_SMB_CONF="yes"
    susejunky schrieb:
    [*]den aktuellen Inhalt der Datei "/etc/sysconfig/network/routes"
Die Datei ist leer. Deshalb der Inhalt des Verzeichneses
Code:
RoemersServer-II:/etc/sysconfig/network # ls -all
insgesamt 100
drwxr-xr-x 6 root root  4096 15. Apr 15:02 .
drwxr-xr-x 6 root root  4096 15. Apr 15:02 ..
-rw-r--r-- 1 root root 12900 23. Mär 15:22 config
-rw-r--r-- 1 root root 10789 10. Apr 16:02 dhcp
-rw-r--r-- 1 root root   213 10. Apr 16:02 ifcfg-br0
-rw-r--r-- 1 root root   139 15. Apr 15:02 ifcfg-eth0
-rw------- 1 root root   151  4. Mär 2013  ifcfg-lo
-rw-r--r-- 1 root root 29387  4. Mär 2013  ifcfg.template
drwxr-xr-x 2 root root  4096 24. Mär 16:40 if-down.d
-rw-r--r-- 1 root root   239  4. Mär 2013  ifroute-lo
drwxr-xr-x 2 root root  4096 24. Mär 16:40 if-up.d
drwx------ 2 root root  4096 26. Jan 2013  providers
-rw-r--r-- 1 root root     0 15. Apr 15:02 routes
drwxr-xr-x 2 root root  4096 24. Mär 16:40 scripts
RoemersServer-II:/etc/sysconfig/network #
susejunky schrieb:
hier zeigen könntest.
Ich Habe den PC zurzeit in einer Umgebung bei der es ein begrenztet Datenvolumen gibt und ich deshalb die Updates nicht hier machen kann. Da würde mich meine Umgebung (killen) da sie dann nicht mehr Arbeiten kann. Ich nehme mir den Rechner nach hause mit und mache dort die Updates das das System wieder auf den Aktuellen stand ist.
Ich werde mir die Links gerne ansehen. Mann kann immer was lernen.
susejunky schrieb:
Hier ein paar Informationen zum Thema "NetworkManager"; vielleicht helfen sie Dir bei der weiteren Fehleranalyse:

Viele Grüße

susejunky

Viele Grüße
Roemer
 

susejunky

Moderator
Teammitglied
Hallo Roemer,

vielen Dank, dass Du Dir die Mühe gemacht hast, auf meine vielen Fragen so detailliert zu antworten! Das hat mir sehr geholfen Deine Fehlersituation besser zu verstehen.

Zunächst ein Hinweis in eigener Sache: Ich betreibe zur Zeit nur noch Systeme mit openSUSE 13.1 und openSUSE 13.2 immer mit KDE 4.14.6 als Benutzeroberfläche. Es besteht somit die Möglichkeit, dass ich bestimmte, openSUSE-12.3-spezifische Sachverhalte, bei mir nicht mehr nachvollziehen kann. Ich hoffe jedoch, dass sich die NetworkManager-spezifische Funktionalität nicht allzu sehr verändert hat.

Als erstes ein paar grundsätzliche Anmerkungen:
  • Du solltest (wie Dir hier auch bereits mehrfach geraten wurde) auf eine aktuellere openSUSE-Version umsteigen. Ich persönlich habe openSUSE 13.2 auf zwei recht unterschiedlichen Maschinen seit nunmehr 6 Monaten problemlos in Betrieb. Allerdings gibt es hier im Forum auch Mitglieder, die openSUSE 13.1 für die bessere Wahl halten. Losgelöst von der Versionsauswahl empfehle ich Dir auf jeden Fall eine Neu-Installation von der Installations-DVD (also kein update von 12.3 auf z.B. 13.2) durchzuführen. Der Update ist zwar grundsätzlich möglich, aber die Neuinstallation bietet eben im Fehlerfall eine eindeutigere Ausgangssituation (da keine "alten" Informationen im System vorhanden sind).
  • Um die Sache nicht unnötig kompliziert zu machen, solltest Du auch nicht mehrere "Baustellen" gleichzeitig eröffnen. Da eine funktionierende Netzwerkverbindung für Dich sehr wahrscheinlich wichtiger ist als eine Virtuelle Maschine, solltest Du nach der Neu-Installation erst das Netzwerk funktionsfähig machen und dann VM einrichten.
  • Was NetworkManager anbelangt, so empfehle ich Dir, ihn zu nutzen. Zum einen, weil ich selbst bereits seit mehreren Jahren NetworkManager einsetze, ohne Probleme damit zu haben. Zum anderen steht Dir unter openSUSE 13.2 nur noch "wicked" als Alternative zu NetworkManager zur Verfügung. Und zu "wicked" kann ich Dir nicht helfen, da ich es noch nicht genutzt habe. :D Beide, "wicked" und "NetworkManager" können jedoch mit Hilfe von Werkzeugen mit grafischer Oberfläche (die Du nach eigenere Aussage bevorzugst) konfiguriert werden.

Nun etwas spezifischere Hinweise zu Deiner Fehlersituation:

Roemer schrieb:
Nein Bei der Fritzbox ist ein DHCP Server eingeschaltet aber die IP Adresse des Rechners liegt ausserhalb des Adressbereiches des DHCP Servers.
Ich habe noch nie eine Mischung aus DHCP-Server und lokal vergebenen, festen IP-Adressen in meinem Netz genutzt. Ich kann Dir daher nicht sagen, ob das überhaupt funktioniert und wenn ja, was dabei ggf. zu beachten ist. Warum nutzt Du nicht ausschließlich den DHCP-Server Deiner FRITZ!Box? DHCP-Server bieten in der Regel die Option, feste MAC-Adresse/IP-Adresse-Zuordnungen zu definieren. Warum nutzt Du nicht diese Option?

Wenn Du "NetworkManager" nutzen willst, musst Du zunächst sicherstellen, dass in YaST2 unter "Netzwerkeinstellungen -> Globale Optionen" der "NetworkManager" ausgewählt ist. Das hast Du zwar bereits getan, aber einen erneute Überprüfung schadet nicht. Falls "NetworkManager" bereits ausgewählt ist, solltest Du einen Hinweis erhalten, dass Du Yast nur noch bedingt zur weiteren Konfiguration des Netzwerks nutzen kannst. Meiner Meinung nach ist es nicht kritisch, wenn "klassischen" Netzwerkkonfigurationsdateien (z.B. "/etc/sysconfig/network/ifcfg-*") im System vorhanden sind (zumindest hatten meine Systeme in den letzten Jahren keine Probleme damit). Wenn "NetworkManager" aktiviert ist, sollte er ausschließlich seine eigenen Konfigurationsdateien nutzen (z.B. unter "/etc/NetworkManager/system-connections"). In Deiner Konfiguration ist das die Datei "/etc/NetworkManager/system-connections/LAN" und in der steht die Zeile
Code:
addresses1=192.168.2.33;24;192.168.2.95;
Wenn ich in meinem System eine ähnlich Konfiguration vornehme, dann sieht das Ergebnis bei mir etwas anders aus
Code:
addresses1=192.168.2.33/24,192.168.2.95
Ich kann nicht sagen, ob das dadurch verursacht wird, dass wir unterschiedliche openSUSE-Versionen einsetzen oder ob Deine Datei wirklich fehlerhaft ist. Vielleicht probierst Du es einfach einmal aus (als root die Datei LAN editieren und per cut&paste die fragliche Zeile durch obige Zeile ersetzen). Bitte beachte, dass die Zugriffsrechte der Datei "/etc/NetworkManager/system-connections/LAN" immer auf "-rw- --- ---" gesetzt sein müssen.

Ansonsten wäre es, wie bereits eingangs gesagt, gut, wenn Du erst einmal auf eine aktuellere openSUSE-Version umsteigst und wir, wenn Du dann immer noch Probleme hast, uns diese genauer ansehen.

Viel Erfolg und viele Grüße

susejunky
 
susejunky schrieb:
Ich habe noch nie eine Mischung aus DHCP-Server und lokal vergebenen, festen IP-Adressen in meinem Netz genutzt. Ich kann Dir daher nicht sagen, ob das überhaupt funktioniert und wenn ja, was dabei ggf. zu beachten ist.
Das funktioniert problemlos. Du solltest natürlich darauf achten, daß die manuell vergebenen Adressen nicht mit den vom DHCP-Server vergebenen kollidieren.

susejunky schrieb:
Meiner Meinung nach ist es nicht kritisch, wenn "klassischen" Netzwerkkonfigurationsdateien (z.B. "/etc/sysconfig/network/ifcfg-*") im System vorhanden sind (zumindest hatten meine Systeme in den letzten Jahren keine Probleme damit).
Es wird aber kritisch, wenn (aus welchem Grund auch immer) beide aktiv sind. Risikominimierung schadet nie.
 
Hallo susejunky

Ich muss mich bedanken das ihr meine Probleme bearbeitet und mir helfen wollt.
Es liegt nur in meinem Interesse wenn ihr alle Informationen bekommt die euch weiterhelfen können.
Mit der Methode
Schreib mir ein schönes Programm ohne weitere Zusatzinformationen wird eine echte Herausforderung. Es kommt immer das Falsche raus.
Euch alle Information vom etc Verzeichnis zu Posten macht auch kein Sinn. Von daher war die Anforderung von dir schon sinnvoll.
Nun zu meinen Fortschritten.
PC nach hause genommen (andere IP klar) Updates durchgeführt rebootet
Keine Maus und Tastatur. Nur den Ausknopf 8 Sekunden drücken hat geholfen. Mit XEN gestartet.
Hatte Mus und Tastatur aber Fierfox hat gestreikt.
Am nächsten Tag habe ich versucht Suse 13.2 in Potsdam im Laden zu bekommen. Ohne Erfolg
Dann schnell nach Hause nach Berlin 4 Läden abgeklappert(Conrad, Mediamart, Saturn und ein weiteren PC laden) Ohne Erfol.
Hab mir dann halt online der Express zuschicken lassen um am Wochenende weiterzukommen.
Gestern Abend um 20 Uhr 30 geliefert.
Bis auf das home Verzeichnis (als partion) habe ich eine Neuinstallation durchgeführt.
mit dem Ergebnis
Mit Normalen Kernel
Code:
collectNWData.sh V0.7.5.1

--- Welcher Netzwerkverbindungtyp soll getestet werden?
--- (2) Kabelgebundene Verbindung

--- Welche Netzwerktopologie liegt vor?
--- (2) DSL HW router <---> LinuxClient

--- Auf welchem Rechner wird das Script ausgeführt?
--- (1) LinuxClient

--- NWCollect sammelt Netzwerkkonfigurationsinformationen in Datei ...

--- NWEliza untersucht das System nach häufigen Netzwerkkonfigurationsfehlern ...
!!! CND0120E: Die Netzwerkkarte enp5s0 hat keine IP Adresse
!!! CND0290E: Keine Netzwerkkonfiguration für Interface enp5s0 gefunden
!!! CND0230W: IPV6 ist eingeschaltet und kann der Grund für Netzwerkprobleme sein

--- Gehe zu http://www.linux-tips-and-tricks.de/CND um detailliertere Hinweise 
--- zu den Fehlermeldungen/Warnungen zu bekommen und wie die Fehler selbst beseitigt werden können.

--- Wenn eigene Lösungsversuche erfolglos waren dann den Inhalt der Datei collectNWData.txt im Netz ablegen
--- (Links siehe http://www.linux-tips-and-tricks.de/CND_UPL) 
--- und dann der nopaste Link im bevorzugten Linux Forum posten.

==================================================================================================================
===== cat /etc/*[-_]release || cat /etc/*[-_]version =============================================================
/etc/os-release
/etc/SuSE-release
NAME=openSUSE
VERSION="13.2 (Harlequin)"
VERSION_ID="13.2"
PRETTY_NAME="openSUSE 13.2 (Harlequin) (x86_64)"
ID=opensuse
ANSI_COLOR="0;32"
CPE_NAME="cpe:/o:opensuse:opensuse:13.2"
BUG_REPORT_URL="https://bugs.opensuse.org"
HOME_URL="https://opensuse.org/"
ID_LIKE="suse"
openSUSE 13.2 (x86_64)
VERSION = 13.2
CODENAME = Harlequin
# /etc/SuSE-release is deprecated and will be removed in the future, use /etc/os-release instead
===== uname -a ===================================================================================================
Linux RoemersServer-II 3.16.7-7-desktop #1 SMP PREEMPT Wed Dec 17 18:00:44 UTC 2014 (762f27a) x86_64 x86_64 x86_64 GNU/Linux
===== cat /etc/sysconfig/network/ifcfg-[earwd]* | grep -v "^#|^$" | grep -v "=''" ================================
No config files found
===== ping tests =================================================================================================
Ping of 8.8.8.8 failed
ping: unknown host www.google.com
Ping of www.google.com failed
===== cat /etc/resolv | grep -i "nameserver" =====================================================================
nameserver 172.30.43.95
===== cat /etc/hosts =============================================================================================
127.0.0.1	localhost
===== (route -n && route -A inet6 -n) | egrep "(en|wl|eth|ath|ra|wlan|dsl|ppp)" ==================================
Kernel IP Routentabelle
Ziel            Router          Genmask         Flags Metric Ref    Use Iface
===== ifconfig (filtered for en|wl|eth|wlan|ra|ath|dsl|ppp) ======================================================
enp5s0    Link encap:Ethernet  Hardware Adresse ##:##:##:##:##:#1  
          inet6 Adresse: fe80::feaa:14ff:fe2d:b20a/64 Gültigkeitsbereich:Verbindung
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:2 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 Sendewarteschlangenlänge:1000 
          RX bytes:650 (650.0 b)  TX bytes:432 (432.0 b)
===== lspci ======================================================================================================
05: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
===== lsusb | grep -v "root hub" =================================================================================
Bus 004 Device 004: ID 062a:0201 Creative Labs Defender Office Keyboard (K7310) S Zodiak KM-9010
Bus 004 Device 003: ID 046d:c018 Logitech, Inc. Optical Wheel Mouse
Bus 004 Device 002: ID 2109:3431  
===== hwinfo (filtered) ==========================================================================================
37: PCI 500.0: 0200 Ethernet controller
  Model: "Realtek RTL8111/8168 PCI Express Gigabit Ethernet controller"
  Vendor: pci 0x10ec "Realtek Semiconductor Co., Ltd."
  Device: pci 0x8168 "RTL8111/8168 PCI Express Gigabit Ethernet controller"
  SubVendor: pci 0x1458 "Giga-byte Technology"
  SubDevice: pci 0xe000 "Motherboard"
  Driver: "r8169"
  Driver Modules: "r8169"
  Device File: enp5s0
  Link detected: yes
    Driver Status: r8169 is active
    Driver Activation Cmd: "modprobe r8169"
===== lsmod (filtered) ===========================================================================================
| 6lowpan_iphc    | ablk_helper     | aesni_intel     | aes_x86_64      | af_packet        |
| bnep            | cfg80211        | drm             | drm_kms_helper  | edac_core        |
| edac_mce_amd    | fam15h_power    | gf128mul        | ghash_clmulni_intel| glue_helper      |
| i2c_algo_bit    | i2c_piix4       | ip_tables       | k10temp         | kvm              |
| kvm_amd         | lrw             | mii             | mxm_wmi         | ohci_pci         |
| r8169           | rfkill          | serio_raw       | sg              | shpchp           |
| sp5100_tco      | sr_mod          | tpm             | tpm_infineon    | tpm_tis          |
| ttm             | wmi             | xhci_hcd        |
===== egrep 'en|wl|eth|ath|wlan|ra|ppp' /etc/udev/rules.d/*net_persistent* /etc/udev/rules.d/*persistent-net* ====
==================================================================================================================
*** NWElizaStates V0.7.5.1
PNIN:1 CFR:1 IF:enp5s0 IM:2 DI:1 FALON:1 NIC:1 cNiC:1:1 NI:2 cNI:2 DHCP:0 NIWD:0 CM:0 IP6:1 KM:0 0 WLW:0 RTDT:SuSE GUI:0 UID:0


Mit XEN Kernel
Code:
collectNWData.sh V0.7.5.1

--- Welcher Netzwerkverbindungtyp soll getestet werden?
--- (2) Kabelgebundene Verbindung

--- Welche Netzwerktopologie liegt vor?
--- (2) DSL HW router <---> LinuxClient

--- Auf welchem Rechner wird das Script ausgeführt?
--- (1) LinuxClient

--- NWCollect sammelt Netzwerkkonfigurationsinformationen in Datei ...

--- NWEliza untersucht das System nach häufigen Netzwerkkonfigurationsfehlern ...
!!! CND0290E: Keine Netzwerkkonfiguration für Interface enp5s0 gefunden
!!! CND0230W: IPV6 ist eingeschaltet und kann der Grund für Netzwerkprobleme sein

--- Gehe zu http://www.linux-tips-and-tricks.de/CND um detailliertere Hinweise 
--- zu den Fehlermeldungen/Warnungen zu bekommen und wie die Fehler selbst beseitigt werden können.

--- Wenn eigene Lösungsversuche erfolglos waren dann den Inhalt der Datei collectNWData.txt im Netz ablegen
--- (Links siehe http://www.linux-tips-and-tricks.de/CND_UPL) 
--- und dann der nopaste Link im bevorzugten Linux Forum posten.

==================================================================================================================
===== cat /etc/*[-_]release || cat /etc/*[-_]version =============================================================
/etc/os-release
/etc/SuSE-release
NAME=openSUSE
VERSION="13.2 (Harlequin)"
VERSION_ID="13.2"
PRETTY_NAME="openSUSE 13.2 (Harlequin) (x86_64)"
ID=opensuse
ANSI_COLOR="0;32"
CPE_NAME="cpe:/o:opensuse:opensuse:13.2"
BUG_REPORT_URL="https://bugs.opensuse.org"
HOME_URL="https://opensuse.org/"
ID_LIKE="suse"
openSUSE 13.2 (x86_64)
VERSION = 13.2
CODENAME = Harlequin
# /etc/SuSE-release is deprecated and will be removed in the future, use /etc/os-release instead
===== uname -a ===================================================================================================
Linux RoemersServer-II 3.16.6-2-xen #1 SMP Mon Oct 20 13:47:22 UTC 2014 (feb42ea) x86_64 x86_64 x86_64 GNU/Linux
===== cat /etc/sysconfig/network/ifcfg-[earwd]* | grep -v "^#|^$" | grep -v "=''" ================================
No config files found
===== ping tests =================================================================================================
Ping of 8.8.8.8 OK
Ping of www.google.com OK
===== cat /etc/resolv | grep -i "nameserver" =====================================================================
nameserver 172.30.43.95
===== cat /etc/hosts =============================================================================================
127.0.0.1	localhost
===== (route -n && route -A inet6 -n) | egrep "(en|wl|eth|ath|ra|wlan|dsl|ppp)" ==================================
Kernel IP Routentabelle
Ziel            Router          Genmask         Flags Metric Ref    Use Iface
0.0.0.0         172.30.43.95    0.0.0.0         UG    1024   0        0 enp5s0
172.30.0.0      0.0.0.0         255.255.0.0     U     0      0        0 enp5s0
Kernel IPv6 Routentabelle
Ziel                                        Nächster Hop                                 Flags Metric Ref    Benutzer Iface
fe80::/64                                   ::                                      U     256    0        0 enp5s0  
ff00::/8                                    ::                                      U     256    0        0 enp5s0  
===== ifconfig (filtered for en|wl|eth|wlan|ra|ath|dsl|ppp) ======================================================
enp5s0    Link encap:Ethernet  Hardware Adresse ##:##:##:##:##:#1  
          inet Adresse:172.30.43.121  Bcast:172.30.255.255  Maske:255.255.0.0
          inet6 Adresse: fe80::feaa:14ff:fe2d:b20a/64 Gültigkeitsbereich:Verbindung
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1152211 errors:0 dropped:0 overruns:0 frame:0
          TX packets:411987 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 Sendewarteschlangenlänge:1000 
          RX bytes:1719886189 (1640.2 Mb)  TX bytes:27770176 (26.4 Mb)
===== lspci ======================================================================================================
05: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
===== lsusb | grep -v "root hub" =================================================================================
Bus 001 Device 004: ID 062a:0201 Creative Labs Defender Office Keyboard (K7310) S Zodiak KM-9010
Bus 001 Device 003: ID 046d:c018 Logitech, Inc. Optical Wheel Mouse
Bus 001 Device 002: ID 2109:3431  
===== hwinfo (filtered) ==========================================================================================
37: PCI 500.0: 0200 Ethernet controller
  Model: "Realtek RTL8111/8168 PCI Express Gigabit Ethernet controller"
  Vendor: pci 0x10ec "Realtek Semiconductor Co., Ltd."
  Device: pci 0x8168 "RTL8111/8168 PCI Express Gigabit Ethernet controller"
  SubVendor: pci 0x1458 "Giga-byte Technology"
  SubDevice: pci 0xe000 "Motherboard"
  Driver: "r8169"
  Driver Modules: "r8169"
  Device File: enp5s0
  Link detected: yes
    Driver Status: r8169 is active
    Driver Activation Cmd: "modprobe r8169"
===== lsmod (filtered) ===========================================================================================
| 6lowpan_iphc    | 8250            | ablk_helper     | aesni_intel     | aes_x86_64       |
| af_packet       | blkback_pagemap | blkbk           | blktap          | blktap2          |
| bnep            | cfg80211        | domctl          | drm             | drm_kms_helper   |
| ehci_hcd        | ehci_pci        | evtchn          | fam15h_power    | gf128mul         |
| ghash_clmulni_intel| glue_helper     | gntdev          | hid_generic     | hwmon            |
| i2c_algo_bit    | i2c_core        | i2c_piix4       | ip_tables       | k10temp          |
| lrw             | mii             | mxm_wmi         | nbd             | netbk            |
| ohci_hcd        | ohci_pci        | pciback         | r8169           | rfkill           |
| serial_core     | serio_raw       | sg              | shpchp          | sp5100_tco       |
| sr_mod          | tpm             | tpm_infineon    | tpm_tis         | ttm              |
| usbbk           | usb_common      | wmi             | xenblk          | xenbus_be        |
| xen_scsibk      | xhci_hcd        |
===== egrep 'en|wl|eth|ath|wlan|ra|ppp' /etc/udev/rules.d/*net_persistent* /etc/udev/rules.d/*persistent-net* ====
==================================================================================================================
*** NWElizaStates V0.7.5.1
PNIN:1 CFR:1 IF:enp5s0 IM:2 DI:1 FALON:1 NIC:0 cNiC:1:0 NI:0 cNI:0 PNG:0 DNS:0 MTU:0 NISS:0 IP6:1 KM:0 0 WLW:0 RTDT:SuSE GUI:0 UID:0


Ich weiß IP6 muss ich noch abschalten.
Aber ich wollte euch wieder eine Rückmeldung geben, das das Problem immer noch nich beaeitigt ist.
Ich habe Tamviewer installiert
Ein weitere Möglichkeit wäre das ich die Timevewer ID mit dem Passwort per PN zuschicke so das ihr die Maschine direkt untersuchen könnt.

Vieleicht könnt ihr mir die Frage beantworten warum es 2 Netzwerkeisstellungssysteme gibt. (klassisch und Netzwerkmanager) Das kanndoch nur zu Problemen führen.
Verschiedene Tools die auf die selben Einstellungen zugreifen wäre doch besser für die Systemstabilität.
Zweite Frage.
Webmin!
Welche Variante konfiguriere ich mit Webmin? die klassische oder den Netzwerkmanager.

Ich muss den Rechner jetzt wegen IP6 abschaltung rebooten
Ich melde mich wieder
Roemer
 

susejunky

Moderator
Teammitglied
Hallo Roemer,

schön, dass Du Dich entschlossen hast auf openSUSE 13.2 umzusteigen.

Leider muss ich Dich noch auf weitere Einschränkungen meinerseits hinweisen:

  • XEN
    (bzw. Virtualisierung allgemein) nutze ich nicht und kann Dir diesbezüglich auch keine Hilfestellungen geben
  • Webmin
    habe ich noch nie eingesetzt und kann auch nicht beurteilen, ob Webmin und die openSUSE-Konfigurationswerkzeuge (YaST2, etc.) problemlos miteinander harmonieren. Im Sinne der schon mehrfach bemühten Risikominimierung empfehle ich Dir, zunächst erst einmal nur die openSUSE-Bordmittel für die Netzwerkkonfiguration zu nutzen. Ein Vorgehen mit Webmin kann ich auf meinen Rechnern nicht nachvollziehen und Dir dazu also auch nicht weiterhelfen.
  • IPv6
    setze ich in meinem Netz nicht ein und auch keiner meiner ISPs unterstützt bislang IPv6; d.h. zu diesem Thema habe ich keine Erfahrungswerte sondern nur theoretisches Wissen.

Nun zum konstruktiven Teil meiner Antwort. Um mit den openSUSE-Bordmitteln zu einer lauffähigen Netzkonfiguration zu gelangen, solltest Du wie folgt vorgehen:

  1. "Normalen" Kernel starten
  2. Als Administrator anmelden.
  3. YaST2 -> Netzwerkeinstellungen
    auf der Registerkarte "Global Options"
    • unter "Network Setup Method" den Eintrag "NetworkManager Service" auswählen
    • unter "IPv6 Protocol settings" den Haken aus dem Kästchen vor "Enable IPv6" entfernen
  4. mit "OK" bestätigen
  5. YaST2 beenden
  6. mit Hilfe von "nm-applet" (bei GNOME) oder "plasma-nm" (bei KDE) Deine kabelgebunden Verbindung konfigurieren (die genannten Werkzeuge stehen in aller Regel in der Taskleiste des jeweiligen Desktops zur Verfügung)

Alternativ zum letzten Punkt kannst Du unter "/etc/NetworkManager/system-connections" eine Datei "LAN" mit folgendem Inhalt (Achtung! Die von mir verwendeten IP-Adressen prüfen und ggf. anpassen!)
Code:
[802-3-ethernet]
port=mii

[connection]
id=LAN
type=802-3-ethernet

[ipv6]
method=ignore

[ipv4]
method=auto
dns=192.168.2.95;
addresses1=192.168.2.33/24,192.168.2.95
may-fail=false
und den Dateirechten "-rw- --- ---" anlegen.

Und dann solltest Du ( :D eigentlich :D ) eine funktionsfähige Netzwerkkonfiguration haben.

Viele Grüße

susejunky
 
Ich verstehe nach wie vor nicht, warum es mit dem xen-Kernel funktioniert und mit dem desktop-Kernel nicht. Ich würde jetzt noch den default-Kernel installieren und schauen, ob es damit funktioniert.
 
susejunky schrieb:
Hallo Roemer,

schön, dass Du Dich entschlossen hast auf openSUSE 13.2 umzusteigen.
Der Grund warum ich so lange gezögert habe war die Vermutung von mir das es keine sehr grossen Unterschiede zwischen den beiden Versionen gibt Ich habe ja auch ein Update übers Internet zuhause versucht. Ohne Erfolg. Da blieb dann nur neue DVDs übrig.
Von der Oberfläche gibt es da schon Unterschiede. Ich kann nur vermuten das es in den Eingeweiden erhebliche Veränderungen gibt.

susejunky schrieb:
Leider muss ich Dich noch auf weitere Einschränkungen meinerseits hinweisen:

  • XEN
    (bzw. Virtualisierung allgemein) nutze ich nicht und kann Dir diesbezüglich auch keine Hilfestellungen geben

  • Ich nutze XEN zurzeit nur, weil ich mit dem Kernel ein Netzwerk habe. Die Virtuellen Maschinen mache ich dann, wie Du vorgeschlagen hast entweder über das Systemtool VirualBox oder mit VMware
    Nach einer erfolgreichen Konfiguration werde ich dann auch mit Snapper eine Systemsicherung bevor ich die nächste Baustelle angehe.
    susejunky schrieb:
    [*]Webmin
    habe ich noch nie eingesetzt und kann auch nicht beurteilen, ob Webmin und die openSUSE-Konfigurationswerkzeuge (YaST2, etc.) problemlos miteinander harmonieren. Im Sinne der schon mehrfach bemühten Risikominimierung empfehle ich Dir, zunächst erst einmal nur die openSUSE-Bordmittel für die Netzwerkkonfiguration zu nutzen. Ein Vorgehen mit Webmin kann ich auf meinen Rechnern nicht nachvollziehen und Dir dazu also auch nicht weiterhelfen.
    Mit dem Konfigurieren vom Sambaserver habe ich mit Webmin gute Erfahrungen gemacht. Was Netzwerke betrifft.
    Ich nehme an Du bist eher ein Konsolen Mensch der die graphischen Oberflächen nicht so nutzt.
    Hätte sein können das Du es gewusst haben könntest. Von daher habe ich gefragt. :D
    Vieleich hat ein anderer ja in der Beziehung mehr Erfahrung :roll: .
    susejunky schrieb:
    [*]IPv6
    setze ich in meinem Netz nicht ein und auch keiner meiner ISPs unterstützt bislang IPv6; d.h. zu diesem Thema habe ich keine Erfahrungswerte sondern nur theoretisches Wissen.
Ich habe auch nicht vor IP6 einzusetzen. Bloss suse meint ich soll es einsetzen und dementsprechend muss ich mich mit dem abschalten von IP6 auseinandersetzen
susejunky schrieb:
Nun zum konstruktiven Teil meiner Antwort. Um mit den openSUSE-Bordmitteln zu einer lauffähigen Netzkonfiguration zu gelangen, solltest Du wie folgt vorgehen:

  1. "Normalen" Kernel starten
  2. Als Administrator anmelden.
  3. YaST2 -> Netzwerkeinstellungen
    auf der Registerkarte "Global Options"
    • unter "Network Setup Method" den Eintrag "NetworkManager Service" auswählen
    • unter "IPv6 Protocol settings" den Haken aus dem Kästchen vor "Enable IPv6" entfernen
  4. mit "OK" bestätigen
  5. YaST2 beenden
  6. mit Hilfe von "nm-applet" (bei GNOME) oder "plasma-nm" (bei KDE) Deine kabelgebunden Verbindung konfigurieren (die genannten Werkzeuge stehen in aller Regel in der Taskleiste des jeweiligen Desktops zur Verfügung)
Ich weiss nicht genau ob es ein Unterschied macht ob man sich als root anmedet und Yast2 öffnet oder ob ich mich als normaler user anmelde Yast2 öffne und das root Passwort eingebe.
erst den normalen Kernel gestartet.
Bei dem Versuch habe ich mich als user angemeldet und Yast mit root Passwort geöffnet. Sonst habe ich die Schritte bis zum Punkt 5 genauso ausgeführt.
Ich nutze KDE.
bei Punkt 6 nehme ich an das der Netzwerkmanager in der Taskleiste "plasma-nm" heist. Dort habe ich ein Verbindungs-Editor geöffnet um dort die Netzwerkeinstellungen durchzuführen.
Ohne Erfolg:

susejunky schrieb:
Alternativ zum letzten Punkt kannst Du unter "/etc/NetworkManager/system-connections" eine Datei "LAN" mit folgendem Inhalt (Achtung! Die von mir verwendeten IP-Adressen prüfen und ggf. anpassen!)
Code:
[802-3-ethernet]
port=mii

[connection]
id=LAN
type=802-3-ethernet

[ipv6]
method=ignore

[ipv4]
method=auto
dns=192.168.2.95;
addresses1=192.168.2.33/24,192.168.2.95
may-fail=false
und den Dateirechten "-rw- --- ---" anlegen.

Und dann solltest Du ( :D eigentlich :D ) eine funktionsfähige Netzwerkkonfiguration haben.
Dann habe ich mir den Text der LAN Verbindung Kopiert und nach deinen Anweisungen die Datei erzeugt den Text eingefügt und die Berechtigungen geändert.
In dem Verzeichnis habe ich die Netzwerkverbindung die im Netzwerkmanager eingetragen war gefunden (also das richtige Verzeichnis.) Im Netzwerkmanager war die Verbindung aber nicht erschienen.
Ich glaube nicht das es an der Konfiguration dieser Datei liegt. Die selbe Datei wird ja mit dem normalen und den XEN Kernel genutzt. Oder täusche ich mich dabei. Das es pro Kernel eigene Netzwerkdateien gibt :???:
susejunky schrieb:
Viele Grüße

susejunky


josef-wien schrieb:
Ich verstehe nach wie vor nicht, warum es mit dem xen-Kernel funktioniert und mit dem desktop-Kernel nicht. Ich würde jetzt noch den default-Kernel installieren und schauen, ob es damit funktioniert.
Nun zu Dir josef-wien
Ich verstehe es auch nicht. Ich dachte der desktop-Kernel sei der default-Kernel.
Aber Dein Vorschlag kann ich ja mal probieren.
Beschreibe mir bitte wo ich ihn herbekomme und wie ich ihn installieren kann. Dann probiere ich es einmal aus.

Als Alternative hätte ich ein Vorschlag womit das Problem umgangen wäre ohne es gelöst zu haben.
ihr verratet mir wie ich den xen-Kernel als Standardstartkernel definieren kann so das ich den PC auch mal Remote durchstarten kann und danach Remote noch drankomme.

Bis dann
Schöne grüsse aus Potsdam
Roemer
 

susejunky

Moderator
Teammitglied
Hallo Roemer,

Roemer schrieb:
... ich weiss nicht genau ob es ein Unterschied macht ob man sich als root anmedet und Yast2 öffnet oder ob ich mich als normaler user anmelde Yast2 öffne und das root Passwort eingebe.
erst den normalen Kernel gestartet.
Bei dem Versuch habe ich mich als user angemeldet und Yast mit root Passwort geöffnet. Sonst habe ich die Schritte bis zum Punkt 5 genauso ausgeführt.
Sich als Benutzer anzumelden und dann beim Starten von "YaST2" das Administratorkennwort einzugeben ist vollständig OK.

Roemer schrieb:
... Mit dem Konfigurieren vom Sambaserver habe ich mit Webmin gute Erfahrungen gemacht. Was Netzwerke betrifft.
Ich nehme an Du bist eher ein Konsolen Mensch der die graphischen Oberflächen nicht so nutzt.
Damit kein falscher Eindruck entsteht: Ich habe keine Vorbehalte gegen Werkzeuge mit grafischen Oberflächen! Meine Bedenken sind vielmehr folgende:

Die Konfiguration eines Linux-Systems besteht letztendlich darin, dass bestimmte für den reibungslosen Betrieb eines Rechners erforderliche Werte (z.B. Name des Rechners) in bestimmten Dateien (z.B. /etc/hostname) abgelegt werden und bestimmte Applikationen (z.B. NetworkManager) diese Informationen im laufenden Betrieb aus diesen Dateien auslesen und nutzen. Das Ablegen dieser Informationen kann entweder durch Systemwerkzeuge (z.B. YaST2) oder durch Werkzeuge von Drittanbietern (z.B. Webmin) oder durch manuelles Editieren der jeweiligen Dateien erfolgen. Die Wahrscheinlichkeit, dass die Systemwerkzeuge (z.B. YaST2) die erforderlichen Informationen vollständig vom Benutzer abfragen und dann in der richtigen Datei ablegen, ist ziemlich groß (wenn auch nicht 100%). Werkzeuge von Drittanbietern können den Systemwerkzeugen gleichwertig (oder sogar überlegen) sein. Aber bevor man sie einsetzt, sollten man sich sicher sein., dass sie zu dem Betriebssystem, welches man einsetzt, uneingeschränkt kompatibel sind. Ich habe mir kurz die Web-Seite von "Webmin" angesehen. Dort wird zwar von Kompatibilität zu "SuSE Linux, SuSE OpenExchange Linux, SuSE SLES Linux" gesprochen aber openSUSE wird nicht explizit erwähnt. Auch konnte ich in der Kürze weder feststellen, ob "Webmin" mit "wicked" und/oder "NetworkManager" (den beiden in openSUSE 13.2 zur Verfügung stehenden Netzwerk-Varianten) umgehen kann, noch welche Konfigurationsdateien von "Webmin" wann verändert werden. Im schlimmsten Fall könnte bereits die Installation von "Webmin" ein Teil der openSUSE-Standard-Konfiguration verändern. Das würde eine Fehlersuche (für mich, der ich "Webmin" nicht installiert habe) sehr erschweren.

Nur weil ich mir nicht sicher bin, ob Dein Kenntnisstand über die Arbeitsweise von "Webmin" weiter reicht als der meine, habe ich Dir empfohlen auf die Nutzung von "Webmin" zu vezichten. Das manuelle Bearbeiten der Konfiguration ist natürlich auch mit Risiken verbunden. Allerdings kann man hierbei durch sorgfältige Dokumentation der eigenen Änderungen ggf. auch wieder die Ausgangslage herstellen.

Roemer schrieb:
... bei Punkt 6 nehme ich an das der Netzwerkmanager in der Taskleiste "plasma-nm" heist.
Ja.
Roemer schrieb:
Dort habe ich ein Verbindungs-Editor geöffnet um dort die Netzwerkeinstellungen durchzuführen. Ohne Erfolg
Wie hat sich der Mißerfolg dargestellt?
  • Konntest Du keine Verbindung anlegen?
    ... weil die eingegebenen Daten nicht abspeichert werden konnten
    ...
  • Lies sich die Verbindung nicht aktivieren?
    ... weil die Verbindung vom Applet in der Taskleiste nicht angezeigt wurde
    ... beim Überfahren der Verbindung mit der Maus kein "Verbinden"-Knopf eingeblendet wurde
    ... das Drücken des "Verbinden"-Knopfs keine Reaktion ausgelöst hat
    ...
  • War die Verbindung nicht funktionstüchtig?
    ... das Applet in der Taskleiste zeigt "verbunden" an, es ist aber kein Zugriff auf andere Rechner möglich
Roemer schrieb:
... In dem Verzeichnis habe ich die Netzwerkverbindung die im Netzwerkmanager eingetragen war gefunden (also das richtige Verzeichnis.)
Bitte zeige uns deren Inhalt sowie den aktuellen Inhalt der Datei "/etc/Networkmanager/NetworkManager.conf"
Roemer schrieb:
...Im Netzwerkmanager war die Verbindung aber nicht erschienen.
Welche Verbindungen werden Dir angezeigt, wenn Du
  • mit der rechten Maustaste auf das Applet in der Taskleiste drückst?
  • anschließend mit der rechten Maustaste auf den Schraubenschlüssel in der rechten oberen Ecke der Applet-Anzeige drückst?

NACHTRAG (21.04.2015 13:33 Uhr)
Wenn Du möchtest, dass Deine Netzwerkverbindung (sobald die Kabelverbindung existiert) automatisch hergestellt wird (d.h. ohne im Applet auf den "Verbinden"-Knopf drücken zu müssen), dann musst Du in der Datei "/etc/NetworkManager/system-connections/LAN" im Abschnitt "[connection]" noch den Eintrag "autoconnect=true" hinzufügen. Mit "permissions=user:XXXX:;user:root:;" kannst Du festlegen, welche Benutzer diese Verbindung nutzen dürfen. Insgesamt muss/kann die Datei "/etc/NetworkManager/system-connections/LAN" dann so aussehen:
Code:
[802-3-ethernet]
port=mii

[connection]
id=LAN
type=802-3-ethernet
permissions=user:XXXX:;user:root:;
autoconnect=true

[ipv6]
method=ignore

[ipv4]
method=auto
dns=192.168.2.95;
addresses1=192.168.2.33/24,192.168.2.95
may-fail=false
Die von mir verwendeten IP-Adressen musst Du ggf. anpassen. Ebenso musst Du das "XXXX" im Eintrag "user:XXXX:" durch einen gültigen Benutzernamen ersetzen oder den Eintrag "user:XXXX:" löschen. Dann kann nur noch der Benutzer "root" die Verbindung nutzen. Wenn Du die Zeile komplett löschst, dann dürfen alle Benutzer die Verbindung benutzen.
ENDE NACHTRAG

Roemer schrieb:
... Die selbe Datei wird ja mit dem normalen und den XEN Kernel genutzt. Oder täusche ich mich dabei. Das es pro Kernel eigene Netzwerkdateien gibt
Wie bereits gesagt, zum Thema "Virtualisierung" kann ich Dir nicht weiterhelfen.

Für die weitere Analyse könnte es noch hilfreich sein, die Versionsstände der von Dir verwendeten Programme zu kennen. Bitte gib dazu, als Benutzer, in einer Konsole die Befehle
Code:
zypper se -si network
zypper se -si plasma
ein und zeige hier das Ergebnis.

Vielen Dank und viele Grüße

susejunky
 
susejunky schrieb:
Hallo Roemer,

Die Konfiguration eines Linux-Systems besteht letztendlich darin, dass bestimmte für den reibungslosen Betrieb eines Rechners erforderliche Werte (z.B. Name des Rechners) in bestimmten Dateien (z.B. /etc/hostname) abgelegt werden und bestimmte Applikationen (z.B. NetworkManager) diese Informationen im laufenden Betrieb aus diesen Dateien auslesen und nutzen.
In der Beziehung verstehe ich nicht warum der Netzwerkmanager andere Dateien nimmt als wicked. Das Du dafür eine Erklärung.
susejunky schrieb:
Das Ablegen dieser Informationen kann entweder durch Systemwerkzeuge (z.B. YaST2) oder durch Werkzeuge von Drittanbietern (z.B. Webmin) oder durch manuelles Editieren der jeweiligen Dateien erfolgen. Die Wahrscheinlichkeit, dass die Systemwerkzeuge (z.B. YaST2) die erforderlichen Informationen vollständig vom Benutzer abfragen und dann in der richtigen Datei ablegen, ist ziemlich groß (wenn auch nicht 100%). Werkzeuge von Drittanbietern können den Systemwerkzeugen gleichwertig (oder sogar überlegen) sein. Aber bevor man sie einsetzt, sollten man sich sicher sein., dass sie zu dem Betriebssystem, welches man einsetzt, uneingeschränkt kompatibel sind. Ich habe mir kurz die Web-Seite von "Webmin" angesehen. Dort wird zwar von Kompatibilität zu "SuSE Linux, SuSE OpenExchange Linux, SuSE SLES Linux" gesprochen aber openSUSE wird nicht explizit erwähnt. Auch konnte ich in der Kürze weder feststellen, ob "Webmin" mit "wicked" und/oder "NetworkManager" (den beiden in openSUSE 13.2 zur Verfügung stehenden Netzwerk-Varianten) umgehen kann, noch welche Konfigurationsdateien von "Webmin" wann verändert werden. Im schlimmsten Fall könnte bereits die Installation von "Webmin" ein Teil der openSUSE-Standard-Konfiguration verändern. Das würde eine Fehlersuche (für mich, der ich "Webmin" nicht installiert habe) sehr erschweren.
Dein Kenntnisstand ist inzwischen besser als meiner über Webmin. Seitich mitbekommen habe das es probleme mit Webmin geben kann, habe ich Webmin nur noch zum Betrachten genutzt. ohne etwas zu verändern (Nicht speichern). Also an den Dateien nichts mehr verändert.
susejunky schrieb:
Nur weil ich mir nicht sicher bin, ob Dein Kenntnisstand über die Arbeitsweise von "Webmin" weiter reicht als der meine, habe ich Dir empfohlen auf die Nutzung von "Webmin" zu vezichten. Das manuelle Bearbeiten der Konfiguration ist natürlich auch mit Risiken verbunden. Allerdings kann man hierbei durch sorgfältige Dokumentation der eigenen Änderungen ggf. auch wieder die Ausgangslage herstellen.

Roemer schrieb:
Dort habe ich ein Verbindungs-Editor geöffnet um dort die Netzwerkeinstellungen durchzuführen. Ohne Erfolg
Wie hat sich der Mißerfolg dargestellt?
Ich habe inzwischen 2 Fehler entdeckt die ich gemacht habe.
1. Das das Netzwerk in Yast deaktiviert war. Damit konnten auch keine Netzwerkeinstellungen im Netzwerkmanager vorgenommen werden.
2. Beim Konfigurieren mit dem Verbindungseditor hat sich das Fenster mit der Passworteingabe unter dem Einstellungsfenster geschoben. Ohne rootrechte können die Netzwerkeinstellung nicht vorgenommen werden.
susejunky schrieb:
  • Konntest Du keine Verbindung anlegen?
    ... weil die eingegebenen Daten nicht abspeichert werden konnten

  • Ich glaube damit sind ein paar Probleme von mir erklärt.
    susejunky schrieb:
    ...
    [*]Lies sich die Verbindung nicht aktivieren?
    ... weil die Verbindung vom Applet in der Taskleiste nicht angezeigt wurde
    ... beim Überfahren der Verbindung mit der Maus kein "Verbinden"-Knopf eingeblendet wurde
    ... das Drücken des "Verbinden"-Knopfs keine Reaktion ausgelöst hat
    ...
    Das seltsame ist ja das laut Applet die Verbindung steht. i h kann sie trennen. Dann verschwindet sie im Applett und wieder herstellen. Dann taucht sie wie gewünscht auch wieder auf. Alles bestens.
    Aber: die Datenübertragungsraten sind eher mager bzw. nicht vorhanden. In Verbindungseditor kommt auch die Information Zuletzt verwendet "vor 0 Minuten" Aus der Sicht alles bestens. Ich habe es so eingestellt das er beim Verbinden mit dem Netzwerk er sich automatisch verbindet.
    susejunky schrieb:
    [*]War die Verbindung nicht funktionstüchtig?
    ... das Applet in der Taskleiste zeigt "verbunden" an, es ist aber kein Zugriff auf andere Rechner möglich
Laut anzeige war ist sie Funktionstüchtig , aber ohne Datenübertragung
susejunky schrieb:
Roemer schrieb:
... In dem Verzeichnis habe ich die Netzwerkverbindung die im Netzwerkmanager eingetragen war gefunden (also das richtige Verzeichnis.)
Bitte zeige uns deren Inhalt sowie den aktuellen Inhalt der Datei "/etc/Networkmanager/NetworkManager.conf"
Ich habe inzwischen weiterprobiert das Problem zu lösen. Deshalb sieht es jetzt etwas anders aus.
"/etc/Networkmanager/NetworkManager.con
Code:
[main]
plugins=ifcfg-suse,keyfile
Das Verzeichnis system-connections sieht jetzt so aus
Code:
RoemersServer-II:/etc/NetworkManager/system-connections # ll
insgesamt 8                                                                              
-rw------- 1 root root 183 20. Apr 13:16 LAN                                             
-rw------- 1 root root 233 21. Apr 18:18 LAN-10473eee-85ce-46c9-86f7-edf321cf79fd                  
RoemersServer-II:/etc/NetworkManager/system-connections #

In den beiden Dateien steht
LAN
Code:
[802-3-ethernet]
port=mii

[connection]
id=LAN
type=802-3-ethernet

[ipv6]
method=ignore

[ipv4]
method=auto
dns=192.168.2.95;
addresses1=192.168.2.33/24,192.168.2.95
may-fail=false

LAN-10473eee-85ce-46c9-86f7-edf321cf79fd
Code:
[ethernet]
mac-address=FC:AA:14:2D:B2:0A

[connection]
id=LAN
uuid=10473eee-85ce-46c9-86f7-edf321cf79fd
type=ethernet

[ipv6]
method=ignore

[ipv4]
method=manual
dns=192.168.2.95;
address1=192.168.2.33/24,192.168.2.95
may-fail=false

susejunky schrieb:
Roemer schrieb:
...Im Netzwerkmanager war die Verbindung aber nicht erschienen.
Welche Verbindungen werden Dir angezeigt, wenn Du
  • mit der rechten Maustaste auf das Applet in der Taskleiste drückst?
  • anschließend mit der rechten Maustaste auf den Schraubenschlüssel in der rechten oberen Ecke der Applet-Anzeige drückst?
In beiden fällen nur LAN
susejunky schrieb:
NACHTRAG (21.04.2015 13:33 Uhr)
Wenn Du möchtest, dass Deine Netzwerkverbindung (sobald die Kabelverbindung existiert) automatisch hergestellt wird (d.h. ohne im Applet auf den "Verbinden"-Knopf drücken zu müssen), dann musst Du in der Datei "/etc/NetworkManager/system-connections/LAN" im Abschnitt "[connection]" noch den Eintrag "autoconnect=true" hinzufügen. Mit "permissions=user:XXXX:;user:root:;" kannst Du festlegen, welche Benutzer diese Verbindung nutzen dürfen. Insgesamt muss/kann die Datei "/etc/NetworkManager/system-connections/LAN" dann so aussehen:
Code:
[802-3-ethernet]
port=mii

[connection]
id=LAN
type=802-3-ethernet
permissions=user:XXXX:;user:root:;
autoconnect=true

[ipv6]
method=ignore

[ipv4]
method=auto
dns=192.168.2.95;
addresses1=192.168.2.33/24,192.168.2.95
may-fail=false
Die von mir verwendeten IP-Adressen musst Du ggf. anpassen. Ebenso musst Du das "XXXX" im Eintrag "user:XXXX:" durch einen gültigen Benutzernamen ersetzen oder den Eintrag "user:XXXX:" löschen. Dann kann nur noch der Benutzer "root" die Verbindung nutzen. Wenn Du die Zeile komplett löschst, dann dürfen alle Benutzer die Verbindung benutzen.
ENDE NACHTRAG
Ich habe ich über den Verbindungseditor eingestellt das er sich automatisch verbindet.
susejunky schrieb:
Roemer schrieb:
... Die selbe Datei wird ja mit dem normalen und den XEN Kernel genutzt. Oder täusche ich mich dabei. Das es pro Kernel eigene Netzwerkdateien gibt
Wie bereits gesagt, zum Thema "Virtualisierung" kann ich Dir nicht weiterhelfen.

Für die weitere Analyse könnte es noch hilfreich sein, die Versionsstände der von Dir verwendeten Programme zu kennen. Bitte gib dazu, als Benutzer, in einer Konsole die Befehle
Code:
zypper se -si network
zypper se -si plasma
ein und zeige hier das Ergebnis.
Code:
roemer@RoemersServer-II:~> zypper se -si network
Daten des Repositories laden ...
Installierte Pakete lesen ...

S | Name                            | Typ    | Version        | Arch   | Repository          
--+---------------------------------+--------+----------------+--------+---------------------
i | NetworkManager                  | Paket  | 0.9.10.0-3.8.2 | x86_64 | openSUSE-13.2-Update
i | NetworkManager-openvpn          | Paket  | 0.9.10.0-2.1.4 | x86_64 | openSUSE-13.2-Oss   
i | NetworkManager-openvpn          | Paket  | 0.9.10.0-2.1.4 | x86_64 | openSUSE-13.2-0     
i | NetworkManager-pptp             | Paket  | 0.9.10.0-2.2.2 | x86_64 | openSUSE-13.2-Oss   
i | NetworkManager-pptp             | Paket  | 0.9.10.0-2.2.2 | x86_64 | openSUSE-13.2-0     
i | NetworkManager-vpnc             | Paket  | 0.9.10.0-2.1.4 | x86_64 | openSUSE-13.2-Oss   
i | NetworkManager-vpnc             | Paket  | 0.9.10.0-2.1.4 | x86_64 | openSUSE-13.2-0     
i | glib-networking                 | Paket  | 2.42.1-4.1     | x86_64 | openSUSE-13.2-Update
i | kdenetwork4-filesharing         | Paket  | 14.12.3-16.1   | x86_64 | openSUSE-13.2-Update
i | libNetworkManagerQt1            | Paket  | 0.9.8.2-3.1.3  | x86_64 | openSUSE-13.2-Oss   
i | libNetworkManagerQt1            | Paket  | 0.9.8.2-3.1.3  | x86_64 | openSUSE-13.2-0     
i | libproxy1-networkmanager        | Paket  | 0.4.11-12.1.4  | x86_64 | openSUSE-13.2-Oss   
i | libproxy1-networkmanager        | Paket  | 0.4.11-12.1.4  | x86_64 | openSUSE-13.2-0     
i | libvirt-daemon-driver-network   | Paket  | 1.2.9-20.2     | x86_64 | openSUSE-13.2-Update
i | patterns-openSUSE-network_admin | Paket  | 20141007-5.1   | x86_64 | openSUSE-13.2-Update
i | yast2-network                   | Paket  | 3.1.104-1.3    | x86_64 | openSUSE-13.2-Oss   
i | yast2-network                   | Paket  | 3.1.104-1.3    | x86_64 | openSUSE-13.2-0     
i | network_admin                   | Schema | 20141007-5.1   | x86_64 | openSUSE-13.2-Update
i | glib-networking-lang            | Paket  | 2.42.1-4.1     | noarch | openSUSE-13.2-Update
roemer@RoemersServer-II:~> zypper se -si plasma
Daten des Repositories laden ...
Installierte Pakete lesen ...

S | Name                               | Typ   | Version       | Arch   | Repository          
--+------------------------------------+-------+---------------+--------+---------------------
i | plasma-addons                      | Paket | 4.14.3-12.6   | x86_64 | openSUSE-13.2-Update
i | plasma-addons-akonadi              | Paket | 4.14.3-12.6   | x86_64 | openSUSE-13.2-Update
i | plasma-addons-lancelot             | Paket | 4.14.3-12.6   | x86_64 | openSUSE-13.2-Update
i | plasma-addons-marble               | Paket | 4.14.3-12.6   | x86_64 | openSUSE-13.2-Update
i | plasma-nm                          | Paket | 0.9.3.4-2.1.8 | x86_64 | openSUSE-13.2-Oss   
i | plasma-nm                          | Paket | 0.9.3.4-2.1.8 | x86_64 | openSUSE-13.2-0     
i | plasma-nm-openvpn                  | Paket | 0.9.3.4-2.1.8 | x86_64 | openSUSE-13.2-Oss   
i | plasma-nm-openvpn                  | Paket | 0.9.3.4-2.1.8 | x86_64 | openSUSE-13.2-0     
i | plasma-nm-pptp                     | Paket | 0.9.3.4-2.1.8 | x86_64 | openSUSE-13.2-Oss   
i | plasma-nm-pptp                     | Paket | 0.9.3.4-2.1.8 | x86_64 | openSUSE-13.2-0     
i | plasma-nm-vpnc                     | Paket | 0.9.3.4-2.1.8 | x86_64 | openSUSE-13.2-Oss   
i | plasma-nm-vpnc                     | Paket | 0.9.3.4-2.1.8 | x86_64 | openSUSE-13.2-0     
i | python-kde4-plasma                 | Paket | 4.14.3-8.2    | x86_64 | openSUSE-13.2-Update
i | kdebase4-workspace-plasma-calendar | Paket | 4.11.17-21.5  | x86_64 | openSUSE-13.2-Update
i | plasma-addons-kimpanel             | Paket | 4.14.3-12.6   | x86_64 | openSUSE-13.2-Update
roemer@RoemersServer-II:~>
susejunky schrieb:
Vielen Dank und viele Grüße

susejunky
ich hätte dann noch ein Vorschlag.
Ich mach das System bis auf die /home Partition platt. Auf der /home Partiotion habe ich inzwischen zu viele Daten drauf.
Installiere das System neu. Mache die Automatischen Updates. Wenn Firefox nicht automatisch installiert ist installiere ich ihn neu. genauso mit einem Texteditor. Ich gehe aber davon aus das die beiden Komponenten bei der Basisinstallation mit installiert werden.
Ab da verändere ich das System nur nach euren Anweisungen. Das macht die Fehlersuche für euch leichter.
Auf ins neue Glück.
Da hätte ich noch ne Frage. Wie mache ich Screenshots. Das ich euch auch Bilder Posten kann. Z.B. vom Applet des Netzwerkmanagers.
Bis dann
Röemer
 
Roemer schrieb:
Ich mach das System bis auf die /home Partition platt. ... Installiere das System neu.
Was versprichst Du Dir davon? Mit dem 1. Kernel funktioniert Dein Netzwerk. Mit dem 2. funktioniert es nicht (ich halte es für denkbar, daß dessen Konfiguration mit Deiner Hardware nicht zurechtkommt). Den 3. hast Du noch nicht probiert.

Das einzige, was Du nicht tun sollst, ist immer zwischen ifup/wicked und NetworkManager zu wechseln. Entscheide Dich für 1 Variante, und bleibe dabei.
 
josef-wien schrieb:
Roemer schrieb:
Ich mach das System bis auf die /home Partition platt. ... Installiere das System neu.
Was versprichst Du Dir davon?
Ganz einfach. Jegliche Konfiguration von mir die das Problem erzeugen könnte beseitigen. Damit habt ihr bei der Fehleranalyse weniger Probleme. Z.B. das Webmin nichr installiert ist.
josef-wien schrieb:
Mit dem 1. Kernel funktioniert Dein Netzwerk. Mit dem 2. funktioniert es nicht (ich halte es für denkbar, daß dessen Konfiguration mit Deiner Hardware nicht zurechtkommt).
Ich hatte mir schon überlegt euch die details meiner Hardware zu Posten.
Hier ist die Ausgabe von HWInfo
https://www.dropbox.com/sh/wtvocgcx5rf83lz/AADTQpAbyurSXADcckqVWxrAa?dl=0
Um sie als Quellcode zu Posten reichen die Anzahl der erlaubten Zeichen nicht aus.
Die Fehlermeldung ist
  • Dein Beitrag enthält 638812 Zeichen. Es sind maximal 60000 Zeichen erlaubt.
Deshalb der Link
Klappt mit Dropbox irgendwie nicht so. Wenn ihr eine andere Idee habt und der Inhalt für euch Sinn macht Postet mir bitte den Weg
josef-wien schrieb:
Den 3. hast Du noch nicht probiert.
Wie :???: Du hast mir schon einmal eine Antwort auf meine Frage gegeben.
josef-wien schrieb:
Roemer schrieb:
wie ich ihn installieren kann
YaST (Software bzw. Bootloader).
Meine Versuche waren Yast2 Software installieren oder löschen und dann nach default Kernel suchen mit keinem Treffer
Da brauche ich noch detaillierte Handlungsanweisungen

Das mit dem Bootloder habe ich nach suchen hinbekommen.
josef-wien schrieb:
Das einzige, was Du nicht tun sollst, ist immer zwischen ifup/wicked und NetworkManager zu wechseln. Entscheide Dich für 1 Variante, und bleibe dabei.
Ich versuche nach der Antwort von susejunky nur noch den NetworkManager zu nutzen. Meine Fragen mit den ifup/wicked dienen nur mein Verständnis zu erhöhen warum es 2 Konfigurationsdatensatze gibt.
Unter Microsoft gibt es die Möglichkeit des screenshots mit Str und Druck zu erstellen.
Gibt es bei KDE auch so eine Möglichkeit. Wenn ja wie Funktioniert sie?

Bis dann
Römer
 
Nutze einfach "ksnapshot". Startet z.B. über "Ausführen" => "ksn...". Ksnapshot kann in der Taskleiste abeglegt werden und kann dann jederzeit zum Speichern neuer Screenshots genutzt werden.

CU Freddie
 

susejunky

Moderator
Teammitglied
Hallo Roemer,

vielen Dank für Deine ausführliche Antwort.

Roemer schrieb:
... In der Beziehung verstehe ich nicht warum der Netzwerkmanager andere Dateien nimmt als wicked. Das Du dafür eine Erklärung.
Ich befürchte, diese Frage können Dir nur die Entwickler des NetworkManagers beantworten.

Roemer schrieb:
...Aber: die Datenübertragungsraten sind eher mager bzw. nicht vorhanden.
Wenn die Verbindung besteht und nur die Datenübetragungsgeschwindgkeit nicht Deiner Erwartung entspricht, dann ist das ein anderer Sachverhalt, als der, das sich überhaupt keine Verbindung aufbauen lässt! Was trifft denn zu?

Ist es richtig, dass Du im NetworkManager erfolgreich eine Verbindung konfiguriert hast und diese Verbindung über das NetworkManager-Applet in der Taskleiste erfolgreich aktivieren und deaktivieren kannst ODER ist es richtig, dass Du im NetworkManager erfolgreich eine Verbindung konfiguriert hast, diese Verbindung über das NetworkManager-Applet in der Taskleiste aber nicht aktivieren kannst?

Roemer schrieb:
... Laut anzeige war ist sie Funktionstüchtig , aber ohne Datenübertragung
Was hast Du getan, um festzustellen, ob Daten übertragen werden (oder nicht)?

Roemer schrieb:
... In beiden fällen nur LAN
Das liegt sehr wahrscheinlich daran, dass beide Dateien, "etc/NetworkManager/system-connections/LAN" und "etc/NetworkManager/system-connections/LAN-10473eee-85ce-46c9-86f7-edf321cf79fd" die Zeile "id=LAN" enthalten. Gemäß https://developer.gnome.org/NetworkManager/unstable/ref-settings.html gilt für id: A human readable unique identifier for the connection, like "Work Wi-Fi" or "T-Mobile 3G". Und zweimal "id=LAN" ist eben nicht eindeutig!

Roemer schrieb:
... Ich habe ich über den Verbindungseditor eingestellt das er sich automatisch verbindet.
Das passt zu den von Dir gezeigten Verbindungskonfigurationsdateien "etc/NetworkManager/system-connections/LAN" und "etc/NetworkManager/system-connections/LAN-10473eee-85ce-46c9-86f7-edf321cf79fd" ("autoconnect=true" muss nicht explizit angegeben werden).

Die von Dir gezeigten Ausgaben von "zypper" zeigen, dass Du die aktuellen Versionen von NetworkManager und plasma-nm installiert hast.

Zum Schluß muss ich noch gestehen, dass mir ein Fehler unterlaufen ist, der möglicherweise erklärt, warum Deine Verbindung nicht funktioniert: Im Abschnitt "[ipv4]" der Verbindungskonfigurationsdatei darf NICHT "method=auto" stehen. KORREKT ist in Deinem Fall "method=manual"! Der Einfachheit halber hier nochmals die (nun hoffentlich fehlerfreie) Verbindungskonfigurationsdatei:

Die Datei "etc/NetworkManager/system-connections/LAN" stellt automatisch (wenn Kabel gesteckt ist) eine für alle Benutzer nutzbare Verbindung her:
Code:
[ethernet]
mac-address=FC:AA:14:2D:B2:0A

[connection]
id=LAN
type=ethernet

[ipv6]
method=ignore

[ipv4]
method=manual
dns=192.168.2.95;
addresses1=192.168.2.33/24,192.168.2.95
may-fail=false

Die von mir verwendeten IP-Adressen musst Du prüfen und ggf. anpassen.

Die Datei "LAN" im Verzeichnis "etc/NetworkManager/system-connections" ablegen und Dateirechte korrekt setzen. Alle anderen Dateien aus dem Verzeichnis entfernen (nicht löschen, sondern an einen anderen Ort verschieben, sodass Du sie, falls erforderlich, wieder zurückholen kannst).

Wenn Du tatsächlich eine Neu-Installation durchführst (die aber sehr wahrscheinlich nicht erforderlich ist), dann gehe wie folgt vor:

  1. Sobald die Installation abgeschlossen ist, in YaST2 den NetworkManager aktivieren.
  2. Die Datei LAN im Verzeichnis "etc/NetworkManager/system-connections" anlegen
  3. Verbindung testen

Viel Erfolg und viele Grüße

susejunky
 
Oben