Wenns nur die Einstellungen wären... Wenn eine neue Firmware veröffentlicht wird, kann man einfach alt und neu vergleichen, dann ist es keine Kunst mehr herausfinden was behoben wurde und dann muss man nur noch schauen wie man das ausnutzen kann. Daher steigt das Risiko das jemand die Box erfolgreich attackiert meiner Meinung nach radikal an wenn das Update veröffentlicht wurde und es ist dementsprechend meiner Meinung nach sinnvoll, das Update schnellstmöglich einzuspielen und damit nicht noch 1 Jahr zu warten. Was machen die eigentlich da noch mit, das kann doch eigentlich direkt durchgereicht werden nachdem DVB-C entfernt wurde (und PACM korrekt eingestellt wie ich heute morgen gelernt habe), da kann man sich doch nicht 1 Jahr dran aufhalten. Hab das Gefühl seit es die Endgerätefreiheit gibt ist es noch schlimmer geworden, die Leute die Wert darauf legen haben meistens eh ne eigene Box und nerven nicht den Support.
Fritzbox 6490 Cable Firmware Update?
- Ersteller chill24
- Erstellt am
PeterPawn
IPPF-Urgestein
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,275
- Punkte für Reaktionen
- 1,751
- Punkte
- 113
Ich schaue zwar nur sehr sporadisch bei "kdgforum.de" vorbei (ein anderes Forum - abseits vom VF-eigenen, was eher witzig als informativ ist in meinen Augen - kenne ich da gar nicht) und da wurde zwar vor ca. 4 Wochen vom beginnenden Rollout für die 06.65 geschrieben, aber angesichts der wenigen "Rückmeldungen" kann ich mir irgendwie nicht vorstellen, daß da tatsächlich seit 4 Wochen ein solcher Rollout bei VF/KD für die Provider-Boxen läuft. Auch direkt im Vodafone-Forum liest man praktisch nichts mehr dazu, seit vor vier Wochen der Rollout der 06.65 gestartet sein soll: https://forum.vodafone.de/t5/forums/forumtopicprintpage/board-id/123456/message-id/42622
Danach ist aber praktisch nichts mehr so richtig zu finden ... entweder das läuft sehr reibungslos oder es findet doch nicht in nennenswertem Umfang statt. Das kannte ich allerdings schon von der 6360 her ... da gab es auch eine großartige Ankündigung um VF-Forum für irgendeine neue Version und dann war die 8 Wochen später immer noch nicht zu finden ... noch nicht einmal Anfang September 2016, als dann die 6360 vom Provider durch eine 6490 von routermiete.de ersetzt wurde.
Da war also die "dünne Nachrichtenlage" in den letzten 4 Wochen schon eingepreist, als ich von "man hört generell wenig davon" schrieb ... allerdings schaue ich bei LGI/UM nie vorbei (außer mich führt mal ein Link irgendwie dorthin) und damit weiß ich bei denen wirklich nicht, wie der Stand ist.
-Beim Update und dem Funktionsumfang muß sich dann m.E. der Kunde einfach auch mal entscheiden ... entweder er will die "Freiheit" und nimmt eine eigene Box (bei routermiete.de mit 3 EUR/Monat sogar 2 EUR günstiger als vom Provider, die man dann "vertelefonieren" kann, wenn die eine Leitung mal nicht reicht) - die kann dann automatisch DVB-C - oder er will den Komfort und den Service vom KNB (wobei es eigentlich nur strategische Gründe sein können, die einen KNB von der Freischaltung der DVB-C-Funktionen einer 6490 abhalten können ... das ginge ganz einfach per SNMP).
Dann muß er den Provider aber eben auch machen lassen und nicht parallel selbst an dieser Konfiguration herumfummeln wollen ... wenn ich selbst jemandem seine FRITZ!Box konfiguriere und der geht hinterher hin, verstellt irgendetwas und will dann wieder mich dafür verantwortlich machen, wenn wegen so einer Änderung Teile der von mir vorgenommenen Konfiguration nicht mehr funktionieren, zeige ich dem auch den Finger - da stehe ich dann aber auch nicht in der Verantwortung, das wieder zu beheben ... es ist ja nicht mein Gerät, welches ich dem Kunden irgendwie überlassen oder vermietet habe.
Zu dieser Macht (der freien Routerwahl) gehört dann eben auch große Verantwortung seitens des Kunden und der Provider richtet von da an die Telefonie nicht mehr für den Kunden ein, reserviert zusätzliche Bandbreiten (bei den Provider-Boxen geht das sicherlich immer noch über das zweite virtuelle Interface) und kümmert sich um die Beseitigung von Störungen (die er bei PACM zumindest bemerken könnte, ohne fehlen ihm einfach auch ein paar Möglichkeiten im Monitoring) - das muß dann eben der Kunde selbst übernehmen.
Diejenigen Kunden, die immer alles auf einmal haben wollen (Bridge-Mode mit fester IP, SIP-Trunking und DVB-C, mit eigenem Router, aber vom Provider konfiguriert), haben dann halt auch mal Pech gehabt ... ich kann mit dem Kleinwagen, der in der Innenstadt in jede Parklücke paßt, eben keinen Side-by-Side-Kühlschrank transportieren. Während aber dort das Mißverhältnis jedem sofort einleuchtet, muß eine Software irgendwie immer alles auf einmal bereithalten - aber auch da gibt es eben Sachen, die nicht wirklich zusammengehen.
Und ja, es gibt immer wieder mal neue Sicherheitslücken, die von AVM dann auch irgendwann geschlossen werden ... aber wenn die Provider das nicht mit einem zeitnahen Rollout neuer Versionen gebacken kriegen (vom ersten angekündigten "Feldtest" der 06.65 bei VF/KD (Nov. 2016, iirc) bis zum 09.05. sind fast 6 Monate ins Land gegangen), dann muß man eben auch mal diese Sicherheitslücken ausnutzen und dem Provider zeigen, wieso für solche nicht aktualisierten Geräte echte Gefahren bestehen und ihn auf diesem Weg dann eben dazu veranlassen, sich da etwas (schneller) zu bewegen. Wenn der Supportaufwand für den KNB durch alte Firmware am Ende größer wird als der durch neue, dann überlegt es sich auch der Anbieter, ob er so einen Rollout nicht etwas mehr forciert.
Wie wäre es denn mal ganz treudoof mit einer E-Mail-Anfrage beim KNB, ob das eingefügte (zuvor aus der Box extrahierte) eCM-Zertifikat (der Provider-Box) eigentlich schon ein "neues" ist oder nicht? Wenn der dann fragt, wie man da überhaupt rangekommen ist (das kriegt normalerweise nur das CMTS für BPI), kann man ihn ja mal auf eine paar Sicherheitslücken hinweisen, die von AVM in neueren Versionen schon längst beseitigt wurden.
Ich kann mich häufig des Eindrucks nicht erwehren, daß die (wirklich) Verantwortlichen bei den KNB von diesen behobenen Lücken gar nichts wissen (oder wissen wollen) und weiterhin die älteren FRITZ!OS-Versionen durch ihre rosarote Brille betrachten und mit solchen Updates gar keinen eigenen Sicherheitsgewinn verbinden (und damit auch die Notwendigkeit weder sehen noch verstehen können). Ansonsten ist es ja alles andere als optimal, wenn die Kunden Zertifikate aus einer 6490 auslesen könnten ... wieso da die Provider nicht schon aus reinem "Selbstschutz" so schnell wie möglich eine Firmware ausrollen (wenn die von AVM verfügbar ist, was eigentlich der Fall sein müßte), mit der man das nicht mehr so einfach machen kann (jede geschlossene Lücke ist eine Möglichkeit weniger, unabhängig davon, wieviele andere es noch geben mag), verstehe ich einfach nicht.
[ Abgesehen davon lohnt sich für so eine alte Version wie die 06.65 ja nicht einmal mehr die Suche nach neuen/weiteren Sicherheitslücken (die ist ja schon Asbach, wenn sie überhaupt erst mal beim Kunden ankommt) ... und für eine neue Version (z.B. eben die 06.75) kann man das erst dann wieder in Angriff nehmen, wenn die irgendwo mal endlich auf einem Gerät "gesichtet" wird. ]
Danach ist aber praktisch nichts mehr so richtig zu finden ... entweder das läuft sehr reibungslos oder es findet doch nicht in nennenswertem Umfang statt. Das kannte ich allerdings schon von der 6360 her ... da gab es auch eine großartige Ankündigung um VF-Forum für irgendeine neue Version und dann war die 8 Wochen später immer noch nicht zu finden ... noch nicht einmal Anfang September 2016, als dann die 6360 vom Provider durch eine 6490 von routermiete.de ersetzt wurde.
Da war also die "dünne Nachrichtenlage" in den letzten 4 Wochen schon eingepreist, als ich von "man hört generell wenig davon" schrieb ... allerdings schaue ich bei LGI/UM nie vorbei (außer mich führt mal ein Link irgendwie dorthin) und damit weiß ich bei denen wirklich nicht, wie der Stand ist.
-Beim Update und dem Funktionsumfang muß sich dann m.E. der Kunde einfach auch mal entscheiden ... entweder er will die "Freiheit" und nimmt eine eigene Box (bei routermiete.de mit 3 EUR/Monat sogar 2 EUR günstiger als vom Provider, die man dann "vertelefonieren" kann, wenn die eine Leitung mal nicht reicht) - die kann dann automatisch DVB-C - oder er will den Komfort und den Service vom KNB (wobei es eigentlich nur strategische Gründe sein können, die einen KNB von der Freischaltung der DVB-C-Funktionen einer 6490 abhalten können ... das ginge ganz einfach per SNMP).
Dann muß er den Provider aber eben auch machen lassen und nicht parallel selbst an dieser Konfiguration herumfummeln wollen ... wenn ich selbst jemandem seine FRITZ!Box konfiguriere und der geht hinterher hin, verstellt irgendetwas und will dann wieder mich dafür verantwortlich machen, wenn wegen so einer Änderung Teile der von mir vorgenommenen Konfiguration nicht mehr funktionieren, zeige ich dem auch den Finger - da stehe ich dann aber auch nicht in der Verantwortung, das wieder zu beheben ... es ist ja nicht mein Gerät, welches ich dem Kunden irgendwie überlassen oder vermietet habe.
Zu dieser Macht (der freien Routerwahl) gehört dann eben auch große Verantwortung seitens des Kunden und der Provider richtet von da an die Telefonie nicht mehr für den Kunden ein, reserviert zusätzliche Bandbreiten (bei den Provider-Boxen geht das sicherlich immer noch über das zweite virtuelle Interface) und kümmert sich um die Beseitigung von Störungen (die er bei PACM zumindest bemerken könnte, ohne fehlen ihm einfach auch ein paar Möglichkeiten im Monitoring) - das muß dann eben der Kunde selbst übernehmen.
Diejenigen Kunden, die immer alles auf einmal haben wollen (Bridge-Mode mit fester IP, SIP-Trunking und DVB-C, mit eigenem Router, aber vom Provider konfiguriert), haben dann halt auch mal Pech gehabt ... ich kann mit dem Kleinwagen, der in der Innenstadt in jede Parklücke paßt, eben keinen Side-by-Side-Kühlschrank transportieren. Während aber dort das Mißverhältnis jedem sofort einleuchtet, muß eine Software irgendwie immer alles auf einmal bereithalten - aber auch da gibt es eben Sachen, die nicht wirklich zusammengehen.
Und ja, es gibt immer wieder mal neue Sicherheitslücken, die von AVM dann auch irgendwann geschlossen werden ... aber wenn die Provider das nicht mit einem zeitnahen Rollout neuer Versionen gebacken kriegen (vom ersten angekündigten "Feldtest" der 06.65 bei VF/KD (Nov. 2016, iirc) bis zum 09.05. sind fast 6 Monate ins Land gegangen), dann muß man eben auch mal diese Sicherheitslücken ausnutzen und dem Provider zeigen, wieso für solche nicht aktualisierten Geräte echte Gefahren bestehen und ihn auf diesem Weg dann eben dazu veranlassen, sich da etwas (schneller) zu bewegen. Wenn der Supportaufwand für den KNB durch alte Firmware am Ende größer wird als der durch neue, dann überlegt es sich auch der Anbieter, ob er so einen Rollout nicht etwas mehr forciert.
Wie wäre es denn mal ganz treudoof mit einer E-Mail-Anfrage beim KNB, ob das eingefügte (zuvor aus der Box extrahierte) eCM-Zertifikat (der Provider-Box) eigentlich schon ein "neues" ist oder nicht? Wenn der dann fragt, wie man da überhaupt rangekommen ist (das kriegt normalerweise nur das CMTS für BPI), kann man ihn ja mal auf eine paar Sicherheitslücken hinweisen, die von AVM in neueren Versionen schon längst beseitigt wurden.
Ich kann mich häufig des Eindrucks nicht erwehren, daß die (wirklich) Verantwortlichen bei den KNB von diesen behobenen Lücken gar nichts wissen (oder wissen wollen) und weiterhin die älteren FRITZ!OS-Versionen durch ihre rosarote Brille betrachten und mit solchen Updates gar keinen eigenen Sicherheitsgewinn verbinden (und damit auch die Notwendigkeit weder sehen noch verstehen können). Ansonsten ist es ja alles andere als optimal, wenn die Kunden Zertifikate aus einer 6490 auslesen könnten ... wieso da die Provider nicht schon aus reinem "Selbstschutz" so schnell wie möglich eine Firmware ausrollen (wenn die von AVM verfügbar ist, was eigentlich der Fall sein müßte), mit der man das nicht mehr so einfach machen kann (jede geschlossene Lücke ist eine Möglichkeit weniger, unabhängig davon, wieviele andere es noch geben mag), verstehe ich einfach nicht.
[ Abgesehen davon lohnt sich für so eine alte Version wie die 06.65 ja nicht einmal mehr die Suche nach neuen/weiteren Sicherheitslücken (die ist ja schon Asbach, wenn sie überhaupt erst mal beim Kunden ankommt) ... und für eine neue Version (z.B. eben die 06.75) kann man das erst dann wieder in Angriff nehmen, wenn die irgendwo mal endlich auf einem Gerät "gesichtet" wird. ]
informerex
IPPF-Urgestein
- Mitglied seit
- 20 Apr 2005
- Beiträge
- 17,194
- Punkte für Reaktionen
- 61
- Punkte
- 48
PeterPawn
IPPF-Urgestein
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,275
- Punkte für Reaktionen
- 1,751
- Punkte
- 113
Da fühlt man sich fast versucht, den Lesern dort mal einen Hinweis zu geben, wie man das Problem eines Downgrades viel einfacher lösen könnte als durch einen Gerätetausch.
Wobei mir das Problem mit DS-Lite und 06.83 auch neu war ... dabei wäre gerade so ein Anschluß mal richtig interessant, weil man dort (sofern der Provider mitspielt und einen PCP-Server bereithält) dann endlich mal PCP auch mit einem CGN beim Provider testen könnte - ggf. hat sich in so einem Falle die alte Weisheit: "Eingehende IPv4-Verbindungen funktionieren bei DS-Lite nicht." ja bereits überlebt; das könnte bis zum Funktionieren des AVM-VPN auch bei DS-Lite führen (immer unter der Voraussetzung, daß der Provider PCP verwendet).
Was das hingegen mit dem "Modem-Treiber" zu tun haben soll (wenn das irgendetwas auf der RF-Seite des eCM sein sollte), wenn da auf einem höheren Layer irgendwelche Konfigurationen nicht klappen (den AFTR-Server sollte das CM (bzw. der eRouter) meines Wissens per DHCP übermittelt bekommen), erschließt sich (mir zumindest) irgendwie nicht so richtig ... da würde ich die kolportierte Aussage "Es liegt am neuen Modemtreiber." bis zu einer Erklärung der Zusammenhänge (vielleicht versteht man ja unter einem "neuen Modemtreiber" auch etwas vollkommen anderes) nicht überbewerten.
Wobei mir das Problem mit DS-Lite und 06.83 auch neu war ... dabei wäre gerade so ein Anschluß mal richtig interessant, weil man dort (sofern der Provider mitspielt und einen PCP-Server bereithält) dann endlich mal PCP auch mit einem CGN beim Provider testen könnte - ggf. hat sich in so einem Falle die alte Weisheit: "Eingehende IPv4-Verbindungen funktionieren bei DS-Lite nicht." ja bereits überlebt; das könnte bis zum Funktionieren des AVM-VPN auch bei DS-Lite führen (immer unter der Voraussetzung, daß der Provider PCP verwendet).
Was das hingegen mit dem "Modem-Treiber" zu tun haben soll (wenn das irgendetwas auf der RF-Seite des eCM sein sollte), wenn da auf einem höheren Layer irgendwelche Konfigurationen nicht klappen (den AFTR-Server sollte das CM (bzw. der eRouter) meines Wissens per DHCP übermittelt bekommen), erschließt sich (mir zumindest) irgendwie nicht so richtig ... da würde ich die kolportierte Aussage "Es liegt am neuen Modemtreiber." bis zu einer Erklärung der Zusammenhänge (vielleicht versteht man ja unter einem "neuen Modemtreiber" auch etwas vollkommen anderes) nicht überbewerten.
Zuletzt bearbeitet:
PeterPawn
IPPF-Urgestein
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,275
- Punkte für Reaktionen
- 1,751
- Punkte
- 113
Ich korrigiere mich mal in Bezug auf die 06.75 - bei UM wurde sie jetzt wohl gesehen: https://forum.unitymedia-helpdesk.de/viewtopic.php?f=20&t=8491
So, wie die "Beschreibung" der Änderungen klingt (im achten Beitrag), könnte auch da der Umzug auf den ATOM-Core erfolgt sein.
So, wie die "Beschreibung" der Änderungen klingt (im achten Beitrag), könnte auch da der Umzug auf den ATOM-Core erfolgt sein.
Kurz hierzu, die 6.83 gibt es bisher nicht Final als Provider Version, Labor ja aber mehr nicht. Und das Problem ist das AVM in so ziemlich jeder Firmware etwas verändert was die Provisionierung angeht.
In diesem Fall betrifft es das VOIP Interface (welches übrigens per TR-069 angelegt wird nicht über DOCSIS, obwohl dies auch Provider abhängig sein kann). Es macht im Falle eines Updates zwar kein Problem, aber wenn der Kunde einen Werksreset ausführt, bezieht das VOIP Interface keine IP mehr per DHCP sondern nutzt das WAN1 Interface.
Dazu mal die VOIP Konfiguration änderte sich von der 6.2x auf 6.3x und dann nochmal auf die 6.5x. Würde man mal bei einem bleiben, würde das auch alles schneller gehen für die Provider. Allerdings Provider die noch unter 6.50 einsetzen sind fahrlässig, da stimme ich 100% zu.
Wenn es so ist wie error_403 beschrieben hat, ist es ja doch eher unmöglich eine eigene Firmware auf Basis der neuesten AVM zu bauen weil da zu viel im Bereich der Telefonie geändert wurde. Das erklärt auch warum die Provider auf alten Versionen bleiben wollen, da muss ja ständig alles umgestellt werden wenn nen Update veröffentlicht wird. Wenn man da eins überspringt sind das schon riesige Einsparungen. Danke das wir das nun mal aus Provider-Sichtweise sehen konnten, das macht es für viele bestimmt zumindest etwas verständlicher warum das mit den Updates so gemacht wird.
Wenn das alles aber über TR-069 funktioniert, warum werden dann die Telefonieeinstellungen auf meiner debrandeten Box nicht übernommen? Und kann man die TR-069 Einstellungen "per Hand" vom Server laden und dann manuell eintragen? Was mich wundert ist, das deine Aussage ja genau das Gegenteil von dem ist, was PeterPawn letztens geschrieben hat. Also wird Telefonie nun über DOCSIS oder TR-069 eingerichtet? Und was genau ändern die denn bei der VOIP Konfiguration? Man kann doch nicht jedes mal was daran ändern wie Einstellungen übertragen werden, das ist ja vollkommener Blödsinn und wirtschaftlich ist das bestimmt auch nicht: Bei AVM wird jemand zum ändern bezahlt und bei den Providern werden Leute bezahlt um zu verstehen was die da genau geändert haben..... Fazit: Viele Leute die viel Zeit investieren müssen obwohl es ja so zu funktionieren scheint
Wenn du mir jetzt noch, obwohl es etwas Offtopic ist, sagst warum im Kabelnetz nicht alle Sky Sender eingespeist werden und es trotzdem genauso viel kostet wie Sky über Sattelit verstehe ich auch die Dinge, die ich bislang als "extrem schwachsinnig" abgestempelt hab. Platz sollte da ja von den Frequenzen her auch noch sein.
Wenn das alles aber über TR-069 funktioniert, warum werden dann die Telefonieeinstellungen auf meiner debrandeten Box nicht übernommen? Und kann man die TR-069 Einstellungen "per Hand" vom Server laden und dann manuell eintragen? Was mich wundert ist, das deine Aussage ja genau das Gegenteil von dem ist, was PeterPawn letztens geschrieben hat. Also wird Telefonie nun über DOCSIS oder TR-069 eingerichtet? Und was genau ändern die denn bei der VOIP Konfiguration? Man kann doch nicht jedes mal was daran ändern wie Einstellungen übertragen werden, das ist ja vollkommener Blödsinn und wirtschaftlich ist das bestimmt auch nicht: Bei AVM wird jemand zum ändern bezahlt und bei den Providern werden Leute bezahlt um zu verstehen was die da genau geändert haben..... Fazit: Viele Leute die viel Zeit investieren müssen obwohl es ja so zu funktionieren scheint
Wenn du mir jetzt noch, obwohl es etwas Offtopic ist, sagst warum im Kabelnetz nicht alle Sky Sender eingespeist werden und es trotzdem genauso viel kostet wie Sky über Sattelit verstehe ich auch die Dinge, die ich bislang als "extrem schwachsinnig" abgestempelt hab. Platz sollte da ja von den Frequenzen her auch noch sein.
PeterPawn
IPPF-Urgestein
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,275
- Punkte für Reaktionen
- 1,751
- Punkte
- 113
Zumindest wurde es mal per DOCSIS angestoßen/angelegt (also über PACM/PacketCable):
Code:
[...]
pass | pass_warnings )
[COLOR="#0000FF"]# SIP over snmp[/COLOR]
[COLOR="#FF0000"] LUASCRIPT=/var/tmp/snmp_sip.lua[/COLOR]
if [ -f $LUASCRIPT ] ; then
if [ -x /bin/luavar ] ; then
echo "$0: calling /bin/luavar $LUASCRIPT"
[COLOR="#FF0000"] /bin/luavar $LUASCRIPT[/COLOR]
else
echo "$0: ERROR: /bin/luavar not available."
fi
else
echo "$0: ERROR: $LUASCRIPT not found."
fi
/usr/sbin/docsis_bootdebug pacmstop
;;
off )
[COLOR="#0000FF"]# SIP over snmp[/COLOR]
[COLOR="#FF0000"]LUASCRIPT=/etc/lua/snmp_sip_clean.lua[/COLOR]
if [ -f $LUASCRIPT ] ; then
if [ -x /bin/luavar ] ; then
echo "$0: calling /bin/luavar $LUASCRIPT"
[COLOR="#FF0000"]/bin/luavar $LUASCRIPT[/COLOR]
else
echo "$0: ERROR: /bin/luavar not available."
fi
else
echo "$0: ERROR: $LUASCRIPT not found."
fi
/usr/sbin/docsis_bootdebug pacmstop
;;
[...]Parallel dazu finden sich in der (ausführbaren) Datei "pacm_snmp_agent" dann diverse Zeichenketten (sieht man halt mit "strings pacm_snmp_agent"), die für die Konfiguration von "Eigenen Rufnummern" benötigt würden und aus denen (vermutlich, ich habe es noch nicht live gesehen) eine "/var/tmp/snmp_sip.lua" mit den korrekten Einstellungen für - zumindest die beiden ersten - Einträge erstellt werden konnte.
Es mag sein, daß sich das alles wieder geändert hat bzw. daß es von AVM nur für KDG (bzw. VF/KD) so eingebaut wurde (wobei die 141.06.50-32615 - das sollte die "internationale" sein, die auch bei anderen Providern ggf. verwendet wurde - dieselben Dateien enthält) ... ich würde aber meinen, irgendwo in den Tiefen meiner Archive mal so eine "/var/tmp/sip.lua" gebunkert zu haben, mit der die ersten zwei Rufnummern meiner 6490 Anfang 2015 von KDG gesetzt wurden (will ich aber nicht beschwören, manchmal bringe ich da auch Modelle und Versionen durcheinander, ich werde/bin halt alt).
Daß es keine 06.83 (als "Nummer") für die KNB gibt, war im Prinzip klar ... das meinte ich auch nicht direkt. Ich wollte eher auf eine "funktionsgleiche" (Provider-)Firmware hinaus, bei der dann auch der APP-Teil tatsächlich auf den APP-Prozessor gewandert ist - so wie es geschildert wird von UM-Kunden (s.o.), ist vielleicht die 06.75 dann diese Version.
Zuletzt bearbeitet:
Ich versuche mal auf beide Beiträge jetzt zu Antworten.
@ PeterPawn
Was in angepassten Firmwares passiert kann ich nicht beurteilen, ich rede von der unbearbeiteten ohne Branding oder ähnlisches. Ich kann nur sagen wir setzen den ACS (TR-069) Server im Configfile was DOCSIS betrifft (und nen extra Service Flow für die Telefonie, dies hat aber keinen Einfluss auf das Interface der Box). Was passiert ist, das wir per TR-060 ein Interface anlegen und dieses den String pktc sendet (kann sein was es will) damit können wir es eindeutig zuordnen und diesem eine IP für den entsprechenden Bereich geben. Zwecks der genauen Version kann ich gerade nix sagen, bin daheim aber könnte sein zwecks der 6.50 wurde das hier schonmal öffentlich.
Was das KDG und UM Branding betrifft weiß ich ehrlich nicht was genau drin steht, ich vermute sogar das es etwas mit den Frequenzen zu tun hat. Da die 6490 bis zur Version 6.50 beim ersten Suchlauf sehr langsam war. Auch der Anfang des Suchlaufs. Das hat sich seit der 6.83 sehr stark verbessert übrigens.
Zwecks 6.83 als Nummer für die KNB wird leider so kommen, zumindestens für uns. Ich mag es gar nicht da ich nun nicht mehr unterscheiden kann ob eine Mietbox eine 6.83 hat, ich hoffe der String wird noch geändert.
@flole
Ich habe es auch nur überflogen was du genau machen willst, glaube ein Update auf deiner Mietbox und dir fehlen irgendwann die SIP Daten?
Dazu mal die Erklärung du hast erstens extrem Glück, weil bei anderen Providern wird die Firmware gecheckt wenn die Box bootet (DHCP) und wenn da schon die Firmware nicht passt wird ein Downgrade versucht. Da dies über DOCIS geschiet ist der ERouter dort während des UP/Downgrades deaktiviert. Das Update dauert je nach Verbindung mindestens 10 Minuten, das dann alle halbe Stunde oder Stunde.
Zwecks Telefonie per TR-069, es ist so das dort auch die Firmware gepüft wird und nur Boxen provisioniert werden die eine gültige Firmware haben. Das sind eigentlich maximal 2, die aktuelle und die die es in den aktiven Test geschafft hat.
Ich will hier auch nicht die Provider in Schutz nehmen da ich einige auch kenne die eine ziemlich ... Update Politik fahren. Aber bitte verallgemeinert nicht immer alles, einige Provider bemühen sich auch und es ist leider auch nicht ganz einfach immer mit den Firmware testen. Alleine bei einer Fritzbox betrifft das bei uns 3 Abteilungen, das alleinige Modem, die Telefonie und die Konfiguratin per TR-069.
Und mal mein Schlusswort, ich wäre verdammt froh wenn endlich andere Hersteller mal etwas anbieten um den Irrsinn von AVM einhalt zu gebieten. Alleine das das Zertifikatsthema einfach mal so unter gegangen ist ... Das ist das erste Zertifikat was für DOCSIS je revoked wurde
@ PeterPawn
Was in angepassten Firmwares passiert kann ich nicht beurteilen, ich rede von der unbearbeiteten ohne Branding oder ähnlisches. Ich kann nur sagen wir setzen den ACS (TR-069) Server im Configfile was DOCSIS betrifft (und nen extra Service Flow für die Telefonie, dies hat aber keinen Einfluss auf das Interface der Box). Was passiert ist, das wir per TR-060 ein Interface anlegen und dieses den String pktc sendet (kann sein was es will) damit können wir es eindeutig zuordnen und diesem eine IP für den entsprechenden Bereich geben. Zwecks der genauen Version kann ich gerade nix sagen, bin daheim aber könnte sein zwecks der 6.50 wurde das hier schonmal öffentlich.
Was das KDG und UM Branding betrifft weiß ich ehrlich nicht was genau drin steht, ich vermute sogar das es etwas mit den Frequenzen zu tun hat. Da die 6490 bis zur Version 6.50 beim ersten Suchlauf sehr langsam war. Auch der Anfang des Suchlaufs. Das hat sich seit der 6.83 sehr stark verbessert übrigens.
Zwecks 6.83 als Nummer für die KNB wird leider so kommen, zumindestens für uns. Ich mag es gar nicht da ich nun nicht mehr unterscheiden kann ob eine Mietbox eine 6.83 hat, ich hoffe der String wird noch geändert.
@flole
Ich habe es auch nur überflogen was du genau machen willst, glaube ein Update auf deiner Mietbox und dir fehlen irgendwann die SIP Daten?
Dazu mal die Erklärung du hast erstens extrem Glück, weil bei anderen Providern wird die Firmware gecheckt wenn die Box bootet (DHCP) und wenn da schon die Firmware nicht passt wird ein Downgrade versucht. Da dies über DOCIS geschiet ist der ERouter dort während des UP/Downgrades deaktiviert. Das Update dauert je nach Verbindung mindestens 10 Minuten, das dann alle halbe Stunde oder Stunde.
Zwecks Telefonie per TR-069, es ist so das dort auch die Firmware gepüft wird und nur Boxen provisioniert werden die eine gültige Firmware haben. Das sind eigentlich maximal 2, die aktuelle und die die es in den aktiven Test geschafft hat.
Ich will hier auch nicht die Provider in Schutz nehmen da ich einige auch kenne die eine ziemlich ... Update Politik fahren. Aber bitte verallgemeinert nicht immer alles, einige Provider bemühen sich auch und es ist leider auch nicht ganz einfach immer mit den Firmware testen. Alleine bei einer Fritzbox betrifft das bei uns 3 Abteilungen, das alleinige Modem, die Telefonie und die Konfiguratin per TR-069.
Und mal mein Schlusswort, ich wäre verdammt froh wenn endlich andere Hersteller mal etwas anbieten um den Irrsinn von AVM einhalt zu gebieten. Alleine das das Zertifikatsthema einfach mal so unter gegangen ist ... Das ist das erste Zertifikat was für DOCSIS je revoked wurde
@error_403:
Ganz so schlimm ist es bei mir doch nicht. Ich habe eine KDG Mietbox mit meinem Vertrag bekommen, hab diese provisionieren lassen und die läuft sowohl mit Telefon als auch mit Internet. Dann hab ich das Branding auf AVM geändert und dabei gleich die neueste Firmware aufgespielt, auch das läuft super. Es kann gut sein, das ein Downgrade versucht wird, das wird aber von der Box nicht akzeptiert da Branding auf AVM steht. Nun hatte ich bereits 2 mal nach einiger Zeit das Problem, das die Telefonie nicht mehr funktionierte. Es gab davor keinen Neustart der Box, die Telefonie hat einfach den Dienst eingestellt. Daraufhin hab ich das Branding zurück auf KDG gesetzt und dann wurde nach einem Neustart sofort die aktuellste KDG Firmware aufgespielt und die Telefonie wieder neu provisioniert. Dann alles wieder zurück auf AVM und es läuft erstmal wieder, bis irgendwann wieder etwas nicht geht.
Es kann also gut sein, das die CMTS (ich glaub die ist dafür zuständig) schon weiß das die Version nicht passt und ein Update/Downgrade versucht, die Box akzeptiert das aber wahrscheinlich nicht.
Du schreibst ja, dass die Konfiguration der Telefonie über TR-069 erfolgt. Das würde auch bei mir Sinn ergeben, es ist ein ACS eingetragen in meiner Box. Kann man nicht irgendwie manuell das alles auslesen was TR-069 tun möchte? Also quasi die Konfiguration manuell einrichten? Wenn ich das richtig weiß ist das Programm was die TR-069 Konfiguration übernimmt eine Binärdatei, das Teil dazu zu bringen die Konfiguration trotz falschem branding zu übernehmen wird also eher schwierig. Ich würde gerne das Umschalten und Downgrade alle 2 Monate (bin mir da noch nicht sicher, hab die letzten beiden Male mal dokumentiert und jetzt heißt es abwarten) irgendwie umgehen, ich glaube die Telefoniedaten werden routinemäßig geändert und das ungefähr alle 2 Monate, eventuell gibt's ne Zeit wo alt und neu geht aber irgendwann sind die Daten scheinbar anders.
Zum Thema andere Hersteller war ich bei der CeBIT (Planet Reseller) mal bei TP Link und hab da direkt einfach mal nachgefragt wies mit nem EuroDocsis Router aussieht: Vielleicht in 2018, aber versprechen tun die nichts. Bleibt also momentan nur Cisco, Motorola, Hitron und AVM wobei AVM die schnellsten Geräte hat, da kommt im Moment meines Wissens nach kein anderer ran (von der Anzahl der Kanäle und daraus resultierend die maximale Übertragungsgeschwindigkeit). Kann sein das ich nen Hersteller vergessen hab, das sind jedenfalls die verbreitesten.
Ganz so schlimm ist es bei mir doch nicht. Ich habe eine KDG Mietbox mit meinem Vertrag bekommen, hab diese provisionieren lassen und die läuft sowohl mit Telefon als auch mit Internet. Dann hab ich das Branding auf AVM geändert und dabei gleich die neueste Firmware aufgespielt, auch das läuft super. Es kann gut sein, das ein Downgrade versucht wird, das wird aber von der Box nicht akzeptiert da Branding auf AVM steht. Nun hatte ich bereits 2 mal nach einiger Zeit das Problem, das die Telefonie nicht mehr funktionierte. Es gab davor keinen Neustart der Box, die Telefonie hat einfach den Dienst eingestellt. Daraufhin hab ich das Branding zurück auf KDG gesetzt und dann wurde nach einem Neustart sofort die aktuellste KDG Firmware aufgespielt und die Telefonie wieder neu provisioniert. Dann alles wieder zurück auf AVM und es läuft erstmal wieder, bis irgendwann wieder etwas nicht geht.
Es kann also gut sein, das die CMTS (ich glaub die ist dafür zuständig) schon weiß das die Version nicht passt und ein Update/Downgrade versucht, die Box akzeptiert das aber wahrscheinlich nicht.
Du schreibst ja, dass die Konfiguration der Telefonie über TR-069 erfolgt. Das würde auch bei mir Sinn ergeben, es ist ein ACS eingetragen in meiner Box. Kann man nicht irgendwie manuell das alles auslesen was TR-069 tun möchte? Also quasi die Konfiguration manuell einrichten? Wenn ich das richtig weiß ist das Programm was die TR-069 Konfiguration übernimmt eine Binärdatei, das Teil dazu zu bringen die Konfiguration trotz falschem branding zu übernehmen wird also eher schwierig. Ich würde gerne das Umschalten und Downgrade alle 2 Monate (bin mir da noch nicht sicher, hab die letzten beiden Male mal dokumentiert und jetzt heißt es abwarten) irgendwie umgehen, ich glaube die Telefoniedaten werden routinemäßig geändert und das ungefähr alle 2 Monate, eventuell gibt's ne Zeit wo alt und neu geht aber irgendwann sind die Daten scheinbar anders.
Zum Thema andere Hersteller war ich bei der CeBIT (Planet Reseller) mal bei TP Link und hab da direkt einfach mal nachgefragt wies mit nem EuroDocsis Router aussieht: Vielleicht in 2018, aber versprechen tun die nichts. Bleibt also momentan nur Cisco, Motorola, Hitron und AVM wobei AVM die schnellsten Geräte hat, da kommt im Moment meines Wissens nach kein anderer ran (von der Anzahl der Kanäle und daraus resultierend die maximale Übertragungsgeschwindigkeit). Kann sein das ich nen Hersteller vergessen hab, das sind jedenfalls die verbreitesten.
Ich glaube KDG handhabt dies anders als wir. Und der UP/Downgrade geht auch bei einer Fritzbox rein über DOCSIS und das kannst du nicht verhindern, alles über TR-069 ja, das wahrscheinlich auch auch der Grund warum deine Telefonie irgendwann nciht mehr geht. Um eines klarzustellen ich erkläre hier nur mal die Hintergründe aus der anderen Seite, ich werde bestimmt nix dazu beitragen um eine ProviderBox irgendwie zu manipulieren. Da ich leider aus Erfahrung sagen kann, dass es in 98% aller Fälle schief geht.
Die CMTS checkt nur das Zertifakt übrigens.
Zwecks Binär, dass ist das DOCSIS Configfile, ACS kommt weit weit später. Ich verstehe aber allerdings auch nicht wieso du du dir keine eigene Box mietest oder kaufst, dann kannst die einrichten wie du magst?
Zwecks ähm wieso bleibt Cisco (übrigens Arris nun), Motorola (auch Arris), Hitron, ich kenne kein einziges Modem mit einer Firmware die man runterladen und selber updaten kann. Am ehesten ist wohl eher TP-Link dran was auf den Mark zu bringen. Aber gesehen und in der Hand gehalten habe ich nix.
Zwecks Kanäle und Geschwindigkeit hast leider unrecht, schau bei deiner Fritzbox alleine mal die Kanäle an sind wirklich alle 256 Qam? Auch ansonsten 16 Downstreams ist derzeit recht perfekt, mehr macht auch aus Sicht des LoadBalancing kein Sinn. Und ich weigere mich 64 Qam im Downstream einzuspeisen.
Die CMTS checkt nur das Zertifakt übrigens.
Zwecks Binär, dass ist das DOCSIS Configfile, ACS kommt weit weit später. Ich verstehe aber allerdings auch nicht wieso du du dir keine eigene Box mietest oder kaufst, dann kannst die einrichten wie du magst?
Zwecks ähm wieso bleibt Cisco (übrigens Arris nun), Motorola (auch Arris), Hitron, ich kenne kein einziges Modem mit einer Firmware die man runterladen und selber updaten kann. Am ehesten ist wohl eher TP-Link dran was auf den Mark zu bringen. Aber gesehen und in der Hand gehalten habe ich nix.
Zwecks Kanäle und Geschwindigkeit hast leider unrecht, schau bei deiner Fritzbox alleine mal die Kanäle an sind wirklich alle 256 Qam? Auch ansonsten 16 Downstreams ist derzeit recht perfekt, mehr macht auch aus Sicht des LoadBalancing kein Sinn. Und ich weigere mich 64 Qam im Downstream einzuspeisen.
Du sagst ja das ein Up/Downgrade über DOCSIS geht, also könnte man als Provider theoretisch eine AVM Box einfach mal mit nem Providerimage versehen..... Na wenn das mal gut geht, ich erinnere mich gerade daran das KDG mal aus Versehen ne Ladung Mietboxen zurückgesetzt hat.
Eine eigene Box miete/kauf ich mir deshalb nicht, weil ich es als Schwachsinn ansehe eine 2. Box hier hinzustellen, dann lieber alle 2 Monate Up und Downgrade wenn es da keinen anderen weg gibt. Außerdem kostet so eine Fritzbox ja nicht gerade wenig, das schreckt erstmal ab. Ich fände es ja schon "akzeptabel" wenn die mir endlich die Telefoniedaten rausrücken würden, aber ohne eigenes Endgerät tun die das auch nicht.... Ich hab eine SIP Telefonanlage hinter der Fritzbox und muss die nun an der Fritzbox anmelden die sich dann bei VF/KD anmeldet.
Bei meiner Fritzbox hab ich 11xQAM256 und 9xQAM64.... Bei der CeBIT hat mir ein AVM Mitarbeiter erklärt je mehr Kanäle desto besser um temporäre Überlastungen auf einzelnen Kanälen abzufangen. Hab da nämlich auch nachgefragt ob es heutzutage überhaupt Sinn macht, die werden ja nicht mal annähernd ausgenutzt, das wurde aber ganz klar bejaht.
Eine eigene Box miete/kauf ich mir deshalb nicht, weil ich es als Schwachsinn ansehe eine 2. Box hier hinzustellen, dann lieber alle 2 Monate Up und Downgrade wenn es da keinen anderen weg gibt. Außerdem kostet so eine Fritzbox ja nicht gerade wenig, das schreckt erstmal ab. Ich fände es ja schon "akzeptabel" wenn die mir endlich die Telefoniedaten rausrücken würden, aber ohne eigenes Endgerät tun die das auch nicht.... Ich hab eine SIP Telefonanlage hinter der Fritzbox und muss die nun an der Fritzbox anmelden die sich dann bei VF/KD anmeldet.
Bei meiner Fritzbox hab ich 11xQAM256 und 9xQAM64.... Bei der CeBIT hat mir ein AVM Mitarbeiter erklärt je mehr Kanäle desto besser um temporäre Überlastungen auf einzelnen Kanälen abzufangen. Hab da nämlich auch nachgefragt ob es heutzutage überhaupt Sinn macht, die werden ja nicht mal annähernd ausgenutzt, das wurde aber ganz klar bejaht.
Nein seid der 6.62 ist keinerlei Downgrade von einer Retail Firmware möglich, daher wird es ja ständig wieder probiert nach einem Reboot.
Es ist für die Provider UNMÖGLICH eine selbst geupdate Box wieder mit einer Provider Firmware zu versorgen!
Edit Zwecks Kanäle wir bieten wenn NUR 16 256 Qam an.
Was bringen z.B. 20 64 Qam Kanäle, solche aussagen mehr ist besser halt ich mal für sehr fragwürdig.
Rechne einfach mal nach als alles zu glauben. Einzige was klar ist es geht um Load Balncing, davon hast vielleicht auch etwas aber den Provider interessiert es mehr. Deswegen hoffe ich der Markt gibt endlich mehr Modems mit 16 oder mehr DS frei.
Zuletzt bearbeitet:
- Mitglied seit
- 7 Okt 2015
- Beiträge
- 9,169
- Punkte für Reaktionen
- 1,429
- Punkte
- 113
Das ist doch mal eine Aussage (bei welchem Konzern arbeitest du - hab ich das verpasst?? ^^)
Das ist so ebenfalls falsch. Ich habe ja meine 6.65 mit AVM Branding erfolgreich wieder zurücksetzen lassen indem ich das Branding auf das nicht verfügbare KDG geändert habe. Man kann die Box also wieder mit einem Update versorgen, und die Retail firmware ist in den Moment ja auch drauf und zum kdg Branding sind keinerlei Daten in dem Retail image vorhanden. Man kann eine Retail box also durchaus vom Provider updaten lassen, man muss es nur wollen (das macht aber nur in sehr wenigen Fällen Sinn).
PeterPawn
IPPF-Urgestein
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,275
- Punkte für Reaktionen
- 1,751
- Punkte
- 113
@error_403:
Ok, hier kommen sicherlich die kleineren Provider (und das ist für mich alles außer VF/KD und LGI/UM) bei solchen Betrachtungen immer etwas unter die Räder, aber in diesen Threads geht es ja auch fast immer um Updates ehemaliger Provider-Boxen und - zumindest soweit ich das bisher kenne - diese Geräte gab es dann lange Zeit nur von den beiden (ganz) Großen - die Zahl der "anderen" Geräte von solchen Anbietern (von m-net bis Primacom) ist sicherlich eher überschaubar (zumindest im Vergleich).
Ich gebe es frank und frei zu, daß ich bis eben nicht mal mitbekommen hatte, daß es bei der Primacom auch die 6490 als Mietgerät (oder Überlassung oder wie auch immer - entscheidend ist "vom Provider") gibt. Ist das schon lange der Fall? Es macht ja auch Sinn, solange EPC 2.0/RST für die Telefonie vom Provider genutzt wird - daß es da bei den ganzen TC-Töchtern durchaus unterschiedliche Infrastruktur gibt, geht häufig etwas unter und daher habe ich bei "TC" eigentlich immer die Schranke im Kopf: EPC 1.5 -> keine AVM-Geräte. Ich werde mir aber merken, daß auch Primacom zu den Anbietern einer Provider-6490 gehört. :mrgreen:
Wenn ich von KNB schreibe, meine ich halt diejenigen, die ihren Kunden 6490 mit einer Firmware zur Verfügung stellen, wo ein eMTA konfiguriert werden kann. Daß da Primacom auch dazu zählt, war mir bisher gar nicht bewußt. Daher will ich auch die Update-Politik von Primacom gar nicht beurteilen ... das kann ich auch gar nicht, ich wußte bisher ja nicht einmal, daß es da eine solche geben könnte (in Bezug auf FRITZ!Boxen, bei anderen CM ist es ja genauso, wenn auch sicherlich seltener Updates erscheinen).
Wenn man sich bei Primacom also tatsächlich um einen zeitnahen Rollout bemüht, hebt das diesen KNB ja trotzdem von den (beiden) anderen ab ... denn daß es dort extrem lange dauert (und als größerer Anbieter könnte man sicherlich auch mit mehr Personal an solche Evaluierungen herangehen), ist sicherlich unbestritten.
Das ging dort auch nicht erst mit der 6490 und der Routerfreiheit los ... wenn bei VF/KD eine 6360 bis in den Herbst 2016 mit 06.06 betrieben wurde (inzwischen ist die wohl auch bei 06.50 angelangt), dann ist das (soweit mir die Abfolge von AVM-Versionen für die KNB bekannt ist) eher dem KNB anzulasten als AVM.
-Spaßigerweise entsteht aber auch dieses "Bedürfnis" nach Firmware-Updates beim Kunden nur bei denen, die mit einer FRITZ!Box arbeiten. Wieviele Leute schreien wohl nach einer neuen Firmware für ihr Hitron- oder Arris-Modem?
Das kommt ja auch nur dadurch zustande, daß der Teil jenseits des eCM bei einer FRITZ!Box mit den jeweiligen DSL-Boxen vergleichbar ist und die Leute daher diese neuen Versionen kennen und "haben wollen". Bei anderen Herstellern gibt es aber für den Kunden auch keine Möglichkeit, sein Kabel-Modem (oder auch seinen Router) auf die Firmware-Version seiner Wahl zu updaten.
Also muß man da auch mal bei den "Bedürfnissen" die Kirche im Dorf lassen ... ich warne seit mind. zwei Jahren vor unzulässigen Analogien zwischen DSL- und DOCSIS-FRITZ!Boxen. Weil die einen (recht frei) aktualisierbar sind und irgendwelche Funktionen unterstützen, müssen das die anderen noch lange nicht - auch eine Retail-6490 ist eben (im Gegensatz zu den DSL-Modellen) vom Kunden nicht per Recovery-Programm auch irgendeine beliebige Version zu setzen.
-Wobei ich schon staune, wenn ein KNB die Telefonie bei seinen Kunden per TR-069 konfiguriert ... ich hätte jetzt (aus dem Bauch heraus) die eMTA-Konfiguration nach der (Euro-)PacketCable-Spezifikation für "genormter" gehalten und erwartet, daß KNB dann auf diese Schnittstelle setzen, weil sie damit mehr Geräte gleichzeitig "erschlagen" können.
@error_403: Konfiguriert ihr wirklich alle eigenen Geräte bei der Telefonie über TR-069 (EPC 1.5 aber sicherlich nicht, oder?) oder ist der Gerätepark da so übersichtlich, daß das kein wirkliches Problem darstellt?
Bei VF/KD kenne ich halt die TR-069-Konfiguration noch aus den Zeiten der Homebox 1 (also der 7270 und da konnte die Telefonie selbstverständlich nicht nach EPC konfiguriert werden, denn die 7270 hatte vom Kabel keine Ahnung und wurde hinter irgendeinem Modem eingesetzt) und das rettete sich dann in die 6360 (Homebox 2) hinüber (da gab es ja auch schon die Infrastruktur bei KDG dafür). Es gab dort in der Firmware sogar mal eine "Spezialaktion" für KDG (tr069:settings/tr069resetcfg = 1), bei der nur die Telefonie-Konfiguration gelöscht und neu vom ACS abgerufen wurde. Für die 6490 (als Provider-Box von KDG, die hatte ich aber nur 4 Monate bis Apr. 2015) kann ich mich eigentlich nur an Konfigurationen über den PACM-Mechanismus erinnern (und ich habe der eigentlich von Beginn an auf die Finger gesehen) - allerdings ist natürlich immer ein ACS eingetragen bei einer Provider-Box (zumindest bei VF/KD und soweit ich das gesehen habe), weil über TR-069 ja auch noch andere Geschichten (z.B. regelmäßige INFORM-Requests) abgewickelt werden können und eine Konfiguration der VoIP-Telefonie darüber höchstens ein Teilaspekt ist.
Wenn allerdings ein KNB seine eigenen Boxen ohnehin per TR-069 für die Telefonie konfiguriert, dann könnte er ja tatsächlich wieder hingehen und auch für die Kunden mit eigenen Geräten zumindest so etwas wie eine "Startkonfiguration" anbieten, bei der die - ansonsten irgendwo per Brief oder über ein Kundencenter bereitgestellten - Daten für die Telefonie einfach mal eingetragen werden, wenn der Typ des Kundengerätes unterstützt wird. Das wäre dann wirklich mal Kundendienst ... wenn ohnehin die Infrastruktur vorhanden ist und man sich als Anbieter mit dem Gerät auch noch auskennt (weil man es selbst anbietet) und obendrein der Kunde auch noch den TR-069-Zugriff gestattet (dann kann man ja auch den eigenen ACS per config setzen), dann spricht ja fast nur noch "Unwillen" (und ein bißchen "Du wirst schon sehen, was Du davon hast, wenn Du Dein eigenes Endgerät verwenden willst.") dagegen.
Das ist sicherlich für den Provider ein (kleiner) zusätzlicher Aufwand ... aber dann auch wieder einer, der als "echter Kundendienst" verstanden werden kann. Bisher habe ich "die Provider" immer mit dem Argument in Schutz genommen, daß die bei der 6490 ihre eigenen Boxen gar nicht per TR-069 konfigurieren bei den VoIP-Accounts - das fällt ja dann praktisch weg (wobei ich bei VF/KD immer noch der Ansicht bin, daß die nicht (mehr) über TR-069 konfigurieren - aber ich habe leider keine Möglichkeit, auf einen VF/KD-Anschluß mit Provider-Router zuzugreifen).
Selbst wenn es kein gesondertes Interface ist und vielleicht ein paar QoS-Settings fehlen, dürfte das generelle Vorgehen bei so einer Konfiguration so weit identisch sein, daß man es auch für das erste WAN-Interface anbieten könnte ... wenn man nicht den eigenen ACS so betreibt (mit internen Adressen), daß er nur über ein gesondertes Interface erreichbar ist (welches dann bei den Kundengeräten wieder nicht konfiguriert wird). Man kann ja beim FRITZ!OS auch ziemlich frei konfigurieren, auf welchem Interface man eigentlich TR-069 betreiben will ... bis hin zu einem komplett eigenen, nur für TR-069.
-Ich habe mal ein wenig gekramt und bei der 06.10 für die 6490 (am 02.01.2015) sah die Interface-Konfiguration dann so aus:
Da wurde also für die Telefonie und für TR-069 ein gesondertes (gemeinsames) Interface mit interner Adresse konfiguriert - dieses gesonderte Interface gab es auch schon bei der 6360, da arbeitete das aber (ebenfalls bei KDG) noch mit öffentlichen IP-Adressen:
Für SNMP von der CMTS-Seite gab es dann noch ein "wan0"-Interface mit einer internen IP (aus einem 10er-Netz) und wenn TR-069 dort aktiv gewesen sein sollte (der Port wird vom "ctlmgr" geöffnet, es gibt aber keine Weiterleitungen ... m.E. war vor "wan0" überhaupt keine Firewall aktiv und damit brauchte es auch keine Freigaben), dann kann ich das heute aus den Support-Daten nicht mehr herauslesen.
Das handhabt also selbst ein und derselbe Provider (im Laufe der Zeit und mit verschiedenen Geräten) vollkommen unterschiedlich ... mir fiele jetzt nur ein einziger Weg ein, auf dem man vielleicht feststellen könnte, wie VF/KD da nun wirklich heutzutage die eigenen 6490 konfiguriert. Vielleicht ist das ja auch dort (wenn @error_403 von ständigen Änderungen durch AVM an dieser Stelle berichtet) von der Firmware-Version auf der Box abhängig ... und zumindest haben die Leute, die ansonsten immer der Meinung waren, der Provider könne die Firmware-Version ja gar nicht ermitteln, das jetzt auch noch mal von jemandem gelesen, der (offenbar) bei einem KNB arbeitet.
In einer "frischen" Box (also ohne jegliche Konfiguration) könnte jedenfalls nach SIP-Konfiguration über SNMP noch die Datei "/var/tmp/snmp_sip.lua" in der Support-Datei beim Inhalt von "/var/tmp" auftauchen (die ist allerdings beim Reboot weg) - zumindest ist in der "pacm_state_changed" (die gibt es auch in der 06.83 für die Retail-Modelle, nur wird sie halt nie aufgerufen) nichts in Richtung des Löschens dieser Datei zu sehen. Die ausführlichere Protokollierung für TR-069 in den Supportdaten (über "showshringbuf tr069") gibt es m.W. erst in den neueren Versionen ... die wird vielleicht noch nicht mal in der 06.65 bei KDG enthalten sein (in der 06.6x für die Retail war das auch noch nicht drin).
Selbst ein "Der Dienstanbieter hat [...] übertragen." im Event-Log ist noch kein sicheres Zeichen ... da steht ja nicht dabei, welche Einstellungen das nun waren und das geht von Update-Erlaubnis über das GUI bis zum INFORM-Intervall, was da sonst noch so gesetzt werden könnte.
Ok, hier kommen sicherlich die kleineren Provider (und das ist für mich alles außer VF/KD und LGI/UM) bei solchen Betrachtungen immer etwas unter die Räder, aber in diesen Threads geht es ja auch fast immer um Updates ehemaliger Provider-Boxen und - zumindest soweit ich das bisher kenne - diese Geräte gab es dann lange Zeit nur von den beiden (ganz) Großen - die Zahl der "anderen" Geräte von solchen Anbietern (von m-net bis Primacom) ist sicherlich eher überschaubar (zumindest im Vergleich).
Ich gebe es frank und frei zu, daß ich bis eben nicht mal mitbekommen hatte, daß es bei der Primacom auch die 6490 als Mietgerät (oder Überlassung oder wie auch immer - entscheidend ist "vom Provider") gibt. Ist das schon lange der Fall? Es macht ja auch Sinn, solange EPC 2.0/RST für die Telefonie vom Provider genutzt wird - daß es da bei den ganzen TC-Töchtern durchaus unterschiedliche Infrastruktur gibt, geht häufig etwas unter und daher habe ich bei "TC" eigentlich immer die Schranke im Kopf: EPC 1.5 -> keine AVM-Geräte. Ich werde mir aber merken, daß auch Primacom zu den Anbietern einer Provider-6490 gehört. :mrgreen:
Wenn ich von KNB schreibe, meine ich halt diejenigen, die ihren Kunden 6490 mit einer Firmware zur Verfügung stellen, wo ein eMTA konfiguriert werden kann. Daß da Primacom auch dazu zählt, war mir bisher gar nicht bewußt. Daher will ich auch die Update-Politik von Primacom gar nicht beurteilen ... das kann ich auch gar nicht, ich wußte bisher ja nicht einmal, daß es da eine solche geben könnte (in Bezug auf FRITZ!Boxen, bei anderen CM ist es ja genauso, wenn auch sicherlich seltener Updates erscheinen).
Wenn man sich bei Primacom also tatsächlich um einen zeitnahen Rollout bemüht, hebt das diesen KNB ja trotzdem von den (beiden) anderen ab ... denn daß es dort extrem lange dauert (und als größerer Anbieter könnte man sicherlich auch mit mehr Personal an solche Evaluierungen herangehen), ist sicherlich unbestritten.
Das ging dort auch nicht erst mit der 6490 und der Routerfreiheit los ... wenn bei VF/KD eine 6360 bis in den Herbst 2016 mit 06.06 betrieben wurde (inzwischen ist die wohl auch bei 06.50 angelangt), dann ist das (soweit mir die Abfolge von AVM-Versionen für die KNB bekannt ist) eher dem KNB anzulasten als AVM.
-Spaßigerweise entsteht aber auch dieses "Bedürfnis" nach Firmware-Updates beim Kunden nur bei denen, die mit einer FRITZ!Box arbeiten. Wieviele Leute schreien wohl nach einer neuen Firmware für ihr Hitron- oder Arris-Modem?
Das kommt ja auch nur dadurch zustande, daß der Teil jenseits des eCM bei einer FRITZ!Box mit den jeweiligen DSL-Boxen vergleichbar ist und die Leute daher diese neuen Versionen kennen und "haben wollen". Bei anderen Herstellern gibt es aber für den Kunden auch keine Möglichkeit, sein Kabel-Modem (oder auch seinen Router) auf die Firmware-Version seiner Wahl zu updaten.
Also muß man da auch mal bei den "Bedürfnissen" die Kirche im Dorf lassen ... ich warne seit mind. zwei Jahren vor unzulässigen Analogien zwischen DSL- und DOCSIS-FRITZ!Boxen. Weil die einen (recht frei) aktualisierbar sind und irgendwelche Funktionen unterstützen, müssen das die anderen noch lange nicht - auch eine Retail-6490 ist eben (im Gegensatz zu den DSL-Modellen) vom Kunden nicht per Recovery-Programm auch irgendeine beliebige Version zu setzen.
-Wobei ich schon staune, wenn ein KNB die Telefonie bei seinen Kunden per TR-069 konfiguriert ... ich hätte jetzt (aus dem Bauch heraus) die eMTA-Konfiguration nach der (Euro-)PacketCable-Spezifikation für "genormter" gehalten und erwartet, daß KNB dann auf diese Schnittstelle setzen, weil sie damit mehr Geräte gleichzeitig "erschlagen" können.
@error_403: Konfiguriert ihr wirklich alle eigenen Geräte bei der Telefonie über TR-069 (EPC 1.5 aber sicherlich nicht, oder?) oder ist der Gerätepark da so übersichtlich, daß das kein wirkliches Problem darstellt?
Bei VF/KD kenne ich halt die TR-069-Konfiguration noch aus den Zeiten der Homebox 1 (also der 7270 und da konnte die Telefonie selbstverständlich nicht nach EPC konfiguriert werden, denn die 7270 hatte vom Kabel keine Ahnung und wurde hinter irgendeinem Modem eingesetzt) und das rettete sich dann in die 6360 (Homebox 2) hinüber (da gab es ja auch schon die Infrastruktur bei KDG dafür). Es gab dort in der Firmware sogar mal eine "Spezialaktion" für KDG (tr069:settings/tr069resetcfg = 1), bei der nur die Telefonie-Konfiguration gelöscht und neu vom ACS abgerufen wurde. Für die 6490 (als Provider-Box von KDG, die hatte ich aber nur 4 Monate bis Apr. 2015) kann ich mich eigentlich nur an Konfigurationen über den PACM-Mechanismus erinnern (und ich habe der eigentlich von Beginn an auf die Finger gesehen) - allerdings ist natürlich immer ein ACS eingetragen bei einer Provider-Box (zumindest bei VF/KD und soweit ich das gesehen habe), weil über TR-069 ja auch noch andere Geschichten (z.B. regelmäßige INFORM-Requests) abgewickelt werden können und eine Konfiguration der VoIP-Telefonie darüber höchstens ein Teilaspekt ist.
Wenn allerdings ein KNB seine eigenen Boxen ohnehin per TR-069 für die Telefonie konfiguriert, dann könnte er ja tatsächlich wieder hingehen und auch für die Kunden mit eigenen Geräten zumindest so etwas wie eine "Startkonfiguration" anbieten, bei der die - ansonsten irgendwo per Brief oder über ein Kundencenter bereitgestellten - Daten für die Telefonie einfach mal eingetragen werden, wenn der Typ des Kundengerätes unterstützt wird. Das wäre dann wirklich mal Kundendienst ... wenn ohnehin die Infrastruktur vorhanden ist und man sich als Anbieter mit dem Gerät auch noch auskennt (weil man es selbst anbietet) und obendrein der Kunde auch noch den TR-069-Zugriff gestattet (dann kann man ja auch den eigenen ACS per config setzen), dann spricht ja fast nur noch "Unwillen" (und ein bißchen "Du wirst schon sehen, was Du davon hast, wenn Du Dein eigenes Endgerät verwenden willst.") dagegen.
Das ist sicherlich für den Provider ein (kleiner) zusätzlicher Aufwand ... aber dann auch wieder einer, der als "echter Kundendienst" verstanden werden kann. Bisher habe ich "die Provider" immer mit dem Argument in Schutz genommen, daß die bei der 6490 ihre eigenen Boxen gar nicht per TR-069 konfigurieren bei den VoIP-Accounts - das fällt ja dann praktisch weg (wobei ich bei VF/KD immer noch der Ansicht bin, daß die nicht (mehr) über TR-069 konfigurieren - aber ich habe leider keine Möglichkeit, auf einen VF/KD-Anschluß mit Provider-Router zuzugreifen).
Selbst wenn es kein gesondertes Interface ist und vielleicht ein paar QoS-Settings fehlen, dürfte das generelle Vorgehen bei so einer Konfiguration so weit identisch sein, daß man es auch für das erste WAN-Interface anbieten könnte ... wenn man nicht den eigenen ACS so betreibt (mit internen Adressen), daß er nur über ein gesondertes Interface erreichbar ist (welches dann bei den Kundengeräten wieder nicht konfiguriert wird). Man kann ja beim FRITZ!OS auch ziemlich frei konfigurieren, auf welchem Interface man eigentlich TR-069 betreiben will ... bis hin zu einem komplett eigenen, nur für TR-069.
-Ich habe mal ein wenig gekramt und bei der 06.10 für die 6490 (am 02.01.2015) sah die Interface-Konfiguration dann so aus:
Code:
Networking
----------
cat: can't open '/var/dsld.autodetect': No such file or directory
time: 2015-01-02 16:02:43
0: sync_cable: CABLE (showtime)
maxspeed 106000000 6360000 106Mbit/s 6.36Mbit/s
actual 7248 400 7.25Kbit/s 400bit/s
0.01% 0.01%
running (voip=1,tr069=1,tv=0,ntp=0,ipv6=0,ipv4=0,vpn=0)
Active Provider: -
PPPoE Forward: disabled
0: name internet
0: sync_group: sync_cable
0: iface erouter0 RBE/14/dsl 34:31:c4:87:d9:e2 stay online 1 (prop: default internet)
0: IPv6: off
0: IPv4: native
0: IPv4: connected since 2014-12-27 21:41:13 (setup time 0 secs) (connect cnt 1)
0: IPv4: disconnect prevention disabled
0: IPv4: ip 91.65.203.229 mask 255.255.255.0 gw 91.65.203.254 dhcp mtu 1500
0: IPv4: masqaddr 91.65.203.229
0: IPv4: dns 83.169.184.33 83.169.184.97
0: route 91.65.203.0/24 protocol iface
0: route 83.169.184.33/32 protocol dns
0: route 83.169.184.97/32 protocol dns
0: RX bytes:1438382926 pkt error:0 discard:0 filtered:4379 dropped:347
0: RX pkts:4170596 unicast:1307123 multicast:166940 broadcast:2696533
0: TX bytes:136013601 pkt error:0 discard:0 filtered:0 dropped:47
0: TX pkts:918907 unicast:917317 multicast:0 broadcast:1590
[COLOR="#FF0000"]1: name voip+tr069[/COLOR]
1: sync_group: sync_cable
1: iface mta0 RBE/14/dsl 34:31:c4:87:d9:e7 stay online 1 (voip)
1: IPv6: off
1: IPv4: native
1: IPv4: connected since 2014-12-27 21:41:16 (setup time 3 secs) (connect cnt 1)
1: IPv4: disconnect prevention disabled
[COLOR="#FF0000"]1: IPv4: ip 10.4.243.85 mask 255.255.248.0 gw 10.4.247.254 dhcp mtu 1500[/COLOR]
1: IPv4: masqaddr 10.4.243.85
1: IPv4: dns 83.169.184.33 83.169.184.97
1: route 10.4.240.0/21 protocol iface
1: RX bytes:177241399 pkt error:0 discard:0 filtered:0 dropped:0
1: RX pkts:2864895 unicast:1422 multicast:166940 broadcast:2696533
1: TX bytes:940658 pkt error:0 discard:0 filtered:0 dropped:0
1: TX pkts:3744 unicast:3687 multicast:0 broadcast:57
Code:
Networking
----------
cat: can't open '/var/dsld.autodetect': No such file or directory
mode: CABLE
cpmacconfig:normal
running (voip=1,tr069=0,tv=0,ntp=0)
speed 106000000/6360000 token 5000
PPPoE Forward: disabled
time: 2013-07-15 00:48:42
0: name internet
0: iface erouter0 RBE/14/dsl 9c:c7:a6:87:26:22 stay online 1
0: IPv6: off
0: IPv4: native
0: IPv4: connected since 2013-07-14 16:01:49 (setup time 1 secs) (connect cnt 3)
0: IPv4: next disconnect time is never
0: IPv4: ip 91.65.212.12 mask 255.255.248.0 gw 91.65.215.254 dhcp mtu 1500
0: IPv4: masqaddr 91.65.212.12
0: IPv4: dns 83.169.184.33 83.169.184.97
0: route 91.65.208.0/21 protocol iface
0: mc to wan 239.0.0.250 (unknown)
0: RX bytes:2946041621 pkt error:0 discard:0 filtered:2142 dropped:1868718
0: RX pkts:4402903 unicast:1962970 multicast:548725 broadcast:1891208
0: TX bytes:87147779 pkt error:0 discard:0 filtered:0 dropped:166
0: TX pkts:913861 unicast:912858 multicast:190 broadcast:813
1: name voip
1: iface erouter0 RBE/14/dsl 9c:c7:a6:87:26:26 stay online 1 (voip)
1: IPv6: off
1: IPv4: native
1: IPv4: connected since 2013-07-14 16:01:49 (setup time 1 secs) (connect cnt 3)
1: IPv4: next disconnect time is never
1: IPv4: ip 91.65.212.13 mask 255.255.248.0 gw 91.65.215.254 dhcp mtu 1500
1: IPv4: masqaddr 91.65.212.13
1: IPv4: dns 83.169.184.33 83.169.184.97
1: RX bytes:166903791 pkt error:0 discard:0 filtered:621 dropped:1868493
1: RX pkts:2443922 unicast:3989 multicast:548725 broadcast:1891208
1: TX bytes:1196570 pkt error:0 discard:0 filtered:0 dropped:0
1: TX pkts:4349 unicast:4107 multicast:0 broadcast:242Das handhabt also selbst ein und derselbe Provider (im Laufe der Zeit und mit verschiedenen Geräten) vollkommen unterschiedlich ... mir fiele jetzt nur ein einziger Weg ein, auf dem man vielleicht feststellen könnte, wie VF/KD da nun wirklich heutzutage die eigenen 6490 konfiguriert. Vielleicht ist das ja auch dort (wenn @error_403 von ständigen Änderungen durch AVM an dieser Stelle berichtet) von der Firmware-Version auf der Box abhängig ... und zumindest haben die Leute, die ansonsten immer der Meinung waren, der Provider könne die Firmware-Version ja gar nicht ermitteln, das jetzt auch noch mal von jemandem gelesen, der (offenbar) bei einem KNB arbeitet.
In einer "frischen" Box (also ohne jegliche Konfiguration) könnte jedenfalls nach SIP-Konfiguration über SNMP noch die Datei "/var/tmp/snmp_sip.lua" in der Support-Datei beim Inhalt von "/var/tmp" auftauchen (die ist allerdings beim Reboot weg) - zumindest ist in der "pacm_state_changed" (die gibt es auch in der 06.83 für die Retail-Modelle, nur wird sie halt nie aufgerufen) nichts in Richtung des Löschens dieser Datei zu sehen. Die ausführlichere Protokollierung für TR-069 in den Supportdaten (über "showshringbuf tr069") gibt es m.W. erst in den neueren Versionen ... die wird vielleicht noch nicht mal in der 06.65 bei KDG enthalten sein (in der 06.6x für die Retail war das auch noch nicht drin).
Selbst ein "Der Dienstanbieter hat [...] übertragen." im Event-Log ist noch kein sicheres Zeichen ... da steht ja nicht dabei, welche Einstellungen das nun waren und das geht von Update-Erlaubnis über das GUI bis zum INFORM-Intervall, was da sonst noch so gesetzt werden könnte.
Ok 6.65 ist rein KDG, dazu kann ich nix sagen was beinhalten rücksetzen?
Ich weiß (da uns das auch passiert ist) das die 6.60 und 6.61 per Downgrade auf die 6.50 gebracht werden konnten durch ein Fehler, der numal pasieren kann (Boxen wurden ersetzt)
Seit der 6.62 ist es unmöglich per DOCSIS eine Fritzbox wieder auf eine 6.50 zu bekommen. Ich hatte es erst neulich mit einen Business Kunden der die tollen neuen Routing Funktionen (????) der 6.83 nutzen wollte. Es gab keine Chance bis er auf die 6.61 gegangen ist, dann lief auch das Downgrade durch,
Allerdings beobachte ich sämtiche Boxen mit welcher Firmware sie kommen ob es passt, Mietboxen 6.5x oder 6.83-Labor, bei Retail schaue ich ich mir alles an was unter 6.60 ist, Die werden auch net gesperrt aber Beobachtung was so los ist kann nie schaden
Edit: Nur kurz gelesen vielleicht kommt noch eine längere Antwort
@ PeterPawn, die 6490 ist das einzige Gerät zwecks Telefonie un TR-069 was dem SIP geschuldet sit, die kann ja kein PacketCable 1.5
Alle anderen Boxen sind MGCP also PacketCable 1.5 und sind nicht im ACS und auch in keinem anderen TR-69 Server
Edit: Primacom hat die 6490 seit August 2016 in Betrieb laut Forum, wenn nicht eher
Zuletzt bearbeitet:
Zurücksetzen beinhaltet neueste Provider Firmware und alle Einstellungen die ich gemacht hab sind weg und die Telefonie wird dann eingerichtet. So wie du es beschreibst werde ich mit meiner 6.83 Probleme haben auf die neueste KDG zurückzugehen wenn die Telefonie mal wieder nicht will. Wie gut das ich das Image von der Retail die ich vorher drauf hatte noch hab, das wird dann wohl eingespielt werden müssen. Genaueres werde ich bestimmt in so etwa einem Monat sagen können, dann wäre es mal wieder Zeit für mein Problem.
Jetzt nur mal so aus Interesse, sind bei euch im Netz auch Boxen mit aktivem Provider Branding? Also wenn z.B. jemand eine Box auf ebay gekauft hat und die einfach stumpf mit z.B. KDG Branding an den Anschluss hängt? Die sollten ja eigentlich funktionieren, oder? Gut, Telefonie kann man nicht einrichten aber ansonsten hat man ja erstmal alles was man so brauchen könnte.
Jetzt nur mal so aus Interesse, sind bei euch im Netz auch Boxen mit aktivem Provider Branding? Also wenn z.B. jemand eine Box auf ebay gekauft hat und die einfach stumpf mit z.B. KDG Branding an den Anschluss hängt? Die sollten ja eigentlich funktionieren, oder? Gut, Telefonie kann man nicht einrichten aber ansonsten hat man ja erstmal alles was man so brauchen könnte.
Gibt genug Boxen mit 6.50 die im Netz sind auch genug wo ich weiß das es keine Retail Box sein kann mit > 6.60, Was soll es mich jucken solange es die gültigen Zertifikate hat. Klar ich hab ne Liste aber erher aus Interesse (MAC Adressen bis wann so was war von Versionen und Bootloader)
Aber ausgesperrt wird niemand solange die Zertifikate passen.
Wer aber eine Mietbox updatet und nicht kooperativ ist, der sollte sich mal die die TLV 202 anschauen (ja tatsächlich diesselbe wo der ACS gesetzt wird) und wird sehen man kann die Box tatsächlich als Modem betreiben (nicht LAN Bridge)
Neueste Beiträge
-
[Sammlung] AVM-Gateway-kompatible Zigbee-Geräte
- Letzte: Erforderlich
-
Yealink SIP T42U keine Auslandsgepräche
- Letzte: KunterBunter
-
Fritzbox als SIP-Gateway bzw. DECT-Station an NetCologne Anschluss
- Letzte: KunterBunter
-
AVM Geofencing - Smart Home: Fragen
- Letzte: sentry80
-
[Sammlung] Fritz!Box 7690 Labor/INHAUS Zyklus Smart24P1FCS - Fw ab 7.90
- Letzte: frank.lennert20
-
[Frage] Kompletter Ausfall von DNS over TLS (DoT)
- Letzte: DerderkeineAhnunghat
-
Fritz Dect200: Temperaturabhängig plus manuelle Schaltung
- Letzte: Erforderlich
