[Info] FRITZ!Box 7490 Labor-Firmware FRITZ!OS 06.69-42246 (25.11.2016)

Status
Für weitere Antworten geschlossen.
- die BPjM-Liste ist immer noch zu überschreiben (Incident 460241, s. auch hier)

- Export-Problem (falsches Kennwort für die Export-Datei bei Verwendung von "Enter" im Kennwort-Eingabefeld) beseitigt ... allerdings auf die denkbar "dümmste" Art, die man sich vorstellen kann - so einen Unsinn habe ich lange nicht mehr gesehen (und entgegen meiner sonst eher zurückhaltenden Art der Bewertung drücke ich das mal ganz drastig und eindeutig aus, ohne wenn und aber); anstatt da eine ordentliche Behandlung durchzuführen, wird jetzt die "Enter"-Taste im betreffenden Formular gar nicht mehr erkannt, weil man einfach ein "dummy control" mit Typ "submit" definiert hat, was generell die Behandlung eines "submit"-Events abwürgt mit einem "return false;":
Code:
<input type="submit" value="" style="position:absolute;top:-9999px;left:-9999px;" name="dummyenter" onclick="return false;">
OT:
Ich weiß nicht, ob da mal ein Praktikant an den Code durfte oder ob die Leute dank der ganzen Frameworks heute wirklich alle keine Ahnung mehr davon haben, wie JS im Browser intern arbeitet und was man unter "event bubbling" versteht bzw. wie man selbst eine passende Behandlung auslösen kann. Aber wenn da ein "return false" anstelle des Aufrufs des richtigen Eventhandlers (notfalls mit einen Event-Objekt, das man selbst erstellt) steht, dann fällt (meiner Meinung nach) jedem halbwegs ordentlichen Programmierer vor lauter Lachen das Essen aus dem Gesicht. Auch eine passende "keydown"-Behandlung für "keyCode == 13" sollte das ermöglichen ... es gibt praktisch so viele Wege, so etwas zu lösen, daß dieses "dummy control" schon fast wieder witzig wirkt. Das erinnert mich an so etwas: http://www.heise.de/autos/artikel/D...turen-1717729.html?bild=26;view=bildergalerie ... die Vermutung mit dem Praktikanten befällt mich auch deshalb, weil da das Submit-Control tatsächlich durch lustige X/Y-Koordinaten "versteckt" wird anstatt die dafür vorgesehenen HTML/CSS-Mechanismen zu verwenden. Wenn das wirklich ein "ausgewachsener Programmierer" gewesen sein sollte, wird mir erst so richtig bange, wenn ich an künftige "Code-Qualität" bei AVM denke. Das sieht irgendwie mehr nach einer Suche im Internet und Übernahme eines obskuren Tipps von "stackoverflow.com" aus, als nach jemandem, der sich mit der Materie auch wirklich auskennt. Hier erlaube ich mir mal ein beherztes "Pfui" und ein "Sechs, setzen!" als Kommentar. Wer selbst mit JS-Frameworks und/oder HTML bzw. CSS umgehen kann, wird mir (vermutlich oder zumindest hoffentlich) zustimmen - die hier "gefundene" Lösung sorgt nämlich auch noch für einen "Bruch" in der UX - daß die "Enter"-Taste eine Eingabe beendet und zumindest den Fokus zum nächsten Eingabefeld verschiebt oder sogar das Formular entsprechend absendet, ist das Verhalten so ziemlich jedes "normalen" Programms und jeder beliebigen Webseite; bei anderen Formularen im AVM-GUI ist das ja auch nicht anders. Das macht diese "Lösung" zur Flickschusterei - daß es auch anders geht, kann man sich z.B. in der Benutzerverwaltung im FRITZ!OS ansehen.

- verwaiste Links in der Übersicht korrigiert

- den JS-(Schönheits-)Fehler beim Ändern der FTP-Portnummer für den externen Zugriff findet bestimmt auch noch jemand

- der Mediaserver erlaubt ebenfalls noch den unbeschränkten Lese-Zugriff auf jede einzelne Datei, unabhängig vom Inhaltsverzeichnis und sonstigen NAS-Einstellungen ... ich habe die Hoffnung auch begraben, daß sich daran jemals etwas ändern wird

- - - Aktualisiert - - -

Die Thematik der "Vermischung" der Namensräume von DNS (fritz.box) und mDNS (local) hat AVM aber immer noch nicht angepackt:
Code:
  hash 123:
     wpad.fritz.box ([COLOR="#FF0000"]mdns[/COLOR]):
         192.168.123.234 (dynamic)
         fe80::201:2eff:feed:cafe (dynamic)
und nach wie vor erhält ein Client im LAN bei der entsprechenden Abfrage auch von der FRITZ!Box die passende Antwort:
Code:
# dig @192.168.123.1 wpad.fritz.box. any

; <<>> DiG 9.9.6-P1 <<>> @192.168.123.1 wpad.fritz.box. any
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11225
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 3

;; QUESTION SECTION:
;wpad.fritz.box.                        IN      ANY

;; ANSWER SECTION:
[COLOR="#FF0000"]wpad.fritz.box.         9       IN      A       192.168.123.234[/COLOR]

;; AUTHORITY SECTION:
wpad.fritz.box.         9       IN      NS      fritz.box.

;; ADDITIONAL SECTION:
fritz.box.              9       IN      A       192.168.123.1
fritz.box.              9       IN      AAAA    fd00:c8a8:affe:0:a96:d7ff:feed:dead
fritz.box.              9       IN      AAAA    2002:cafe:beef:0:a96:d7ff:feed:dead

;; Query time: 1 msec
;; SERVER: 192.168.123.1#53(192.168.123.1)
;; WHEN: Sun Nov 27 11:43:43 CET 2016
;; MSG SIZE  rcvd: 134
 
Niemand ist verpflichtet, ne Labor zu testen !


Und deswegen nutze ich die seit 2 Wochen nicht mehr und habe auch seit dem keine Probleme mehr.
Jeder muss das für sich selber abwägen, Grund war da sich bei meinen Wlan Problemen von Labor zu Labor
nichts änderte. Trotz massig Supportdateien an AVM keine Verbesserung. Dann halt ohne mich.........
 
Kann sich eigentlich irgendjemand etwas unter einem "Security Report" und einem "sicherheitsrelevanten Ereignis" vorstellen, in dessen Zuge AVM jetzt (standardmäßig aktiviert) irgendwelche Daten erhält, wenn man es nicht deaktiviert?

Man mag mich ja als übermäßig neugierig schelten - ich will so etwas halt immer ganz genau wissen und da ist (zumindest bisher) der AVM-Hilfetext nicht wirklich eine solche:
Security Report.PNG
 
Tastenanschläge, Pin, Tan, Favoriten, E-Mailkonten, also alles was Du für Dich und die NSA behalten willst. :gruebel:
 
@playboy2:
Da verwechselst Du irgendetwas ... bei mir hat die FRITZ!Box keine (sinnvoll nutzbaren) Tasten, eine PIN hat höchstens der AB und die SIM-Karte im UMTS-Mobilfunk-Stick. E-Mails lese ich grundsätzlich nicht über den "maild" (der kann nämlich nur POP3-Zugriffe verwenden) und meine Favoritenlisten speichere ich auch nicht auf der FRITZ!Box.

Wie kommst Du jetzt auf die Idee, AVM würde diese Daten "abgreifen" und an die NSA übermitteln? Wäre hier nicht ohnehin eher der BND zuständig? Ich meine, wenn Du schon von Anschlägen schreibst ... :gruebel:
 
Hey PeterPawn,
Verstehe zwar nix von Programmieren und JS, aber wenn Du soviele Code-Fehler findest und ja auch offensichtlich Lösungsvorschläge hast, würde es doch allen viel mehr helfen, wenn Du diese an AVM sendest, damit wir alle wtwas davon haben. Oder nicht? :rolleyes:
 
Hallo

OT

ich möchte keinem zu nahe treten aber, bei zwei Beiträgen solch eine Aussage ist schon gewagt wobei ich nicht wissen kann wie lange du schon mitliest und es vielleicht besser wissen könntest.

Die Frage von Peter finde ich schon berechtigt, ich habe 5 Fritzboxen zwei 450er Repeater alleine bei mir in Betrieb, ohne die, die ich im Bekanntenkreis noch betreue. Wenn ich mir Ansehe und lese was alles für lücken offen sind muss man sich fast die Frage stellen, ob unser Berliner Hersteller AVM für uns noch der richtige Partner ist, obwohl ich nicht weis ob andere besser sind. Bisher habe ich mich immer wohl gefühlt mit Hardware aus Berlin. Doch mache ich mir immer mehr Sorgen. Mediaserver tut mir richtig weh das ich den abschalten musste.

Doch zurück zu Peter Pawn, wir hier im Forum, können froh sein, solch einen Programmierer zu haben der schon viele lücken gefunden und auch an AVM gemeldet hat, wenn auch nicht immer öffentlich.

Danke dafür :meinemei:

wenn ich auch nicht immer alles verstehe.
 
Zuletzt bearbeitet:
würde es doch allen viel mehr helfen, wenn Du diese an AVM sendest, damit wir alle wtwas davon haben. Oder nicht?
Wer oder was sollte AVM denn davon abhalten (und vor allem wie, womit und warum), das IPPF zu lesen? Haben nicht auf diesem Weg dann tatsächlich "wir alle" etwas davon?

Eine "vertrauliche" Meldung an AVM gab/gibt es auch noch in genug anderen Fällen ... hier ist (mit Ausnahme des "DNS vs. mDNS"-Themas, was ggf. noch einmal einen Hintergrund in Richtung einer potentiellen Sicherheitslücke hat) ohnehin alles Beta/Labor.

Dafür sieht AVM genau eine Meldung per "Feedback"-Formular vor - ohne jede weitere, verbriefte Reaktion (das wird deutlich "angesagt") seitens AVM. Wenn es hier also jemand liest, kann er es melden oder nicht ... oder AVM kann es eben hier nachlesen.

Warum soll man das dann nicht gleich direkt "öffentlich" machen und es u.a. auch den Leuten schreiben, die es tatsächlich "angeht"? Das sind deutlich "die Kunden" - und niemand hält AVM davon ab, ebenfalls Kenntnis zu nehmen.

Warum sollte ich mir jetzt die doppelte Arbeit machen und das alles noch einmal an AVM "melden" und vor allem, auf welchem Wege bitte? Ich denke nicht, daß einer meiner etwas ausführlicheren Beiträge sich in ein "Feedback"-Formular zwängen läßt (meistens ist schon die Auswahl der richtigen "Kategorie" schwierig).

Ansonsten hast Du vielleicht nur einige wenige Beiträge von mir gelesen ... wenn im GitHub-Repository von "vendor" die Rede ist bei einer Beschreibung eines Problems im FRITZ!OS (in einer "timeline"), dann ist dort jeweils AVM gemeint und diese "Firmware-Threads" sind meines Wissens genau dafür gedacht, daß man "seine Probleme" mit einer Labor-Version (oder auch einer Release-Firmware) beschreibt.

Ob das "vendor" nun immer gerechtfertigt ist oder ob "manufacturer" besser wäre, ist mir vollkommen gleich ... eine nicht ganz unwichtige Quelle in Bezug auf "vulnerabilities" (https://www.cvedetails.com) spricht/schreibt von "vendors" und die werden es ja wohl wissen.

Es gibt also beide Möglichkeiten der Kommunikation ... zuerst den Hersteller (vertraulich) informieren und dann - nach einer entsprechenden "Schonzeit" - die Öffentlichkeit oder sofort "an alle" (s.a. "full disclosure"-Maillingliste), womit auch der Hersteller die Gelegenheit hat, davon Kenntnis zu erlangen.

Zu eingeräumten Fristen gibt es sicherlich auch unterschiedliche Meinungen ... eine viel größere und bekanntere Quelle bei der Entdeckung solcher Sicherheitslücken (Google's "Project Zero") räumt dafür exakt 90 Tage ab Meldung einer Lücke an den Hersteller ein - Ausnahmen gibt es praktisch keine und verzögert wird eine Bekanntgabe (nach offizieller Lesart) nur dann (und auch nur für kurze Zeit), wenn der Hersteller glaubhaft macht, daß ein Fix unmittelbar bevorsteht und es sich deutlich nicht nur um eine Verzögerungstaktik (Spiel auf Zeit) handelt.

Ich habe genug (auch "brotlose") E-Mails mit AVM gewechselt, um meine Entscheidung für die Anwendung so einer 90-Tage-Regel begründen zu können ... wenn man sich die derzeit offenen Lücken und auch die davon bereits ausführlicher beschriebenen im Repository ansieht, wird man auch bemerken, daß ich nicht unmittelbar nach 90 Tagen dann sofort alle Einzelheiten veröffentliche.

Unter einer "koordinierten Veröffentlichung" (wenn Du Dich mit dem Thema beschäftigen möchtest, empfehle ich als Einstieg diese beiden Dokumente des BSI:

https://www.internet-sicherheit.de/.../2012-03_Lebenszyklus_einer_Schwachstelle.pdf
https://www.allianz-fuer-cybersiche...ads/BSI-CS_019.pdf?__blob=publicationFile&v=2

) versteht man bei AVM etwas, wo seitens AVM angeboten wird, einmal beim Erscheinen der ersten korrigierten Beta-Version eine Nachricht an den Finder einer Lücke zu senden (für eine Lücke erreichte mich diese Mail dann drei Wochen nach der Veröffentlichung einer gefixten Laborversion) und eine weitere, wenn alle noch "in service" befindlichen Modelle mit einem Update versorgt wurden. Letzteres wäre bei AVM so nach ca. 1 Jahr bis 18 Monaten der Fall - wie die Vergangenheit belegt.

Da es keine definitiven Aussagen seitens AVM zu den von einem gemeldeten Problem betroffenen Modellen gibt und auch die Pläne für die Bereitstellung von neuer Firmware nicht nur bei der Frage nach dem "genauen Datum", sondern schon nach "ob überhaupt noch geplant" offensichtlich höchster Geheimhaltung unterliegen, kann auch niemand exakt sagen/kontrollieren, ob denn nun alle "geplanten Veröffentlichungen" neuer Firmware bereits erfolgt sind und eine Lücke damit im Nachhinein publiziert werden kann oder ob AVM nur "vergessen" hat, das Ende der Auslieferung gefixter Firmware zu verkünden.

Und auch wenn das "Eitelkeit" sein mag ... der einzige eigene Ertrag, den man häufig genug aus der Meldung einer solchen Lücke an den Hersteller ziehen kann (und zieht), ist der "Ruhm" des Entdeckers. Wieviel Arbeit sich tatsächlich hinter der Entdeckung solcher Lücken verbirgt, kannst Du vermutlich nicht kompetent einschätzen ... aber frage Dich doch einfach einmal, warum so etwas bei AVM (und die haben obendrein noch den Einblick in ihre eigenen Quelltexte) nicht von Beginn an gesucht und gefunden wird.

Ich kann jedenfalls versichern, daß einen "Sicherheitslücken" nicht unmittelbar anspringen ... man muß richtig danach suchen und sehr viel testen - lange nicht jede Auster enthält dann auch wirklich eine Perle, es sind sogar die eher seltenen Ausnahmen.

Solche "credits" in Form der Danksagung seitens des Herstellers sind jedenfalls dann auch absolut üblich in der Branche (und wieder: Lies Dir einfach mal die beiden oben verlinkten Dokumente durch.) und sie gehören nun einmal in eine (meinetwegen auch nachträglich, dann aber trotzdem in "endlichen Zeiträumen") veröffentlichte Beschreibung eines gefixten Problems.

Da es eine solche bei AVM generell nicht gibt (man vergleiche nur den - inhaltlichen - Unterschied zwischen einer "dürren" Meldung bei AVM und einer ausführlichen Beschreibung durch redteam, um eine Vorstellung zu kriegen, wie unterschiedlich da das Verständnis seitens "einer Branche" und des Herstellers AVM am Ende ist), hat AVM auch wenig Gelegenheit, sich entsprechend "zu bedanken".

Da ist es dann auch "normal" (und hoffentlich nachvollziehbar), wenn man das selbst in die Hand nimmt ... und wenn nicht, ist mir das am Ende auch vollkommen egal. Wenn sich der Hersteller "verweigert" (und eine eher zähe und widerwillige "Zusammenarbeit" ist am Ende auch nichts anderes als eine Verweigerung und verdient den Namen "Zusammenarbeit" nicht wirklich), dann muß er auch mit den Konsequenzen leben. Punkt.

Also ganz direkt an Dich (@DocMarc) die Antwort: Man kann das eine tun, ohne das andere zu lassen ... und wenn AVM "schlau" ist, liest man dort mit, was hier geschrieben wird. Und dort ist man tatsächlich nicht auf den Kopf gefallen (ich glaube sogar, daß das Verhalten bei AVM in Bezug auf Firmware-Probleme gar nicht jedem einzelnen Mitarbeiter "zusagt" und eher eine (ziemlich dämliche, auch das muß man vielleicht mal in aller Deutlichkeit festhalten) Management-Entscheidung ist), wie ich "aus sicherer Quelle" weiß und tut das auch ... Deine "Sorge" ist also einigermaßen unbegründet.

Wenn ich dann keine Lust habe, zusätzliche Arbeit in "direkte Kommunikation" zu stecken bei bestimmten Problemen, ist das meine Entscheidung und meine Sache - solltest Du Deinerseits Befürchtungen haben, solche "Wortmeldungen" könnten untergehen, ist es Dir ja jederzeit möglich, Dich selbst ans Werk und AVM ausdrücklich auf solche Beiträge aufmerksam zu machen.

Daß AVM in Bezug auf potentielle Sicherheitsprobleme eher "verschwiegen" ist und das ihnen dann sogar selbst auf die Füße fällt, haben wir erst in allerjüngster Zeit wieder einmal erleben dürfen ... das ganze Fiasko bei den CM-Zertifikaten war (auch wieder nur meine "unmaßgebliche Meinung") am Ende reichlich unprofessionell in der Kommunikation (mit den KNB und den Kunden, inkl. "der Presse").
 
Zuletzt bearbeitet:
Danke für diese umfangreiche Stellungnahme!
Solch ein passionertes Engagement finde ich toll.
Wie gesagt, bin ich völliger Laie und mir wird natürlich ganz mulmig, wenn ich solche Dinge über vermeidbare Lücken im Code lese.
Leider scheint es ein gesamtgesellschaftliches Problem unserer Zeit zu sein, dass es nur noch um künstlich generiertes "Wachstum" in einer abgsättigten Gesellschaft (Märkten) geht und Qualität sich nicht mehr rechnet.
Danke für die Ausführungen!
 
Auf dem Screenshot steht allerdings nicht "an AVM senden", sondern zweimal "an AM senden". Nur ein Schreibfehler - oder was soll "AM" heißen?

Nachtrag: Irgendwie bin ich auch zu dumm, diesen Punkt zu finden...
 
Zuletzt bearbeitet:
"Inhalt" (links unten) -> "AVM-Dienste" (unten)
fritz_labor_sec_report.jpg
 
@SnoopyDog:
Ist halt ein Screenshot der "Online-Hilfe" von AVM, die ist wohl für die Laborversion noch nicht fertig ... die funktioniert ja auch nur, solange die FRITZ!Box ins Internet kommt - das macht es gerade bei Problemen mit der Ersteinrichtung so unheimlich sinnvoll.

Ich habe auch wenige Probleme damit, wenn irgendeine andere Funktion noch nicht in der Hilfe "erklärt" wird ... aber so ein "Persilschein", wie ihn sich AVM an dieser Stelle ausstellen lassen will (und das ist eben als Standard aktiviert, wenn ich das richtig getestet habe), wirft schon Fragen auf - auch in einer Beta- oder Labor-Version.

Irgendein "oops" hinterher ist mir da deutlich zu wenig - ergo: abgeschaltet (vorerst).

Das gilt aber nur für die Funktion an sich (drücken wir mal die Daumen, daß sich die Firmware daran hält, aber dafür muß sie bei mir ohnehin über einen "mitmproxy" bei der Kommunikation mit AVM) und nicht für meine - nach wie vor existierende - Neugierde, was man bei AVM darunter wohl verstehen mag. Es ist ja auch schwer zu "triggern", wenn man gar nicht weiß, was sich dahinter verbirgt.
 
Hoffentlich bleibt uns PeterPawn noch länger erhalten.
Denn ich glaub er ist mittlerweilen von AVM ziehmlich angepi....., oder er ist extrem cool.
:groesste:
 
Kann mir jemand sagen wie ich von der Labor am einfachsten wieder zurück zur "FRITZ.Box_7490.113.06.60.image" komme ?
Nur über fritz.box_7490.06.60.recover-image.exe oder auch über Update *.image ??
Seit der Labor gehen meine Gigaset S685 IP Telefone nicht mehr d.h. es kommen keine Anrufe mehr an - ich kann aber telefonieren.
Auf der Gigaset Konfigurationsseite habe ich plötzlich: 621 1und1 #2 Anmeldung fehlgeschlagen
Deßhalb wollte ich ein Downgrade machen.

Gruß Klaus
 
Zuletzt bearbeitet:
https://github.com/PeterPawn/modfs/blob/master/BOOTSELECTION.ger

Erst einmal auf die andere Partition sehen... wenn es nur ein einziges Update gab und Du nicht schon die gesamte "Reihe" mitgenommen hast, kostet das irgendwas zwischen 2 und 5 Minuten, wieder auf das andere System umzuschalten. Alles ohne Downgrade und Verlust irgendeiner Einstellung (mit Ausnahme sehr weniger, die es in der 06.60 einfach noch nicht gab).
 
... (mit Ausnahme sehr weniger, die es in der 06.60 einfach noch nicht gab).
Nennenswert zu erwähnen bliebe die getätigte Namens-Vergabe von DECT200 unter 06.69. die sich halt lapidar mit #Dect200 1 bis X zurückmelden unter 06.60 und unter ggfs. abgeänderter Reihenfolge unter 06.69 etwas "verwürfeln". Lässt sich schon herausfinden wer/was ist nur die Time-Schaltungsprofile müssen neu angelegt werden! Die Grundeinstellungen wie bei Stromausfall etc. zu verfahren sind kompatibel/bleiben erhalten beim Downgrade.

Ergo wer eine Aquariumsheizung für Fische betreibt o.ä. sollte Obacht walten lassen ob Downgrade und Zeitprofilen.

Wie sich vormals eingerichtete DECT-ULE Thermostaten verhalten ... k.A.

LG
 
Zuletzt bearbeitet:
@sneaker2: Danke :)
@PeterPawn: Es wäre wirklich interessant zu wissen, was da genau an A(V)M gesendet wird und wie die Box ein "sicherheitsrelevantes Ereignis" überhaupt erkennen will. Einen Hackversuch wie den der letzten Tage auf Router im Telekom-Netz etwa? (Das potentielle Einfallstor TR069 habe ich bei mir so oder so schon immer deaktiviert).
 
@PeterPawn: Es wäre wirklich interessant zu wissen, was da genau an A(V)M gesendet wird und wie die Box ein "sicherheitsrelevantes Ereignis" überhaupt erkennen will. Einen Hackversuch wie den der letzten Tage auf Router im Telekom-Netz etwa? (Das potentielle Einfallstor TR069 habe ich bei mir so oder so schon immer deaktiviert).
Anmeldeversuche mit falschem Kennwort? (SIP, Weboberfläche, FTP, ...)
 
Ok, das klingt logisch :)
 
Das ist nicht "natürlich", da die Telekom mit Vectoring häufig ~109.000 kbit/s als Profilmaximum einstellt, selbst wenn das gebuchte Produkt nur 16, 25 oder 50 Mbit/s hergibt. Gedrosselt wird dann erst am BNG. (Ob das bei Dir zutrifft, war aus Deinem ersten Beitrag nicht ersichtlich.)

Zur Leitungskapazität: was gibt es da "in den Griff" zu kriegen? Hast Du Sync-Abbrüche, zu viele CRC-Fehler o.ä.? Denn >= 50.000 kbit/s Sync hast Du ja anscheinend. Ich sehe nicht, wo da ein Problem liegt, um das AVM sich kümmern müßte.

Bei mir (Broadcom 164.97) mit alternativem Treiber auch in dieser Firmware wieder besserer Sync im Upload (volle 42000 statt 40169) und vor allem das Wichtigere: keine Verbindungsabbrüche. Solange AVM in der Release-Version dann den Treiber 1.100.133.44 als Alternative beibehält, solls mir recht sein. Ist bisher der stabilste Treiber überhaupt. Diesen hatte ich seit Release der 06.60 über drei Monate am Stück ohne einen einzigen Resync in Betrieb.

Letzte Woche hat die Telekom im Übrigen bei mir auf BNG umgestellt, Auswirkungen auf das Synchronisationsverhalten hatte es, soweit ich das beurteilen kann, keine. Dieses ist bei beiden Treibern genau wie vor der Umstellung auch – vom höheren Downloadprofil (109 statt 102) einmal abgesehen.

Klink mich mal hier mit ein, da ich aktuell auf dieser Labor unterwegs bin....

Hatte seit November 2014 VDSL50 von der T-Com ohne Probleme an der 7490 laufen - mal gefühlte 1-2 Resyncs in den 2 Jahren gehabt...

Seit 21.11.2016 bin ich nun bei 1und1 mit nem 100Mbit Anschluss - Leitung ist ja nach wie vor von der Telekom....

Nach anfänglichen Problemen (wurde am 2. Tag nur mit 50/10 verbunden) lief es dann mit 100Mbit erstmal....erstmal

Am 24. oder 25. November verlor die 7940 (noch mit der 6.60 FW) alle 3 Minuten den Sync :/
Hatte dann mal bei der Störsicherheit alle Regler auf "Maximale Stabilität" gestellt und es war erstmal wieder an Arbeiten zu denken - Sync zwar nur mit 95 Mbit aber die Leitung stand für 2h stabil...

Hab dann die Beta vor dieser installiert und die Leitung lief dann auch mit "Maximaler Performance" stabil - halbwegs - gab teilweise viele CRC Fehler auf beiden Seiten - teilweise dann wieder 0

Bin nun auf der aktuellen Beta hier und Problem scheint noch nicht wirklich "gelöst" zu sein - in den letzten 15 Minuten wieder 15 CRC Fehler auf Seite der FritzBox...

Da ich ja nun 2 Jahre keine Probleme hatte und nun erstmal überhaupt was zu dem Thema gesucht habe (Techniker war auch schon da, Leitung ist ok), frage ich mich nun was ich tun kann?!

Habe z.B. Beiträge aus dem Februar 2016 gefunden mit ständigen Resyncs und der LAN-Port Problematik - aber dies sollte ja ausgemerzt sein - bei mir hängt auch nur nen NAS an Port1...

DSLAM ist ein Broadcom 176.29....

Ist hier generell was von Problemen mit der 7490 und Broadcom DSLAM's und 100er DSL bekannt?

Lese auch was vom 1.100.133.44er Treiber, und das er der stabilste sein soll - ist das der aus der 6.60 Final? Hatte wie gesagt bis vor ner knappen Woche nie wirklich auf Treiberversionen und CRC Fehler geachtet, da ja alles stabil lief...

Falls ich irgendwo was zur Thematik überlesen habe, steinigt mich net:p

Und ja, ich muss mal die Signatur aktualisieren --> Aktuell
 
Zuletzt bearbeitet:
Status
Für weitere Antworten geschlossen.
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.