[Sammlung] Sammelthema für F!B mit "beta/netze" 7490/7590

[Benares]

54214? Ich bin inzwischen bei 54394. Welche Reihe hast du? die Phone?

 

[koyaanisqatsi]

Kann sich da einer was drunter vorstellen?

Unterstützung für AVM ACS-Server und direktes Routing nach Frankfurt dann Norden/Norddeich ins TAT-14 zum GCHQ und weiter zur NSA .
( scnr )

 

[Pom-Fritz!]

.... und weiter zur NSA .

Darauf kann ich gut verzichten!

 

[fritzfon9]

@Benares FRITZ.Box_7590_BETA.113.06.98-54214

Die 54214 ist eine Beta und ist aktuell. Deine Version ist eine Interne 54394. Die gehört nicht hier ins Brett Sammelthema für F!B mit "beta/netze" 7490/7590

 

[Benares]

Ah, verstanden. Also doch die Phone-Reihe. Was wird dir als Version exakt angezeigt? 113.06.98-54214-Phone?

 

[fritzfon9]

FRITZ!OS: 06.98-54214 PHONE

 

[Benares]

Also doch. Ich finde, AVM verzettelt sich da momentan etwas - Labor/Beta//Inhaus und jetzt auch noch Phone?
Na ja, die Osterferien sind vorbei, die Schüler-Praktikanten weg. Vielleicht wird's ja doch noch was mit einer 07.00-was auch immer ;-)

 

[TSprecher]

Neuerdings wird die synchronisierte Bandbreite (Up- und Download) am Telekom-VVDSL-Anschluss als Reale Bandbreite angezeigt.

 

[Lurtz]

Also auch mit der Firmware läuft meine 7490 am Broadcom 177.40 einfach grottig. Gerade mal wieder 50 CRC-Fehler auf der Leitung und synct generell mit 2 mbit/s im Upload weniger als mit der vorherigen DSL-Version. Das mit der realen Bandbreite im Upload scheint auch ausgewürfelt zu werden. Hab jetzt wieder den Abzug auch im Upload.

 

[fritz-fuchs]

Mir ist aufgefallen, dass bei den Phone-Versionen nicht angezeigt wird, wenn ein Update zur Verfügung steht. Habe soeben manuell auf die neue Version 54214 aktualisiert. Bis dahin wurde mir von der FB noch die 54018 als aktuell angezeigt.

 

[Robert T-Online]

Es gibt hiervon eine neue Version bis jetzt nur für die 7590.
FRITZ.Box_7590_BETA.154.06.98-54836.image
DECT ist immer noch bei 5.49
VDSL 1.180.129.30

https://download.avm.de/fritzbox/beta/netze/fritzbox-7590-beta-54836.zip

 

[1110473]

Bei mir steht bei dieser Version bei realer Bandbreite folgendes:

reale Bandbreite: ↓ 103,3 Mbit/s ↑ 38,7 Mbit/s



aber bei den Ereignissen folgendes:

24.04.18 16:53:22 Information des Anbieters über die reale Bandbreite: 96783/35934 kbit/s



Die Werte passen irgendwie nicht zueinander.



### Zusammenführung Doppelpost by stoney ###

Hier noch der Speedtest dazu:

 

[megakeule]

Der Speedtest sagt doch gar nichts aus. Der schliesst ja den Weg zur Test-Gegenstelle mit ein und den hat AVM ja nun nicht unter Kontrolle.
Kein Carrier der Welt erkennt das als Mangel an, ebensowinig wie die Routerhersteller dieser Welt. Wenn du da die gelichen Werte wie beim Sync oder der realen Bandbreite erwartest, dann kannst du lange warten. Ausserdem ist da der PPPoE Overhead gar nicht berüchsichtigt.

 

[1110473]

Mein Post bezog sich darauf:

reale Bandbreite: ↓ 103,3 Mbit/s ↑ 38,7 Mbit/s

Bei der letzten Labor (154.06.98-54214LABOR_PHONE) stand an dieser Stelle:

reale Bandbreite: ↓ 96,8 Mbit/s ↑ 38,7 Mbit/s


Nun (06.98-54836 PHONE) steht aber in den Ereignissen ein anderer Wert als in der Fritz!Box-Übersicht.

 

[cbeckstein]

Bei mir wird bei dieser Version (update von Inhouse 6.98-54702 auf Beta 6.98-54836) von dem C5, das die Fritz!Box-Daten per Starbildschirm "Fritz!Box" anzeigt, behauptet, dass eine VDSL-Verbindung mit 0.0 down und 0.3 up besteht, obwohl das Web-Interface der 7590 real 103.3 down und 41.2 up signalisiert.

Meine C5s sind auf FW 4.03

WAN-Anschluss in der Übersicht wird nicht mehr angezeigt (war noch so bei 6.98-54702) - jetzt vielleicht nur noch, wenn der Anschluss belegt ist (ist er bei mir nicht)?

 

[NDiIPP]

Die Werte passen irgendwie nicht zueinander.

Das passt schon alles. Zumindest wenn man weiß, was AVM mit dieser speziellen Labor eigentlich bezweckt.


Grund:
Die Telekom übermittelt im PPPoE-Authenticate-Ack eine für den jeweiligen Anschluss ermittelte maximale Nettogeschwindigkeit auf Basis des aktuellen Bruttosync und des Traffic-Shaper des BNG oder BRAS (auch abhängig vom Tarif).
Bei 1und1 Anschlüssen gibt es das ja schon länger aber da die Telekom ein anderes Format im PPPoE-Authenticate-Ack als 1und1 verwendet wird diese Information der Telekom bei den Fritzboxen erst in den neueren 6.98er Laborversionen ausgewertet und die Werte für die Konfiguration des Traffic-Shaper der Fritzbox übernommen.

Format Message im Authenticate-Ack bei 1und1:

Message='[UI-SBR:xxxx,yyyy;UI-LINEID:zzzz;]'

Format Message im Authenticate-Ack bei Telekom:

Message='SRU=yyyy#SRD=xxxx#'

xxxx=Downloadbandbreite in KBit/s
yyyy=Uploadbandbreite in KBit/s
zzzz=LineID

Ohne diese Information im PPPoE-Authenticate-Ack verwendet die Fritzbox die aktuelle Datenrate (Bruttosync) der DSL-Verbindung für die Konfiguration des eigenen Traffic-Shaper. Und das Telekom-Format im Authenticate-Ack wird erst in den neueren Laborversionen überhaupt ausgewertet, übermitteln tut dies die Telekom dagegen schon länger.


Warum macht man das eigentlich?
Einige neuere Anschlüsse werden erst im Breitband-PoP des Netzbetreiber auf die vertraglich vereinbarte Geschwindigkeit geregelt und daher kann der Bruttosync nicht mehr in jedem Fall für die richtige Konfiguration des Traffic-Shaper verwendet werden (wenn man beispielsweise einen DSL 16000er Tarif bei 1und1 hat und dafür aber ein VDSL50-Anschluss verwendet wird weil 1und1 vielleicht noch genügend ungenutzte Kontingente besitzt).

Daher hatte 1und1 schon vor einiger Zeit die "reale Bandbreite" des Anschlusses im PPPoE-Authenticate-Ack übermittelt und Fritzboxen diese Information ausgewertet und für die Konfiguration des eigenen Traffic-Shaper verwendet.
Das hatte schon damals negative Folgen, beispielsweise bei einem DSL 16.000 Anschluss von 1und1 der über einen ADSL AnnexJ oder VDSL-Anschluss geschaltet wurde (mit einem Bruttosync von größer 2MBit/s) denn da hat 1und1 als "reale Bandbreite" 1000 oder 1024 KBit/s für den Upload im PPoE-Authenticate-Ack als Information übermittelt, so wie es auch im Vertrag bei DSL 16000 steht. Und da die Fritzbox diesen Wert als Bruttowert betrachtet (denn vorher wurde ja auch der Bruttosync der DSL-Verbindung für die Konfiguration hergenommen) waren real vielleicht nur noch 850-900KBit/s messbar bei einem Speedtest. Ohne den auf 1MBit/s konfigurierten Traffic-Shaper der Fritzbox ist aber an solchen Anschlüssen tatsächlich eher 1,1-1,3MBit/s im Upload erreichbar (bis dann wirklich erst der Traffic-Shaper im Breitband-PoP zuschlägt). Das kann man beispielsweise erreichen wenn man ein externes Modem verwendet anstatt das interne der Fritzbox denn dann kann man eigene Werte für den Traffic-Shaper der Fritzbox verwenden. Oder man verwendet einfach einen anderen Router anstatt eine Fritzbox der diesen übermittelten Wert im PPPoE-Authenticate-Ack nicht auswertet oder es erlaubt eigene Werte vorzugeben.


Problem 1:
Es ist ein Irrtum wenn man glaubt, dass die bei "reale Bandbreite" angezeigten Werte immer den Werten entsprechen mit denen der Traffic-Shaper im Breitband-PoP des jeweiligen Netzbetreiber arbeitet. Wie obiges Beispiel bei DSL 16000 von 1und1 zeigt ist die übermittelte "reale Bandbreite" in Wirklichkeit nicht immer die reale Bandbreite. 1und1 verwendet dort manchmal Bruttowerte, manchmal Nettowerte und manchmal Werte die auch irgendwo dazwischen liegen.
Abhängig ist das bei 1und1 vom Tarif, dem Vorleister und der Plattform des Vorleister, ein kleines durcheinander also.

Beispiele:
https://www.onlinekosten.de/forum/showthread.php?p=2419510#post2419510
Und das obwohl der Anschluss real wohl immer die gleiche maximale Geschwindigkeit hatte, von der letzten Änderung im Upload von 20 auf 40MBit/s mal abgesehen.

Außerdem muss man ja auch noch zwischen Netto und Brutto unterscheiden und bei Netto ob man den Overhead für IPv4 oder IPv6 berücksichtigt.

Dieses durcheinander der angeblichen "realen Bandbreite" gibt es zwar bei der Telekom derzeit nicht da es immer die von der Telekom angenommene Nettodatenrate (offensichtlich mit kalkuliertem Overhead für IPv4) ist aber das ist auch das eigentliche Problem. Da diese Werte eigentlich dafür gedacht sind den Traffic-Shaper im DSL-Router zu konfigurieren müsste die Telekom dort eigentlich die Bruttowerte übermitteln anstatt (geschätzte) Nettowerte.


Problem 2:
Wenn die Fritzbox Werte im PPPoE-Authenticate-Ack vorfindet und das dabei verwendete Format versteht, setzt sie diese Werte ausnahmslos auch für den eigenen Traffic-Shaper ein. Bei sehr alten Firmwareversionen konnte man auch bei Nutzung des internen DSL-Modem der Fritzbox noch eigene Werte vorgeben anstatt den Bruttosync zu verwenden. Aber zu dieser Zeit hatte die Firmware von AVM auch noch nicht die Informationen aus dem Authenticate-Ack ausgewertet und es gab diese Informationen auch bei 1und1 noch nicht im Authenticate-Ack.
Das ist wie gesagt kein neues Problem mit der 6.98er Version, das gab es auch schon mit der Firmware-Version 6.20. Neu ist nur, dass nun auch das Telekom-Format mit Ver. 6.98 verstanden wird.

Problem 3:
Eigentlich verwendet man für die Konfiguration des Traffic-Shaper Bruttowerte, die Fritzbox geht derzeit zumindest auch davon aus. Die Telekom übermittelt allerdings Nettowerte.


Beispiel:
Bruttosync im Upload von 38.000 KBit/s. Wenn man auch einen VDSL100-Tarif hat und keinen VDSL50-Tarif dann wird der Traffic-Shaper im BNG korrekt auf 38.000KBit/s brutto konfiguriert (bei VDSL50 würde er auf 10MBit/s konfiguriert werden anstatt 38MBit/s, zumindest solange der Bruttosync nicht unter 10MBit/s fällt).
Davon zieht die Telekom den Overhad (PTM, Ethernet, PPPoE, IPv4) ab und übermittelt 35.800 KBit/s im PPPoE-Authenticate-Ack was die Fritzbox als "reale Bandbreite" anzeigt. Nun übernimmt die Fritzbox diesen Wert (35.800KBit/s) für die Konfiguration des eigenen Traffic-Shaper anstatt den Bruttosync (38.000KBit/s) da sie davon ausgeht, dass ja der Anbieter nicht umsonst einen anderen oder niedrigeren Wert übermittelt und übernimmt diesen Wert somit für die Konfiguration des eigenen Traffic-Shaper. Aber der geht wiederum davon aus, dass ihm Bruttowerte vorgegeben werden und zieht ebenfalls wieder den Overhead ab (was natürlich nicht notwendig wäre da das ja bereits der Anbieter gemacht hat), bei 35.800KBit/s werden daraus knapp 34MBit/s, mehr erlaubt dann quasi der Traffic-Shaper der Fritzbox im Upload nicht mehr, daher ist dann bei vielen Telekom-Kunden mit der neueren Laborversion die Geschwindigkeit im Upload beim Speedtest eingebrochen. Im Downstream ist das anders, da bestimmt primär noch der Breitband-PoP des Netzbetreiber die Datenrate.


Lösung 1:
Die Provider einigen sich was sie nun für Werte gedenken im PPPoE-Authenticate-Ack zu übermitteln, netto, brutto oder irgendwas dazwischen (beispielsweise netto ohne IPv4/6 Overhead). Dann kann AVM diese Werte auch entsprechend sicher verwenden und wenn die Provider beispielsweise Nettowerte übermitteln so müsste AVM das berücksichtigen bei der Übername dieser Werte für den eigenen Traffic-Shaper damit nicht unnötig Performance verschenkt wird. Würde man dagegen zu hohe Werte verwenden wäre der Traffic-Shaper wirkungslos.

Lösung 2:
AVM bietet wieder die Möglichkeit, so wie in den ganz alten Firmwareversionen (imo noch vor Ver. 6.00), auf Wunsch selbst Werte für den Traffic-Shaper vorzugeben und die Werte im Authenticate-Ack oder den Bruttosync zu ignorieren (hilfreich falls beispielsweise der Provider wieder mal was geändert hat oder völlig falsche Werte übermittelt). Das würde ich sowieso begrüßen.


Was bezweckt nun AVM vermutlich mit dieser speziellen Labor-Reihe?
AVM könnte das Problem temporär lösen indem sie für den Upload nicht den Wert aus dem Authenticate-Ack für den Traffic-Shaper verwenden sondern den Bruttosync. Beim Download nehmen sie dagegen weiterhin die Werte aus dem Authenticate-Ack. Das löst aber das Problem nur bei VDSL100 Anschlüssen, bei VDSL50-Anschlüssen mit VDSL100 Profil, welche erst vom Traffic-Shaper im Breitband-PoP gedrosselt werden, hilft das nicht weiter. Vielleicht könnte man das auch nur machen wenn sich die Werte sich im Authenticate-Ack und des Bruttosync nicht zu stark unterscheiden.

Eine andere Lösung scheint zu sein, welche wohl auch aktuell mit dieser speziellen Laborreihe getestet wird, wenn AVM die Werte, die die Telekom im Authenticate-Ack übermittelt, mit einem Korrekturfaktor erst einmal wieder auf (vermutete) Bruttowerte hochrechnet, vorher nur im Upload und nun wohl auch im Download.
Daher entstehen dann jedenfalls die hier beobachten Unterschiede bei den Werten.


Und wer hat nun eigentlich Schuld an dem Ganzen?
Gute Frage. Eigentlich ist das keine schlechte Idee die wahre Geschwindigkeit des Anschlusses an den Router zu übermitteln, schließlich kann man sich nicht mehr auf den DSL-Bruttosync verlassen um die wahre Geschwindigkeit des Anschlusses herauszufinden und als Werte für den eigenen Traffic-Shaper zu verwenden. Nur hätte man sich dann auch auf ein standardisiertes Verfahren oder Format einigen sollen damit dann der Router auch weiß was das für Werte sind und diese richtig interpretieren kann. Ich finde es auch etwas unglücklich, dass die Telekom Nettowerte inklusive IPv4-Overhead übermittelt, es wäre meiner Ansicht nach besser die Telekom würde hier Bruttowerte übermitteln, dann müsste man jetzt nicht so herumdoktern wie es AVM gerade mit dieser Laborreihe macht. Und was wenn dann AVM die hier gewonnen Erkenntnisse in die Release-Version übernimmt und die Telekom auf einmal anfängt Bruttowerte zu übertragen?

Ein weiteres Problem ist die Diskrepanz zwischen Bruttosync und realer Bruttodatenrate im Download wenn der Sync größer 103MBit/s liegt, daher dann auch die von dir beobachteten Werte die deiner Ansicht nach nicht zusammenpassen. Mit dieser Labor-Reihe hat das aber direkt nichts zu tun.
Die Telekom hatte bisher beim Traffic-Shapper im BNG bei VDSL100 brutto 103MBit/s (netto 96MBit/s) als Maximum, auch wenn der Bruttosync 109MBit/s war. In den letzten Wochen scheint die Telekom diese Drossel an einigen Anschlüssen aufzuheben und mehr als 103MBit/s brutto zu erlauben wenn der Sync im Download entsprechend hoch ist. Das merkt man dann auch daran, wenn man im Speedtest auf einmal mehr als 96MBit/s im Download messen kann.

 

[DickS]

Vielen Dank für die tolle Erklärung, das mit dem "Leitungskapazität" vs. "Vertragskapazität" macht Sinn. Habe selbst 1&1 und die Leitung gibt mehr her als was real ankommt (sieht man auch in der DSL-Übersicht).

Was micht allerdings wundert, an meinem Anschluss ist keinerlei Unterscheid festzustellen zwischen diese "Phone-Version" und eine Labor oder Inhaus. Das liegt vermutlich daran, dass ich ein 1&1 Vertrag habe und kein Telekomvertrag?

 

[flak65]

Der neue VDSL Treiber ist echt spitze! Ich habe bisher keine Fehler auf der Leitung. Sehr gut!

 

[Lurtz]

Das passt schon alles. Zumindest wenn man weiß, was AVM mit dieser speziellen Labor eigentlich bezweckt.
[...]

Ist das deine Interpretation oder gesicherte Informationen?

Ich hatte zuletzt bei der Telekom und der Phone-Version auch wieder eine niedrigere reale Bandbreite im Upload als im Sync.

 

[TSprecher]

Die aktuelle PHONE-Beta (6.98-54836) ist bei mir am VVDSL-Anschluss zuverlässig und stabil. Besonders die Mesh-Funktionalität mit zwei 1750E-Repeatern ist beindruckend zuverlässig. Wenn dann die Repeater noch eine angepasste Firmware bekommen, wird das Zusammenspiel nach Einstellungsänderungen am Repeater oder der FB bestimmt auch noch besser. Momentan sind oft noch Reboots von FB und Repeater nötig, nachdem Einstellungen verändert wurden, damit die Repeater auf beiden Frequenzen (2,4 und 5 GHz) Verbindungen aufbauen.