Feeds:
Beiträge
Kommentare

Archive for the ‘Netzwerk’ Category

Um per UMTS online gehen zu können habe ich eine Vodafone Karte zur Verwendung.

andreas@abo-mxcit:~$ lsusb
Bus 006 Device 002: ID 0af0:5000 Option UMTS Card

Nachdem ich festgestellt habe, dass der Network Manager unter Ubuntu 8.10 nicht in der Lage ist, damit eine Verbindung herzustellen, habe ich wvdial ausprobiert.

Meine Konfiguration sieht folgendermaßen aus:

# /etc/wvdial.conf

[Dialer Defaults]
Init1 = ATZ
Init2 = ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0
Init3 = AT+CGDCONT=1,"IP","web.vodafone.de","0.0.0.0",0,0
Modem Type = Analog Modem
Baud = 460800
New PPPD = yes
Modem = /dev/ttyUSB0
ISDN = 0
Phone = *99***1#
Password = egal
Username = egal
Stupid Mode = 1
Dial Attempts = 2
Carrier Check = no

Weiterhin war es notwendig, meinen angemeldeten Benutzer in die Gruppe dip aufzunehmen, da sonst /usr/sbin/pppd durch wvdial nicht aufgerufen kann, wenn man dies ohne root-Rechte tut. Wobei wir auch beim nächsten Punkt wären. Man kann wvdial mit und ohne root-Rechte starten. Wenn dies ohne root-Rechte geschieht beschwert sich wvdial völlig korrekt, dass die Datei /etc/ppp/pap-secrets nicht geschrieben werden kann. In dieser Datei wird bei mir der folgende Eintrag angelegt, der die Angaben aus der Datei wvdial.conf zu username und password wiederspiegelt:

# /etc/ppp/pap-secrets
egal    *       egal

Dieser Eintrag wird nicht automatisch wieder entfernt, so dass es ausreichen sollte, wvdial einmal mit root-Rechten zu starten.

Wenn eine Verbindung aufgebaut werden konnte, dann sieht das so aus:

andreas@abo-mxcit:~$ sudo wvdial
--> WvDial: Internet dialer version 1.60
--> Cannot get information for serial port.
--> Initializing modem.
--> Sending: ATZ
ATZ
OK
--> Sending: ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0
ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0
OK
--> Sending: AT+CGDCONT=1,"IP","web.vodafone.de","0.0.0.0",0,0
AT+CGDCONT=1,"IP","web.vodafone.de","0.0.0.0",0,0
OK
--> Modem initialized.
--> Sending: ATDT*99***1#
--> Waiting for carrier.
ATDT*99***1#
CONNECT 384000
--> Carrier detected.  Starting PPP immediately.
--> Starting pppd at Tue Mar 17 16:02:06 2009
--> Pid of pppd: 29954
--> Using interface ppp0
--> pppd: �[0f]�� i�[08][10]i�[08]
--> pppd: �[0f]�� i�[08][10]i�[08]
--> pppd: �[0f]�� i�[08][10]i�[08]
--> pppd: �[0f]�� i�[08][10]i�[08]
--> pppd: �[0f]�� i�[08][10]i�[08]
--> pppd: �[0f]�� i�[08][10]i�[08]
--> local  IP address 77.25.231.17
--> pppd: �[0f]�� i�[08][10]i�[08]
--> remote IP address 10.64.64.64
--> pppd: �[0f]�� i�[08][10]i�[08]
--> primary   DNS address 139.7.30.125
--> pppd: �[0f]�� i�[08][10]i�[08]
--> secondary DNS address 139.7.30.126
--> pppd: �[0f]�� i�[08][10]i�[08]

Woher die Zeilen mit den hübschen unlesbaren Zeichen kommen, kann ich leider nicht erklären. Interessant sind die Angaben der Nameserver. Diese musste ich in die Datei /etc/resolv.conf eintragen:

# /etc/resolv.conf
nameserver 139.7.30.125
nameserver 139.7.30.126

Scheinbar muss ich das ständig wiederholen, da der Network Manager unter Ubuntu 8.10 diese Angaben wieder entfernt, wenn die über ihn verwalteten Netzwerkverbindungen gestartet und wieder beendet werden.

Um Probleme mit der Namensauflösung vorzubeugen ist es meines Erachtens sinnvoll, die bestehenden Netzwerkverbindungenvor dem Aufruf von wvdial zu trennen. Dazu reicht ein Abziehen des Netzwerkkabels. Danach wvdial starten und die gemeldeten Angaben zum Nameserver in die resolv.conf eintragen.

Advertisements

Read Full Post »

Auch wenn das vielleicht den falschen trifft, für mich ist der „network-manager“ das Problem.
Ich betreibe mehrere PCs mit Ubuntu in der aktuellen Version 8.10. Davon machte ein Laptop bis heute Probleme, wann das begann kann ich nicht mehr sagen. Fakt ist, dass sich nach einer Anmeldung an Gnome keine Programme mehr starten liesen. Eine Zeit lang half es, den X-Server neu zu starten, aber aus mir unerklärlichen Gründen funktioniert das seit gestern abend auch nicht mehr. Und wenn ich mir so die Lösung ansehe, die ich heute gefunden habe, dann muss ich mich fragen, was denn der Neustart des X-Servers damit zu tun haben soll. In diversen Foren und Bugreports habe ich dieses Problem auch oft in Zusammenhang mit einem Nichtfunktionieren von „sudo“ gefunden.
Bei meiner Problemsuche bin ich sehr schnell darauf gestoßen dass der X-Server sich nicht verantwortlich fühlte (Auszug aus /var/log/gdm/:0.log):

AUDIT: Fri Jan  2 18:18:40 2009: 8044 X: client 4 rejected from local host ( uid=0 gid=0 pid=8069 )

Ein Starten der Anwendungen über ssh funktionierte tadellos.

Als nächstes fiel mir ein, dass bei der Anmeldung an Gnome über GDM ein Hostname angezeigt wurde, der mir so nicht gefiel: localhost.localdomain

ein Aufruf von „hostname“ brachte aber genau diese Anzeige. Also habe ich den hostname durch das bearbeiten von „/etc/hostname“ geändert und danach „/etc/init.d/hostname.sh“ ausgeführt. Ein wiederholter Aufruf von „hostname“ brachte jetzt das gewünschte Ergenbis.

Mein nächster Blick führte in die Datei „/etc/hosts“ (ich kann diese Angaben nicht mehr genau wiedergeben, da ich die Ursprungsversion nicht mehr habe):

127.0.0.1    tolpan.local localhost localhost.localdomain
127.0.1.1    tolpan

So sollte das nicht aussehen. Also änderte ich auch „/etc/hosts“.

Nachdem der „network-manager“ neu gestartet war, waren alle Änderungen wieder verschwunden (Ok, ich gebe es zu, ich habe den gesamten PC neu gestartet). Der Hostname stand wieder auf einen anderen Wert und die „/etc/hosts“ hatte wieder ihre alten Einträge. Zum Erfolg führte letztendlich dieser Beitrag in einem Bugreport: Bug #204824. Dieser Beitrag erwähnt die Datei „/etc/NetworkManager/nm-system-settings.conf“. Und genau diese Datei war auf dem für mich fehlerhaft arbeitenden System leer, auf allen anderen Systemen aber mit folgenden Inhalt versehen:

[main]
plugins=ifupdown,keyfile

[ifupdown]
managed=false

Diese Angaben decken sich exakt mit den Angaben, die im erwähnten Beitrag im Bugreport eingetragen sein sollen. Also habe ich alle Schritte des Beitrages ausgeführt, da sie mir sehr schlüssig und nachvollziehbar erscheinen. Einzig die Wiederholung der Hostnamen für die beiden IP-Adressen sind für mich nicht logisch. Es führt aber auch nicht zu einer Fehlfunktion.

Seit dem funktioniert das problematische System wieder tadellos.

Read Full Post »