@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:
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
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:
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:242
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.