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

ursache für dial on demand

pft

Advanced Hacker
Hallo,

wie kann man am einfachsten herausfinden was die Ursache für ein EInwahl ins Internet ist.

Das Problem: meine Kiste baut seit dem Upgrade auf 10.2 ca. alle 10 Minuten eine Verbindung auf.

Fetchmail ist es definitiv nicht, auch wenn das Zeitraster passen würde.
Da dies auch zu Zeiten passiert, zu denen definitv kein Clientrechner mehr läuft muss es wohl ein lokaler Prozess sein.

Gruß
pft
 
A

Anonymous

Gast
Mit dem Problem hab ich mich auch schonmal tagelang rumgeschlagen.
Die einzige Lösung war, den nscd zu deaktivieren.

rootkonsole:
Code:
insserv -r nscd

Falls Du den aber brauchst, wirst Du vielleicht dessen Config entsprechend ändern müssen (was ich mangels Bedarf nicht versucht habe).


Gruß
 
Für die Analyse wären hilfreich:
Liste der laufenden Prozesse: -> ps aux
Einträge in den Crontabs: /etc/crontab + etc/cron.d/*
Weitere Infos: z.B. läuft ein Virenscanner (Antivir) mit autom. Update
Wie sind YOU etc. eingestellt?
...
 
A

Anonymous

Gast
Wenn mein Vorschlag oben nicht funzt, dann beobachte hiermit doch mal wer der Auslöser ist:
Code:
watch -n 1 netstat -pantou

Eine weitere Möglichkeit, den Verursacher ausfindig zu machen wären Netzwerksniffer (aber aufwändig, bis man die passend gefiltert hat).

Das in Kombination mit Logfileauswertung und Abschalten des Crondienstes ergab bei mir immer wieder, dass eine DNS-Anfrage ausgelöst wird.
Die war immer an Adressen gerichtet, die zuvor irgendwann in Benutzung waren, oder des öfteren sowieso vom System benutzt werden.
Weil aber die legitimen Interessenten an den Namensauflösungen zu diesem Zeitpunkt jeweils gar nicht aktiv waren, die Zeitabstände der Einwahlen zudem irgendwie regelmäßig schienen, bin ich auf den nscd gekommen, und siehe da ...

Dienst abgeschaltet, Problem gelöst.

Gruß
 
OP
P

pft

Advanced Hacker
Also /var/log/messages bringt aus meiner Sicht nichts - hatte ich vergessen zu erwähnen. Hier trotzdem nochmal der relevante Ausschnitt:
Feb 27 02:38:32 sonne pppd[5864]: capiplugin: phase dormant (was dead).
Feb 27 02:38:32 sonne pppd[5864]: Script /etc/ppp/ip-down finished (pid 1939), status = 0x0
Feb 27 02:38:32 sonne kernel: kcapi: appl 2 ncci 0x10102 down
Feb 27 02:47:38 sonne pppd[5864]: Starting link
Feb 27 02:47:38 sonne pppd[5864]: capiplugin: phase serialconn (was dormant).
Feb 27 02:47:38 sonne pppd[5864]: capiplugin: leased line (adslpppoe)
Feb 27 02:47:38 sonne kernel: capilib_new_ncci: kcapi: appl 2 ncci 0x10102 up
Feb 27 02:47:38 sonne pppd[5864]: capiplugin: connected: "" -> "" outgoing
Feb 27 02:47:38 sonne pppd[5864]: capiplugin: using /dev/capi/0: "" -> "" outgoing
Feb 27 02:47:39 sonne pppd[5864]: Connect: dsl0 <--> /dev/capi/0

Antivir oder you sind definitiv deaktiviert, cron ist auch nicht relevant. Eigentlich ist mir überhauptkein Programm bekannt das hier in Frage kommt. Das ist ja mein Problem.

Ich gehe mit ner Fritzcard DSL ins internet.

die anderen Punkte - nscd und netstat - klingen interessant. Werde es mir mal anschauen.

Allerdings habe ich offenbar noch ein paar andere Probleme, da manchmal (wann genau ist mir noch nicht klar) die default route nicht mehr gesetzt ist und damit ein dial on demand gar nicht geht.
Insofern ist nscd bzw. die Änderung des DNS bei Auf- und Abbau der Verbindung ein guer Kandidat zum nachforschen.

Noch was: ich habe IPv6 grundsätlich deaktiviert. Was zu vielen lästigen Meldungen in der messages führt. Kann man das abstellen - gibt es auch "echte" Probleme durch deaktivierten IPv6 support?
 

Ghoul

Member
Ist die Zeit zwischen Schleißen und wieder einwählen immer so zimlich gleich?
Dann schau mal im down script nach ob da irgendetwas gestartet wird
 
OP
P

pft

Advanced Hacker
Ja, es sieht jetzt soaus, dass, unabhängig wie groß ich den Timeout wähle innerhalb von 1 bis 2 Minuten danach wieder aufgebaut wird.
werd dem also mal nachgehen.

ich selbst hab da nur zwei einträge eingebracht:
1. den fetchmail daemon wieder stoppen (derzeit start und stop auskommentiert)
2. Verbindungsdaten in ein logfile schreiben

Also nichts was internet relevant wäre.

Darüber hinaus habe ich jezt den Zustand das can eta zehn internetverbindungen der pppd abschmiert und ich erst
nach "rcnetwork restart dsl0" und "rcsmpppd restart" wieder Internetzugang bekomme.

Echt ätzend.

Auch ein abschalten verschiedenster Dienste hat nichts gebracht: cups, postfix, amavis, nscd, ip_forwarding ...

Langsam fange ich an über eine Neuinstallation nachzudenken evtl. mit 'nem externen Modem, obwohl die ISDN/DSL Kombi ganz praktisch ist.
 
A

Anonymous

Gast
Hast Du das denn mal ausprobiert?
Code:
watch -n 1 netstat -pantou

Ich hab mir das in einem Beobachtungsfenster geöffnet, und jedesmal wenn ohne erkennbaren Anlass verbunden wurde, hab ich die Verbindung manuell abgeschossen. So erkennst Du zumindest, welche Dienste am Verbindungsaufbau beteiligt sind.


Gruß
 
OP
P

pft

Advanced Hacker
sorry dass ich noch nicht explizit darauf eingegangen bin.
ja ich habe es versucht. Da war aber absolut nichts zu sehen ausser am Anfang amavis, den ich aber jetzt still gelegt habe.

Das macht mir echt Sorgen! Daher der Gedanke an Neuinstallation bzw. den Versuch mit 'nem externen Router.

der Vorteil wäre dass man mit ethereal die Schnittstelle überwachen kann das sie dauerhaft aktiv ist was beim Modem bzw. der internen Karte nicht geht. Zumindest ist das mein Erfahrung aus der Prä-DSL-, also ISDN-Zeit.

Der momentane Stand ist dass das alles sehr wenig deterministisch ist. Es werden aber hin und wieder (derzeit wenig regelmäßig) verbindungen aufgebaut und der Abbau passiert auch oft sehr spät.
Vor allem änderte sich das verhalten ohne dass ich eine klare Korrelation zu meinen Veränderungen herstellen konnte.
 
Oben