FBF 7050 trennt ständig Internetverbindung

[dummuser]

Warum die Telekom die Leitungen unterbricht, darüber gibt es noch nicht einmal Vermutungen. Will sie vielleicht Fremd-VoIP stören?

Unwahrscheinlich - sie stören damit ja auch ihr eigenes VoIP-Angebot. Die (fast schon historischen) Gründe für diese Trennung sind ganz einfach die Einsparung einiger IP-Adressen sowie die Unterbindung von Serverdiensten, die ohne die Trennung dauerhaft unter einer festen IP erreichbar wären. (Ja, es gibt die automatische Wiedereinwahl - aber die haben ja nicht alle angewählt und ja, es gibt DynDNS und nein, handfeste Beweise für exakt diese Gründe der Zwangstrennung kann ich gerade nicht vorlegen, meine aber, das mal in irgendeiner Newsgroup gelesen zu haben.)

Wenn die Verbindung von der Vermittlung abgebrochen wird, baut sie sie keineswegs wieder auf.

Warum sollte sie das auch tun, wenn sie sie gerade selbst absichtlich unterbrochen hat?

Übrigens ist das ein weiterer Vorteil von News: Dort gibts keine Zensur.

Diese Zensur-Debatte hat mal wieder sooooo einen Bart. Das ist übrigens ein Nachteil von News: Dort wird es ziemlich schnell OT und man sucht sich einen Wolf, um aus dem ganzen Gesülze wenigstens etwas an Information rauszufischen...

Ich bitte übrigens explizit um Löschung des letzten Absatzes nach Kenntnisnahme durch den ippmaten.

 

[antje.susann]

Hallo Community
ich habe den Thread durchgelesen und möchte auch mal meinen Senf dazugeben.
Das gleiche Problem mit dem Trennen der Internetleitung trotz stabiler DSL Verbindung habe ich auch.
Mir ist das Problem mit der Fritz!Box 7050 Version 14.04.31 so richtig aufgefallen, kann aber bei der 14.04.26 auch schon gewesen sein.
Für mich ist allerding dieses jetzt soweit problematisch, da ich remote auf meinen Rechner zugreifen möchte und die DynDns Provider diese IP-Wechsel so oft nicht mitmachen.

Hier jetzt mein bisheriger Leidensweg

Fehlersuche :

1. Log meine Fritz!Box

06.04.07 02:13:20 Internetverbindung wurde erfolgreich hergestellt.
IP-Adresse: 91.10.15.197, DNS-Server: 217.237.151.115 und
217.237.150.51, Gateway: 217.0.118.28

06.04.07 02:13:20 Internetverbindung wurde getrennt.

06.04.07 01:57:08 Internetverbindung wurde erfolgreich hergestellt.
IP-Adresse: 91.10.16.10, DNS-Server: 217.237.151.115 und
217.237.150.51, Gateway: 217.0.118.28

06.04.07 01:57:07 Internetverbindung wurde getrennt.

06.04.07 01:13:48 Internetverbindung wurde erfolgreich hergestellt.
IP-Adresse: 91.10.19.162, DNS-Server: 217.237.151.115 und
217.237.150.51, Gateway: 217.0.118.28

…

2. T-Com angerufen

Fehlerbeschreibung mitgeteilt:
T-Com hat Leitung gemessen und keinen Fehler festgestellt. Ebenso haben Sie mir versichert, dass sie die Leitung nicht unterbrechen.
Ist ja auch aus DSL Sicht nur bei einer Störung notwendig (z.B. Sync Verlust oder kein Reply).
Hierzu muss ich auch sagen, dass ich meinen Anschluss nicht verkauft habe und mein Provider ist Congster.

3. Jetzt an AVM eine Fehlermeldung geschickt.
Trennung der Verbindung auf PPP Ebene DSL ist stabil.
Es hat dann ca. 2 Tage gedauert bis AVM reagiert hat und von mir weitere Logs haben wollte
- Statuslog der Fritzbox
- DSL Mitschnitt
- Screenshots der DSL Eigenschaften (SR bzw Dämpfung)

Dann hat es wieder ca. 2 Tage gedauert bis ich was von AVM hörte.

Diese Trennung wird ohne ersichtlichen Grund von Ihrer Gegenstelle
eingeleitet. Den Grund für die Trennung auf PPP Ebene liegt ausserhalb der
FRITZ!Box und den Grund können wir somit leider nicht ermitteln.

4. Provider Fehlermeldung
Ich habe dann meinem Internetprovider eine Mail geschrieben.

Congster hat mir dann versichert, dass sie mit der Trennung nicht zu tun haben. Es erfolgt lediglich eine 24h Trennung!

5. Weitere Provider ausprobiert.

Ich habe mir dann noch Zugangsdaten von T-Online besorgt. --> gleicher Fehler
Zugangsdaten von Freenet. --> gleicher Fehler

6. Weitere Meldung an AVM

Da meinen Fehlersuche auf PPP Ebene durch die Einwahlserver der obigen Provider doch etwas ist 'stocken' geraten ist, habe ich AVM meine Ergebnisse mitgeteilt.
AVM hat dann wieder nach 2 Tagen geantwortet

wie ich Ihnen schon mitteilte wurde diese Trennung von Ihrem Anbieter
ausgelöst. Warum ist im Mitschnitt nicht erkennbar. Den Grund kann Ihnen
nur Ihr Anbieter selbst nennen. Im Mitschnitt ist jedoch ersichtlich das
diese Trennung ziehmlich exakt nach 15 Minuten Inaktivität vorgenommen
wurde, was vermuten lässt das der Provider auf Grund von Inaktivität die
PPP-Verbindung trennt. Näherer Informationen sollten Ihnen Ihr Anbieter
dazu geben können.

7. Frustration

AVM :
Von welchen 15 Minuten der AVM Mann hier gesprochen hat, konnte ich nicht nachvollziehen.
Die Trennung ist eher sporadisch. Ebenso ist er überhaupt nicht auf meine Ergebnisse der DSL Provider eingegangen.
Ich habe mir dann den Paketmitschnitt auch einmal angeschaut. Es kommt tatsächlich von extern ein PADT welches die PPP Verbindung trennt.
So die Optionen sind jetzt schon weniger

8. T-Com

Ich habe dann irgendwo im Inet gelesen, dass sich DSL Ports gegenseitig stören sollten (z.B. DSL 16000).
Also habe ich erneut ein Ticket bei der T-Com eröffnet.
Die T-Com ist ja bei Support schon fantastisch. Das Ticket habe ich via Internet angelegt. Nach etwas 30 Minuten bekam ich einen Rückruf.
Ich habe dann den T-Com Mitarbeiter meinen ganzen bisherigen Leidensweg geschildert. Diese hat mir dann versichert, dass die T-Com den Anschluss nicht trennen würde. Die Leitung ist in Ordnung und auch der Ports in der Vermittlungsstelle schaut i.O. aus. Aber er schickt mir einen Techniker vorbei und schaltet mich auch auf einen anderen Port. Nach etwa 1h hat es dann tatsächlich an meiner Tür geklingelt (starke Leistung). Der Techniker hat sich meine Verkabelung angesehen. --> Alle gemessen Werte waren gut bis sehr gut. Dann ist er in die Vermittlungsstelle gefahren und hat mich auf einen anderen DSL-Port geschalten. Leider war auch diese Aktion nicht von Erfolgt gekrönt.

9. Verzweiflung

Ich war schon jetzt drauf und dran mich meinem Schicksal zu ergeben.
Ich habe dann durch Zufall in meinem Keller eine DSL Modem (Teledat 330) entdeckt.
Da mein Anschluss ein DSL6000 ist, und das DSL Modem bis 8Mbit freigegeben ist, wollte ich einfach die Fritz!Box durch das DSL Modem ersetzten und den PC die PPP Verbindung aufbauen lassen. Mir ist dann noch die Idee mit dem LAN A gekommen (Abschaltung des internen FritzBox-Modems).

Jetzt kommt’s: der Fehler ist weg!!!!!!!

10. Es sind jetzt so ca. 3 Wochen vergangen. Mir ist auch die Fehlerentstehung nicht klar (PPP) Verbindung und DSL (PAPT).

Alles weitere ist nur eine Vermutung:
Das DSL Modem in der Fritz!Box ist defekt oder aber ein Fehler in der Firmware ist das Problem. Es wird ein Fehler (welcher im Mitschnitt nicht sichtbar ist)
durch das interne DSL Modem verursacht. Diese wird dann durch die Vermittlungsstelle mit einem PADT beantwortet.. ???


11. AVM
Ich habe AVM jetzt meine Erkenntnisse geschickt.
Dies möchte ich jetzt nicht weiter kommentieren.
Vielleicht hat ja von Euch Jemand Lust hierzu noch etwas zu sagen.

Sie wandten sich wegen Trennungen der PPP-Verbindung (nicht zu verwechseln mit der eigentlichen DSL-Verbindung) an uns. Diese finden eine Ebene höher statt und haben nichts mit der eigentlich vorliegenden DSL-Synchronisation zutun. Bei der Suche der Ursache für diese PPP-Trennungen helfen auch keine Messungen der DSL-Leitung und DSL-Portwechsel, sondern nur ein Mitschnitt auf PPP-Ebene bzw. das Anschauen der Log-Files vom Einwahlserver.

Die im eingesandten Trace enthaltene Trennung auf PPP-Ebene wurde defintiv durch Ihren Einwahlserver ausgelöst und der Grund ist von Seiten der FRITZ!Box nicht ersichtlich. Die Ursache der Trennung auf PPP-Ebene kann hier nur durch einen Trace auf Seite des Einwahlservers oder der Einsicht der Log-Files vom Einwahlserver ermittelt werden.

Es muss hier also zwischen Trennungen der DSL-Synchronisation und Trennungen der PPP-Verbindung unterschieden werden, welche von Ihnen jedoch vermischt werden. Trennungen der DSL-Synchronisation waren unter dieser Ticket-ID bisher kein Bestandteil der Kommunikation, sondern ausschliesslich die Trennung auf PPP-Ebene.

Sollten Sie hier von einem Defekt der FRITZ!Box ausgehen, so kann ich gerne einen Austasuch einleiten. Ich gehe jedoch davon aus, dass dieser am Verhalten der PPP-Trennungen nichts bewirken wird und das Problem somit fortbesteht.

Um einen Austausch auslösen zu können, benötige ich die vollständige Seriennummer Ihrer FRITZ!Box (vom Aufkleber auf der Geräteunterseite) sowie Ihren Vor- und Nachnamen, Ihre Adresse und Telefonnummer mit, damit ich den Versand eines Austauschgerätes an Sie veranlassen kann.

Viele Grüße
Antje

 

[speedocom]

Hallo,

also ich könnte wetten das hängt mit dem Firmware Update auf die
.31 zusammen.
Auch bei mir mit einer 7050 und 5050 dieselben Probleme, immer wieder
SYNC Verlust.
Laut AVM soll ich die Kabel überprüfen.
Ich echt der Witz das Teil läuft Jahre stabil und dann kommt die Firmware und alles ist hin.
Wenn AVM wenigstens den Fehler eingestehen würde.

Mit der Hoffnung auf baldige Besserung.
Gruss
Flo

 

[frank_m24]

Hallo,

lasst euch von der T-Com oder von Congster nichts erzählen: Es sind eindeutig Trennungen nach 15 Minuten Inaktivität. Deshalb treten die Trennungen auch sporadisch auf, weil Inaktivität auch durch ungewollte Pakete von außen unterbrochen wird. Bei der Aktivität, die Viren wie Sasser oder Lovesan da draußen noch immer entwickeln, kommt man nicht andauernd auf 15 Minuten Inaktivität.

Laaange Analysen mit Wireshark, Paketmittschnitten etc. belegen eindeutig (u.a. auch von mir), dass AVM recht hat: Es sind Inaktivitätstimeouts. In den Logs der Box erkennt man es daran, dass schon 1 oder 2 Sekunden nach Abbruch die Verbindung wieder aufgebaut wird. Dauert es länger als 5 Sekunden, so kommen andere Ursachen in Frage.
Und es ist absolut unabhängig von der Firmware, tritt nämlich regelmäßig auf, seit die T-Com auf ADSL2 aufrüstet.
Siehe auch:
7050 trennt ständig DSL Verbindung -> gelöst mit 14.04.25
Überregionles Problem mit Verbindungsabbrüchen in einigen T-Com Subnetzen?

@speedocom: Sync Probleme haben mit diesem Problem absolut gar nichts zu tun. Das steht auch schon ziemlich oft hier. Du solltest dich hier mal umsehen: http://www.ip-phone-forum.de/showthread.php?t=86116

Viele Grüße

Frank

 

[antje.susann]

Hallo,

also Sync Probleme haben mit dem Thread rein gar nichts zu tun.
Auch habe ich die Firmware auf 14.04.26 ausprobiert. Hier war auch der Fehler da. --> evtl wäre eine noch ältere zu testen?
@frank_m24
Ich tippe nach wie vor auf das interne DSL Modem.
Mit einem externen DSL Modem an LAN A ist der Fehler definitiv weg.
So ist es auf jeden Fall bei mir. Ich empfehle dieses zu testen !
Auch ich habe einen DSL Mitschnitt in dem der vermeindliche PADT von der Vermittlungsstelle kommt. Dies hat bei mir aber nichts zu sagen.
Bitte meinen obigen Beitrag auch lesen.


mfg
Antje

 

[frank_m24]

Hallo,

@antje.susann: Nein, es hat auch nichts mit dem externen DSL Modem zu tun. Lies die verlinkten Beiträge, unter dem Phänomen leiden Fritzboxen Besitzer genau so, wie Leute mit anderen DSL Modems oder Fritzboxen.
Entweder hast du durch das Umstellen auf "Internet über LAN A" in der Fritzbox etwas ausgelöst, was regelmäßigen Traffic erzeugt, so dass die 15 Minuten Inaktivität nicht mehr zusammen kommen ("Portweiterleitungen des Internetrouters für VoIP offenhalten" z.B.), oder es wurde etwas im PPP Server des Providers verändert.

Viele Grüße

Frank

 

[antje.susann]

Hallo,
ich beschäftige mich immer noch mit dem Problem.
Ich habe nochmals um eine Klärung mit AVM gebeten.
Die Ergebnisse habe ich denen geschickt:
-support_config funktionierend
-support_config Trennung
-mitschnitt Trennung

Leider will wohl AVM nicht?


Ich habe mal einen Mitschnitt angehängt.
Fakt ist auf jeden Fall:
Fritzbox mit internen Modem --> Trennung der Verbindung
Fritzbox mit externen Modem --> keine Trennung.

Es ist auch kein anderer Traffic mit dem externen Modem vorhanden.
Somit gibt es keine andere Möglichkeit
a) Fritzbox defekt
b) generelles Problem mit AVM DSL Modems
c) ich bin wahnsinning

Sollte jemand auch eine AVM FritzBox oder Derivat besitzen, so würde ich Mal mit einem anderen DSL Modem probieren.(nur der den Fehler hat)

Antje



AVM

Ich kann an der Stelle nicht beurteilen ob andere Provider bei Ihnen auch
über einen anderen Breitband-POP geroutet werden. Wie ich Ihnen auch schon
mitteilte, wurde die eine mitgeschnittene Trennung durch Ihre Gegenstelle
ausgelöst (LC Termination Request #394). Wieso ist von unserer Seite aus
(also auf Seiten der FRITZ!Box) nicht erkennbar und auch nicht ermittelbar.
Die zuvor stattgefundene LCP-Kommunikation sieht auf unserer Seite sauber
aus. Also mit anderen Worten, die eine Trennung die mir hier zur Diagnose
vorlag, liegt ausserhalb des Einflussbereichs der FRITZ!Box. Ich kann hier
jedoch nicht beurteilen wie es sich bei allen anderen Trennungen verhält,
da hier nur eine Trennung zur Einsicht vorlag.

Über die anderen von Ihnen durchgeführten Aktionen liegen mir keinerlei für
den Support verwertbare Daten vor. Ich als Supporter kann hier nur die
Daten auswerten, welche mir vorliegen. Und in den mir vorliegenden
Informationen ist kein Fehlverhalten der FRITZ!Box erkennbar.

Ein generelles Problem dieser Art unter Verwendung der Firmwareversion
14.04.30/31 liegt ebenfalls nicht vor.

Log:
No. Time Source Destination Protocol Info
253 2007-04-24 05:47:21.974884 00:19:e8:6e:76:31 Avm_64:0c:60 PPP LCP Echo Request
254 2007-04-24 05:47:21.974884 Avm_64:0c:60 00:19:e8:6e:76:31 PPP LCP Echo Reply
255 2007-04-24 05:47:29.944958 Avm_64:0c:60 00:19:e8:6e:76:31 PPP LCP Echo Request
256 2007-04-24 05:47:29.964884 00:19:e8:6e:76:31 Avm_64:0c:60 PPP LCP Echo Reply
257 2007-04-24 05:47:39.944942 Avm_64:0c:60 00:19:e8:6e:76:31 PPP LCP Echo Request
258 2007-04-24 05:47:39.964884 00:19:e8:6e:76:31 Avm_64:0c:60 PPP LCP Echo Reply
259 2007-04-24 05:47:49.944989 Avm_64:0c:60 00:19:e8:6e:76:31 PPP LCP Echo Request
260 2007-04-24 05:47:49.964884 00:19:e8:6e:76:31 Avm_64:0c:60 PPP LCP Echo Reply
261 2007-04-24 05:47:51.994884 00:19:e8:6e:76:31 Avm_64:0c:60 PPP LCP Echo Request
262 2007-04-24 05:47:51.994884 Avm_64:0c:60 00:19:e8:6e:76:31 PPP LCP Echo Reply
263 2007-04-24 05:47:59.944942 Avm_64:0c:60 00:19:e8:6e:76:31 PPP LCP Echo Request
264 2007-04-24 05:47:59.964884 00:19:e8:6e:76:31 Avm_64:0c:60 PPP LCP Echo Reply
265 2007-04-24 05:48:08.914884 00:19:e8:6e:76:31 Avm_64:0c:60 PPP LCP Termination Request
266 2007-04-24 05:48:08.914884 00:19:e8:6e:76:31 Avm_64:0c:60 PPPoED Active Discovery Terminate (PADT)
267 2007-04-24 05:48:08.914884 Avm_64:0c:60 00:19:e8:6e:76:31 PPP LCP Termination Ack
268 2007-04-24 05:48:08.926279 Avm_64:0c:60 00:19:e8:6e:76:31 PPPoED Active Discovery Terminate (PADT)
269 2007-04-24 05:48:08.945327 Avm_64:0c:60 Broadcast PPPoED Active Discovery Initiation (PADI)
270 2007-04-24 05:48:09.004884 00:19:e8:6e:76:31 Avm_64:0c:60 PPPoED Active Discovery Offer (PADO)
271 2007-04-24 05:48:09.022343 Avm_64:0c:60 00:19:e8:6e:76:31 PPPoED Active Discovery Request (PADR)
272 2007-04-24 05:48:09.044884 00:19:e8:6e:76:31 Avm_64:0c:60 PPPoED Active Discovery Session-confirmation (PADS)
273 2007-04-24 05:48:09.062680 Avm_64:0c:60 00:19:e8:6e:76:31 PPP LCP Configuration Request
274 2007-04-24 05:48:09.084884 00:19:e8:6e:76:31 Avm_64:0c:60 PPP LCP Configuration Request
275 2007-04-24 05:48:09.084884 00:19:e8:6e:76:31 Avm_64:0c:60 PPP LCP Configuration Ack
276 2007-04-24 05:48:09.084884 Avm_64:0c:60 00:19:e8:6e:76:31 PPP LCP Configuration Ack
277 2007-04-24 05:48:09.100762 Avm_64:0c:60 00:19:e8:6e:76:31 PPP LCP Discard Request
278 2007-04-24 05:48:09.100909 Avm_64:0c:60 00:19:e8:6e:76:31 PPP PAP Authenticate-Request
279 2007-04-24 05:48:09.184884 00:19:e8:6e:76:31 Avm_64:0c:60 PPP PAP Authenticate-Ack
280 2007-04-24 05:48:09.184884 00:19:e8:6e:76:31 Avm_64:0c:60 PPP IPCP Configuration Request
281 2007-04-24 05:48:09.197936 Avm_64:0c:60 00:19:e8:6e:76:31 PPP IPCP Configuration Request
282 2007-04-24 05:48:09.184884 Avm_64:0c:60 00:19:e8:6e:76:31 PPP IPCP Configuration Ack
283 2007-04-24 05:48:09.224884 00:19:e8:6e:76:31 Avm_64:0c:60 PPP IPCP Configuration Nak
284 2007-04-24 05:48:09.235979 Avm_64:0c:60 00:19:e8:6e:76:31 PPP IPCP Configuration Request
285 2007-04-24 05:48:09.254884 00:19:e8:6e:76:31 Avm_64:0c:60 PPP IPCP Configuration Ack

 

[frank_m24]

Hallo,

Es ist auch kein anderer Traffic mit dem externen Modem vorhanden.

Woher weist du das? Du kannst bei einem extern angeschlossenen Modem ja keinen Paketmittschnitt auf DSL Ebene mehr machen, sondern nur noch auf PPPOE Ebene.

Sollte jemand auch eine AVM FritzBox oder Derivat besitzen, so würde ich Mal mit einem anderen DSL Modem probieren.(nur der den Fehler hat)

Hab ich. Ein Teledat 300 LAN hab ich vor die Box gehängt. Fazit: Kein Unterschied, die Abbrüche treten genau so auf. Ist auch kein Wunder, schließlich werden die Abbrüche von der Gegenseite ausgelöst, und zwar auf PPP Ebene, also im OSI Schichtenmodell in einer Schicht oberhalb des Modems. Damit ist es theoretisch wie praktisch absolut ohne Einfluss auf das Verhalten.

Übrigens hat der angehängte Ausschnitt keinen Wert. Zum einen hat man keine Vergleichsmöglichkeit zwischen Betrieb mit und ohne Modem (kann man als Endnutzer auch nicht anfertigen). Zum anderen wäre es nur interessant, wenn man den kompletten Block zwischen zwei Verbindungsabbrüchen sehen könnte, weil nur dann kann man einschätzen, ob ein Timeout aufgetreten ist, oder eine andere Ursache vorliegt. Der Ausschnitt sieht bei jeder Zwangstrennung vom Provider genau so aus.

Viele Grüße

Frank

 

[Music]

Wirklich interessante Angelegenheit... Ich hänge an einem DSL 6.000 Port, Resale 1und1, und habe diesen Fehler noch nicht bemerkt... Andererseits laufen hier im Netzwerk auch div. Applikationen, die für regelmäßigen Traffic sorgen (zB DynDNS-Check alle 5min etc...)

@Antje: Du kannst ja relativ leicht nachvollziehen, ob das stimmt, was Frank erzählt: Einfach mal das Modem rausnehmen (jetzt müsste es ja wieder zu Abbrüchen kommen) und einen Dauer-Ping auf einen (freundlichen) Host starten... Das geht so: ping -t www.host.de <- hier darfst du dir was aussuchen... Solange der Ping läuft herrscht Aktivität und es gibt keine Abbrüche... Wenn es trotzdem Abbrüche mit dem gleichem Fehlerbild gibt wäre das interessant... Wenn nicht kannst du dein Teledat ja wieder ranhängen, dann ist wirklich davon auszugehen, dass ein 15min Idle-Disconn vorliegt...

-> Interessant wäre wirklich mal die Frage, WARUM das gemacht wird... Gibts da außer der Sache mit den knappen IP-Adressen Spekulationen? Es ist ja außerdem davon auszugehen dass AVM zumindest mal mit der T-Com auf höherer Ebene Kontakt aufnimmt, die werden ja mehr als eine solcher Anfragen im Support reinkriegen nehme ich, wenn die jedesmal kiloweise Logs analysieren dürfen ist das ja auch nicht das wahre...

 

[frank_m24]

Hallo,

Andererseits laufen hier im Netzwerk auch div. Applikationen, die für regelmäßigen Traffic sorgen (zB DynDNS-Check alle 5min etc...)

Damit bist du eigentlich schon aus dem Rennen. 15 Minuten ist der Timeout in allen mir bekannten Fällen.

Interessant wäre wirklich mal die Frage, WARUM das gemacht wird... Gibts da außer der Sache mit den knappen IP-Adressen Spekulationen?

Das habe ich mich auch schon gefragt, vor allem, weil es ja nichts bringt. Router wie die Fritzbox oder Draytek Router bauen die Verbindung sofort nach Verlust wieder auf und belegen damit wieder eine IP-Adresse. Um die Probleme durch Übersprechen zu reduzieren, eignet sich die Methode auch nicht, weil der DSL Sync ja bestehen bleibt.

Übrigens konnte ich anhand meiner Push-Mails ja sehr zuverlässig nachvollziehen, dass diese Abbrüche erst nach Wartungsarbeiten an der Vermittlungsstelle auftraten. Die erkennt man an den stundenlangen PPPOE-Timeouts nachts. Da das genau in die Phase fiel, als die T-Com die Vermittlungsstellen ADSL2 tauglich machte, gehe ich davon aus, das es im Zuge der Umstellung erst eingeführt wurde.

Viele Grüße

Frank

 

[Music]

Hallo Frank,

hm, normalerweise würde ich spekulieren dass die Telekom in der Zukunft irgendwas plant was das nötig / hilfreich macht, da aber DSL eh ne standleitung ist kann ich das absolut nicht nachvollziehen... Selbst die Router von der TCom bauen die Verbindung sofort wieder auf, für die hat es doch auch nur ne höhere Serverlast wenn die ständig neue Verbindungen aufbauen müssen.

Könnte es eine Fehlkonfiguration sein? Dass da irgendwo Timeout 900sek steht und bei der Installation der ADSL2+ Hardware keine 0 gesetzt wurde?

 

[antje.susann]

Hallo Leute,

ich bin jetzt mit meiner Analyse fertig.

Am LAN A habe ich ebenfalls einen Paketmitschnitt gestartet (mit ext. DSL Modem).
Es ist tatsächlich mehr Traffic auf dem Interface vorhanden. Nachvollzogen habe ich das ganze nicht?
Aber die 15 Minuten Inactivity wird so nicht erreicht.

Ich habe dann mein VOIP und Dyndns abgeschaltet, und jetzt wird auch die Verbindung an dem externen DSL Modem getrennt.
Somit ist der Verursacher jetzt eindeutig mein Internet Provider (z.B. Congster oder T-Online).

Die Fritzbox ist wirklich schuldlos !! --> Wollte ich einfach nicht glauben :-Ö

Da ich mich nicht mit dem Problem abfinden kann bin ich an Lösungen interessiert.
Mein Ansatz (wenn hier auch nicht ganz passend) ist einfach die Fritzbox dazu veranlassen den Traffic selbst zu erzeugen.
Dieses habe ich dann auch getan :

mkdir -p /var/spool/cron/crontabs
echo "0-59/14 * * * * ping -c 1 -q dns00.sda.t-online.de > /dev/null" >> /var/spool/cron/crontabs/root
/var/tmp/busybox crond

Diese Lösung funktioniert für mich (nicht von AVM unterstützt).
Mann müsste mal darüber nachdenken wie man ansonsten das Problem in den Griff bekommen kann?
Evtl. auch einen Providerwechsel anstreben?

Für mich ist dieses Problem durch meinen 'Patch' erstmal gelöst.
Aber schön ist das nicht.
Fazit : Meiden sie Congster u. T-Online.
Antje

 

[frank_m24]

Hallo,

Mann müsste mal darüber nachdenken wie man ansonsten das Problem in den Griff bekommen kann?

Die Erfahrung lehrt, dass 4 registrierte VoIP Accounts reichen, um den Disconnect zu verhindern. Die Box registriert standardmäßig jeden VoIP Account in etwa alle 30 Minuten. Bei 4 Accounts verteilt sich diese Aktualisierung so, dass die 15 Minuten Inaktivität nicht mehr erreicht werden.
Alternativ kann man in der voip.cfg den TTL Wert der VoIP Accounts reduzieren.

Evtl. auch einen Providerwechsel anstreben?

Bedenke, dass alle T-Com Reseller davon betroffen sind, also neben Congster und T-Online auch z.B. 1&1 und GMX (mit T-Com IP). Bei den letzteren kann man ja recht einfach über eine kleine Änderung am Benutzer Account das Backbone wechseln: Von T-Com zu Telefonica. Bei Telefonica treten die Abbrüche nicht auf ...

Viele Grüße

Frank

 

[Music]

So, bin seit heute morgen auch auf ADSL2+ umgestellt worden, wie erwartet bleiben die Disconnects bei mir aber durch laufende Netzwerkdienste aus...

So doof das natürlich finde ich auf der anderen Seite auch nicht, dass es sooo schlimm ist, letztendlich ist es ja keinen Problem durch einen Ping alle 10min oä. die Verbindung offen zu halten.

Btw: Kennt jemanden einen vernüftigen DSL Speedtest? Die von Google vorgeschlagenen zeigen mir abwechselnd irgendwas zwischen 2 und 14 MBit an, ohne wirkliches System. Da muss es doch was besseres geben?

 

[frank_m24]

Hallo,

Btw: Kennt jemanden einen vernüftigen DSL Speedtest? Die von Google vorgeschlagenen zeigen mir abwechselnd irgendwas zwischen 2 und 14 MBit an, ohne wirkliches System. Da muss es doch was besseres geben?

Howto: Geschwindigkeitsprobleme ins Internet
Kapitel "Speedtests" :shock: (Wer hätte das gedacht?)

Viele Grüße

Frank

 

[Music]

Danke Immer wieder hilfreich...

 

[Melchisedek]

Hallo, auch wenn dieser Thread schon lange ruht und ich mit meiner 7170 eigentlich nur bedingt hierhin gehöre:

Ich habe das Problem anscheinend auch und hätte es gerne gelöst. Gibt es irgendeine Möglichkeit der 7170 mitzuteilen, dass sie bitte Traffic verursacht, damit das nicht passiert? Also per Telenet audf die Bx kommen, schaffe ich, aber von Linux habe ich kaum Ahnung. Für ein paar Befehle in der Kommandozeile wird es aber wohl reichen. Geht sowas, wie ein zeitgesteuerter Ping?

 

[Perseus]

geht, siehe http://www.ip-phone-forum.de/showthread.php?p=1134515.