sendto returned: Network is down
Ich versuche schon seit längerer Zeit, einen DSL-Zugang fehlerfrei zum Laufen zu bringen. Inzwischen bin ich bei Kernel 2.4.20 angekommen (dieses RPM-Paket aus dem personenenbezogenen Bereich von SuSE), und ich habe einen Fehler in einem selbstgeschriebenen Programm gefunden, das in einer zunehmenden Anzahl von Instanzen "busy waiting" betrieb. Nun geht es tagelang gut, bis mal wieder keine Verbindung zustande- kommt. Unten habe ich angefügt, was /var/log/messages sagt. Nach einem "rcnetwork dsl0 restart" geht alles wieder. Hat jemand eine Ahnung, wo das Problem liegen könnte? Version: 8.1 original, aber mit Kernel 2.4.20 Jochen Auschnitt /var/log/messages: Jun 25 07:00:00 fw2 /USR/SBIN/CRON[4950]: (root) CMD ( /usr/sbin/uucico -S shuttle) Jun 25 07:00:02 fw2 pppd[19423]: Starting link Jun 25 07:00:02 fw2 pppd[19423]: Sending PADI Jun 25 07:00:02 fw2 pppd[19423]: sendto returned: Network is down Jun 25 07:00:32 fw2 last message repeated 4 times Jun 25 07:01:04 fw2 pppd[19423]: sendto returned: Network is down Jun 25 07:02:08 fw2 pppd[19423]: sendto returned: Network is down Jun 25 07:04:16 fw2 pppd[19423]: sendto returned: Network is down Jun 25 07:08:32 fw2 pppd[19423]: sendto returned: Network is down Jun 25 07:17:04 fw2 pppd[19423]: sendto returned: Network is down Jun 25 07:30:00 fw2 /USR/SBIN/CRON[5001]: (root) CMD ( /usr/sbin/uucico -S shuttle) Jun 25 07:34:08 fw2 pppd[19423]: sendto returned: Network is down Jun 25 07:34:08 fw2 pppd[19423]: Connecting PPPoE socket: 00:90:1a:10:11:bf 0000 eth0 0x8088150 Jun 25 07:34:08 fw2 pppd[19423]: Couldn't get channel number: Transport endpoint is not connected Jun 25 07:34:08 fw2 pppd[19423]: Doing disconnect Jun 25 07:34:08 fw2 pppd[19423]: sendto returned: Network is down Man beachte, daß die Sache 07:00 und 07:30 verschieden aussieht. Das wiederholt sich dann so jede Stunde. Am Abend zuvor sah es dagegen so aus (und ging): Jun 24 19:30:00 fw2 /USR/SBIN/CRON[3755]: (root) CMD ( /usr/sbin/uucico -S shuttle) Jun 24 19:30:01 fw2 pppd[19423]: Starting link Jun 24 19:30:01 fw2 pppd[19423]: Sending PADI Jun 24 19:30:02 fw2 pppd[19423]: HOST_UNIQ successful match Jun 24 19:30:02 fw2 pppd[19423]: HOST_UNIQ successful match Jun 24 19:30:02 fw2 pppd[19423]: Got connection: 1182 Jun 24 19:30:02 fw2 pppd[19423]: Connecting PPPoE socket: 00:90:1a:10:11:bf 8211 eth0 0x8088150 Jun 24 19:30:02 fw2 pppd[19423]: Connect: ppp0 <--> eth0 Jun 24 19:30:02 fw2 pppd[19423]: Setting MTU to 1492. Jun 24 19:30:02 fw2 pppd[19423]: Couldn't increase MRU to 1500 Jun 24 19:30:02 fw2 pppd[19423]: Setting MTU to 1492. Jun 24 19:30:02 fw2 pppd[19423]: Setting MTU to 1492. Jun 24 19:30:02 fw2 pppd[19423]: Couldn't increase MRU to 1500 Jun 24 19:30:02 fw2 pppd[19423]: Setting MTU to 1492. Jun 24 19:30:03 fw2 pppd[19423]: Setting MTU to 1492. Jun 24 19:30:03 fw2 pppd[19423]: Couldn't increase MRU to 1500 Jun 24 19:30:03 fw2 pppd[19423]: Setting MTU to 1492. Jun 24 19:30:03 fw2 pppd[19423]: Couldn't increase MRU to 1500 Jun 24 19:30:04 fw2 pppd[19423]: Open TCP 194.95.225.8:1678 -> 194.95.249.247:540 Jun 24 19:30:05 fw2 modify_resolvconf: Service pppd tried to modify resolver configuration, but it Jun 24 19:30:05 fw2 modify_resolvconf: was not modified due to MODIFY_RESOLV\NAMED_CONF_DYNAMICALLY=no Jun 24 19:30:05 fw2 pppd[19423]: Script /etc/ppp/ip-up finished (pid 3779), status = 0x0 Jun 24 19:35:08 fw2 pppd[19423]: Terminating connection due to lack of activity. Jun 24 19:35:09 fw2 pppd[19423]: Setting MTU to 1492. Jun 24 19:35:09 fw2 pppd[19423]: Couldn't increase MRU to 1500 Jun 24 19:35:09 fw2 pppd[19423]: Connection terminated. Jun 24 19:35:09 fw2 pppd[19423]: Connect time 5.1 minutes. Jun 24 19:35:09 fw2 pppd[19423]: Sent 35289794 bytes, received 76524399 bytes. Jun 24 19:35:09 fw2 pppd[19423]: Doing disconnect Jun 24 19:35:09 fw2 modify_resolvconf: Service pppd tried to modify resolver configuration, but it Jun 24 19:35:09 fw2 modify_resolvconf: was not modified due to MODIFY_RESOLV\NAMED_CONF_DYNAMICALLY=no Jun 24 19:35:09 fw2 pppd[19423]: Script /etc/ppp/ip-down finished (pid 3806), status = 0x0 Wo und wie man diese Meldung mit dem "modify_resolvconf" loswerden kann, habe ich auch noch nicht herausgefunden, aber das wird hier wohl keine Rolle spielen.
Jochen Roedenbeck wrote:
Hat jemand eine Ahnung, wo das Problem liegen könnte?
Die 24h Zwangstrennung vom Provider sorgt manchmal bei mir dafuer, das der pppd nur noch "pppd[123]: tcflush failed: Input/output error" und "pppd[123]: Exit." meldet und die DoD-Geschichte dann natuerlich nicht mehr fluppt. Ein /etc/init.d/network start sorgt dann auch dafuer, das alles wieder geht. Peter
Peter Wiersig schrieb:
Die 24h Zwangstrennung vom Provider sorgt manchmal bei mir dafuer, das der pppd nur noch "pppd[123]: tcflush failed: Input/output error" und "pppd[123]: Exit." meldet und die DoD-Geschichte dann natuerlich nicht mehr fluppt.
Das war es bei mir nicht, da ich ein Timeout von 5 min eingestellt habe, auch stürzt der pppd nicht ab, sondern funktioniert einfach nicht mehr. Irgendwie könnte aber dieselbe Ursache dahinterstecker, ich wüßte aber nicht, wo man suchen kann. Ich habe an anderer Stelle noch ein Problem, das hier vielleicht dazupaßt: Dort wartet ein selbstgeschriebener Server auf TCP-Ver- bindungen. Die Clients öffnen eine Verbindung, es werden einige Bytes hin- und herübertragen, und die Verbindung wird wieder ge- schlossen. Bei der alten SuSE-Version 7.* funktionierte das ein- wandfrei. Mit der 8.1 geht es einige Zeit, und dann können keine Verbindungen mehr aufgebaut werden, oder aufgebaute Verbindungen werden nicht wieder abgebaut. Bei meinem DSL-Problem kommt nach einiger Zeit keine Verbindung mehr zustande. Bei dem obigen 24h-Problem scheint das Schreiben auf irgendeinen Dateideskriptor nicht mehr möglich zu sein. Merkwürdig ist bei mir auch, daß immer wieder eine Meldung in /var/log/messages auftaucht, daß die Kernel-Symbole geladen worden seien, ohne daß anschließend eine OOPS-Meldung oder so etwas kommt. Das war schon beim Kernel 2.4.19 so.
Ein /etc/init.d/network start sorgt dann auch dafuer, das alles wieder geht.
Und ich nehme rcnetwork dsl0 restart, was auf dasselbe hinauslaufen dürfte. Jochen
participants (2)
-
Jochen Roedenbeck -
Peter Wiersig