Eine gute Nachricht für die Leute, die auf der Suche nach der "capture.lua" bei der 6490 waren und sind ... bei der 06.62 hat AVM die mehrfach zitierte Abfrage nunmehr auf
Code:
--- 141.06.61/usr/www/avm/capture.lua 2016-07-26 17:58:51.000000000 +0200
+++ 141.06.62/usr/www/avm/capture.lua 2016-08-23 16:30:27.000000000 +0200
@@ -8,7 +8,7 @@
g_page_title = [[{?946:222?}]]
------------------------------------------------------------------------------------------------------------>
dofile("../templates/global_lua.lua")
-if config.DOCSIS and config.gu_type == 'release' then
+if config.DOCSIS and config.gu_type == 'release' [COLOR="#FF0000"]and config.oem ~= "avm"[/COLOR] then
http.redirect("")
end
if box.get.xhr and box.get.wlantrace
geändert ... damit ist dann bei Branding "avm" der Paketmitschnitt auch wieder "freigegeben". Alle Spekulationen, daß dieser "unerwünscht" sein könnte, sind damit obsolet - es war also wohl doch nur ein Versehen, wenn es bisher fehlte. Das ist nunmehr auch nicht nur eine versehentliche oder falsche Änderung (das hätte bei drei AND-Verknüpfungen ja auch vorkommen können), die korrespondierenden Stellen in der "menu_data.lua" und der "support.lua" wurden ebenfalls geändert.
Damit fehlt in der Liste der Änderungen in #1 also noch die Feststellung, daß der Paketmitschnitt nunmehr bei der 6490 auch möglich ist - was mich persönlich zwar verblüfft, aber AVM wird sich ja etwas dabei gedacht haben (das ist keine zufällige Änderung).
Damit kann man dann endlich auch auf Spekulationen verzichten, wie so eine Provisionierung im Kabelnetz abläuft ... wer sich wirklich dafür interessiert, sollte das eigentlich auf dem "DOCSIS Management"-Interface mitschneiden können (wenn meine Interpretation des "DOCSIS Management" nicht falsch ist, leider habe ich genau für dieses Interface keinen alten Mitschnitt aus 2015 mehr). Damit der Mitschnitt auch rechtzeitig beginnt (das GUI steht ja erst später zur Verfügung), kann man ja auch das Kabel für das eCM erst später verbinden.
Die Interfaces unterscheiden sich ja deutlich von denen anderer Boxen, hier kann zur Einordnung dann ein Blick in die eDOCSIS-Spezifikation nicht schaden (S. 11, Bild 5-1 und S. 21, Bild 5-16).
So weit ich weiß (und das ist nicht allzu weit), verbirgt sich hinter den Namen dann folgendes (ich kann die Box aber im Moment nicht am Kabelanschluß betreiben, mangels Vertrag):
| acc0 | |
| tunl0 |
- ein Interface für Linux-IP-Tunnel, habe ich bisher auch noch nicht aktiv erlebt
- entweder es kommt bei L2TPv3 für Repeater zum Einsatz oder eben
- bei einem Tunnel zum Provider für die "Homespot"-Geschichte (oder wie auch immer das bei UM heißen mag)
- ist die erste Vermutung richtig, wird man bei aktivem Repeater hier etwas sehen (nur, wenn der "LAN-Bridge" ist, das WLAN kommt aus einem anderen Interface)
- den Tunnel zum Provider gibt es m.W. in den Retail-Boxen nicht, auch wenn sicherlich jedem schon mal der leere Eintrag "hotspotcfg" in einer exportierten Datei (in der ar7.cfg) aufgefallen ist
|
| l2sd0* |
- anders als in den DSL-Modelle heißen hier die Schnittstellen des Switches in der Box nicht "ethX", sondern l2sd0.X
- m.E. (das ist jetzt ungetestet) ist der Uplink bei LAN1-Modus dann l2sd0.1000 und
- das Gastnetz, sofern es über WLAN "ankommt", die l2sd0.99 - das kommt hier vom ATOM-Core, weil der das WLAN verwaltet
- das Gastnetz, wenn es über das LAN-Kabel geht, l2sd0.4
- die "allgemeine" l2sd0-Schnittstelle ist dann nach meinen Begriffe die Zusammenfassung aller l2sd0-Interfaces
|
| cni0 |
- das müßte die "netzseitige" Schnittstelle des eCM sein (cable network interface), ob das nun die MAC-Bridge (in den Bilder 5-3 ff. bei den einzelnen eSAFE-Modellen das, was links steht und in Bild 5-1 das rechte Interface des mittleren "Kastens" bei den eCM-Interfaces) oder das linke im mittleren Kasten in Bild 5-1 ist, weiß ich auch nicht, spielt für die meisten wahrscheinlich ohnehin keine Rolle
- noch weiter "nach links" in die Richtung des RF-Interfaces dürfte es nicht gehen, das sollte "in Hardware" laufen und nicht für das CM bestimmte Pakete sollten es auch nicht bis zu dieser Schnittstelle schaffen
- wobei es wohl eher die linke Schnittstelle in 5-1 ist, denn die rechte ist (nach meinem Verständnis) eher "lbr0"
|
| lbr0 |
- das müßte die "clientseitige" Schnittstelle des eCM sein (local bridge), im Prinzip das gesamte CMCI, was aus so einem CM "rauskommen" darf bzw. soll
|
| lan0 |
- das ist das LAN-seitige Diagnose-Interface mit der IP-Adresse 192.168.100.1, siehe OSSI-Spezifikation, Punkt 9.1
|
| wan0 |
- hier bin ich mir ziemlich unsicher ... von meiner alten 6490 kenne ich dieses Interface (aus den Supportdaten) als eines, wo der netzseitige Zugriff auf den SNMP-Stack möglich war
- praktisch das netzseitige Pendant zum lan0, wobei da m.W. mehr Kontrolle machbar war/ist, als von lan0 aus ... siehe wieder die OSSI-Spec, wer da was steuern darf und was nicht
|
| lan/guest |
- die normalen "Bridges", wie man sie auch aus den DSL-Boxen kennt
- praktisch das netzseitige Pendant zum lan0, wobei da m.W. mehr Kontrolle machbar war/ist, als von lan0 aus ... siehe wieder die OSSI-Spec, wer da was steuern darf und was nicht
|
| erouter0 |
- das (wohl einzige) "embedded Service/Application Functional Entities"-Interface, was in einer Retail-Box implementiert ist, m.E. ist das für die Telefonie kein eMTA im Sinne der DOCSIS-Spezifikation, anders als bei den Provider-Boxen
|
| esafe0 |
- das ist in meiner Vorstellung die "Zusammenfassung" sämtlichen eSAFE-Verkehrs, was wohl dann auch wieder eine 1:1-Kopie des erouter0 ergeben könnte in einer Retail-Box
|
| WLAN |
- hier ergibt sich bei der 6490 wohl das Problem, daß die WLAN-Implementierung seit einigen Versionen auf dem ATOM-Core läuft und damit auf dem ARM-Core (wo die anderen Interfaces alle liegen, auf dem ATOM-Core heißen die Schnittstellen dann auch wieder wie gewohnt "ethX" und man sieht schon an deren Fehlen, daß es eben nur ARM-Interfaces in der Liste gibt) nichts mitgeschnitten werden kann ... selbst wenn am Ende irgendein l2sd0.irgendwas-Interface vielleicht den resultierenden Traffic bieten könnte, das ganze Management, was man bei den anderen Boxen auch noch mitschneiden kann im WLAN, das fehlt hier
|
| DOCSIS management |
- das ist in meinen Augen dann auch das interessanteste Interface, wenn man sich für DOCSIS-Spezialitäten interessiert, denn hier müßten sich (wenn ich das nicht vollkommen falsch interpretiere) auch die ganzen "pre-registration"-Pakete wiederfinden (und wieder kann ich nicht wirklich nachsehen bzw. hier will ich es nicht, weil ich die Box nicht mit eingeschaltetem eCM an den Kabelanschluß hängen will - bei mir ist auf diesem Interface jedenfalls absolute Ruhe im LAN1-Modus)
- vielleicht macht ja mal jemand mit einer 6490 (mit aktivem eCM) an einem BK-Anschluß und der 06.62 in der Box einen Mitschnitt auf diesem Interface ... bei der Interpretation bin ich gerne behilflich
|
Das bitte alles mit einer gehörigen Portion Skepsis lesen ... es ist bei einer Box im LAN1-Modus nicht ohne weiteres möglich, die Daten auf den ganzen eDOCSIS-Schnittstellen mitzuschneiden und zu interpretieren - einfach weil diese ohne aktiven CM-Modus fast alle gar nicht aktiviert werden. Einiges ist also auch nur Rückschluß aus meiner alten 6490 mit 06.10 aus dem Frühjahr 2015 - wobei sich Schnittstellennamen und Inhalte sicherlich nicht so grundlegend ändern - und ein paar älteren Mitschnitten aus dieser Box, als ich noch bei KDG Kunde mit einem Internet-Anschluß war.
Sollte jemand Fehler finden, korrigiere ich diese gerne ...
Ob das interne Interface (das hat sicherlich jeder auch schon in seinen Support-Daten gesehen, es ist das mit der 169.254.1.1 und die kann man - anders als bei den DSL-Modellen und auch da geht das im Prinzip seit einiger Zeit nicht mehr komplikationslos - hier auch nicht guten Gewissens ändern) auch irgendwo in einem Mitschnitt auftaucht, habe ich noch nicht probiert, in den Support-Daten steht es als "lan:0" (nicht mit "lan0" verwechseln). Schaut man dann bei der ar7.cfg (in den Export-Daten) einer 6490 vorbei, sieht man dort zwar das Interface "lan:0" auf beiden Cores (der ATOM-Core kriegt seine IP-Konfiguration aus "br2interfaces") und es steht dort in trauter Eintracht mit den lokalen Bridges (lan und guest), aber intern ist es wohl doch anders geregelt, denn bei den "richtigen" Bridges taucht es dann wieder nicht mehr auf.
Ich kann auch nur dringend davon abraten, an den Adressen dieser LAN-Interfaces (also lan:0 auf beiden Kernen) irgendwie "herumzuspielen" ... deren Adressen werden intern noch oft genug verwendet und zwar genau in der Form 169.254.1.1 und .2 - wer hier also experimentieren will, sollte sich
lange vorher einen Plan zurechtlegen, wie er im Falle eines Problems seine Box wieder so weit gestartet bekommt, daß er so eine Änderung dann rückgängig machen kann; das ist nicht so einfach, wie das auf den ersten Blick wirken mag, solange es kein Recovery-Programm gibt.
Ähnliches gilt auch für die Konfiguration des LAN-Segments auf die IP-Adresse 192.168.100.1/24 ... wegen des möglichen Konfliktes mit der 192.168.100.1 aus der OSSI-Spezifikation würde ich das ebenfalls nur probieren, wenn ich einen Plan hätte, wie ich im Notfall wieder zurück komme ... sollte der "ctlmgr" aus irgendeinem Grund nicht starten wollen oder abstürzen, wenn die "lan"-Bridge nicht richtig konfiguriert werden kann (falls das lan0-Interface seine Adresse zuerst erhält, was ich nicht einschätzen kann), dann könnte auch der Zugriff auf das Wiederherstellen von Einstellungen oder sogar auf "Werkseinstellungen" zum Problem werden.
