[Gelöst] Neuinstallation von Opensuse 15.2 Netzwerkmanager spielt verrückt!

[HarryMalaria]

Ich hab bei meinem Bruder auf einen neuen PC leap 15.2 installiert, ich hab den Rechner mit dem Router über ein Kabel verbunden. Über den Firefox komme ich nicht auf den speedport, weder mit der ip noch mit http://speedport.ip.
Der NetworkManager poppt dauernd auf, einmal ist die Verbindung aktiviert, dann wieder deaktiviert. Ich hab dann in Yast auf wicked umgestellt, so wie ich das auf meinem Rechner auch mache, aber ich komme nicht auf den Router. Ich hab auch mehrfach versucht, den Netzwerkmanager zu konfigurieren, als Kabelgebundene Verbindung, was auch nicht klappte. Bei mir ist der Netzwerkmanager gar nicht installiert. Liegt das am Neztwerkmanager oder ist es wahrscheinlicher, dass das Kabel oder eine Buchse defekt ist, anders kann ich mir das nicht erklären, denn die Netzwerkkarte funktioniert und wird angezeigt.

P.S: Ich kann mich dunkel erinnern, da es vor Jahren mal hies, man sollte den Networkmanager runterschmeißen, da er nur Probleme macht. das könnte auch der Grund sein, warum ich ihn nicht mehr auf dem System habe.

 

[Sauerland]

Poste mal:

/sbin/lspci -nnk | grep -iA3 net

Und das war eine Neuinstallation, auf dem PC war vorher noch kein Betriebssystem installiert?

 

[HarryMalaria]

Ja ein komplett neuer Rechner. Zusammengebaut und installiert.

 

[susejunky]

Hallo HarryMalaria,

... ich hab den Rechner mit dem Router über ein Kabel verbunden. Über den Firefox komme ich nicht auf den speedport, weder mit der ip noch mit http://speedport.ip.

War zu der Zeit auf dem Router bereits ein DHCP-Server aktiv?

Falls Du statische IP-Adressen verwendet hast, gehörte die statische IP-Adresse Deines Rechners zum selben Subnetz wie die IP des Speedports?

... Liegt das am Neztwerkmanager oder ist es wahrscheinlicher, dass das Kabel oder eine Buchse defekt ist, anders kann ich mir das nicht erklären, denn die Netzwerkkarte funktioniert und wird angezeigt.

Was ist das Ergebnis von

# journalctl -b 0 -p 3

und

# systemctl status network

Bitte als Administrator ausführen und die Ergebnisse inkl. der Befehlseingabe und der neuen Eingabeaufforderung zeigen.

... Ich hab auch mehrfach versucht, den Netzwerkmanager zu konfigurieren, als Kabelgebundene Verbindung, was auch nicht klappte.

Zeige bitte das zu dieser "Kabelgebundene Verbindung" gehörige NetworkManager-Verbindungsprofil.

Viele Grüße

susejunky

 

[HarryMalaria]

Ich bin leider grade nicht an dem Rechner, aber das war ein guter Hinweis. Es handelt sich um einen neuen DSL Anschluß, als Router wurde ein Speedport Entry2 verwendet. Der Router wurde verkabelt, so wie das aussieht, hat sich der von selbst eingerichtet oder es ist was faul. Es leuchten 4 Lämpchen. Power-DSL-Online-Telefon. Das Telefon funktioniert auch. Normalerweise muß man auf den Speedport zugreifen, das Gerätepassword eingeben und dann die Zugangsdaten der Telekom eingeben. Aber ich komme leider nicht drauf, kann also nicht sagen, ob DHCP am Router aktiv ist oder nicht. Jetzt bin ich etwas irritiert, ich weiß zwar, das die Telekom automatisch konfiguriert, aber ich dachte erst nachdem man die Zugangsdaten eingegeben hat.

 

[Sauerland]

Poste mal:

/sbin/lspci -nnk | grep -iA3 net

 

[susejunky]

Hallo HarryMalaria,

... Es handelt sich um einen neuen DSL Anschluß, als Router wurde ein Speedport Entry2 verwendet. Der Router wurde verkabelt, so wie das aussieht, hat sich der von selbst eingerichtet oder es ist was faul. Es leuchten 4 Lämpchen. Power-DSL-Online-Telefon. Das Telefon funktioniert auch. Normalerweise muß man auf den Speedport zugreifen, das Gerätepassword eingeben und dann die Zugangsdaten der Telekom eingeben. Aber ich komme leider nicht drauf, kann also nicht sagen, ob DHCP am Router aktiv ist oder nicht. Jetzt bin ich etwas irritiert, ich weiß zwar, das die Telekom automatisch konfiguriert, aber ich dachte erst nachdem man die Zugangsdaten eingegeben hat.

mein DSL-Anschluss stammt noch aus der Zeit, als die Router noch nicht Fern-Konfiguriert wurden.

Meines Wissen bezieht sich die Fern-Konfiguration nur auf den WAN-Teil des Routers; d.h. in Deinem Fall die Zugangsdaten der Telekom. Das würde auch zu der Tatsache passen, dass das Telefonieren bereits funktioniert.

Der interne Teil (LAN und/oder WLAN) muss sehr wahrscheinlich noch konfiguriert werden:

• PC und Router per LAN-Kabel verbinden.
• Dem PC eine IP-Adresse zuweisen, die aus dem selben Subnetz stammt, wie die IP-Adresse des Routers (z.B.: Router 192.178.1.1 dann PC 192.178.1.2).
• Mit Hilfe eines Browsers, der initialen IP-Adresse des Routers und einem initialen Gerätekennwort (beides oft auf dem Typenschild des Routers vermerkt) auf der Web-Oberfläche des Routers anmelden und LAN/WLAN wunschgemäß konfigurieren.

Das alles funktioniert natürlich nur, wenn alle Netzwerkkomponenten des PCs einwandfrei arbeiten. Daher solltest Du die von Sauerland und mir nachgefragten weiteren Informationen auch noch zur Verfügung stellen.

Viele Grüße

susejunky

 

[HarryMalaria]

Ja das werde ich nachmittags mal machen. Und es mit einer statischen Adresse versuchen. Deshalb hab ich auch erst an das Kabel gedacht, der Zugriff ist ja weder über speedport.ip noch über 192.168.2.1 möglich. Die Variante mit der statischen ip hab nich noch nicht probiert.

 

[HarryMalaria]

so ich hab die fehlermeldungen mal ausgelesen. ich hab auch die patchkabel getauscht, keine änderung:

lspci:

@localhost:~> /sbin/lspci -nnk | grep -iA3 net
06:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev 15)
        Subsystem: ASRock Incorporation Motherboard (one of many) [1849:8168]
        Kernel driver in use: r8169
        Kernel modules: r8169

system:

systemctl status network
● wicked.service - wicked managed network interfaces
   Loaded: loaded (/usr/lib/systemd/system/wicked.service; enabled; vendor preset: disabled)
   Active: active (exited) since Sat 2020-07-04 12:37:55 CEST; 29min ago
  Process: 20696 ExecReload=/usr/sbin/wicked --systemd ifreload all (code=exited, status=0/SUCCESS)
  Process: 19147 ExecStart=/usr/sbin/wicked --systemd ifup all (code=exited, status=0/SUCCESS)
 Main PID: 19147 (code=exited, status=0/SUCCESS)
    Tasks: 0
   CGroup: /system.slice/wicked.service

Jul 04 12:37:49 localhost.localdomain systemd[1]: Starting wicked managed network interfaces...
Jul 04 12:37:55 localhost.localdomain wicked[19147]: lo              up
Jul 04 12:37:55 localhost.localdomain wicked[19147]: eth0            up
Jul 04 12:37:55 localhost.localdomain systemd[1]: Started wicked managed network interfaces.
Jul 04 12:39:06 localhost.localdomain systemd[1]: Reloading wicked managed network interfaces.
Jul 04 12:39:37 localhost.localdomain wicked[20696]: eth0            device-ready
Jul 04 12:39:37 localhost.localdomain wicked[20696]: eth0            setup-in-progress
Jul 04 12:39:37 localhost.localdomain systemd[1]: Reloaded wicked managed network interfaces.

journal:

ocalhost: journalctl -b 0 -p 3    
-- Logs begin at Sat 2020-07-04 11:55:27 CEST, end at Sat 2020-07-04 13:08:17 CEST. --
Jul 04 11:55:27 localhost kernel: do_IRQ: 1.55 No irq handler for vector
Jul 04 11:55:27 localhost kernel: do_IRQ: 2.55 No irq handler for vector
Jul 04 11:55:27 localhost kernel: do_IRQ: 3.55 No irq handler for vector
Jul 04 11:55:27 localhost kernel: do_IRQ: 4.55 No irq handler for vector
Jul 04 11:55:27 localhost kernel: do_IRQ: 5.55 No irq handler for vector
Jul 04 11:55:27 localhost kernel: do_IRQ: 6.55 No irq handler for vector
Jul 04 11:55:27 localhost kernel: do_IRQ: 7.55 No irq handler for vector
Jul 04 11:55:30 localhost kernel: sp5100-tco sp5100-tco: Watchdog hardware is disabled
Jul 04 11:55:53 localhost wickedd-dhcp4[2126]: unable to confirm lease
Jul 04 11:56:05 localhost kernel: nouveau 0000:0b:00.0: gr: intr 00000040
Jul 04 11:56:08 localhost wickedd-dhcp4[2126]: unable to confirm lease
Jul 04 11:56:30 localhost wickedd-dhcp4[2126]: unable to confirm lease
Jul 04 11:56:40 localhost wickedd-dhcp4[2126]: unable to confirm lease
Jul 04 11:57:03 localhost wickedd-dhcp4[2126]: unable to confirm lease
Jul 04 11:57:37 localhost wickedd-dhcp4[2126]: unable to confirm lease
Jul 04 11:57:53 localhost wickedd-dhcp4[2126]: unable to confirm lease
Jul 04 11:58:57 localhost wickedd-dhcp4[2126]: unable to confirm lease
Jul 04 11:59:12 localhost wickedd-dhcp4[2126]: unable to confirm lease
Jul 04 11:59:37 localhost wickedd-dhcp4[2126]: unable to confirm lease
Jul 04 11:59:53 localhost wickedd-dhcp4[2126]: unable to confirm lease
Jul 04 12:00:59 localhost firewalld[1181]: ERROR: UNKNOWN_INTERFACE: 'eth0' is not in any zone
Jul 04 12:01:19 localhost wickedd-dhcp4[2126]: unable to confirm lease
Jul 04 12:01:31 localhost wickedd-dhcp4[2126]: unable to confirm lease
Jul 04 12:01:43 localhost wickedd-dhcp4[2126]: unable to confirm lease
lines 1-25

 

[susejunky]

Hallo HarryMalaria,

so ich hab die fehlermeldungen mal ausgelesen. ich hab auch die patchkabel getauscht, keine änderung:

was ist das Ergebnis von

# ip addr

Viele Grüße

susejunky

 

[Heinz-Peter]

Hallo,

ich habe die Fehlermeldung

 12:00:59 localhost firewalld[1181]: ERROR: UNKNOWN_INTERFACE: 'eth0' is not in any zone

in die Suchmaschine geschmissen: Hier ein Treffer von vielen: https://forums.opensuse.org/showthread.php/518486-In-Yast-no-zone-assigned-to-interface-in-firewall-which-firewall-rules-apply

Grüße

Heinz-Peter

 

[susejunky]

... ich habe die Fehlermeldung

 12:00:59 localhost firewalld[1181]: ERROR: UNKNOWN_INTERFACE: 'eth0' is not in any zone

in die Suchmaschine geschmissen: Hier ein Treffer von vielen: https://forums.opensuse.org/showthread.php/518486-In-Yast-no-zone-assigned-to-interface-in-firewall-which-firewall-rules-apply

Bitte beachten:

Der Beitrag stammt aus dem Jahre 2016 (openSUSE Leap 42.x ?) und betrifft SuSEfirewall2!

openSUSE Leap 15.2 verwendet in der Standard-Konfiguration firewalld.

Wenn die Firewall nicht explizit abweichend konfiguriert wurde, reguliert sie auch nur eingehende Verbindungen. Ausgehende Verbindungen werden nicht eingeschränkt.

Viele Grüße

susejunky

 

[Heinz-Peter]

OK, ist dieses Suchergebnis besser?
https://access.redhat.com/discussions/2779921

 

[susejunky]

Hallo Heinz-Peter,

OK, ist dieses Suchergebnis besser?
https://access.redhat.com/discussions/2779921

es liegt nicht in meiner Absicht die Beiträge Anderer als "gut" oder "schlecht" zu bewerten! Falls das bei Dir anders angekommen ist, dann bitte ich das zu entschuldigen.

Ich wollte nur auf die Tatsache hinweisen, dass openSUSE Leap 15.2 in der Standard-Installation firewalld und nicht SuSEfirewall2 verwendet.

Meines Erachtens kontrolliert firewalld, wenn es nicht abweichend konfiguriert wurde, auch primär eingehende Verbindungsanfragen. Wenn ich die Beiträge von HarryMalaria soweit richtig verstanden habe, dann möchte er aber von seinem PC aus, mittels eines Webbrowsers, auf die Weboberfläche seines Routers zugreifen (also eine ausgehende Verbindung).

Leider bin ich kein Netzwerkspezialist, daher wäre ich Dir dankbar, wenn Du mir kurz erläutern könntest, welche Zusammenhänge zwischen dem von Dir gezeigten Fehlerreport und dem von HarryMalaria geschilderten Problem bestehen.

Viele Grüße

suejunky

 

[josef-wien]

"Firewall-Oberflächen" waren mir schon immer suspekt, daher kann ich dazu nicht wirklich etwas sagen, aber deutet nicht

'eth0' is not in any zone

darauf hin, daß etwas nicht Definiertes auch keine Verbindungen herstellen kann?

 

[susejunky]

Hallo josef-wien,

"Firewall-Oberflächen" waren mir schon immer suspekt, daher kann ich dazu nicht wirklich etwas sagen, aber deutet nicht

'eth0' is not in any zone

darauf hin, daß etwas nicht Definiertes auch keine Verbindungen herstellen kann?

wie bereits erwähnt, ich bin kein Netzwerkspezialist und meine Kenntnisse zu firewalls (oder besser iptables) sind "ziemlich dünn" ...

> man firewalld.zones
...
How to set or change a zone for a connection?
       The zone is stored into the ifcfg of the connection with ZONE= option. If the option is missing or empty, the default zone set in firewalld is used.
...

# cat /etc/firewalld/firewalld.conf
# firewalld config file

# default zone
# The default zone used if an empty zone string is used.
# Default: public
DefaultZone=public
...

(aus meiner openSUSE Tumbleweed Installation, von mir nicht geändert).

> man firewalld.zones
...
       public
           For use in public areas. You do not trust the other computers on networks to not harm your computer. Only selected incoming connections are accepted.
...

... aber meine Vermutung war und ist, dass eine Verbindung vom PC mittels WebBrowser zur Weboberfläche des Routers nicht an der "fehlenden" Zone-Zuweisung scheitern sollte.

Vielleicht kann uns Heinz-Peter da aber mehr dazu sagen.

Viele Grüße

susejunky

 

[Heinz-Peter]

Hallo Heinz-Peter,

OK, ist dieses Suchergebnis besser?
https://access.redhat.com/discussions/2779921

es liegt nicht in meiner Absicht die Beiträge Anderer als "gut" oder "schlecht" zu bewerten! Falls das bei Dir anders angekommen ist, dann bitte ich das zu entschuldigen.

Wenn sich hier einer entschuldigen soll dann Betrifft das eher mich wie Dich.
Ich wollte lediglich hinweisen das dieser Fehler öfter zu finden ist.
Durch meine schlechte englisch Kenntnisse habe ich einen falschen Hinweis geliefert, den Du hast korrigiert. Dafür bin ich Dir dankbar.

Grüße

Heinz-Peter

 

[spezi]

Guten Tag,
was passiert denn wenn die Firewall ausgeschaltet ist?

 

[Sauerland]

Und

ip a

Fehlt immer noch.... (ip address oder ip addr ist dasselbe)

 

[HarryMalaria]

Das Problem ist gelöste, hatte nix mit Leap zu tun. in einer Dose war eine Ader nicht richtig angeklemmt, dadurch konnte der Router nicht erreicht werden. Danach trat der Fehler aber weiterhin auf, was durch einen Routerreset behoben werden konnte, nach dem Reset lief alles wie es soll.