[Erledigt] FRITZ!Box 6490 - SNMP-Zugriff auf 192.168.100.1 nach Update auf 06.83?

[PeterPawn]

Vielleicht kann ja jemand von gegenteiligen Erfahrungen berichten ... hier meine Ergebnisse beim Test des Zugriffs auf das lokale Management-Interface:

• Beschrieben/spezifiziert ist dieser Zugriff in der DOCSIS-Spezifikation (Teil OSSI) im Punkt 9.1 - dort steht ziemlich unzweideutig:
  

  The CM MUST support SNMP access, as specified in Section 8.5.4.2, through the following IP addresses regardless of the CM registration state:
  
  • The CM MUST support 192.168.100.1, as the well-known diagnostic IP address accessible only from the CMCI interfaces. The CM MUST support the well-known diagnostic IP address, 192.168.100.1, on all physical interfaces associated with the CMCI. The CM MUST drop SNMP requests coming from the RF interface targeting the well-known IP address.

• Angesichts des "regardless of registration state" sollte so ein Zugriff auch dann funktionieren, wenn das CM provisioniert ist und arbeitet.
• Um SNMP-Zugriff zu ermöglichen, braucht es erst einmal eine korrekte IP-Konfiguration für ein entsprechendes Interface; das soll in der neuen AVM-Firmware offenbar das Interface "lan0" auf dem ARM-Core übernehmen.
• Dieses "lan0"-Interface wird mit einer MAC-Adresse konfiguriert, die bei meiner 6490 im Environment als "usb_rndis_mac" geführt wird - das ist hier die CM-MAC (steht als "macdsl" im Environment) + 2.
• An dieses Interface (bzw. an seine IP-Adresse) sind folgende Dienste gebunden:
  

  # netstat -anp | grep 100\.1
  tcp        0      0 192.168.100.1:80        0.0.0.0:*               LISTEN      709/pumaglued
  tcp        0      0 192.168.100.1:443       0.0.0.0:*               LISTEN      709/pumaglued
  udp        0      0 192.168.100.1:161       0.0.0.0:*                           948/snmp_agent_cm
  udp        0      0 192.168.100.1:162       0.0.0.0:*                           948/snmp_agent_cm

  Das ist also einmal der von der DOCSIS-Spezifikation geforderte SNMP-Zugriff (i.d.R. nur read-only und mit eingeschränktem Vorrat an SNMP-Settings, die man abfragen kann) und ein Proxy-Service, der HTTP(S)-Zugriffe auf diese IP-Adresse auf den ATOM-Core (und dort auf das GUI) weiterleiten soll. Letzterer ist zumindest für den Port 443 vermutlich auch schon mal "bullshit", weil zwar im "pumaglued" die Weiterleitung auf die 169.254.1.1 (also den ATOM-Core) gesetzt wird:
  

  # showshringbuf pumaglued
  1970-01-01 01:00:23.202 - syncstate: InitState: *UNKNOWN* -> NOT RUNNING
  1970-01-01 01:00:23.206 - syncstate: setup module done.
  1970-01-01 01:00:23.348 - voipdqos: setup module done.
  1970-01-01 01:00:23.350 - docsis: setup module done.
  1970-01-01 01:00:23.351 - pumacmflt: setup module done.
  1970-01-01 01:00:24.844 - syncstate: InitState: NOT RUNNING -> NOT SYNCHRONIZED (NOT READY)
  1970-01-01 01:00:29.365 - tcpproxy: 192.168.100.1:80 -> 169.254.1.1:80
  1970-01-01 01:00:29.366 - tcpproxy: 192.168.100.1:443 -> 169.254.1.1:443
  1970-01-01 01:00:29.366 - tcpproxy: init done.
  1970-01-01 01:00:32.122 - pumacmflt: snmp_allowed: 0
  1970-01-01 01:00:32.132 - pumacmflt: tr069_allowed: 0
  1970-01-01 01:00:32.223 - startstop: start: undef -> start
  1970-01-01 01:00:49.844 - syncstate: InitState: NOT SYNCHRONIZED (NOT READY) -> NOT SYNCHRONIZED
  1970-01-01 01:00:50.844 - syncstate: InitState: NOT SYNCHRONIZED -> RANGING IN PROGRESS (DS TOPOLOGY RESOLUTION)
  1970-01-01 01:00:50.844 - syncstate: SyncState: no-sync -> training
  1970-01-01 01:00:53.843 - syncstate: InitState: RANGING IN PROGRESS (DS TOPOLOGY RESOLUTION) -> REGISTRATION: US PARAMETERS ACQUIRED
  1970-01-01 01:00:54.843 - syncstate: InitState: REGISTRATION: US PARAMETERS ACQUIRED -> RANGING IN PROGRESS
  1970-01-01 01:01:01.844 - syncstate: InitState: RANGING IN PROGRESS -> NOT SYNCHRONIZED
  1970-01-01 01:01:01.844 - syncstate: SyncState: training -> no-sync
  1970-01-01 01:01:02.843 - syncstate: InitState: NOT SYNCHRONIZED -> RANGING IN PROGRESS (DS TOPOLOGY RESOLUTION)
  1970-01-01 01:01:02.843 - syncstate: SyncState: no-sync -> training
  1970-01-01 01:01:05.844 - syncstate: InitState: RANGING IN PROGRESS (DS TOPOLOGY RESOLUTION) -> REGISTRATION: US PARAMETERS ACQUIRED
  1970-01-01 01:01:07.843 - syncstate: InitState: REGISTRATION: US PARAMETERS ACQUIRED -> RANGING IN PROGRESS
  1970-01-01 01:01:14.843 - syncstate: InitState: RANGING IN PROGRESS -> RANGING COMPLETE
  1970-01-01 01:01:16.843 - syncstate: InitState: RANGING COMPLETE -> REGISTRATION: DHCPV6 IN PROGRESS
  2017-05-14 20:59:16.575 - docsis: erouter on
  2017-05-14 20:59:16.576 - docsis: edva off
  2017-05-14 20:59:16.576 - docsis: emta off
  2017-05-14 20:59:16.578 - docsis: B2B: commit start
  2017-05-14 20:59:16.579 - docsis: B2B: add l2sd0.2 erouter0
  2017-05-14 20:59:16.579 - docsis: B2B: commit end
  2017-05-14 20:59:16.582 - docsis: B2B: commit start
  2017-05-14 20:59:16.583 - docsis: B2B: commit end
  2017-05-14 20:59:16.617 - syncstate: InitState: REGISTRATION: DHCPV6 IN PROGRESS -> REGISTRATION: CONFIG FILE DOWNLOAD COMPLETE
  2017-05-14 20:59:17.617 - syncstate: InitState: REGISTRATION: CONFIG FILE DOWNLOAD COMPLETE -> REGISTRATION: IN PROGRESS
  2017-05-14 20:59:22.617 - syncstate: InitState: REGISTRATION: IN PROGRESS -> OPERATIONAL
  2017-05-14 20:59:22.617 - syncstate: SyncState: training -> showtime
  2017-05-14 20:59:22.617 - syncstate: DS/US: 0/0 -> 106000/6360

  , aber das läuft nun mal auf dem ATOM-Core genauso wie auf anderen FRITZ!Boxen, daß der "ctlmgr" bei abweichend konfiguriertem, externem HTTPS-Port (was man schon wg. der Portscans nutzen sollte) auch intern nur auf diesem Port aktiviert wird.
  Ich hatte mal die stille Hoffnung, daß AVM das mit der Einführung von PCP wenigstens auf ein Port-Mapping (von extern irgendwas auf intern 443) umstellen würde, so daß man aus dem internen Netz einen HTTPS-Aufruf auch ohne die Angabe eines abweichenden Ports machen kann. Wenn man das unbedingt auch intern auf dem externen Port erreichen will (wg. NAT-Hairpinning), dann muß man eben zwei Ports binden oder einen transparenten, lokalen Tunnel legen.
  Jedenfalls zeigt dann eben ein Mapping auf 169.254.1.1:443 bei mir auch prompt ins Leere, weil der "ctlmgr" für HTTPS bei mir an einem anderen Port lauscht.
• Ungeachtet all dieser Vorbereitungen, reagiert eine FRITZ!Box 6490 mit 153.06.83 bei mir jedoch auf keinen ARP-Request, kein ICMP (wenn ich die MAC-Adresse mit "arp" fest setze), kein HTTP (HTTPS natürlich erst recht nicht, s.o.) und - natürlich - auch nicht auf irgendwelche SNMP-Pakete (die ja i.d.R. ohnehin ARP-Auflösung bräuchten, der Test mit festem ARP-Eintrag war ja nur ein versuchter Workaround).

Aktiviert man dann mal das Interface ":lan0" im "Paketmitschnitt" (die Interfaces mit dem Doppelpunkt am Beginn beziehen sich in der 06.83 auf das eCM, die anderen auf das IAD - also den ATOM-Teil), dann kommen da auch nur die (ARP-)Broadcasts des CMTS von der WAN-Seite an, mit der dieses nach dem richtigen CM für IPv4-Adressen sucht - von der LAN-Seite (bzw. von einem CMCI) ist da nicht ein Paket zu sehen. Auch dann nicht, wenn man direkt auf dem ATOM-Teil versucht, mit der 192.168.100.1 zu kommunizieren.

Ausgehend von dem vermuteten Aufbau müßte m.E. über den externen Switch (mithin die LAN-Ports der Box) eingehender IP-Verkehr erst einmal zum ATOM-Core, bevor dieser dann den Packet-Prozessor entsprechend programmiert (für "externe" Verbindungen) oder eben selbst antwortet für interne. Anhand der Routing-Tabelle im ATOM-Core würde dieses System die Daten so behandeln, als wären sie für ein externes Ziel gedacht ... die Tabelle auf dem ATOM-Core hat keine "Sonderbehandlung" für die 192.168.100.1 (meine ansonsten übliche "Standardroute" für 192.168.0.0/16 über "dev lan" habe ich extra auf 192.168.128.0/17 präzisiert):

# ip r
default dev dsl  metric 2
83.169.184.33 dev dsl  metric 2
83.169.184.97 dev dsl  metric 2
91.66.91.0/24 dev dsl  metric 2
169.254.0.0/16 dev lan  src 169.254.1.1
169.254.1.0/30 dev acc0  src 169.254.1.1
172.31.179.0/24 dev guest  src 172.31.179.1
192.168.128.0/17 via 192.168.1xx.2 dev lan
192.168.1xx.0/28 dev lan  src 192.168.1xx.1
192.168.180.1 dev dsl  metric 2
192.168.180.2 dev dsl  metric 2

Zunächst könnte man also mal unterstellen, daß hier einfach eine Route vom ATOM-Core zum ARM-Core fehlt, über die dann Pakete an diese Adresse nicht dem ganzen Geraffel mit NAT und CT im "dsld" unterzogen werden - zumindest könnte das ja ein Ansatz sein, warum da nichts beim "lan0"-Interface des ARM-Cores ankommt bzw. warum das wohl einer Filterung zum Opfer fallen könnte.

Also tragen wir mal selbst eine Route ein:

# ip r add 192.168.100.1 via 169.254.1.2 dev acc0
# ip r
default dev dsl  metric 2
83.169.184.33 dev dsl  metric 2
83.169.184.97 dev dsl  metric 2
91.66.91.0/24 dev dsl  metric 2
169.254.0.0/16 dev lan  src 169.254.1.1
169.254.1.0/30 dev acc0  src 169.254.1.1
172.31.179.0/24 dev guest  src 172.31.179.1
192.168.100.1 via 169.254.1.2 dev acc0
192.168.128.0/17 via 192.168.1xx.2 dev lan
192.168.1xx.0/28 dev lan  src 192.168.1xx.1
192.168.180.1 dev dsl  metric 2
192.168.180.2 dev dsl  metric 2
# ping 192.168.100.1
PING 192.168.100.1 (192.168.100.1): 56 data bytes
64 bytes from 192.168.100.1: seq=0 ttl=64 time=2.813 ms
64 bytes from 192.168.100.1: seq=1 ttl=64 time=6.170 ms
^C
--- 192.168.100.1 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 2.813/4.491/6.170 ms
# wget -O - http://192.168.100.1
Connecting to 192.168.100.1 (192.168.100.1:80)
<!DOCTYPE html>
<html lang="de">
<head>
<meta http-equiv=content-type content="text/html; charset=utf-8" />
<meta http-equiv="Cache-Control" content="private, no-transform" />
[...]

Damit hätte man jetzt auch - zumindest vom ATOM-Core aus - einen funktionierenden Zugriff auf die 192.168.100.1 - halt über den "Interconnect" zwischen den Kernen geroutet, wie auch immer diese Verbindung aussehen mag. Das zeigt zumindest, daß diese Adresse prinzipiell vorhanden und erreichbar ist ... selbst wenn natürlich auch jetzt noch nichts in einem Mitschnitt für ":lan0" zu sehen ist, weil das ja kein Traffic ist, der über dieses Interface läuft. Das kommt ja jetzt über ":acc0" herein und geht wohl auch nur deshalb wieder über dieses Interface raus - denn der ARM-Core selbst hat keine Standardroute o.ä., nur eine einzige für 169.254.1.0/30 für die Kommunikation mit dem ATOM-Core.

Da stellt sich mir halt jetzt die Frage, was AVM da wohl vergessen haben mag (oder was ich wohl falsch machen könnte), damit die 192.168.100.1 dann auch - so wie es m.W. bei jedem anderen DOCSIS-Gerät Usus ist, zumindest für SNMP eben auch in der Spezifikation gefordert wird (s.o.), der HTTP(S)-Zugriff über den Proxy im "pumaglued" ist hingegen Kür - aus dem LAN jenseits des IAD erreichbar ist.

Auch wenn der Satz an abfragbaren SNMP-Variablen beschränkt ist, sollte doch zumindest der Hersteller (bzw. alles unter OID 1.3.6.1.2.1.1) und die Version der eingesetzten Firmware (und noch ein paar Sachen aus den DOCSIS-MIBs unter OID 1.3.6.1.2.1.69.1.1 - docsDevBase) abfragbar sein.

Ich habe es auch leider versäumt, das bei den 06.6x-Versionen für die Retail-Modelle explizit zu testen ... wenn meine Aufzeichnungen stimmen, klappte es zumindest bei der 06.10 mit meiner alten KDG-Box noch problemlos (allerdings ist das schon 2,5 Jahre her). Ich hege ein wenig den Verdacht (lasse mich aber auch gerne vom Gegenteil überzeugen), daß hier etwas dem Umbau auf die "new architecture" zum Opfer gefallen ist (und ich will jetzt deshalb auch nicht auf eine 06.6x "zur Kontrolle" wechseln, weil mich viel mehr interessiert, wie man es unter 06.83 zum Laufen bringen kann als die Frage, wie es zuvor bei der Retail-Version aussah).

Ich habe zwar den SNMP-Zugriff unter "Anbieter-Dienste" deaktiviert, das sollte aber ohnehin nur für den Zugriff des Anbieters jenseits des eCM (also z.B. auf den eRouter, ein eMTA gibt es ja in der Retail-Version nicht) gelten und nicht für den Zugriff von der CMCI-Seite auf die 192.168.100.1 ... aber eine Änderung dieser Einstellungen bewirkt auch keine Besserung (es hätte ja sein können, daß AVM hier beim "Abschalten" etwas zu weit geht).

Vielleicht liest hier ja jemand mit, der ansonsten Provider-Boxen bei Kunden einrichtet und dafür normalerweise (zumindest zur Abfrage des CM-Status) auf SNMP zurückgreift (bzw. dann ist es sicherlich die Software seines Arbeitgebers, die damit arbeitet) ... ggf. kann so jemand mir ja den entscheidenden Tipp geben oder seinerseits bestätigen, daß es ihm bei der FRITZ!Box 6490 mit "new architecture" (die 06.6x hat m.W. auch bei den Providern noch den alten Aufbau) auch nicht gelingt, da per SNMP irgendetwas von der 192.168.100.1 zu erhalten.

- - - Aktualisiert - - -

Falls es jemanden interessiert ... die DOCSIS-Spezifikation (konkret die CMCI-Spezifikation, also "Cable Modem to CPE Interface") wurde erst vor kurzem subtil verändert und steht seit dem 10.05.2017 in Version I03 zur Verfügung.

Ich verstehe zwar den Unterschied zwischen dem alten und dem neuen Text an einer Stelle (Punkt 6.1) nicht so richtig:

A CM MUST NOT allow access to CM functions via a management access interface. (DOCSIS CM functions are defined by the DOCSIS specifications and are essentially layer 1/layer 2 functions.) Access to CM functions MUST only be allowed via interfaces specifically prescribed by the DOCSIS specifications, such as the RF interface and operator-controlled SNMP (Simple Network Management Protocol) access via the CMCI (see [OSSIv3] for more information).

A CM is required to not allow access to CM functions (CM IP stack) via a management access interface [MULPI]. Access to CM functions are only allowed via interfaces specifically prescribed by the DOCSIS specifications, such as the RF interface and operator-controlled SNMP (Simple Network Management Protocol) access via the CMCI, [MULPI], and [OSSIv3].

, aber das wird schon seine Gründe haben.

Für mich persönlich wäre jetzt der Unterschied zwischen "darf den Zugriff nicht erlauben" (MUST NOT allow) und "ist verpflichtet, den Zugriff nicht zu erlauben" (is required to not allow) nicht so prägnant (immerhin ist das "MUST NOT" auch noch als "This phrase means that the item is an absolute prohibition of this specification." präzisiert), aber das liegt vermutlich nur an meinem mittelmäßigen Englisch. Oder es erklärt den Versuch für ausreichend und erwartet in der neuen Formulierung gar nicht mehr wirklich, daß der Hersteller den Zugriff wirksam unterbindet ... der (gezeigte) Wille allein genügt vielleicht schon.

Bei der Beschreibung des "Engineering Change" mit "Remove management access interfaces normative text" hätte ich irgendwie etwas anderes erwartet ... gut, da kam jetzt am Satzende noch ein Verweis auf [MULPI] und eine etwas präzisere Fassung hinzu, was diese "DOCSIS CM functions" nun sein mögen, aber irgendwie erklärt das (für mich jedenfalls) die Änderung von "MUST NOT" auf "is required to not" noch nicht so richtig, zumal eben die meisten solcher Spezifikationen mit "MUST (NOT)", "SHOULD", "MAY", usw. arbeiten und da fiel mir diese Änderung halt besonders auf. ;-)

EDIT 04.02.2022: CODE-Tags auf CODE=rich geändert, um die eingebetteten Farben wieder zu aktivieren.

 

[robert_s]

FWIW, mir hat mal ein "VFKD-Insider" gesagt, dass die bei kundeneigenen Kabelmodems die SNMP-Funktion per DOCSIS-Befehl abschalten, weil sie der Ansicht sind, auf Kundengeräten nichts zu suchen zu haben. Das war auf mein Angebot, meine Fritzbox 6490 mit gesetztem Häkchen bei der SNMP-Funktion für den Anbieter doch mal direkt einzusehen.

Ich habe mich nicht tiefer damit beschäftigt, aber könnte es vielleicht sein, dass es deshalb bei Dir nicht geht? Denn soweit ich gelesen habe, hattest Du es zuletzt mit einer Leihbox versucht, und da wird SNMP ja nicht vom CMTS abgeschaltet...

 

[PeterPawn]

Das wäre zwar auch denkbar und ich hatte das (insbesondere einen "off"-gesetzten Wert bei TLV 55) in Erwägung gezogen ... aber eben nur für den SNMP-Zugriff an sich (also das "denkbar") und außerdem ist es auch im config-File von VFKD bei mir nicht gesetzt.

Angesichts der Bemühungen von AVM mit dem Proxy im "pumeglued" würde ich eben auch erwarten, daß dieses Interface (inkl. GUI) zumindest irgendwie auch über die 192.168.100.1 erreichbar ist ... vielleicht ist das tatsächlich nur beim unkonfigurierten Gerät verfügbar (das habe ich nicht ausprobiert) - für den SNMP-Zugriff wäre das aber auch wieder (siehe Spezifikation oben) unzureichend.

Ich hoffe irgendwie auf @scuros oder jemand anderen, der bei einem KNB arbeitet und das mal selbst getestet hat ... vielleicht gibt es bei irgendeinem KNB ja einen vorgeschriebenen Testablauf für neue DOCSIS-Geräte und da gehört dann event. auch die Prüfung dazu, ob/wie sich eine FRITZ!Box 6490 (irgendwann wird sicherlich auch auf den Provider-Boxen die "new architecture" Einzug halten) per SNMP vom Laptop des Technikers (oder was der auch immer heutzutage mit sich herumschleppen mag, ggf. ja auch ein Tablet mit LAN-Adapter) bei der Installation kontaktieren läßt oder nicht.

Im Gegensatz zu irgendeinem GUI, was jeder Hersteller machen kann, wie er lustig ist, wäre die SNMP-Schnittstelle eben standardisiert und recht genau spezifiziert - d.h., es könnte ein Programm für alle denkbaren DOCSIS-Router beim Installieren eines neuen Kabelanschlusses geben, was z.B. so eine Art Protokoll erzeugt und dabei die Daten (vielleicht sogar mit US/DS-Kanälen) per SNMP ausliest und vielleicht auch ausdruckt, damit der Kunde darunter dann quittieren kann, daß die Installation erfolgreich ausgeführt wurde.

 

[robert_s]

Im Gegensatz zu irgendeinem GUI, was jeder Hersteller machen kann, wie er lustig ist, wäre die SNMP-Schnittstelle eben standardisiert und recht genau spezifiziert - d.h., es könnte ein Programm für alle denkbaren DOCSIS-Router beim Installieren eines neuen Kabelanschlusses geben, was z.B. so eine Art Protokoll erzeugt und dabei die Daten (vielleicht sogar mit US/DS-Kanälen) per SNMP ausliest und vielleicht auch ausdruckt, damit der Kunde darunter dann quittieren kann, daß die Installation erfolgreich ausgeführt wurde.

Neben GUI und SNMP gibt es auch noch UPNP. Zumindest für meinen Anwendungszweck (einen Traffic-Monitor) kann das bei Fritz!Boxen die Funktionalität ersetzen, die ich früher (noch zu ADSL-Zeiten...) per SNMP hatte. UPNP auf den Fritz!Boxen gibt aber nicht viele Informationen her und teilweise auch nur "Dummies"...

 

[fesc]

Falls es relevant ist:
Ich hatte mir auf 6.63 mal zugriff auf SNMP von LAN seite geschaffen, allerdings indem ich den snmp daemon auf ein anderes interface gebunden habe:

/usr/sbin/snmpcmd -s /var/tmp/cm_snmp_ctrl -c SNMPA_DELETE_SOCKET_ENTRY -t 1 -i lan0 -p 161 -a 192.168.100.1
/usr/sbin/snmpcmd -s /var/tmp/cm_snmp_ctrl -c SNMPA_DELETE_SOCKET_ENTRY -t 1 -i lan0 -p 162 -a 192.168.100.1


/usr/sbin/snmpcmd -s /var/tmp/cm_snmp_ctrl -c SNMPA_ADD_SOCKET_ENTRY -t 1 -i lan -p 161 -a 192.168.0.1
/usr/sbin/snmpcmd -s /var/tmp/cm_snmp_ctrl -c SNMPA_ADD_SOCKET_ENTRY -t 1 -i lan -p 162 -a 192.168.0.1

In /etc/agent_cm.cnf bzw. /etc/snmp_cm_nv.txt steht sind dann verschiedene views/user definiert, d.h. welche OIDs sichtbar sind. Wenn man da etwas editiert (z.b. alles fuer den dhKickstart nutzter sichtbar macht) und den snmp agent neu startet (mit pfad zum editierten agent_cm.cnf) kommt man so ziemlich an alle unterstuetzten OIDs ran bzw kann einen snmpwalk machen.

Geht prinzipiell auch mit ctlmgr_ctl, aber der stuerzte bei mir immer ab wenn eine unbekannte OID abgefragt wurde, d.h. fuer einen scan taugt das nicht.

Ausgehend von dem vermuteten Aufbau müßte m.E. über den externen Switch (mithin die LAN-Ports der Box) eingehender IP-Verkehr erst einmal zum ATOM-Core, bevor dieser dann den Packet-Prozessor entsprechend programmiert

Das glaube ich nicht, denn wie soll sonst die IP vom Atom gleichzeitig router sein (der Atom ist ja gerade nicht router)? Ich denke die Pakete gehen immer ueber den internen switch zum DOCSIS port/PP, und werden ggf. zum Atom zurueckgeroutet (meine Vermutung).

Das kommt ja jetzt über ":acc0" herein und geht wohl auch nur deshalb

acc ist ein UDMA port des internen switches. Die waren in 6.63 noch brach gelegen und alles zwischen arm/atom ging ueber den packet processor.

 

[PeterPawn]

@fesc:
Ich glaube, wir schreiben gerade aneinander vorbei - ich habe ja im Thread-Titel ausdrücklich die 06.83 drin.

Da eben der ARM-Core jetzt gerade nicht mehr der Router ist und der ATOM-Core i.d.R. bei "new architecture" (als Default-Gateway für alle LAN-Clients bei der (hier mal angenommenen) Standardkonfiguration) alle Pakete aus dem LAN auch für die 192.168.100.1 erhalten wird (zumindest wird die L2-Adresse die des Gateways sein und da der ATOM-Core entsprechende ARP-Requests mit seiner MAC-Adresse beantwortet (der aus "maca"), ist das zunächst mal die MAC-Adresse der Box und zwar des ATOM-Cores), müssen die entweder direkt über den PP (mit einer Sonderbehandlung) oder über den ATOM-Core irgendwie auf dem ARM-Core ankommen (der kennt von sich aus ja keine andere Route als die 169.254.1.0/30 über "acc0") oder der ARM-Core gibt sich selbst per ARP als 192.168.100.1 auf der LAN-Seite zu erkennen - für das "lan0"-Interface hat der aber nicht einmal eine link-lokale Route eingetragen und m.E. erreichen ihn die ARP-Broadcasts mit der Frage nach 192.168.100.1 aus dem LAN ohnehin nicht.

Wenn das also nicht alles ausschließlich mit L2-Adressierung funktionieren soll (bei IPv4 schon ungewöhnlich und die Spezifikation gibt ja auch eine fixe L3-Adresse vor, also sollte die irgendwie aufzulösen sein für die Schicht darunter), muß ein LAN-Client zu dieser IP-Adresse auch eine MAC für L2 finden können.

Bei dem von Dir oben zitierten ersten Text meinte ich zunächst auch mal nur die Daten mit "unbekanntem Ziel", für die noch kein Eintrag in irgendeiner Tabelle des PP vorliegt und mit "den PP programmiert" meinte ich dann den Teil, der bei weiteren Paketen dafür sorgt, daß der ATOM-Core damit nichts mehr zu tun hat, solange das eCM das eigentliche Ziel als nächster Hop ist.

Der Mitschnitt auf den beiden "acc0"-Interfaces ist praktisch wertlos ... offenbar erfolgt auch die Übertragung eines Paket-Mitschnitts für jedes ARM-Interface über diese interne Kommunikation und damit hat man innerhalb von Sekunden Hunderte Megabyte gesammelt, die auch von keinem Wireshark-Dissector sinnvoll vorsortiert werden.

Die Konfigurationsmöglichkeiten für den "snmp_agent_cm" kenne ich ... aber auch die ändern eben nur, welche OIDs ggf. aus Richtung CMCI abgefragt werden können; den generellen Zugriff hat AVM ja offenbar vorgesehen (siehe die "netstat"-Ausgabe oben, der Daemon fürs SNMP - und auch der "pumaglued" - läuft ja, er ist nur nicht erreichbar), aber er funktioniert meines Erachtens nicht.

Bei der "new architecture" stelle ich mir den Ablauf für "normale" Pakete von LAN-Clients nach extern (also mit der MAC-Adresse des Default-Gateways auf L2) so vor, daß alles, was keinen Eintrag im PP vorfindet (also noch nicht im "connection tracking" erfaßt ist), tatsächlich wieder an den ATOM-Core geht. Der richtet dann entsprechende Verbindungen im PP ein (wenn das irgendwelche SYN-Pakete beim TCP sind bzw. das erste UDP-Paket einer Verbindung - laß uns mal nur bei TCP und UDP bleiben) und sendet das dann erneut ... nur diesmal geht es wirklich über das eCM nach extern. Weitere Pakete in dieser Verbindung (egal ob von extern als Antworten oder von innen) finden dann in den PP-Tabellen die notwendigen Angaben vor, um die Pakete direkt zu modifizieren und die gehen dann - solange es kein FIN-Paket ist, was dann wieder (ggf. auch parallel) zum ATOM-Core geht, damit der die Verbindung abräumen kann - direkt vom eCM zum LAN-Client. So stelle ich mir das zumindest (grob) vor und das sollte ja eigentlich auch in etwa so funktionieren. Wie genau AVM das jetzt auf dem ATOM-Core mit der Programmierung des PP angeht, wird man erst in den Kernel-Quellen halbwegs ergründen können.

Das läßt dann m.E. für die Verbindung zum "lan0"-Interface des ARM-Cores nur zwei Möglichkeiten offen ... entweder der ATOM-Core programmiert den PP entsprechend, so daß die Pakete direkt vom LAN-Client zum ARM-Core gelangen (ggf. sogar von jedem LAN-Client und dann auch inkl. Broadcasts mit ARP-Requests für die 192.168.100.1, denn irgendwie müssen die LAN-Clients ja wissen, wohin sie die Pakete auf L2 senden sollen - ich weiß nicht, wie weit man da die PP-Rules präzisieren kann) oder er routet das selbst; aber dann muß er das eben auch irgendwie behandeln können.

Ich denke jedenfalls, daß die Pakete beim ARM dann - im Gegensatz zu Paketen, die wirklich an externe Adressen gehen sollen - nicht mit modifiziertem Absender (also der Public-IP des eRouters) aufschlagen dürfen, denn auch da ist die DOCSIS-Spezifikation in meinen Augen eindeutig und schreibt vor, daß Zugriffe auf dieses Management-Interface auf der CPE-Seite nur von dort auch kommen dürfen. Das wäre zwar vermutlich mit irgendwelchem Tracking auch noch machbar, aber am ehesten würde ich mir hier irgendeine Regel vorstellen, die bei einer Ziel-IP(v4) von 192.168.100.1 zum ARM-Core hin ausgibt und dabei das Paket ansonsten unangetastet läßt. Je nachdem, wie genau man das dann machen will, braucht es eine entsprechende Anzahl von Regeln, wenn man nur bestimmte Ports zulassen will am Ziel (wobei die beiden SNMP-Ports i.d.R. mit einem "von-bis" erschlagen werden können) - es reicht aber auch eine einzelne, wenn man sich auf den IP-Stack an der Zieladresse verläßt. Eventuell braucht man noch einen solchen Tabelleneintrag für ARP-Broadcasts, die nach der 192.168.100.1 fragen, damit der ARM-Core auch solche Suchanfragen sieht.

Ansonsten müßte der ATOM-Core nämlich m.E. wenigstens Proxy-ARP für die 192.168.100.1 machen, weil ein als 192.168.100.2/24 konfigurierter LAN-Client gar nicht auf die Idee käme, für den Weg zur .1 irgendein Gateway verwenden zu wollen, das wäre für ihn alles "link local" und was er nicht per ARP auflösen kann, ist für ihn i.d.R. "unreachable" (na gut, man könnte mit einer /32-Maske und einer Default-Route den Client auch konfigurieren - das würde zu den "Feinheiten" gehören, die ich suche als Information).

Für diesen Zugriff auf die 192.168.100.1 ist es m.E. nicht einmal sinnvoll, wenn man die FRITZ!Box entsprechend auf dieses Subnetz konfiguriert (abgesehen davon, daß der eRouter nach meinem Verständnis gar keine zusätzliche/abweichende Konfiguration brauchen sollte für den Zugriff auf das Management-Interface von der LAN-Seite) ... sie würde sich wohl selbst für den ATOM-Core die .1 greifen und die 192.168.100.1 ist ja keine "variable" Adresse, die ist 1:1 in der Spezifikation so festgelegt und soll den Zugriff auf das CPE-seitige Management-Interface des CM ermöglichen. Theoretisch müßte m.E. AVM sogar dafür sorgen, daß man bei den DOCSIS-Modellen für das LAN gar nicht das Netz 192.168.100.0/24 einstellen kann - ich denke mal, der Aufwand, da für den ATOM-Core auf die .2 "umzuschalten" dürfte höher sein als einfach das Segment zu sperren.

Ich denke mal, daß hier der "dsld" von AVM mit dem eigenen "WAN-Stack" (der stammt wohl in Teilen bzw. von der Idee her noch auch den Zeiten des AVM-MPR) anders reagiert als die "üblichen" Puma6-Geräte, die auf dem APP-Teil nur mit Routing und "iptables" arbeiten und die Daten mit externen Zielen in ihrer Rolle als "eRouter" meist nur blind weiterreichen (bzw. dann wohl den PP genauso programmieren, wie oben vermutet). Die bieten dann auch solche Modi wie "LAN1-Router" halt nicht an - das dürfte AVM hier auch nur deshalb relativ leicht fallen (auch bei den DSL-Geräten), weil man einfach nur das ausgehende Interface woandershin mappen muß und die grundsätzlichen Abläufe im "dsld" trotzdem dieselben bleiben (man müßte glatt mal schauen, ob bei LAN1-Routermode bei den Puma6-Geräten (mit "na") überhaupt der "packet accelerator" im Spiel ist, wenn die Daten jetzt wieder zum externen Switch zurück müssen anstatt zum eCM zu gehen).

Ich bin jedenfalls der Meinung, daß dieser Zugriff auf das Management-Interface auch im "production mode" des eCM möglich sein müßte/sollte und nicht nur im "test mode" - daher suche ich die Informationen, ob/wie das bei der "new architecture" der AVM-Boxen nun funktioniert.

 

[fesc]

@PeterPawn

Ich meinte auch 6.83, 6.63 hatte ich nur in Bezug auf meine SNMP tests erwaehnt.

Wobei ich ehrlich gesagt nicht ganz verstehe was das eigentliche Problem ist. Ich sehe nicht dass sich 6.83 anders als 6.6x verhaelt, denn auf SNMP ist man da auch nicht gekommen.
Deswegen habe ich ja die Verrenkung mit an einen anderen port binden gemacht. Ich denke das ist auch gewollt so.

Was die internen Datenpfade betrifft, da verrenke ich mir schon seit einiger Zeit das Gehirn wie die nun aussehen (da fehlt mir auch dein Vorwissen von dsl boxen ..). Gerade bei 6.83 hat sich auch in Bezug aufs lan gewaltig was gaendert.
Der externe switch laeuft jetzt in einer Art MAC mode, d.h. eth0-3 sind jetzt ueber vlans direkt mit den ports assoziiert, und man kann traffic zwischen den ports direkt mitlesen (mittels tcpdump). Bei 6.6x war der switch noch ein switch.
Traffic nach aussen genauso, den kann man direkt ueber das master interface vlan_master0 (was wohl das RGMII interface bedient) abgreifen. Es scheint mir also so dass der PP hier gar nicht mehr involviert ist ...

Und die inter-core Kommunikation laeuft nicht ueber udma ports im internen switch, anders als von mir vermutet. Was "acc0" ist habe ich keine Ahnung.

 

[PeterPawn]

Ich denke das ist auch gewollt so.

Ja und nein ... es gibt eben unterschiedliche SNMP-"Interfaces" und so, wie die Spezifikation den SNMP-Zugriff von der CPE-Seite auf die RF-seitigen Interfaces verbietet (weshalb Du das Binding beeinflussen mußtest), so fordert sie (s. #1 und nach meiner "Lesart") von der CPE-Seite einen (auf r/o beschränkten) Zugriff auf einige SNMP-Variablen unter der festen IP-Adresse 192.168.100.1.

Ich denke mal, wenn die Quellen für den ATOM-Core erst einmal vorliegen, wird man ein paar mehr Infos darin finden und vielleicht auch die Änderungen der Datenpfade wieder besser verstehen (oder zumindest präziser spekulieren können) ... das geht beim "sk_buff" und irgendwelchen Zusatzinformationen darin für die PP-Programmierung dann los (der "docsis_pp.ko" auf dem ARM-Core sollte der Module-Info nach auch der GPL unterliegen:

# modinfo lib/modules/2.6.39.3/drivers/net/docsis_pp.ko
filename:       [...]/lib/modules/2.6.39.3/drivers/net/docsis_pp.ko
author:         Orit Brayer
description:    Docsis Packet Processor Kernel Module
[COLOR="#FF0000"]license:        GPL[/COLOR]
depends:
vermagic:       2.6.39.3 preempt mod_unload ARMv6

und damit Teil der (schon von Intel) veröffentlichten Quellen sein - vermutlich auch ggü. 06.63 gar nicht groß geändert, aber der verwaltet nach meiner Ansicht (der Binärdatei) ohnehin nur irgendwelche Zähler) und wenn man sich die nachgeladenen LKM auf dem ATOM-Core ansieht, dann hat AVM die ganze Beschleunigung entweder in den "kdsldmod.ko" gepackt oder es gibt auch in der 06.83 in den Kernel-Quellen einen x86-AVM-PA, weil der direkt mit dem Kernel gelinkt ist. Jedenfalls ist ja nach "/proc/net/avm_pa/status" erstens ein PA vorhanden und für diesen auch zweitens eine Hardware-Unterstützung aktiv - das kann ja eigentlich nur der PP des Puma6 sein.

 

[robert_s]

Ich frage mich, ob die Fritz!Box überhaupt ein CMCI hat? Da es keinen Bridge-Modus gibt, gibt es ja auch kein exponiertes CMCI. Und wenn es eh nur intern ist, macht es "von außen" ja keinen Unterschied, ob es nun wirklich DOCSIS-konform vorhanden ist oder nicht...

Google findet mir ein Buch, worin behauptet wird, die CMCI-MAC wäre HFC-MAC + 1. Im LAN zeigt sich meine 6590 mit HFC-MAC + 3, also ist das wohl nicht das CMCI (war ja auch nicht zu erwarten).

Stimmt es denn, dass DOCSIS feste Konventionen für mehrere MAC-Adresse vorgibt? Wenn ich mal in meinem Segment schnüffele findet ich folgende Muster:

1. HFC-MAC - empfängt (fast) immer nur DOCSIS Management-Nachrichten, kein IP
2. CMCI-MAC(?) (HFC-MAC+1) - empfängt PDUs, aber nicht bei allen (bei meiner 6590 nicht)
3. CPE-MAC(?) (HFC-MAC+3) - empfängt PDUs, und ist bei meiner 6590 dieselbe MAC-Adresse, unter der sie sich auch im LAN meldet

Ich sehe bei ankommendem Traffic die Kombinationen:

- nur 1. (hatten vielleicht gerade keinen IP-Traffic, oder sind als reine Bridges unterwegs?)
- 1. + 2.
- 1. + 2. + 3.
- 1. + 3. (meine 6590)

Sind PDUs an 2. vielleicht ein Indiz, dass es sich um ein Leihgerät handelt, welches netzseitige SNMP-Anfragen bekommt? Aber das scheint mir der Anforderung zu widersprechen, dass das CMCI nicht von der RFC-Seite aus zugreifbar sein darf, oder verstehe ich da etwas falsch?

Ich frage mich auch, wofür HFC-MAC+2 reserviert sein mag...

 

[PeterPawn]

Nach meinem Verständnis sind diese "CPE-seitigen Interfaces" nach der CMCI-Spezifikation nicht notwendigerweise auf physikalische Interfaces beschränkt. Schaut man sich die eDOCSIS-Spezifikation an (Abbildung 5.1 auf Seite 17), sind auch die logischen Interfaces innerhalb des eDOCSIS-Gerätes, mit denen irgendwelche eSAFE(s) an das eCM angebunden sind, "CPE interfaces" - und die Zugriffsrechte und Beschränkungen nach der CMCI-Spezifikation (auch wenn die noch die zwei physikalischen Interfaces (ETH und USB) genauer spezifiziert, was bei "nur logischen" Interfaces ja auf L2/L1 nicht notwendig ist) sollten meines Erachtens auch für diese "internen Datenpfade" gelten.

Ich denke also, daß die heutigen FRITZ!Boxen für DOCSIS mit aktueller Firmware tatsächlich kein physikalisches (externes) Interface haben, was direkt unter die CMCI-Spezifikation fällt ... selbst der früher mögliche "Bridge-Mode" war vielleicht (habe ich aber nie selbst überprüft) mehr eine Art ePS für die "gebridgten" Interfaces (ohne DHCP/DNS/NAT) als irgendein direkt mit dem eCM verbundenes Interface - aber wie gesagt, habe ich nie selbst getestet und auch nie nachgesehen, wie da die Konfiguration dann aussah.

Hat eigentlich schon mal jemand eine Provider-6490 mit Firmware mit "new architecture" in der Hand gehabt und dabei zu allem Überfluß auch noch eine, wo für den Kundenanschluß dann auch WLAN-Hotspots über GRE-Tunnel zum Provider aktiviert waren? Mich würde nur mal interessieren, ob die in dieser "na" schon problemlos arbeiten oder nicht.

Von festen Konventionen beim Durchnummerieren von MAC-Adressen wüßte ich nichts ... auch bei AVM gab es zumindest bei der 6490 mind. zwei verschiedene "Zählweisen". In MULPI gibt es im Anhang A ein paar "well-known addresses", aber nichts wirklich Wildes, sondern eher das Übliche, wenn man mal von einer Broadcast-MAC (bzw. Multicast) speziell für CM absieht.

 

[fard_dwalling]

Hallo,
ich habe da mal eine Frage zu und finde irgendwie keine richtige Antwort.
Ich habe eine 6490 Cable von Unitymedia, Firmware steht bei 6.50. Wir haben 5 statische IPv4 Adressen. Die FB hat ja eine eigene, und ich kann die 5 weiteren dahinter nutzen. Komischerweise kann ich die FB aber über den LAN1 unter der 192.168.100.1 erreichen. Kann mir das jemand etwas näher erleutern warum das so ist und wer dafür verantwortlich scheint? Hinter der FB haben wir eine pfSense hängen. Unsere internen Clients haben Adressen aus dem 192.168.0.0er Netz...

 

[TSMusik]

Kann mir das jemand etwas näher erleutern warum das so ist und wer dafür verantwortlich scheint?

Die ist für Diagnosezwecke da und so im Standard für alle DOCSIS-Modems/Router verpflichtend definiert:

The CM MUST support 192.168.100.1, as the well-known diagnostic IP address accessible only from the CMCI interfaces. The CM MUST support the well-known diagnostic IP address, 192.168.100.1, on all physical interfaces associated with the CMCI.

https://www.cablelabs.com/wp-content/uploads/2015/08/CM-SP-OSSIv3.0-I05-071206.pdf

 

[fard_dwalling]

Das heißt, keine Möglichkeit der Abschaltung? Selbst die AVM Hotline wußte da nix von...

 

[TSMusik]

Nein, Standard ist Standard:

"MUST" This word means that the item is an absolute requirement of this specification.
[…]
Equipment must comply with all mandatory (MUST and MUST NOT) requirements to be considered compliant with this specification.

Und was genau sollte eine Abschaltung bringen? Die Box bleibt ja über die anderen Adressen eh erreichbar.

 

[fard_dwalling]

Naja Problem war eigentlich, das ich auf der pfSense einen IPSec Tunnel in eben ein 100er Netz habe. Von einem meiner Clients hatte ich dann einen Dauerping zu Testzwecken auf die 100.1 (das Gateway am anderen Ende).

Ich war etwas verwundert das der Ping noch lief obwohl die VPN Verbindung gekappt war.
Wie ich dann rausfand, von der Ping an 100.1 über die pfSens WAN1 raus und wurde von der Fritzbox beantwortet....

 

[PeterPawn]

Das sollte sich nach dem Update der FRITZ!Box auf eine Version, wo der Router auf dem ATOM-Core läuft, auch erledigt haben ... das war ja genau mein Thema, daß ich kein Interface mit der 192.168.100.1 mehr finden konnte und ich glaube (bis zum Beweis des Gegenteils) nicht, daß da von der 06.87 zur 06.88 von UM noch etwas passiert ist in dieser Hinsicht.

 

[fard_dwalling]

Das kann allerdings nur Unitymedia durchführen bzw müssten sie ja das Update erstmal freigeben. Und ich glaube, da tut sich nix mehr....

 

[PeterPawn]

https://community.unitymedia.de/cat...ble-der-rollout-der-6-88-hat-begonnen?page=26

PS: Bevor jemand fragt ... nein, ich habe auch keine Ahnung, warum solche Nachrichten bei UM offenbar aus dem "Kostüm-Fundus" kommen, wenn man dem Bild folgen will. Oder was will man dem Kunden ansonsten damit sagen? Ist das am Ende alles "maßgeschneidert"?

 

[fard_dwalling]

Ja schau an, vielen Dank.
Bei mir ist noch keine 6.88 angekommen. Selbst auf die neue getauschte heute ist mir 6.50..
Mal sehen wann die dann kommt.

 

[fesc]

Wobei man beachten muss: Clients welche die fb als default router hernehmen erreichen 192.168.100.1 immer noch, der atom routet das intern zum arm.