7390 Problemen mit verschiedenen DSLAMs

[hafi71]

Ich habe keine Probleme mit meinem VDSL2-Anschluss. Der läuft nun schon mehr als 50 Tagen ohne Reconnect super stabil. Hier mal ein paar Screenshots:
screen1.jpgscreen2.jpgscreen3.jpgscreen4.jpg

Die Firmware ist die letzte offizielle. Ich habe mir diesmal das Labor geschenkt...

[Novize]

distanzcheck:
Probiere mal, die Dämpfung durch Widerstände künstlich zu erhöhen - vielleicht hast Du auch einen übersteuerten DSL-Eingang. Der macht auch immer wieder mal Probleme, wenn das Signal einfach zu stark in den Chipsatz hineinbrüllt...
Das HowTo habe ich ja oben nochmals verlinkt, näheres zur SNR / Dämpfung steht auch darin.
Wobei 2 CRCs in einer Stunde:

[Joe82]

Ich bemühe mich die Diskussion hier sehr neutral anzugehen, das denke ich hat man schon in den letzten Postings gemerkt. In einem muss man aber, auch ohne Belege Novize Recht geben:

Wenn ein Nutzer Probleme hat mit einer Box meldet er sich in einem Forum an. Um, sollte der Support nicht weiterhelfen können, diese Probleme dort zu diskutieren und zu einer Lösung zu kommen. Kauft nun ein Kunde eine Box, welche problemlos an seinem Anschluss läuft, wird er nicht in Foren rennen um dort zu verkünden das alles problemlos geht. Ein Forum dient eben primär der Problemlösung. Wenn du nun also hier im Forum eine Umfrage erstellst, wer Probleme mit seiner Box hat, so lässt das einen Schluß auf die Nutzer in diesem Forum zu. "Soundsoviel Prozent aller Nutzer des Forums haben Probleme mit der Box." Deshalb kann man aber nicht den Schluss ziehen, welchen du auch nicht gezogen hast, dass die gleiche Prozentzahl aller AVM 7390 Kunden diese Probleme haben. Denn die Nutzer mit Problemen sind in einem Forum eben einfach überrepräsentiert. Ich hoffe das war halbwegs verständlich ausgedrückt.

Wie hoch der Problemteil der Nutzer ist, kann nur AVM sagen. Denn die Wissen mit sicherheit genau wie hoch die Rückläufer zwecks Austausch sind. Und die Wissen auch wie gut oder wie schlecht das Modem ist. Nur wird niemals ein Mitarbeiter sich hier outen und diese Daten preisgeben. Und wenn er sich nicht Outet, kann er die Daten nicht belegen und ist unglaubwürdig. Womit wir wieder bei dem Problem wären...

Nun nochmal zu der Sache mit den CRC. Ein normaler Otto-Normal Verbraucher wird in einen Laden gehen oder die Box von 1&1 bekommen, die Box einrichten und in die Ecke hängen. Ob die Box CRCs produziert interessiert den nicht die Bohne. Auch wird der Normalnutzer nicht merken, ob die Box mit 48.000 oder 50.000 syncronisiert hat. Es geht, nur das zählt. Was aber ein Normalnutzer mitbekommt ist, wenn die Box den Sync verliert oder Rebootet. Denn das beeinträchtigt ihn in der Nutzung.

[Gonzo18]

Hallo,

ich möchte hier auch meine Werte posten. Bitte könnten mir, da ich mich nicht so auskenne, einer
von Euch "alten Hasen" meine Werte kommentieren. Bitte nicht so ins technische gehen. Danke.


LG Gonzo18



Übersicht.JPG
DSL.JPGStatistik.JPGSpektrum.JPG

[Novize]

Hast Du denn Probleme?
Auf den ersten Blick sind es tolle Werte!

[distanzcheck]

nee nicht ganz im Keller, aber nur ca. 60 Meter Luftlinie staht der Outdoor DSLAM.

lg DirkEdit. Seit letzten Samstag bis heute waren es ca 90 Resyncs. Die davor mal nicht mitgerechnet.

lg Dirk

[Gonzo18]

@Novize

nein ich habe keine Probleme. Nur gelegentliches stocken des Entertain empfangs (nur 1-2 sek.).
In meinem Fall scheint es ja mal positiv zu sein eine "alte Version" zu haben.


LG Gonzo18

[Novize]

Die Entertain-Ruckler haben wahrscheinlich nichts mit dem Modem zu tun sondern mit allem möglichen anderen:
- Verstopfer im Internet?
- ausgelastete Datenleitung auf Deiner Seite durch paralleles P2P / Downloadmanager?
- Fehler im (W)LAN
- ausgelastete Entertain-Server
- VLan-Protokollfehler...
- Schluckauf deiner Entertainbox

Du kannst natürlich auch mal genau während einer Störung auf die Box schauen, ob die Signalqualität einbricht und die CRCs massiv in die Höhe schießen (deutlich größer als 3-stellig pro Sek!)
Das und nur das deutet auf DSL-Probleme hin. Da aber in der Regel auf Störungen auf der Leitung, nicht auf Probleme mit dem Chipsatz, denn dann würden die Probleme ständig präsent sein und nicht nur gelegentlich für 1..2 Sek erscheinen.

[marcus010676]

Ich habe mit der 7390 auch ruckler bie IPTV, die mit einem SP920 nicht auftreten.
Das ganze ist erst mit der letzten internationalen Labor mit dem neuen dsl-Treiber einigermaßen erträglich geworden.
Bei mir liegen die Ruckler bei Entertain eindeutig bei der 7390, diese gibt es beim SP920 einfach nicht.

Gruß

Marcus

[robert_s]

Wenn du nun also hier im Forum eine Umfrage erstellst, wer Probleme mit seiner Box hat, so lässt das einen Schluß auf die Nutzer in diesem Forum zu. "Soundsoviel Prozent aller Nutzer des Forums haben Probleme mit der Box."

Richtig, um nichts anderes geht es. Über das, was ausserhalb des Forums passiert, ist es nutzlos zu spekulieren. Da mag es problemfreie Anwender geben, aber auch völlig unbedarfte, die einfach zurückgeben, was nicht funktioniert. Wie groß die jeweiligen Anteile davon sind, müssten ganz eigene Studien zu ergründen versuchen, die aber den Rahmen jedes Forums sprengen. Auch @Novize sprach lediglich von den Nutzern dieses Forums:

Die Summe der hier nachlesbaren Einzelfälle jedoch, die Probleme mit dem Modemteil haben ist drastisch geringer als die Summe der User hier, die keine Probleme damit haben.

Nun nochmal zu der Sache mit den CRC. Ein normaler Otto-Normal Verbraucher wird in einen Laden gehen oder die Box von 1&1 bekommen, die Box einrichten und in die Ecke hängen. Ob die Box CRCs produziert interessiert den nicht die Bohne.

Den interessiert sehr wohl, wenn sein IPTV nicht richtig funktioniert und das Bild dauernd einfriert. Es gibt zwar einen Mechanismus, mit dem der IPTV-Receiver verlorengegangene IP-Multicast-Pakete neu anfordern kann, aber bei dem Ausmaß, welches die berüchtigten "Ikanos-Fehlerbursts" annehmen, hilft gar nichts mehr. Und auch ein VDSL2-Kunde ohne IPTV merkt irgendwann, wenn sein 50Mbps-Anschluss nicht mehr als 2Mbps liefert, denn auch das passiert dann. Das ist also keineswegs ein "spitzfindiges" Problem, sondern ein ganz handfestes mit spürbaren Auswirkungen auch auf den unbedarften Nutzer.

Die Entertain-Ruckler haben wahrscheinlich nichts mit dem Modem zu tun sondern mit allem möglichen anderen:
- Verstopfer im Internet?
- ausgelastete Datenleitung auf Deiner Seite durch paralleles P2P / Downloadmanager?
- ausgelastete Entertain-Server

Diese Punkte kann man streichen, denn 1) läuft Telekom-IPTV nicht über das Internet, 2) werden IP-Multicast-Pakete bevorzugt vom BRAS/Switch in den Downstream eingefügt, sodass P2P- und Download-Pakete verworfen werden, nicht aber IPTV-Pakete und 3) die TV-Streams eben per Multicast verteilt werden, sodass die Anzahl der Zuschauer keinen Unterschied macht. Wenn die Entertain-Server überlastet sein sollten, macht sich das bundesweit bemerkbar und nicht an einem einzelnen Anschluss.

An LAN-Problemen oder einem defekten/überhitzten IPTV-Receiver kann es dagegen durchaus liegen, ebenso am verwendeten Router.

[Novize]

Den interessiert sehr wohl, wenn sein IPTV nicht richtig funktioniert und das Bild dauernd einfriert. Es gibt zwar einen Mechanismus, mit dem der IPTV-Receiver verlorengegangene IP-Multicast-Pakete neu anfordern kann, aber bei dem Ausmaß, welches die berüchtigten "Ikanos-Fehlerbursts" annehmen, hilft gar nichts mehr. Und auch ein VDSL2-Kunde ohne IPTV merkt irgendwann, wenn sein 50Mbps-Anschluss nicht mehr als 2Mbps liefert, denn auch das passiert dann. Das ist also keineswegs ein "spitzfindiges" Problem, sondern ein ganz handfestes mit spürbaren Auswirkungen auch auf den unbedarften Nutzer.

...und damit wird dieser User zu einem klassischen Forums-Hilfe-Sucher, wird also zu großen Anteilen hier erfasst.
Und kleine CRC-Fehleranteile werden einfach ignoriert, FECs sowieso, denn diese Datenpakete werden schon in der Fritzbox repariert, bevor sie das interne LAN "betreten", spielen also für Entertain keinerlei Rolle (und auch für jegliche weitere Datenübertragung)!

[OT]
Über welchen Mechanismus werden eigentlich bei dem Entertain-Protokoll "IGMPv3" defekte Datenpakete neu angefordert?
[/OT]

BtW: Damit ist Deine Umfrage leider jetzt schon Makulatur, denn: kleine CRC-Mengen sind völlig normal bei jeder Datenübertragung - deshalb wird ja der CRC-Check genutzt. FECs sind erst recht uninteressant, da ja reparabel.
Also ist Punkt 2 Deiner Umfrage zumindest recht fragwürdig.
Punkt 4: Warum sollten denn Nicht-VDSL-User antworten, wenn Du doch explizit nur nach Erfahrungen der Box an VDSL-Anschlüssen fragst?

[distanzcheck]

Nachdem nun das neue Kabel gelegt wurd, gestern der Test. Und wie immer andauernde Resyncs am aben teilweise bis in die Nacht. Gestern abend waren es um die 10 mal.Warum ist es immer nur abends ? Und nein ich nutze da nicht Entertain.
Siehe Screen.

lg Dirk

Screen07.jpg

[robert_s]

[OT]Werden diese Entertain-Streams eigentlich per UDP oder per TCP übertragen?[/OT]

In UDP Multicast-Paketen, die mit dem RTP verpackte MPEG-2 Transport Streams enthalten.

BtW: Damit ist Deine Umfrage leider jetzt schon Makulatur, denn: kleine CRC-Mengen sind völlig normal bei jeder Datenübertragung - deshalb wird ja der CRC-Check genutzt. FECs sind erst recht uninteressant, da ja reparabel.
Also ist Punkt 2 Deiner Umfrage zumindest recht fragwürdig.
Punkt 4: Warum sollten denn Nicht-VDSL-User antworten, wenn Du doch explizit nur nach Erfahrungen der Box an VDSL-Anschlüssen fragst?

Genau das ist ja der Sinn der Punkte 2 und 4 - dort Benutzer "auszufiltern", die entweder gar nicht angesprochen waren, oder keine ernsteren Probleme haben, sodaß man unter den Punkten 1 und 3 genau die hat, die entweder vollauf zufrieden oder "berechtigt" unzufrieden sind.

Und wenn ich mir mal den derzeitigen Zwischenstand anschaue: 51 angesprochene Teilnehmer, wovon 21 = 41% vollauf zufrieden mit dem Modemteil sind, und 13 = 25% inakzeptable Probleme haben, dann sehe ich Deinen Eindruck:

Die Summe der hier nachlesbaren Einzelfälle jedoch, die Probleme mit dem Modemteil haben ist drastisch geringer als die Summe der User hier, die keine Probleme damit haben.

nicht bestätigt. Ich denke bei 25% ist die Einstufung als "Einzelfälle" nicht mehr angebracht. Wäre es nicht angebrachter, das Problem mal in seinem Ausmaß anzuerkennen, statt es als "Einzelfälle" wegzudiskutieren zu versuchen...?

[bullethead]

.

...[OT]
Über welchen Mechanismus werden eigentlich bei dem Entertain-Protokoll "IGMPv3" defekte Datenpakete neu angefordert?
[/OT]

Wenn vom anliefernden A-Server Multicast-Pakete fehlen so werden diese von der Box per UDP vom D-Server (Unicast) angefordert und von diesem über Port 47806 nachgeliefert. Die Box hat dann im niedrigen 3stelligen ms-Bereich Zeit, die Pakete in den Stream zu packen.


Sollte also mal tatsächlich im gesamten Unicast-Stream eine Störung auftreten, so kommt es sofort zu entsprechendem Traffic bei allen Entertainkunden, die gerade diese Sendung sehen.

[Novize]

In UDP Multicast-Paketen, die mit dem RTP verpackte MPEG-2 Transport Streams enthalten.

Pardon, ich hatte exakt zu der Zeit, in der Du geantwortet hast den Punkt noch einmal verfeinert.
In Wikipedia steht zu dem Thema

Der Sender von Multicast-IP-Paketen weiß dabei nicht, welche und wie viele Stationen seine Pakete empfangen. Denn er verschickt nur ein einziges Datenpaket an seinen übergeordneten Router. Der dupliziert das IP-Paket bei Bedarf, wenn er mehrere ausgehende Schnittstellen mit Empfängern hat.

Da meines Wissens nach ein Router keinen ausreichend großen Datenpuffer für defekte Datenpakete beinhaltet und bei UDP pauschal defekte Pakete verworfen werde, um den kontinuierlichen Datenfluss zu gewährleisten - bei UDP spielen einzelne defekte/verlorene Pakete keine Rolle, sonst würde man auf das Datenübertragungsverfahren wie TCP setzen - komme ich mit Deiner Erklärung so nicht zurecht...
Vor allem: Wie soll ein defektes Datenpaket vom Server neu angefordert werden, der nichts von dem einzelnen Empfänger weiß, korrekt in den (schon abgearbeiteten) Datenfluss integriert werden...
Das widerspricht imo dem RTP-Prinzip.
Wobei wir an dieser Stelle auch nicht wissen, ob das Handling der (defekten) Datenpakete in der 7390 korrekt ist - mal völlig losgelöst von irgendwelchen Modem-Problemen. Wer weiß, vielleicht klemmt hier ja eine Routine in der allgemeinen Fritz-Firmware, sodass bei mehreren defekten Datenpaketen der Datenstrom komplett zum erliegen kommt und neu aufgebaut werden muss Für diese Theorie spricht zumindest, dass es bei teils vergleichbaren DSL-Werten im Modemteil bei unterschiedlicher Firmware drastische Änderungen im Entertain-Bereich kommt.

Genau das ist ja der Sinn der Punkte 2 und 4 - dort Benutzer "auszufiltern", die entweder gar nicht angesprochen waren, oder keine ernsteren Probleme haben, sodaß man unter Punkt 1 und 3 genau die hat, die entweder vollauf zufrieden oder "berechtigt" unzufrieden sind.
Und wenn ich mir mal den angeschauten Zwischenstand anschaue: 51 angesprochene Teilnehmer, wovon 21 = 41% vollauf zufrieden mit dem Modemteil sind, und 13 = 25% inakzeptable Probleme haben, dann sehe ich Deinen Eindruck:
...
nicht bestätigt.

Geringe vernachlässigbare Datenfehler sind ja normal, also sind die User der Gruppe 2 eigentlich der Gruppe 1 zuzuschlagen. Die Gruppe 4 hingegen ist eh irrelevant und komplett zu vernachlässigen. Somit haben bisher 22 + 17 = 39 User hier keinerlei nennenswerte Fehler
Dagegen haben 14 User nennenswerte Fehler gemeldet
Damit haben wir einer Quote von ~35% (nach eigener subjektiven Empfindung) unzufriedene User
Wobei ehrlich gesagt nichts davon auch nur ansatzweise repräsentativ ist bei einer Beteiligung von gerade mal 53 gewerteten VDSL-Usern - weder für Deine These noch dagegen... Auch der VDLS-Useranteil mit der 7390 hier im Forum ist weit höher.
Man muss hier weiterhin noch berücksichtigen., dass es einen großen Teil von ADSL-Usern gibt, die ebenfalls die 7390 einsetzen und auch diesen Modemteil müssen wir betrachten, denn Du gehst ja pauschal von einem Schrott-Chipsatz aus.
Also ist die Umfrage absolut nicht mehr brauchbar.
Represäntativ für alle Nutzer der 7390 werden wir es eh niemals auch nur ansatzweise greifen können, da keiner von uns weiß, wie viele zufriedene 7390-User draußen in der freien Wildbahn das Ding nur nutzen, statt versuchen zu perfektionieren.

[distanzcheck]

distanzcheck:
Probiere mal, die Dämpfung durch Widerstände künstlich zu erhöhen - vielleicht hast Du auch einen übersteuerten DSL-Eingang. Der macht auch immer wieder mal Probleme, wenn das Signal einfach zu stark in den Chipsatz hineinbrüllt...

Wie wo muß ich denn da einen Widerstand einbauen oder wie bekomme ich das hin ?
Kann mir evtl. jemand dabei Helfen mal die Aktuelle Internationale Labor auf die 7390 zu bekommen ?
lg Dirk

[robert_s]

Da meines Wissens nach ein Router keinen ausreichend großen Datenpuffer für defekte Datenpakete beinhaltet und bei UDP pauschal defekte Pakete verworfen werde, um den kontinuierlichen Datenfluss zu gewährleisten - bei UDP spielen einzelne defekte/verlorene Pakete keine Rolle, sonst würde man auf das Datenübertragungsverfahren wie TCP setzen - komme ich mit Deiner Erklärung so nicht zurecht...

TCP und Multicast sind nicht vereinbar, weil bei TCP bidirektional kommuniziert wird, und das geht ja gerade nicht. Aber bidirektional ist der "klassische" Rundfunk (DVB-C/S/T) auch nicht, und funktioniert trotzdem. Um ein ähnliches Maß an Datensicherheit zu erreichen, hat die Telekom ein eigenes (vom Internet getrenntes) IP-Multicast-Verteilnetz, das MediaNet, aufgebaut. Da man genau weiss, welche Datenmengen da durchgehen (maximal die Summe aller IPTV-Streams, welche die Telekom erstellt) kann man das so auslegen, dass es keine Überlastungen gibt.

Vor allem: Wie soll ein defektes Datenpaket vom Server neu angefordert werden, der nichts von dem einzelnen Empfänger weiß, korrekt in den (schon abgearbeiteten) Datenfluss integriert werden...
Das widerspricht imo dem RTP-Prinzip.

@bullethead hat das Verfahren schon beschrieben: Es gibt lokale "D-Server", welche am MediaNet alle durchlaufenden IP-Multicasts "belauschen" und zwischenpuffern. Wenn der IPTV-Receiver feststellt, dass ihm ein Multicast-Pakt fehlt, fordert er das vom D-Server via Unicast erneut an. Dafür kann der Receiver natürlich auch nur ein begrenztes Zeitfenster schaffen (ein Grund, warum beim IPTV das Tor immer einige Sekunden nach DVB-C/S/T fällt). Also wenn die Neuanforderung auch verlorengeht (z.B. weil das eigene Endgerät immer wieder Pakete verliert...) gibt's trotzdem einen Bildfehler.

Neben der Neuanforderung von fehlenden Paketen werden die D-Server auch zum schnellen Senderwechsel verwendet. Dann fordert der IPTV-Receiver vom D-Server dessen gesamten Zwischenpuffer für den neuen Sender an, der schneller als in Echtzeit geliefert wird, sodass der IPTV-Receiver schneller an den ersten Keyframe kommt, als das nur bei Empfang des IP-Multicasts möglich wäre.

Also ist die Umfrage absolut nicht mehr brauchbar.

Ja, nee, ist klar. Passt nicht in Dein Weltbild, also wird es einfach diskreditiert. Akzeptiere doch einfach mal, dass es ein nicht unerhebliches Problem mit dem Modemteil der Fritz!Box 7390 gibt, und es nicht nur um "bedauerliche Einzelfälle" geht. Und dass Du hier völlig zu Unrecht Leute niederzureden versuchst, die das offen aussprechen.

Eigentlich kommt der beste Beleg für Probleme mit dem Ikanos-Chipsatz doch von AVM selbst: In der nach der Fritz!Box 7390 herausgebrachten Fritz!Box 3370 steckt kein Ikanos mehr. Warum wohl... Bestimmt nicht, weil man so gerne seine Software auf einen neuen Chipsatz portiert...

[bullethead]

...
Vor allem: Wie soll ein defektes Datenpaket vom Server neu angefordert werden, der nichts von dem einzelnen Empfänger weiß, korrekt in den (schon abgearbeiteten) Datenfluss integriert werden...

Die Anforderung kommt von der STB und der D-Server kennt, anders als der A-Server, sehr wohl den Empfänger; das ist genau so wie in den ersten Sekunden nach dem Kanalumschalten - das bedient auch der D-Server. Schließlich hat der D-Server ja die Anforderung von der STB bekommen. Der Router macht nur das was er immer tut - den Port 47086 an die STB weiterleiten, welche die Anforderung abgesetzt hat.

UDP deshalb weil eine weiter Verzögerung durch Fehlerkorekturen dann sicher uu spät kommen würde.

[Novize]

Robert, lies und beachte bitte alles, nicht nur einen Teilsatz, den Du mir dann im Munde umdrehst, weil es Dir so gut in den Kram passt! Immerhin habe ich ausreichend begründet, warum diese Umfrage im Moment noch nicht repräsentativ ist, Du aber verlässt Dich einzig auf Polemik

TCP und Multicast sind nicht vereinbar, weil bei TCP bidirektional kommuniziert wird, und das geht ja gerade nicht. Aber bidirektional ist der "klassische" Rundfunk (DVB-C/S/T) auch nicht, und funktioniert trotzdem.

Das ist mir klar, das funktioniert mal besser dank der eingebauten Fehlerkorrekturmechanismen (FEC), die für Dich ja auch problematisch erscheinen, wie Du oben schreibst, mal schlechter (CRC-Fehler), hier muss ignoriert bzw neu angefordert werden.
Danke an dieser Stelle für die Erklärung der Datenanbindung und des Handlings zum D-Server.
Das erklärt aber noch nicht die Bild-Hänger, denn einzelne Datenpakete sind ja scheinbar doch kein Problem, da auch DVB-irgendwas damit umgehen kann. Solche kleineren Fehler äußern sich ja meist in kurzen Blockartefakten bzw klirrendem Ton. Komplette Bildausfälle sind eine andere Nummer, die wohl auch andere Ursachen haben muss.

Eigentlich kommt der beste Beleg für Probleme mit dem Ikanos-Chipsatz doch von AVM selbst: In der nach der Fritz!Box 7390 herausgebrachten Fritz!Box 3370 steckt kein Ikanos mehr. Warum wohl... Bestimmt nicht, weil man so gerne seine Software auf einen neuen Chipsatz portiert...

Nö, denn warum AVM in einer anderen Box ein anderes Modem einsetzt, wissen wir beide nicht! Wenn das Dein scheinbar stärkstes Argument ist, dann beruht Deine Aussage einzig und alleine auf einer privaten Vermutung. Das ist sogar für einen Indizienprozess viel zu wenig.
=> Für eine sachliche Diskussion eindeutig zu wenig.

Schließlich hat der D-Server ja die Anforderung von der STB bekommen. Der Router macht nur das was er immer tut - den Port 47086 an die STB weiterleiten, welche die Anforderung abgesetzt hat.
UDP deshalb weil eine weiter Verzögerung durch Fehlerkorekturen dann sicher zu spät kommen würde.

Dann sollen Entertain-Stolperer nicht vom Fritz-Modem kommen, da dieses nichts damit zu tun hat.
Eher von Routing- VLAN-Fehlern in der Fritzbox-Firmware.
Leider ist ja die Umstellung auf die xx.05.yyer Firmware genau in dieser Zeit, in der die alte Fritz-Firmware keine Zeit hatte, ausreichend zu reifen und AVM somit an mehreren Baustellen zugleich tätig. Bei der Einführung der 7170 / 7270 war die Firmware ja auf einer schon gereiften Plattform und es brauchten "nur noch" Anpassungen vorgenommen werden. Wenn ich aber schaue, was in der xx.04.yy-er Firmware der versch. Boxen schon alles gut funktionierte, was nun mit der xx.05.yy-er Firmware immer noch Probleme bereitet, dann vermute ich mal auch Fehler im Handling für T-Entertain. Das Modem hat damit aber nichts zu tun, denn es übersetzt ja nur "stumpfsinnig" fertige Datenpakete in analoge Signale und zurück. Ob das nun leere Datenpakete sind, wenn nichts transportiert werden muss oder was übermittelt wird, spielt ja keine Rolle, der analoge Signalaustausch ist identisch.

[rst-cologne]

Dann sollen Entertain-Stolperer nicht vom Fritz-Modem kommen, da dieses nichts damit zu tun hat.

Wenn AVM in seiner Firmware etwas am T-Entertain Handling verbessert, dann steht das in der Releasenote in der Kategorie "Internet:" und nicht unter "DSL:". Du könntest also recht haben.