Internet Vorhandener Zugang über LAN - Verbindung bricht ab

[philippkuehne]

Lese ich die Diagramme richtig und bei der Benutzung des WLANs tritt gar kein einziges "timeout" oder "host unreachable" auf?

Doch tut es... nur hab ich die als -1 und -2 gelabelt... und negative Zahlen lassen sich schlecht in einem logarithmischen Plot darstellen - mein Fehler.

Auch finde ich trotz mehrmaligen Lesens keine Angabe dazu, was auf dem Kabel zum Thomson-Router letzten Endes verwendet wird ... vermutlich kann er nur FE, aber schon die Frage HD oder FD ist ja nicht ganz unwichtig.

Ich vermute mal das HD und FD half und full duplex sind... ich denke ich verstehe was Du meinst, und das könnte ich mir durchaus vorstellen das sowas die Ursache sein könnte. Letztendlich geht es
darum, richtig? https://en.wikipedia.org/wiki/Ethernet_over_twisted_pair#Autonegotiation_and_duplex_mismatch

Bevor ich zu den Pingstatistiken komme die ich gerade gemacht habe will ich kurz noch vorrausschicken das sich das Verhalten von Tag zu Tag unterschiedlich ist (was wiederum auch in das Bild passen wuerde). Heute ist ein Tag an dem wir zum Grossteil einen Ausfall haben... hin und wieder kommen ein paar Pakete durch, aber die Verbindung besteht dann vielleicht fuer 15sec, danach ist wieder Sendepause fuer ein paar Minuten.
Auch die Pingzeiten scheinen heute anders zu sein. Die beiden Statistiken nach denen du fragst sind durchaus in den Graphen enthalten (Ping zum Thompson Router: erster Graphe, mitte; Ping direkt per LAN zur FB: zweiter Graph, oben). An dem Tag als das gemessen wurde ging das Netz fast immer (wie man sehen kann kamen ca. 95% der Pakete durch). Heute sind die Ping Zeiten relativ gut (sowohl zum Thompson Router als auch zur FB) aber dafür gehen 63% der Pakete verloren (pro Zeit gesehen ca 95%).


Okay ich habe das WLAN deaktiviert. Hier sie Statistiken von heute:

Fritzox (Notebook-LAN-FB):
Ping statistics for xxx.xxx.xxx.xxx:
Packets: Sent 1000, Received 999, Lost 1 (0% loss),
Approximate round trip times in milli-seconds:
Minimum 0ms, Maximum 4ms, Average 0ms

Thompson Router (Notebook-LAN-FB-LAN-Thompson):
Ping statistics for xxx.xxx.xxx.xxx:
Packets: Sent 1000, Received 368, Lost 632 (63% loss),
Approximate round trip times in milli-seconds:
Minimum 1ms, Maximum 4ms, Average 1ms

Das ganze graphisch (oben äquivalenten Graphen von letzter Messung, unten Messung von heute, log Skala!):



Philipp



EDIT:
Wenn ich heute per WLAN den Thompson Router anpinge, dann habe ich neben den 63% Ausfall noch zusätzlich langsame Ping Zeiten bei den Paketen die durchkommen d.h. etwa 3ms bis 300ms.

 

[starbright]

Ich hab wirklich viele Stunden damit verbracht. Ich habe die anderen WLAN Geräte auch ausgeschaltet um damit mögliche Fehlerquellen auszuschließen. Ebenso habe ich verschiedene Kanäle benutzt. Leider konnte ich auf den anderen Geräten keine solchen Ping-Tests machen.
Als Gegentest hab ich übrigens eine 7312 (OS 6.21) benutzt, die hatte kein Problem.
Das schreibe ich jetzt nicht um weitere Hilfe zu bekommen, sondern um andere mit ähnlichem Problem zu sagen: du bist nicht allein. AVM hat inzwischen auch ein Problem beschrieben:
http://service.avm.de/support/de/sk...che-wird-nach-Anmeldung-nur-langsam-aufgebaut
Das beschreibt zumindest einen Teil des Problems.

 

[PeterPawn]

@philippkuehne:
Ja, ich meinte etwas in der Richtung mit dem "auto sensing" beim Ethernet ... allerdings nicht nur als permanentes "mismatch" auf einer Seite, sondern tatsächlich als Reaktion auf wechselnde (sich verschlechternde) Bedingungen, wenn dann so eine Art "Reset" erfolgt und der Port erneut per "auto sensing" irgendetwas einstellt, was dann wieder ein paar Pakete lang funktioniert (bis wieder mal ein Übersprechen erfolgt und eine Seite damit verwirrt wird). Wenn man das fest auf "half duplex" stellt, sollten solche Situationen mit potentiellem Übersprechen weitgehend wegfallen, weil immer nur Daten in einer Richtung gleichzeitig unterwegs sind.

Wenn ich den neuen Test mal zusammenfasse, dann gibt es kein Problem vom Notebook zur Box selbst (das geht dort auf "dev lan" ein), aber parallel verschwinden >60% der Pakete auf dem "dev dsl" der FRITZ!Box. Um einen Schaden am PHY des LAN1-Ports tatsächlich auszuschließen, würde ich nun die Box nehmen und als IP-Client mit statischer Adresse konfigurieren, dann das Notebook mit LAN-Kabel an LAN1 der Box anschließen und auf diesem Port einen weiteren Ping-Test machen lassen. Sollte es ein (physikalisches) Problem des LAN1-Ports sein, müßten da ja auch Probleme sichtbar werden.

Ansonsten kann es ja nur noch der Routing-Code in der FRITZ!Box sein, das könnte man dann mit einem "ping" auf der FRITZ!Box per Telnet noch testen, wobei auch dort eigentlich diese Pakete (bei der AVM-Implementierung des (k)dsld) denselben Weg nehmen würden, wenn sie unter der lokalen LAN-IP der Box erzeugt würden (externe IP geht da nicht).

Wenn Du schreibst, das wäre ein neues Kabel ... ich gehe mal davon aus, daß bei einem solchen Kabel die Stecker an den Enden dann selbst mit der Crimp-Zange angebracht wurden. Nur aus reiner Vorsicht frage ich noch mal nach, ob da auch die richtige Belegung der Adernpaare (also deren Zuordnung zu den Kontakten im Stecker) berücksichtigt wurde - die ist nämlich immer paarweise entscheidend. Die elektrischen Signale werden komplementär übertragen (jeweils ein "Draht" mit dem Positiv- und einer mit dem Negativ-Signal) und diese beiden Drähte müssen dann auch miteinander verdrillt sein, damit äußere Störungen die komplementären Signale gleichermaßen beeinflussen und sich damit aufheben (differenzielle Übertragung). Wenn das nicht hinhaut, gibt es ähnliche Effekte, wie Du sie beschreibst ... da kann es dann wieder sein, daß Dein Windows-Test mit dem direkten Anschluß an das Kabel zum Thomson-Router mit der kleinsten Möglichkeit (10 MBit/s, half duplex) gearbeitet hat, was zwar auch zwei passend verdrillte Paare bräuchte, aber mit reiner Phasencodierung weit weniger störanfällig ist als ein PAM-Verfahren - für einen Ping-Test merkt man da auch keinen Unterschied in der Geschwindigkeit. Aber ich gehe eigentlich davon aus, daß Dir das bekannt ist ... also nimm es als Wiederholung für spätere Leser.

Solltest Du noch einmal mit dem Notebook direkt am Kabel testen, schau doch dort mal nach, was der Netzwerk-Adapter verwendet nach einem "auto sensing" - meist kann man bei den Hardware-Eigenschaften des Netzwerkadapters auch eine Einstellung vorgeben, womit man verschiedene ausprobieren könnte.

 

[starbright]

Ich hab jetzt eine andere, ältere 7320 im Test mit OS 6.03. Die zeigt ein anderes Fehlerbild.
Einstellung wieder "Zugang über LAN". WLAN und LAN zeigen bis zur Box sehr konstante niedrige Ping-Zeiten. Zur Quellbox oder ins Internet ebenfalls relativ konstante Pingzeiten, aber Aussetzer - also verlorene Pakete. So von 80 ungefähr 12. Was mich verblüfft ist, das das schon reicht, das praktisch kein oder nur extrem langsamer Seitenaufbau möglich ist.
Wie gesagt, gleiche Einstellung mit einer 7312 funktioniert tadellos. Da muss AVM einen richtigen Bug drin haben. Gibt es irgendein exotisches internes Setting, dass sich in 7312 und 7320 unterscheidet, das für das Zusammenspiel mit dem externen Netz von Bedeutung sind?
Die 7312 zeigt "Vom Hersteller nicht unterstützte Änderungen", ich glaub weil ich sie mal "debranded" hab. Aber das kann es ja wohl nicht sein.

Welche Sektion im Setting könnte betroffen sein, das kann ich mal bei 7312 und 7320 vergleichen.
Die 7312 hat zum Bsp Einträge, die es in der 7320 nicht gibt:
dhcp_ignore_options_in_renewing = no;
is_erouter = no;
oder
limit_tcp_ds_rate = yes;
oder
manual_aftrfqdn = "";
use_gw_as_pcpserver = no;
pcpserver_supports_rfc7220 = no;

 

[starbright]

@philipkuehne:

Wie ist das bei dir weitergegangen? Ich hab jetzt erst realisiert, dass du ja eine 7490, also das Flagschiff hast. Das macht meine Hoffnung irgendwie zunichte, dass nur die 7320 so ein Problem hat. Hast du dich mal an AVM gewendet? (Ich wiederhole hier noch mal, das die 7312 tut, leider hat sie keinen zweiten Port um das Netzwerksignal weiterzuverteilen).
Hab so viele Test gemacht, dass ich denen selber kaum mehr traue, weil ich je nach Box (oder OS Version) unterschiedliche Ergebnisse bekommen.
Mit OS 6.03 hatte ich jedenfalls keine so stark erratisch schwankenden Ping-Zeiten, sondern verlorene Pakete. Und nur zu Modembox, zur eigenen war alles ok.
Das war mit anderer 7320 Box mit 6.30 definitiv anders.

Wie hast du die Ports eingestellt, auf 100MB oder GB?

Wieso legen eigentlich verlorene Pakete die Verbindung so lahm, dass praktisch kein Seitenaufbau im Browser mehr möglich ist - das verstehe ich nicht.

Ich werde den Test noch mal mit einem Switch zwischen lokaler und entfernter FB wiederholen. Die Frage ist nur, was mach ich damit: Beide Interfaces sind in der Box, da kann ich kein Autosensing deaktivieren oder zwischen HD und FD einstellen.

 

[PeterPawn]

@starbright:
Das ist ja auch kein Allheilmittel, so ein Test mit einem Switch ... soweit ich das verstehe, sind die Probleme und die Testergebnisse bei Dir ganz andere. Insofern war es vielleicht von @philippkuehne nicht so ganz schlau, keinen eigenen Thread zu dem Problem aufzumachen ... aber die Symptome bei ihm sind ja nun vollkommen andere als bei Dir - jedenfalls nach dem zu urteilen, was Du bisher geschrieben hast. Außerdem hast Du doch eigentlich explizit geschrieben, daß Du es aufgegeben hast ... warum sollte sich jetzt noch jemand Deine Berichte zu den aufgetretenen Problemen durchlesen? Wenn Du ohnehin nichts mehr machen willst, ist das ja verschenkte Zeit ... oder hast Du Deine Meinung geändert? Wenn ja, wie schnell wäre mit dem nächsten Sinneswandel zu rechnen? Nicht falsch verstehen ... aber die Nachfragen wurden ja nicht allzu umfassend beantwortet und das Fazit war:

Ich gehe von einem Defekt aus habe AVM kontaktiert.

Habe ich irgendeine Stelle überlesen, wo es sich herausgestellt hat, daß es nicht der angenommene Hardware-Defekt ist?

Ansonsten besteht eben zwischen der 7320 mit ihren zwei GbE-Anschlüssen und einer 7312 mit einem einzelnen FE-Anschluß schon per se ein Unterschied, die PHYs sind verschieden.

Bei Dir kann man m.W. bisher auch noch nichts dazu lesen, woher das Kabel zwischen 7312 und 7320 stammt. Häufig genug ist das ja irgendeine Inhouse-Installation, bei der eben kein fertig konfektioniertes Kabel zum Einsatz kommt, sondern Catn-Kabel von der Rolle durch den Elektriker verlegt wird, das dann auf beiden Seiten auf einer RJ45-Buchse aufliegt bzw. mit einem Stecker versehen wird. Dabei kann man eben genug falsch machen, was dann genau zu solch unwägbarem Verhalten führt.

Vielleicht rückst Du ja doch noch ein paar Informationen heraus, von @philippkuehne wissen wir ja z.B., daß es ein längeres, selbst verlegtes Kabel in einem Leerrohr zum Nachbarn gibt. Bei Dir muß man derzeit in fast allen wichtigen Punkten raten ... auch wäre es hier genauso wichtig wie in jedem anderen Zusammenhang, die Feststellung "verlorene Pakete" dann etwas genauer zu erläutern. Gehen schon die "echo requests" auf dem Weg zur 7312 verloren oder erst deren Antworten (echo replies) auf dem Weg zur 7320? Beide Boxen sollten das Anfertigen eines Paketmitschnitts gestatten und dann läßt sich auch diese Frage beantworten.

Ansonsten ist es vollkommen normal, daß verlorene TCP-Pakete (und Webseitenabrufe sind nun mal TCP) zu Wiederholungen und damit zu starken Verzögerungen beim Seitenaufbau führen. TCP hat zwar Mechanismen integriert, um die Folgen von Paketverlusten weitgehend zu mindern (also die Notwendigkeit von unnützen Wiederholungen zu reduzieren), aber dann wird es erst recht langsam, weil dann für jedes gesendete Paket erst die Quittung beim Absender eingehen muß, bevor das nächste gesendet wird. Das führt natürlich zu einer Addition der Laufzeiten in beide Richtungen für jedes einzelne Paket und in der Folge zu einer drastischen Reduktion des möglichen Durchsatzes.

 

[starbright]

Ja, sorry, bei mir war irgendwann der Reifen runter. Und ich dachte, her mit einer anderen (erst desselben Typs und jetzt hab ich eine 7330 bestellt) und dann ist das Problem gelöst.
Hardwaredefekt glaub ich nicht mehr, weil mehrere Geräte den Fehler zeigen.
Die Kabelverbindung ist tatsächlich etwas schräg. Zum meiner Verteidigung und deshalb hatte ich das nicht weiter thematisiert: die 7312 hat damit offensichtlich kein Problem und hab das als Ursache ausgeschlossen. Möglicherweise ist aber die 7320 einfach empfindlicher?

Also die DSL Leitung vom TAL (oder so) geht an ein Patch-Panel und von da über eine Cat5E etwa 15m an eine Anschlußdose (RJ45) und dann über ein Netzwerkkabel zur 7390 (DSL Modem). Über ein Netzwerkkabel geht es auf die gleiche Netzwerkdose und über das gleiche CAT5e an das Patchpanel zurück. Das geht, weil es zwei Splitter gibt, die die 8 Adern so nutzt, das auf 2 das DSL und auf 4 die 100MBit zurückgehen. Es gab eben nur 1 Kabel und vom Modem kommen eh nicht mehr als 16MBit, von daher theoretisch alles grün. So, bin bereit für den Shitstorm. Zu meiner Verteidigung: siehe oben.

Ich werde wohl mal mit meiner FB in die Wohnung vom Nachbarn gehen müssen und das dort direkt ausprobieren um diese Doppelnutzung des Kabels zu umgehen.

Für die eine ältere FB mit 6.03 könnte das eine Erklärung sein. ABER die anderen beiden (OS 5.22 und 6.30) haben ein massives WLAN (lange Pings und Aussetzer) Problem, ohne dass ein LAN-Kabel überhaupt dran ist. Die zuletzt getestete 3720 mit 6.03 hat aber (gleiche Settings, gleiche Position usw. kein WLAN Problem).

An der Stelle versteht man (wenn man es denn verstehen kann) das es bei mir scheinbar spukt und ich entnervt bin. Das AVM die Hardware intern geändert hat wurde mir dementiert. Das wäre noch eine Erklärung für unterschiedliches Verhalten.

Ich dachte bei TCP wird eh jedes Paket quittiert? Und warum wird ein neues Paket erst gesendet, wenn das davorige quittiert wurde? Das macht doch keinen Sinn, weil der Speed brutal einbricht? Es handelt sich doch um kein Streaming, wo die Reihenfolge wichtig ist.

Ich hab ja hier anscheinden zwei verschiedene Probleme
a) WLAN
b) Verbindung von 7320 zu 7390
aber das von Philipp ursprünglich beschriebene kommt bei mir auch vor.

 

[Feuer-Fritz]

Für sporadische Ausfälle einer FritzBox können auch "altersschwache" Netzteile die Ursache sein. Im Gegensatz zur FritzBox sind die billigst aufgebaut.

Und genau das musst du erst mal finden: Ich hab drei Boxen vernetzt und gesucht und probiert, wie blöde, bis ich an der richtigen Box, das defekte Netzteil ermittelte.
Das Problem stellte sich bei mir so dar, dass augenscheinlich alles in Ordnung war, auch die Logs der Boxen und auch deren Status.
Irgendwann kam ich nicht mehr per LAN-Kabel auf die Repeaterbox usw., Smartphones könnten nicht mehr surfen, Notebooks schob und umgekehrt, völlig wirr.....

Nach tagelangem Suchen und tauschen von Netzteilen, Neukonfig usw usw usw fand ich dann die Ursache: ein alterschwaches (erst 2 Jahre altes) Netzteil.
Neues Netzteil dran und seitdem: Alles ist gut.

 

[KunterBunter]

Über ein Netzwerkkabel geht es auf die gleiche Netzwerkdose und über das gleiche CAT5e an das Patchpanel zurück. Das geht, weil es zwei Splitter gibt, die die 8 Adern so nutzt, das auf 2 das DSL und auf 4 die 100MBit zurückgehen.

Mach mal ein Foto von der Beschaltung der Netzwerksplitter.

 

[PeterPawn]

@starbright:
Genau das macht TCP auch (Senden mehrerer Pakete auch ohne ACK) ... bis eben Pakete verloren gehen. Nimmt das dann einen erheblichen Umfang an (und 12 von 80 echo-request/-replies ist mehr als erheblich und diese Pakete sind noch winzig -> damit schnell übertragen und von intermittierenden Störungen nach reiner Wahrscheinlichkeitsrechnung seltener betroffen) - die Ursache spielt hier gar keine Rolle, egal ob es ein schwaches Netzteil oder falsches Kabel ist -, kommt es immer wieder zu einem "slow start" mit einem Fenster von "1", und wenn dann bei der Verdopplung des Fensters wieder Pakete verschwinden, bleibt die Verbindung irgendwann mit einem RWIN von 1 stehen. Was das ist und wie die Fehlervermeidungs-/-korrektur-Algorithmen beim TCP funktionieren, ist mehrfach im Internet beschrieben.

Wenn Du zusammen mit den Boxen auch jeweils die Netzteile getauscht hast, würde ich (persönlich) eher nicht auf die Suche nach einem defekten Netzteil gehen, denn wenn ich die Beschreibung richtig interpretiere (die Trennung in WLAN-Problem und Kabel-Problem wäre m.E. ebenfalls richtig), dann tritt das Problem ja nicht spontan auf, z.B. wenn sich das Netzteil oder das Gerät erwärmt, sondern von Beginn an und reproduzierbar. Das wäre über 5 verschiedene FRITZ!Boxen (wenn ich richtig mitgezählt habe) und 5 verschiedene Netzteile schon recht überraschend, wenn es daran liegen sollte.

Der einfachste Test dürfte erst einmal darin bestehen, das LAN-Kabel auszustöpseln, das sich ein Kabel mit der DSL-Leitung teilen muß und an dessen Stelle ein beliebiges Gerät zur Diagnose an die 7390 anzuschließen, von dem dann ein länger laufendes Ping einmal zur 7390 (um Schäden am LAN-Anschluß auszuschließen) und einmal zu irgendeinem Server im Internet (damit da mal die DSL-Leitung ohne Störungen durch das Ethernet auf dem Kabel arbeiten kann).

Geht das alles klar, mal die DSL-Signale aus dem Kabel nehmen (also das DSL-Kabel auf der TAL-Seite aus dem Line-Splitter ziehen, am besten auch auf der FRITZ!Box-Seite) und nur die FE-Verbindung zwischen den Boxen testen. Wenn auch die problemlos läuft und die Probleme unmittelbar beim Einstecken der DSL-Leitung wieder auftreten, würde ich auch hier auf Übersprechen tippen.

Ob das am Ende an einem falschen Splitting der Adern liegt (darauf zielt vermutlich die Frage von KunterBunter nach der Belegung der Kontakte an den Splittern ab) oder an einer generell schlechten Idee, DSL (als höchst dynamisches Signal) mit Ethernet (als eher statisches Signal, wobei ich auch erst nachschlagen müßte, welche Frequenzen dabei erreicht werden (bei 100BaseTX der Erinnerung nach 31,25 MHz), aber irgendeine Harmonische irgendeines Trägers wird schon passen für das Einkoppeln von Störungen durch DSL in die Ethernet-Signale) auf demselben "Patchkabel" zu mixen. Irgendein schmalbandiges Signal (wie meinetwegen ISDN) parallel zu nutzen, mag ja noch funktionieren, bei DSL wäre ich am Ende eher verblüfft, wenn das störungsfrei läuft. Zumindest störungsfrei bei 100 MBit/s, denn die verwendeten Modulationsverfahren ähneln sich schon sehr und jedes Verfahren, was mit mehr als einfachen Phasenwechseln arbeitet, ist eben anfällig gegen die Verformung des Nutzsignals - vielleicht klappt das tatsächlich mit 10 MBit/s, da ist das dann noch einfaches PSK.

 

[philippkuehne]

Kleines Update. Seit letem Mittwoch habe ich keinerlei Probleme. Keine Aussetzer, guter Ping (1-2ms zum Thompson Router, mit ein paar Ausreißern). Ich hab deshalb nicht weiter getestet bzw testen können - ohne Problem ist das schwierig.

Wenn Du schreibst, das wäre ein neues Kabel ... ich gehe mal davon aus, daß bei einem solchen Kabel die Stecker an den Enden dann selbst mit der Crimp-Zange angebracht wurden. Nur aus reiner Vorsicht frage ich noch mal nach, ob da auch die richtige Belegung der Adernpaare

Ja die Stecker hab ich selber gecrimpt. Ich hab das nochmal überprüft, die Kabelbelegung ist korrekt auf (beiden Seiten).

Zum Thema per Telnet von der Box aus pingen.. Das wollte ich schon ausprobieren, aber ich bekomme keinen Zugang zur Box. Habe das Telnet per Telefon aktiviert (1sec Piep ertönt) und dann per PuTTY versucht. Ich bekomme da nur "Network error: connection timed out" wenn ich die IP benutze und "Host does not exist wenn ich "fritz.box" benutze.

Ich meld mich wieder wenn das hier wieder in stottern kommt.

Philipp

 

[starbright]

Erst mal Dank für Geduld und Anteilnahme. (Mit-)geteiltes Leid ist halbes Leid.

Ich bin wie vorgeschlagen an die Quelle, die 7320 direkt an die 7390 (ohne Problem) und hab mich dann weiter vorgearbeitet. Immer jeweils Ping auf die eigene, die fremde Box und ins Internet. Am Ende stand ich an meiner Dose und es hat funktioniert. Ein Wackelkontakt irgendwo der nur bei der 7320, nicht bei der 7312 zuschlägt? Das war der Test mit einer alten 7320 vom Kollegen (6.03).
Wie lange kann man denn auf einen Server pingen (heise, google) ohne dass man als Cyberterrorist gilt? Ein paar Minuten lief das jedenfalls recht stabil, Zeiten <20ms waren die Regel, verloren Paket gab es nicht.

Die Konfiguration hab ich abgespeichert und auf eine der Austauschboxen von AVM geladen (nach Recovery und Werksreset). Das lief weder bei 6.30 noch bei 6.03 gut (ganz ohne Anschluß ans LAN1). Bei WLAN bin ich sicher, bei LAN hatte ich zumindest zeitweise den Fehler nicht auf LAN2 umgesteckt zu haben (LAN 1 ist ja der Zugang). Was mich gewundert hat: Nach dem Laden von Telefonbuch und Konfiguration war auch ein kleiner Teil Anrufhistorie zu sehen. Ich hatte bisher nicht die Erfahrung das dies zu den mitgespeicherten Daten gehört. Das macht mich misstrauisch, inwieweit Recovery und Werksreset wirklich 100% aufräumen. Davon war ich eigentlich immer ausgegangen.
Nach den zwei Stunden hatte ich dann keine Lust mehr, zumal ich die beiden Austauschboxen eh wieder zurück sende, Komisch aber doch, dass die beiden neuen Boxen (zumindest im WLAN) zickig sind. Einen Kreuztausch der Netzteile hab ich nicht gemacht, vielleicht kann ich heute abend noch mal Energie aufbringen.

Das das "Line-Sharing" gar nicht so ohne ist (unterschiedliche Frequenzen) war mich nicht so klar. Auf der Zweidrahtleitung geht neben DSL auch ISDN. Also helfen da auch die einzeln abgeschirmten Paare nicht so richtig? Wäre sicher gut, die DSL Qualität mit der 7390 mal zu testen, jeweils mit und ohne Verkehr auf der Rückleitung. Aber dazu muss ich meinem Nachbarn wieder auf den Geist gehen ...

Ein update der (im Moment laufenden) 7320 mit 6.03 trau ich mir erst mal nicht mehr.

 

[PeterPawn]

1. Die Anrufliste wird exportiert und auch wieder importiert - nach Recovery (mit dem AVM-Programm) ist auch ein zusätzliches Werksreset überflüssig, da bei Recovery auch die Partitionen mit den Einstellungen bereits neu geschrieben werden.

2. Die Adernpaare innerhalb eines normalen Cat5-Kabels sind m.W. nicht gesondert geschirmt untereinander, lediglich verdrillt (differentielle Übertragung und den Einfluß von Störungen auf solchermaßen übertragene Signale hatten wir schon vorher in diesem Thread).