Suse: 9.2 Dsl Verbindung wird gekappt....

Hallo,

was passiert wenn du
ping -c10 194.25.2.129 &&ifconfig dsl0
machst

So kommt dieses aber denke eher du meintest du Ausgabe wenn ich keine Verbindung habe oder???
Werd ich dann nochmal probieren und posten... Wie gesagt, tritt halt zufällig auf.

linux:/home/jessi # ping -c10 194.25.2.129 && ifconfig dsl0
PING 194.25.2.129 (194.25.2.129) 56(84) bytes of data.
64 bytes from 194.25.2.129: icmp_seq=1 ttl=60 time=1138 ms
64 bytes from 194.25.2.129: icmp_seq=2 ttl=60 time=1251 ms
64 bytes from 194.25.2.129: icmp_seq=5 ttl=60 time=1309 ms

--- 194.25.2.129 ping statistics ---
7 packets transmitted, 3 received, 57% packet loss, time 6035ms
rtt min/avg/max/mdev = 1138.936/1233.331/1309.560/70.843 ms, pipe 2
dsl0      Link encap:Point-to-Point Protocol  
          inet addr:84.137.155.246  P-t-P:217.0.116.109  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1492  Metric:1
          RX packets:104577 errors:0 dropped:0 overruns:0 frame:0
          TX packets:111500 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:3
          RX bytes:33900358 (32.3 Mb)  TX bytes:18190946 (17.3 Mb)

Hallo,

genau wenn die Verbindung abbricht dann mal testen oder hast du ein Timeout eingestellt bei der DSL-Verbindung?

Ne, hab ich eben nicht... sonst würd mich das ja nicht wundern...
glaube aber nun zu wissen welche Prozess das ist, so dass ich ihn wieder anstellen kann, falls er nicht da ist... muss ich erstmal wieder abwarten...

bisher war es noch nicht wieder...

Autoreconnect, unter Suse funktioniert das z.b. wie folgt:

1. Neue Sitzung starten als root
2. begib dich nach /etc/sysconfig/network/providers und oeffne die konfigurationsdatei z.B.(" tonline-dsl ") z.b. mit Kate und fuege den Eintrag

AUTO_RECONNECT='yes'

hinzu.

die Verbindung wird eigentlich nur bei Untätigkeit, in der Regel nach ca. 15 Minuten, unterbrochen.

Zwei weitere Möglichkeiten sehe ich da noch um ständig eine Verbindung zu haben.

1. Dial on Demand  aktivieren. Dann wird automatisch bei Anforderungen ans Internet die Verbindung wieder hergestellt.

Oder man greift ein wenig in die Tickkiste. Schreibe Dir ein Script ( beispielsweise nodslstop ) mit einem Editor. Kopiere es nach /usr/local/bin und mache es ausführbar mit:

chmod a+x /usr/local/bin/nodslstop


Scriptinhalt z.B.

#!/bin/bash

ping -c3 suse.de


Das Script lässt Du alle fünf Minuten durch einen Cronjob aufrufen (einrichten mit  Kcron )und gaukelst dem System damit permanente Internetaktivität vor.

3. Internetverbindung beim Booten starten aktivieren,

Viel Erfolg

Also erstens:

mit ping -c10 usw.
kommt network is unreachable
War ja zu erwarten...

folgende einträge fehlen in meiner Prozessliste wenn keine Verbindung besteht:
3061 ?        Ss     0:00 /usr/sbin/smpppd-ifcfg --up --rc -i ifcfg-dsl0
 3143 ?        Ss     0:00  \_ /usr/sbin/pppd logfd 7 call pppoe eth0 mtu 1492 mru 1492 ipcp-accept-local ipcp-accept-remote idle 0 defaultroute replacedefaultroute nodetach


Dachte auch erst wegen inaktivität...
Ich kann aber drei stunden keinen browser, e-mail oder sonstiges aufhaben, dann browser starten und alles geht... Kann aber auch gesurft haben und im nächsten Moment ist es weg.. Deswegen kann ich mir nicht vorstellen das es mit inaktivität zusammenhängt

Das Problem besteht teilweise immer nocht...

Mit folgendem Aufruf kann ich die Verbindung wieder herstellen...

/usr/sbin/smpppd-ifcfg --up --rc -i ifcfg-dsl0

Allerdings hält es mal länger und mal kürzer an, bis wieder gekappt wird...

Den Eintrag in meiner Provider Datei hab ich gemacht...

Ich kann auch grad am surfen sein und auf mal is die Verbindung weg... Kann doch nicht sein sowas.. macht mich noch ganz verrückt....

Das ist das Problem:

May 20 19:42:29 linux pppd[10205]: No response to 4 echo-requests
May 20 19:42:29 linux pppd[10205]: Serial link appears to be disconnected.
May 20 19:42:29 linux pppd[10205]: Couldn't increase MTU to 1500
May 20 19:42:29 linux pppd[10205]: Couldn't increase MRU to 1500
May 20 19:42:29 linux modify_resolvconf: restored /etc/resolv.conf.saved.by.pppd.dsl0 to /etc/resolv.conf
May 20 19:42:30 linux pppd[10205]: Script /etc/ppp/ip-down finished (pid 15611), status = 0x0
May 20 19:42:33 linux pppd[10205]: Connection terminated.
May 20 19:42:33 linux pppd[10205]: Connect time 87.0 minutes.
May 20 19:42:33 linux pppd[10205]: Sent 29844792 bytes, received 28874745 bytes.
May 20 19:42:33 linux pppd[10205]: Connect time 87.0 minutes.
May 20 19:42:33 linux pppd[10205]: Sent 29844792 bytes, received 28874745 bytes.
May 20 19:42:33 linux pppd[10205]: Exit.


Ich meine des hängt mit LCP zusammen, was auch immer das genau ist.
Laut O'Reilly:
Schließlich gibt es noch zwei Optionen, die sich mit LCP-Echo-Nachrichten beschäftigen. PPP definiert zwei besondere Nachrichten: Echo Request und Echo Response. pppd verwendet diese, um zu prüfen, ob der Link noch funktioniert. Sie aktivieren diese Option durch lcp-echo-interval und die Angabe einer Zeit in Sekunden. Werden vom entfernten Host innerhalb dieser Zeitspanne keine Frames empfangen, erzeugt pppd einen Echo Request und erwartet, daß die Gegenseite mit einer Echo Response antwortet. Erfolgt von der Gegenstelle keine Antwort, wird die Verbindung nach einer bestimmten Anzahl von Versuchen unterbrochen. Diese Anzahl können Sie mit der Option lcp-echo-failure bestimmen. Per Standardeinstellung ist dieses Feature deaktiviert.
(http://www.oreilly.de/german/freebooks/linag2/netz0806.htm)

Da das Standardmäßig deaktiviert ist, müsste man das deaktivieren können.. In der /etc/ppp/options steht folgendes dazu:

# If this option is given, pppd will send an LCP echo-request frame to
# the peer every n seconds. Under Linux, the echo-request is sent when
# no packets have been received from the peer for n seconds. Normally
# the peer should respond to the echo-request by sending an echo-reply.
# This option can be used with the lcp-echo-failure option to detect
# that the peer is no longer connected.
lcp-echo-interval 30

# If this option is given, pppd will presume the peer to be dead if n
# LCP echo-requests are sent without receiving a valid LCP echo-reply.
# If this happens, pppd will terminate the connection.  Use of this
# option requires a non-zero value for the lcp-echo-interval parameter.
# This option can be used to enable pppd to terminate after the physical
# connection has been broken (e.g., the modem has hung up) in
# situations where no hardware modem control lines are available.
lcp-echo-failure 4

# Send up to 60 LCP configure-request during negotiation. With a value
# of 2 for lcp-restart below, this might take up to 2 minutes.
lcp-max-configure 60

# Resend unanswered LCP requests after 2 seconds.
lcp-restart 2

# Specifies that pppd should disconnect if the link is idle for n seconds.
idle 600


Zu MTU und MRU:

# Set the MRU [Maximum Receive Unit] value to <n> for negotiation.  pppd
# will ask the peer to send packets of no more than <n> bytes. The
# minimum MRU value is 128.  The default MRU value is 1500.  A value of
# 296 is recommended for slow links (40 bytes for TCP/IP header + 256
# bytes of data). The value 1492 is for DSL connections (PPP Default -
# PPPoE Header: 1500 - 8 = 1492)
# mru 1492

# Set the MTU [Maximum Transmit Unit] value to <n>. Unless the peer
# requests a smaller value via MRU negotiation, pppd will request that
# the kernel networking code send data packets of no more than n bytes
# through the PPP network interface. The value 1492 is for DSL connections
# (PPP Default - PPPoE Header: 1500 - 8 = 1492)
# mtu 1492

Was sollte ich ändern?
Vorschläge?