Networkmanager - shared connection Probleme

Hi Susecommunity!

Ich habe aktuell nur über W-Lan Zugriff aufs Internet und da mein PC keinen W-Lan Chip onboard hat und ich auch keinen Stick besitze habe ich mich entschlossen mit meinem Laptop ins W-lan zu gehen und diese Verbindung per Kabel für meinen PC freizugeben.

So weit so gut. Theoretisch ist das auch recht einfach. Man sagt der suse Firewall, dass kabelgebundene Netzwerk eine interne Zone ist und dasW-Lan Netzwerk extern. Außerdem setzt man noch einen Haken bei "Masquerade Networks" und leg im Networkmanager eine Kabelgebundene Verbindung mit der Methode "gemeinsam" oder "shared" an.

In der Praxis sieht es dann bei mir so aus, dass ich zwar Internet auf dem PC habe, diedser Verbindung aber nach einer scheinbar zufälligen Zeit abbricht. An diesem Punkt hilft es dann nicht im NetworkManager die gemeinsame Verbindung zu trennen und neu aufzubauen, sondern der einzige mir bekannte Weg die Verbindung wieder zum laufen zu bekommen ist das Lan Kabel mindestens etwa 2 Sekunden lang herauszuziehen und wieder einzustecken. Danach ist fast direkt die Verbindung wieder da.

Sagt mir bitte welche Informationen ihr noch benötigt, falls der Log nicht ausreichen sollte.

Vielen Dank für die Hilfe! Ich komme echt nicht drauf woran es liegen könnte...

Das Problem hat sich erledigt.

Problemlösung: IPv6 im YasT deaktivieren. Auch wenn der NetworkManager verwendet wird, reicht es scheinbar nicht IPv6 nur für die betroffenen Verbindungen im NetworkManager zu deaktivieren, sondern es muss global für alle Verbindungen über YasT deaktiviert werden.

Problemlösungen mit aktiviertem IPv6 sind mir nicht bekannt. Wenn allerdings jemand eine Ahnung hat, wie ich die Sache mit IPv6 zum Laufen bekomme wäre ich für Ansätze dankbar.

Leider doch nicht gelöst...

Meine von mir Oben angegebene Lösung hat für etwa 30 Stunden gehalten. Jetzt weigert sich mein Laptop wieder in Zufälligen Zeitabständen mit meinem PC zu kommunizieren... IPv6 ist nach wie vor gänzlich deaktiviert. Ich habe echt keine konkrete Ahnung mehr woran das liegen könnte. Ein aktivieren/deaktivieren von IPv6 scheint das Problem temporär wieder zu beheben. Ich habe ein wenig die Vermutung, dass irgendein Dienst gelegendlich in meinen Netzwerkeinstellungen herumpfuscht, was erklären würde, wesshalb es geht, wenn ich den NetorkManager dazu zwinge die Verbindung neu aufzubauen (ziehen des Lan Kabels/aktivieren/Deaktivieren von IPv6) und die Verbindung dann funktioniert bis sich irgendein Dienst einmischt.

Das ist aber wie gesagt nur eine Vermutung und ich habe keine Ahnung wie ich herausfinden könnte ob und wenn welcher Dienst mich da ärgern möchte.

@ grossing Danke für die Antwort. Ich werde mich Morgen mal dran versuchen.

Nun verwundert hat es mich auch aber scheinbar nutzt es schon etwas und zwar, dass alle Netzwerkverbindungen beendet und neu initialisiert werden incl. Firewall Einstellungen etc. Das Selbe geht aber auch einfacher, indem ich im network Manager einfach den Netzwerkmodus aktivieren HAken entferne und neu setze oder eben das Lan Kabel ziehe und neu einstecke.

Wie auch immer. Ich habe keine Ahnung wie ich bei der shared connection eine fest IP erzwingen kann. Es scheint aber so, dass diese bei mir immer auf 10.42.0.1 gesetzt wird. Aber die bekommt er vermutlich auch nicht von einem DHCP. Mein Client nutzt eine feste IP (10.42.0.2).
Ich habe jetzt auch mal die W-Lan IP auf 192.168.2.11 festgesetzt, wobei es daran nicht liegen sollte, denn mein Laptop hat ja weiterhin eine Internetverbindung, wenn mein PC rausgeworfen wird.

Des weiteren habe ich im Grub den Eintrag net.ipv6.conf.all.disable_ipv6 = 1 hinzugefügt. Ich werde jetzt aber erstmal eine Runde schlafen gehen und Morgen danns ehen, ob der Eintrag etwas gebracht hat oder nicht.

Ich bedanke mich aber jetzt schonmal für die Hilfe.

192.138.2.11 war ein Tippfehler. Dank der 255.255.255.0 subnet mask würde es mit 138 auch garnicht mit dem DSL Router reden können. Sry für den Fehler. Es ist natürlich 192.168.2.11 im Wireless Profil der Verbindung im NetworkManager bei IPv4 gesetzt.

Mit Grub war in diesem Fall die aktuelle Version von Grub also Grub 2 gemeint. Für mich heißt mein bootloader nunmal nach wie vor Grub. Wenn ich dadurch falsch verstanden wurde, ist das aber hiermit geklärt.
Ich habe den Eintrag bei yast2 -> BootLoader -> Boot Loader Options (bei ausgewähltem Grub2) in den Feldern optional Kernel Command Line Parameter und failsafe Kernel Command Line Parameter angehängt.

Das Problem besteht weiterhin. Was mich besonders wundert ist, dass die Verbindung in extrem ungleichmäßigen Abständen den Dienst verweigert. Manchmal dauert es nur wenige Sekunden, bis mein Laptop die Kommunikation verweigert und manchmal läuft es mehrere Stunden am Stück ohne Probleme durch.