Unitymedia Technicolor TC4400 Docsis 3.1 Modem Info Thread

[Andreas1969]

Man müsste per Telnet auf das CLI kommen, aber wie?
Das Modem reagiert da überhaupt nicht drauf.

 Management „ User-friendly GUI via HTTP „ Command Line Interface (CLI)
Telnet
SSH v2
„ SNMP SNMP v1, SNMP v2, SNMP v3 „ Operation, Administration & Maintenance (OAM)
ITU-T Y.1731
„ Software upgrade via WAN RF connection only „ Logging and alert

 

[nts]

Das Modem sollte unmöglich unterscheiden können von wo nun die Anfrage kommt (welche Schnittstelle). Ich hab aber drüben im KDG Forum schonmal festgestellt, das Public auf einen IP adressbereich limitiert ist. Lediglich die Passwörter sind unlimitiert.

Naja, wenn bei jedem Modem eine zufällige Community gesetzt wird, ist das letztendlich wohl auch eine Sackgasse. Aber wenigstens kann man die Modem Logs via SNMP auslesen, die überleben nämlich einen Neustart. :smile:

 

[Flole]

Das Modem sollte unmöglich unterscheiden können von wo nun die Anfrage kommt (welche Schnittstelle). Ich hab aber drüben im KDG Forum schonmal festgestellt, das Public auf einen IP adressbereich limitiert ist. Lediglich die Passwörter sind unlimitiert.

Naja, wenn bei jedem Modem eine zufällige Community gesetzt wird, ist das letztendlich wohl auch eine Sackgasse. Aber wenigstens kann man die Modem Logs via SNMP auslesen, die überleben nämlich einen Neustart. [emoji2]

Wenn man aber die config Dateien auslesen kann, darüber die communities und darüber zugriff kriegt ist doch alles okay.

 

[Andreas1969]

Wenn man aber die config Dateien auslesen kann, darüber die communities und darüber zugriff kriegt ist doch alles okay.

Nein, das geht beim TC4400 nicht.
Ich hatte die Daten mit einem anderen Modem ausgelesen, da ich dachte, die wären Kundenspezifisch und nicht Gerätespezifisch.

 

[Andreas1969]

Das bekommen wir aber eventuell raus.
@MichaelBre @addicted
könnt Ihr mal nachschauen, ob bei Euch auch folgende Community im Log angezeigt wird:
community: 5g21wm7sdl

 

[Orko]

Versucht es doch mal mit dem Enterprise Tree von Broadcom: 1.3.6.1.4.1.4413

Besonderes Augenmerk sollte auf diesen Sub-Tree geworfen werden: 1.3.6.1.4.1.4413.2.2.2.1.1.3

 

[addicted]

community: 5g21wm7sdl

Ich meine ja. Kann ich kommende Woche aber erst wieder nachgucken.

 

[Andreas1969]

Wenn man auf's Web IF kommen würde, gibt es wohl folgende Menüpunkte:

Status
http://192.168.100.1/RgSwInfo.asp

Logout
http://192.168.100.1/logout.asp

Software
http://192.168.100.1/RgSwInfo.asp

Connection
http://192.168.100.1/RgConnect.asp

Ethernet OAM
http://192.168.100.1/RgEthernetOAM.asp


Quelle: http://forums.xfinity.com/t5/Your-Home-Network/Anybody-else-having-issues-with-the-Technicolor-4400-for-Gigabit/td-p/2833417

 

[Andreas1969]

Und hier wird ein Problem mit dem Sicherheitszertifikat vermutet: http://www.dslreports.com/forum/r31628390-Equip-Question-for-Technicolor-TC4400-modem-users

 

[Andreas1969]

Hier mal die Fenster der einzelnen Browser:

1. IE Explorer



2. Firefox



3. Chrome

 

[Andreas1969]

Nach 3maligem Eingabeversuch erscheint folgende Fehlermeldung:


http://www.checkupdown.com/status/E401_de.html

 

[#DiRK]

Leider auch keine bekannten Vulns für den micro_httpd, außer DoS

https://www.cvedetails.com/vulnera...-10442/product_id-19167/Acme-Micro-Httpd.html

 

[0rko]

Hat jemand schon mal versucht, ganz einfach erst mal die sysDescr.0 mittels SNMP abzufragen?

Wenn unter Linux das NET-SNMP Paket installiert ist, dann einfach mit:

<i>
</i>snmpget -v 2c -c public 192.168.100.1 sysDescr.0

Vorher natürlich checken ob das Modem überhaupt erreichbar ist:

<i>
</i>ping 192.168.100.1

Hinweis: Versucht die Anfragen mittels der bekannten Communities (Austausch public) aus diesem Thread auch mal zu einer Zeit, wo das Modem nicht registriert ist. Oft ist der Zugriff auf SNMP nur vor der fertigen Registrierung möglich. Die beste Chance ist eigentlich nach einem Factory-Reset, vor der ersten Anmeldung. Noch bevor das Modem neue Communities vom Provider drübergebügelt bekommen hat. Dann sollten die Communities auch noch public für RO und private für RW lauten.

 

[Andreas1969]

Hat jemand schon mal versucht, ganz einfach erst mal die sysDescr.0 mittels SNMP abzufragen?

Wenn unter Linux das NET-SNMP Paket installiert ist, dann einfach mit:

<i>
</i>snmpget -v 2c -c public 192.168.100.1 sysDescr.0

Vorher natürlich checken ob das Modem überhaupt erreichbar ist:

<i>
</i>ping 192.168.100.1

Hinweis: Versucht die Anfragen mittels der bekannten Communities (Austausch public) aus diesem Thread auch mal zu einer Zeit, wo das Modem nicht registriert ist. Oft ist der Zugriff auf SNMP nur vor der fertigen Registrierung möglich. Die beste Chance ist eigentlich nach einem Factory-Reset, vor der ersten Anmeldung. Noch bevor das Modem neue Communities vom Provider drübergebügelt bekommen hat. Dann sollten die Communities auch noch public für RO und private für RW lauten.

Es ist für mich verdammt schwierig das zu testen, da bei mir noch 2 Mietwohnungen mit über den Anschluss laufen. Da war letztens der Ärger schon groß genug, weil UM die SIP Creditials bei der Freischaltung des Modems neu generiert hat und ich hier 3 Tage ohne Telefonie dastand. Übrigens ist der Brief mit den Zugangsdaten bis heute noch nicht gekommen und im KC sind die immer noch nicht sichtbar. :wand:

Jedenfalls reagiert das Modem im Online Betrieb auf keinerlei SNMP Anfragen.
Nur die Ports 80 und 8080 sind offen.
Über Port 8080 kommt man auf den Spectrum Analyzer, dort wird der Standard Login akzeptiert.
Über Port 80 kommt man nur bis zum Login Fenster, der Standard Login wird hier aber nicht akzeptiert.
Und das Modem lässt sich über die 192.168.100.1 anpingen.
Mehr geht nicht, das Modem ist ansonsten komplett dicht.

 

[Flole]

Hört auf mit dem Public wenn eure ip nicht ein Teil von 10.0.0.0/255.0.0.0 ist, das klappt sowieso nicht weil es in der config limitiert ist. Das könnt ihr euch also sparen. Hatte ich schonmal erwähnt.

 

[Andreas1969]

Hört auf mit dem Public wenn eure ip nicht ein Teil von 10.0.0.0/255.0.0.0 ist, das klappt sowieso nicht weil es in der config limitiert ist. Das könnt ihr euch also sparen. Hatte ich schonmal erwähnt.

Wie meinst Du das genau :kratz:
Ich kann nämlich ein unprovisioniertes Modem anschließen, da bekomme ich dann ne Adresse aus 10.0.0.0/255.0.0.0 zugewiesen.
Dann sollte man ja von da aus übers interne UM Netz auf das TC4400 zugreifen können.
Wie bekomme ich aber die 10er Adresse des TC4400 raus? Man kann da nicht mitloggen.

 

[nts]

Hinweis: Versucht die Anfragen mittels der bekannten Communities (Austausch public) aus diesem Thread auch mal zu einer Zeit, wo das Modem nicht registriert ist. Oft ist der Zugriff auf SNMP nur vor der fertigen Registrierung möglich. Die beste Chance ist eigentlich nach einem Factory-Reset, vor der ersten Anmeldung. Noch bevor das Modem neue Communities vom Provider drübergebügelt bekommen hat. Dann sollten die Communities auch noch public für RO und private für RW lauten.

Hier mal die komplette Ausgabe von snmpwalk, als das Modem noch nicht angeschlossen war: https://dpaste.de/2MO2/raw

 

[Flole]

Hört auf mit dem Public wenn eure ip nicht ein Teil von 10.0.0.0/255.0.0.0 ist, das klappt sowieso nicht weil es in der config limitiert ist. Das könnt ihr euch also sparen. Hatte ich schonmal erwähnt.

Wie meinst Du das genau :kratz:
Ich kann nämlich ein unprovisioniertes Modem anschließen, da bekomme ich dann ne Adresse aus 10.0.0.0/255.0.0.0 zugewiesen.
Dann sollte man ja von da aus übers interne UM Netz auf das TC4400 zugreifen können.
Wie bekomme ich aber die 10er Adresse des TC4400 raus? Man kann da nicht mitloggen.

In der config datei ist der Zugriff von Public limitiert. Das da oben soll auch nicht 10.0.0.0 sein sondern 172.0.0.0. Sorry. Könnte auch ein Management Interface sein wo du so gar kein Zugriff hast.

 

[Flole]

Hinweis: Versucht die Anfragen mittels der bekannten Communities (Austausch public) aus diesem Thread auch mal zu einer Zeit, wo das Modem nicht registriert ist. Oft ist der Zugriff auf SNMP nur vor der fertigen Registrierung möglich. Die beste Chance ist eigentlich nach einem Factory-Reset, vor der ersten Anmeldung. Noch bevor das Modem neue Communities vom Provider drübergebügelt bekommen hat. Dann sollten die Communities auch noch public für RO und private für RW lauten.

Hier mal die komplette Ausgabe von snmpwalk, als das Modem noch nicht angeschlossen war: https://dpaste.de/2MO2/raw

So, und jetzt das ganze nochmal mit provisioniertem Modem und der richtigen Community. Wenn das nicht klappt dann geht es wirklich nur über das Management Interface.

 

[tq1199]

Ich kann nämlich ein unprovisioniertes Modem anschließen, da bekomme ich dann ne Adresse aus 10.0.0.0/255.0.0.0 zugewiesen.
Dann sollte man ja von da aus übers interne UM Netz auf das TC4400 zugreifen können.
Wie bekomme ich aber die 10er Adresse des TC4400 raus? Man kann da nicht mitloggen.

Evtl. mit:

<i>
</i>sudo arp-scan -NR -I <Interface> 10.0.0.0/8

(Interface ohne spitze Klammern und anpassen) mal versuchen.

 

[Flole]

Ich kann nämlich ein unprovisioniertes Modem anschließen, da bekomme ich dann ne Adresse aus 10.0.0.0/255.0.0.0 zugewiesen.
Dann sollte man ja von da aus übers interne UM Netz auf das TC4400 zugreifen können.
Wie bekomme ich aber die 10er Adresse des TC4400 raus? Man kann da nicht mitloggen.

Evtl. mit:

<i>
</i>sudo arp-scan -NR -I <Interface> 10.0.0.0/8

(Interface ohne spitze Klammern und anpassen) mal versuchen.

Falsche IP da oben, muss natürlich 172.0.0.0 heißen. War nen Fehler von mir vorhin. Dürfte das Management nic sein, wenn du pech hast antworten da tausende Unitymedia Modems.

 

[tq1199]

Falsche IP da oben, ...

Naja, aber wenn er doch schon eine IP-Adresse aus dem 10.0.0.0/8er Subnetz zugewiesen bekommen hat und sich mit seinem border device schon in diesem Subnetz befindet, dann kann er doch in diesem Subnetz, mal auch arp-scannen.

Wegen mir, danach auch mit:

<i>
</i>sudo arp-scan -NR -I <Interface> 172.0.0.0/8

(oder gleichwertig).

 

[Andreas1969]

Naja, aber wenn er doch schon eine IP-Adresse aus dem 10.0.0.0/8er Subnetz zugewiesen bekommen hat

Da könnte ich mal einen Versuchsaufbau machen.
Hab hie noch'n paar Modems rumliegen, wo ich die interne 10er Service IP des Modems auslesen kann.
Wenn ich 2 davon anschließe, könnte ich schauen, ob man von einem Modem über die 10er IP auf die Oberfläche des jeweiligen anderen Modems kommt.

 

[Flole]

Falsche IP da oben, ...

Naja, aber wenn er doch schon eine IP-Adresse aus dem 10.0.0.0/8er Subnetz zugewiesen bekommen hat und sich mit seinem border device schon in diesem Subnetz befindet, dann kann er doch in diesem Subnetz, mal auch arp-scannen.

Wegen mir, danach auch mit:

<i>
</i>sudo arp-scan -NR -I <Interface> 172.0.0.0/8

(oder gleichwertig).

Das Modem kriegt aber dort keine IP, da es eben ein Modem ist. Die 10.0.0.0/8 müssten die "öffentlichen" IPs von unprovisionierten Geräten sein.

 

[Andreas1969]

Das Modem kriegt aber dort keine IP, da es eben ein Modem ist. Die 10.0.0.0/8 müssten die "öffentlichen" IPs von unprovisionierten Geräten sein.

Bist Du Dir da sicher?
Hier mal ein Ausschnitt vom einer Protokollierung des Bootvorgangs eines provisionierten Modems:

1076.INFO] [DOCSIS.IPP(pid=662)]: -------------------------------------------------------
1077.[INFO] [DOCSIS.IPP(pid=662)]: IP provisioning start in the IP_PROV_V4_ONLY mode
1078.[INFO] [DOCSIS.IPP(pid=662)]: -------------------------------------------------------
1079.pcd: (87): Rule DOCSIS_DMGPROV: Success (Process /usr/sbin/dmg_provisioning (662)).
1080.pcd: (87): Starting process /sbin/ti_udhcpc (Rule DOCSIS_DHCPV4).
1081.pcd: (87): [DK] PCD_timer_handle_end_condition(703): Kill the Process(pid=324, daemon flag=1) with SIGTERM
1082..
1083.pcd: (87): Rule DOCSIS_DHCPV4: Success (Process /sbin/ti_udhcpc (663)).
1084.info, Received SIGTERM
1085.debug, default_plugin_init
1086.
1087.info, Plugin UDHCPC Default registered successfully
1088.
1089.info, Plugin Sample registered successfully
1090.
1091.info, TI udhcp client (v1.0) started
1092.info, TI udhcp client read_interface, udhcp_client_config.ifindex = 7
1093.debug, entering raw listen mode
1094.info, udhcpc_get_stats
1095.debug, Sending discover...
1096.info, udhcpc_get_stats
1097.info, udhcpc_get_stats
1098.debug, Sending select for 10.139.120.190...
1099.SNMPA_CreateSocketEntry : type 1, addr = a8b78be, port = 161, ifname = wan0 List = 0x6e0c0
1100.SNMPA_CreateSocketEntry : type 1, addr = a8b78be, port = 162, ifname = wan0 List = 0x6e0c0
1101.[INFO_VERBOSE] [DOCSIS.UTILS(pid=663)]: [utils_system]: The processing of the wait status NOT IMPLEMENTED YET opt = 0
1102.[INFO] [DOCSIS.IPP(pid=663)]: [DHCP4_PLG]: Set to the wan0 addr: 10.139.120.190 mask: 255.255.240.0 router: 10.139.112.1
1103.[INFO_VERBOSE] [DOCSIS.IPP(pid=663)]: ================== The DHCPv4 succesfully set to IP DB: ====================
1104.[INFO_VERBOSE] [DOCSIS.IPP(pid=663)]: ******** Cm Ip Addr ********
1105.[INFO] [DOCSIS.UTILS(pid=663)]: 10.139.120.190
1106.[INFO_VERBOSE] [DOCSIS.IPP(pid=663)]: IP addr type = IPv4
1107.[INFO_VERBOSE] [DOCSIS.IPP(pid=663)]: IP addr family = AF_INET
1108.[INFO_VERBOSE] [DOCSIS.IPP(pid=663)]: IP addr subnet = 255.255.240.0
1109.[INFO_VERBOSE] [DOCSIS.IPP(pid=663)]: **************************
1110.[INFO_VERBOSE] [DOCSIS.IPP(pid=663)]: ******** DHCP server Addr ********
1111.info, udhcpc_get_stats
1112.info, No DHCP_T2 option, by default T2=lease * 0.875
1113.
1114.debug, DHCP_T2 selected=146580
1115.
1116.info, No DHCP_T1 option, by default T1=lease/2
1117.
1118.debug, entering none listen mode
1119.Info, default_plugin_init
1120.
1121.Info, Plugin TI_TODC Default registered successfully
1122.
1123.pcd: (87): Error: Process /sbin/udhcpd (324) exited unexpectedly (Rule LOCAL_DHCPV4).
1124.[INFO] [DOCSIS.UTILS(pid=663)]: 81.210.135.4
1125.[INFO_VERBOSE] [DOCSIS.IPP(pid=663)]: IP addr type = IPv4
1126.[INFO_VERBOSE] [DOCSIS.IPP(pid=663)]: IP addr family = AF_INET
1127.[INFO_VERBOSE] [DOCSIS.IPP(pid=663)]: IP addr subnet = 255.255.240.0
1128.[INFO_VERBOSE] [DOCSIS.IPP(pid=663)]: **************************
1129.[INFO_VERBOSE] [DOCSIS.IPP(pid=663)]: ******** Log server Addr ********
1130.[INFO] [DOCSIS.UTILS(pid=663)]: 172.31.1.76
1131.[INFO_VERBOSE] [DOCSIS.IPP(pid=663)]: IP addr type = IPv4
1132.[INFO_VERBOSE] [DOCSIS.IPP(pid=663)]: IP addr family = AF_INET
1133.[INFO_VERBOSE] [DOCSIS.IPP(pid=663)]: IP addr subnet = 255.255.240.0
1134.[INFO_VERBOSE] [DOCSIS.IPP(pid=663)]: **************************
1135.[INFO_VERBOSE] [DOCSIS.IPP(pid=663)]: ******** Router InetAddr List ********
1136.[INFO_VERBOSE] [DOCSIS.IPP(pid=663)]: ******** InetAddr 0 ********
1137.[INFO] [DOCSIS.UTILS(pid=663)]: 10.139.112.1
1138.[INFO_VERBOSE] [DOCSIS.IPP(pid=663)]: IP addr type = IPv4
1139.[INFO_VERBOSE] [DOCSIS.IPP(pid=663)]: IP addr family = AF_INET
1140.[INFO_VERBOSE] [DOCSIS.IPP(pid=663)]: IP addr subnet = 255.255.240.0
1141.[INFO_VERBOSE] [DOCSIS.IPP(pid=663)]: **************************
1142.[INFO_VERBOSE] [DOCSIS.IPP(pid=663)]: IP Addr List length = 1, curr index = 0
1143.[INFO_VERBOSE] [DOCSIS.IPP(pid=663)]: **************************
1144.[INFO_VERBOSE] [DOCSIS.IPP(pid=663)]: ******** TOD Entry ********
1145.[INFO_VERBOSE] [DOCSIS.IPP(pid=663)]: ******** TOD address list ********