network manager

[fitheach]

Hallo,

mein network manager zickt rum. Erst war es die UMTS-Karte: Es wird immer nach dem Pin gefragt und nach der Eingabe passiert nix.
Dann hat er das LAN beim Einstecken nicht mehr erkannt.
Und jetzt bin ich auch aus dem WLAN draußen. Er fragt immer nach dem Passwort, aber passieren tut hier auch nix mehr.

Ich vermute mal, das ist ein Rechteproblem, aber wieso hat es ursprünglich funktoniert und jetzt nicht mehr.

Kann mir jemand Schützenhilfe geben, um das Problem zu lokalisieren?

Vielen Dank

[roli]

Mahlzeit Meister,

findet sich denn vielleicht in /var/log/* irgendetwas verwertbares?

[uname]

Nutzt du nur network-manager oder network-manager-gnome? Könnte mir vorstellen, dass es an policykit-1 liegt. Das habe ich bis heute auch noch nicht verstanden, so dass ich meine Netze generell in /etc/network/interfaces konfiguriere. Ist weit einfacher und wohl auch verständlicher. Solltest du z.B. X11 über .xinitrc usw. starten könnte es sein, dass Policykit-1 nicht mitgestartet wird. Wäre vielleicht ein Ansatz. Also was nutzt du genau an Display-Manager, DE/WM und Network-Manager?

[fitheach]

Hallo,

die logs kommen heute abend.

Ich benutze die gnome shell und dementsprechend auch network-manager-gnome

[Blackbox]

Da der Network Manager ein schwerer Fall mit viel Magic ist, hat sich in der Vergangenheit nur das Entfernen der Benutzereigenen Konfigurationsdateien in $HOME und danach einen Relogin durchzuführen, nachhaltig bewährt.

Wenn du UMTS schreibst, in manchen Fällen wird das Paket modemmanager benötigt.

Sollten diese Maßnahmen alle ins Leere laufen, bleibt dir nur der Reinstall des Paketes, wobei die Systemweiten Konfigurationsdateien entfernt werden müssen.

[fitheach]

so, /var/log hat nix gesagt.

Ich hab die Verbindungen im Networkmanager-Verzeichnis gelöscht. Wlan geht wieder.

Bei umts werde ich nach Eingabe der Pin immer nach dem Passwort von meinem Account gefragt. Wenn ich das eingebe, passiert leider trotzdem nix.

[Blackbox]

Bei umts werde ich nach Eingabe der Pin immer nach dem Passwort von meinem Account gefragt. Wenn ich das eingebe, passiert leider trotzdem nix.

Kann es sein, dass die Kennwortabfrage vom Gnome-Schlüsselbund gnome-keyring kommt ?
Hast du schon einmal versucht das Kennwort doppelt einzugeben, wenn es dann gelingt, fehlt dir das Paket: libpam-gnome-keyring.
Ist zwar schon eine Weile her, als ich mit Gnome(2) gearbeitet habe, aber dies war ein Standardfehler, vielleicht wurde dieser, in Gnome3 übernommen !?

[uname]

Als ich noch Gnome(2) genutzt habe mussten bzw. sollten das Passwort und das Keyring-Passwort übereinstimmen. Vielleicht hast du ein Passwort zwischenzeitlich geändert.

[fitheach]

Ich weiß echt nicht mehr weiter. Seit dem letzten Update ist w-lan wieder weg, umts war bisher noch nicht zurück. Was ich bisher gemacht habe:

• - geschaut, ob policykit-1,Debianlibpam-gnome-keyring installiert ist.
  - Verbindung zu meinem Router gelöscht
  - mir Adminrechte gegeben
  - network-manager-gnome und Debiannetwork-manager neu installiert
  - von slim zurück auf gdm3 gewechselt (wegen keyring & Co.)

Was mich irritiert: Ich bekomme angezeigt, dass sich mein Rechner mit dem Router per wlan verbindet, aber ich habe kein Internet. Genauso scheint umts zu funktionieren (Ich habe die Empfangsbalken) aber wenn ich umts anschalten will, schaltet sich der Schieber immer wieder von selbst aus?

Ich bin ein bisschen frustriert!

[wanne]

Kannst du mal das posten, wenn du vermeintlich verbunden bist:

Code: Alles auswählen

iwconfig
ip a
ip r
ps -ef | grep dhc

[Blackbox]

Ich möchte wissen, funktioniert dein Netzwerk ohne Networkmanager ?

gewöhnlich ist es ja so, dass der Networkmanager mit viel Magic die Netzwerkverbindung herstellt und dabei die Konfigurationsdatei

Code: Alles auswählen

/etc/network/interfaces

komplett ignoriert.

1. wie sieht deine

Code: Alles auswählen

/etc/network/interfaces

aus ?

2. Hast du schon einmal versucht, den Networkmanager zu deaktivieren und eine IP ohne den Networkmanager zu bekommen ?

Wenn dies klappt, ist sichergestellt, dass dein Netzwerk überhaupt funktionsfähig ist.
Und es macht die Diagnostik einfacher...

[fitheach]

Danke, Jungs! Werdet ihr hieraus schlau?

/etc/network/interfaces:

Code: Alles auswählen

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
allow-hotplug eth0
iface eth0 inet dhcp
~

ip r

Code: Alles auswählen

default via 192.168.178.1 dev eth0 
default via 192.168.178.1 dev wlan0  proto static  metric 1024 
169.254.0.0/16 dev wlan0  scope link  metric 1000 
192.168.178.0/24 dev eth0  proto kernel  scope link  src 192.168.178.26 
192.168.178.0/24 dev wlan0  proto kernel  scope link  src 192.168.178.20 
root@axel-PC:/etc/network# iwconfig
eth0      no wireless extensions.

lo        no wireless extensions.

wlan0     IEEE 802.11abgn  ESSID:"cybergate"  
          Mode:Managed  Frequency:2.432 GHz  Access Point: 9C:C7:A6:87:E7:97   
          Bit Rate=1 Mb/s   Tx-Power=16 dBm   
          Retry short limit:7   RTS thr:off   Fragment thr:off
          Encryption key:off
          Power Management:off
          Link Quality=68/70  Signal level=-42 dBm  
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:62   Missed beacon:0

ip a

Code: Alles auswählen

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 60:eb:69:a3:53:d4 brd ff:ff:ff:ff:ff:ff
    inet 192.168.178.26/24 brd 192.168.178.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::62eb:69ff:fea3:53d4/64 scope link 
       valid_lft forever preferred_lft forever
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 1c:65:9d:c6:a3:2c brd ff:ff:ff:ff:ff:ff
    inet 192.168.178.20/24 brd 192.168.178.255 scope global dynamic wlan0
       valid_lft 863507sec preferred_lft 863507sec
    inet6 fe80::1e65:9dff:fec6:a32c/64 scope link 
       valid_lft forever preferred_lft forever

ps -ef | grep dhc

Code: Alles auswählen

root      1599     1  0 Jul27 ?        00:00:00 dhclient -v -pf /run/dhclient.eth0.pid -lf /var/lib/dhcp/dhclient.eth0.leases eth0
ntp       3149     1  0 Jul27 ?        00:00:01 /usr/sbin/ntpd -p /var/run/ntpd.pid -g -c /var/lib/ntp/ntp.conf.dhcp -u 117:122
root      4511   604  0 20:06 ?        00:00:00 /sbin/dhclient -d -sf /usr/lib/NetworkManager/nm-dhcp-helper -pf /var/run/dhclient-wlan0.pid -lf /var/lib/NetworkManager/dhclient-924ca214-1374-4027-b0fb-ed1827c49a3d-wlan0.lease -cf /var/lib/NetworkManager/dhclient-wlan0.conf wlan0
root      4849  4745  0 20:16 pts/0    00:00:00 grep dhc

[wanne]

Ok, da ist einmal eine von Hand konfigurierte Verbindung per kabel und einmal eine vom netzwerkmanager per wlan. Genutzt müsste das Kabel werden.

[fitheach]

ja, zur Zeit funktioniert nur lan. Hab ich aber nicht konfiguriert, war schon da. Allerdings sagt der NW-Manager "Lan wird nicht verwaltet" funktionert jedoch trotzdem.

[uname]

Der Network-Manager verwaltet nur Verbindungen, die gerade nicht in /etc/network/interfaces stehen. Da LAN in /etc/network/interfaces steht kann bzw. wird der Network-Manager diese Verbindung nicht verwalten und die Aussage ist somit korrekt. Du könntest auch das WLAN von /etc/network/interfaces verwalten lassen. Mache ich bei allen Systemen, die sowieso nur ein WLAN kennen bzw. kennen sollen. Spart vor allem Ärger wenn ich bei Bekannten Debian auf Rechnern installiere, die nie das eigene WLAN verlassen (sollen). Da kann der Anwender auch nicht versehentlich die WLAN-Konfiguration verändern.

[wanne]

ja, zur Zeit funktioniert nur lan

Nein. WLAN funktioniert auch. Nur solange das so eingestellt ist, dass LAN bevorzugt genutzt wird, bekommst du davon nichts mit.

[fitheach]

@uname
nein, ich benutze mehrere WLANs. Daher müsste ich die alle in interfaces eintragen.

@wanne
es funktioniert auch nicht, wenn ich das LAN-Kabel abgezogen habe.

[guennid]

ich benutze mehrere WLANs. Daher müsste ich die alle in interfaces eintragen.

wo ist das Problem?
Du kannst labels definieren.

Grüße, Günther

[wanne]

@wanne
es funktioniert auch nicht, wenn ich das LAN-Kabel abgezogen habe.

Ja. Würde mal tippen, dass du dann weiterhin die Pakete durch das nicht vorhandene Kabel schickst.

[mindX]

Ich hab jetzt nicht jedes Detail des Threads gelesen, aber könnte das Problem nicht auch aus dieser Ecke kommen?
=> viewtopic.php?f=27&t=150180#p996425

[wanne]

Achso: Die von mir gewünschten ausgaben sind natürlich immernoch interessant. Aber halt dann, wenn es nicht tut.

[fitheach]

ja, ein

Code: Alles auswählen

# systemctl start resolvconf
# systemctl restart networking

bringt temporär die Lösung.

Kann mir das jemand mit einfachen worten erklären und wie ich den Fehler dauerhaft behebe?

[mindX]

Ich bin kein Experte, aber für mich liest sich das so, als würde networking starten und resolvconf nicht. Also gibts keine Namensauflösung und somit keinen ordentlich beschilderten Weg ins Internet.

Scheint wohl ein Bug in Zusammenhang mit der Umstellung auf systemd (statt sysvinit) zu sein. Als dauerhafte Lösung wirds wohl einen Bugfix geben, als Zwischenlösung könntest du z.B. die Befehle in ein Script packen und beim Start von Gnome ausführen lassen.

[fitheach]

Ich spüle das Thema noch einmal hoch.

Bisher musste ich nach jedem Neustart

Code: Alles auswählen

systemctl restart networking

als root eingeben. Nicht toll, aber hat funktioniert.

Seid dem letzten update gestern funktioniert das so nicht.

Wenn ich obigen Befehl eingebe, habe ich solange Internet, wie die shell mit dem Befehl beschäftigt ist. Sobald der prompt kommt, ist inet wieder weg.

Kann mir jemand weiterhelfen?

VG
fith

[Teddybear]

Ich tippe mal darauf, das resolvconf noch immer Probleme macht.
Ich würde probehalber dieses Paket mal entfernen und die /etc/resolv.conf händisch mit den passenden oder brauchbaren nameservern füttern.