Unitymedia Technicolor TC4400 FW Update Wie?

[robert_s]

ein tftpd laeuft jedenfalls :smile:

Und da sollte eine Datei namens "hardware_id.txt" abrufbar sein, denn die wird da reinkopiert:

cp /data/hardware_id.txt /var/tftpboot

Kannst Du mal probieren, die mit tftp get zu holen? P.S. eine Datei namens "version.txt" könnte da eventuell auch liegen. Bitte auch abzuholen probieren...

Desweiteren wird vermutlich ein inotify auf das beschreibbare tftpd-Verzeichnis gesetzt, sodass das Programm eine Benachrichtigung erhält, wenn man da etwas hochlädt...

 

[sparkie]

sorry, ich muss erst mein Testequipment umbauen. Ich nehm jetzt ein APU mit 3 Ethernetports. Die routet mir dann zwischen dem Modem IP Subnet und meinem internen LAN. Ein Laptop als Testdevice ist auf Dauer etwas laestig. Wenn ich staendig das Interface umschalten muss.

 

[sparkie]

Umbau Testequipment fertig. Jetzt kann man deutlich komfortabler testen :smile:
Folgendes Script starte ich in dem kurzen Zeitfenster, wenn die 172.31.255.40 online ist:

<i>
</i>tftp << !
status
verbose
connect 172.31.255.40
binary
status
get hardware_id.txt
get version.txt
quit
!

Ausgabe:

<i>
</i>tftp> Not connected.
Mode: netascii Verbose: off Tracing: off
Rexmt-interval: 5 seconds, Max-timeout: 25 seconds
tftp> Verbose mode on.
tftp> tftp> mode set to octet
tftp> Connected to 172.31.255.40.
Mode: octet Verbose: on Tracing: off
Rexmt-interval: 5 seconds, Max-timeout: 25 seconds
tftp> getting from 172.31.255.40:hardware_id.txt to hardware_id.txt [octet]
Received 6 bytes in 0.0 seconds [inf bits/sec]
tftp> getting from 172.31.255.40:version.txt to version.txt [octet]
Received 7160 bytes in 0.0 seconds [inf bits/sec]

Inhalt der beiden gewuenschten Dateien:

<i>
</i>4409 root@fire-a[/root] > cat -A hardware_id.txt
3.6.0$

<i>
</i>4413 root@fire-a[/root] > cat version.txt +------------------------------------------------------------------------------------------------+ | _/_/ _/ _/ _/_/_/ | | _/ _/ _/_/ _/_/ _/ | | _/ _/ _/ _/ _/ | | _/ _/ _/ _/_/ | | _/ _/ _/ _/ | |_/ _/ _/ _/ _/ | | _/_/ _/ _/ _/_/_/ | | | | Copyright (c) 1999 - 2017 Broadcom Corporation | | | | Revision : Prod_6.1.2 | | | | Features : IPv6 Stack Version 1.3.1 | | | +------------------------------------------------------------------------------------------------+ | Build Date : May 22 2017 | | Build Time : 14:59:18 (+0200) | | Build Location : /data02/work/swarm/slave_rennslxci13_8096/workspace/tc4400_build_au_eu_am/33 | | Build Location : 9x/rg/rg_apps | | Build By : tc4400_ref | | Build Tag : Tag_Release_SR70.x2.30-2-g9c97696-dirty | | Build Options : BRCM_3390 BRCM_CHIP=3390 PROFILE_ARCH=arm BRCM_BOARD_93390DCM | | Build Options : BRCM_BOARD_ID=93390DCM BUILD_BDMF_SHELL BRCM_CABLE BRCM_CABLE_ARM | | Build Options : LINUX_3_14_STB PROFILE_KERNEL_VER=LINUX_3_14_STB BUILD_BRCM_CMS | | Build Options : BUILD_DM_PURE181 BUILD_BACKUP_PSI COMPRESSED_CONFIG_FILE | | Build Options : CMS_CONFIG_IGNORE_UNRECOGNIZED BUILD_MDM_VERSIONING BUILD_WLAN_none | | Build Options : BUILD_BRCTL BUILD_IPV6 BUILD_SNTP BUILD_IEEE1905 BUILD_LAG BUILD_EBTABLES | | Build Options : BUILD_EROUTERCTL BUILD_EROUTERCTL_CM BUILD_BRONLY_MODE BUILD_CUSTOTP | | Build Options : BUILD_CONSOLED BUILD_CLI_CMD BUILD_TELNETD BUILD_HTTPD_SSL BUILD_WEBSOCKET | | Build Options : BRCM_LANG_EN BRCM_WEBUI_LANG=en_US MGMT_none BUILD_MSO_NONE BUILD_SNMP | | Build Options : BUILD_HASHED_PASSWORDS BUILD_DEBUG_TOOLS ENABLE_APP_COREDUMPS CMS_LOG_DEBUG | | Build Options : CMS_LOG_LEVEL_2 CMS_BYPASS_LOGIN BUILD_CMS_UNIT_TESTS CMS_LOCK_DEBUG | | Build Options : BUILD_IPERF | +------------------------------------------------------------------------------------------------+ | Linux Kernel | | | | Revision : 3.14.28-rgProd_6.1.2#3 SMP Mon May 22 14:58:42 CEST 2017 | | | +------------------------------------------------------------------------------------------------+ | RUNNER | | | | Copyright (c) 1999 - 2017 Broadcom Corporation | | | | Revision : 1.4.0 Software: 127405 Firmware: 127405 | +------------------------------------------------------------------------------------------------+ | BOLT | | | | Copyright (c) 1999 - 2017 Broadcom Corporation | | | | Revision : 1.53 | | Build Timestamp: 2016-09-23 15:03:55 | | Build Tag : v1.53-RLS-6.1.1beta1_B1 | | Build By : lemerrerv@rennslxcomp35 | +------------------------------------------------------------------------------------------------+

 

[robert_s]

Interessant. Er reagiert, wenn man eine Datei namens "eroutercfg.bin" mit tftp draufschiebt. Kannst Du vielleicht mal mit tftp GET versuchen, ob man die auch herunterladen kann? Glaube ich eigentlich nicht, aber probieren kann man's ja mal...

P.S.: Und jetzt wo Du eine version.txt hast, könntest Du die auch mal auf Deinen tftpd legen und schauen, was passiert, wenn das Modem die zieht...

P.P.S.: Hier gibt's ein Log bei pastebin, wo jemand eine eroutercfg.bin in sein Broadcom-Kabelmodem lädt: https://pastebin.com/jTS6V3ET

 

[sparkie]

die "eroutercfg.bin" findet er nicht

<i>
</i>tftp> getting from 172.31.255.40:eroutercfg.bin to eroutercfg.bin [octet]
Error code 1: can't open file

die Sache mit dem eigenen 'tftpd' und dass davon das Modem was abholt scheint ein Geruecht zu sein. Bisher hat man geglaubt, man muesse die IP 172.31.255.40 selbst zur Verfuegung stellen mit dem Service tftp. Vielmehr ist es so, dass das Modem die 172.31.255.40 selbst zur Verfuegung stellt (mit tftp, siehe Portscans weiter unten)

Der Ablauf nach Einschalten des Modems ist folgender. Ich starte dieses Script zeitgleich mit PowerOn:

<i>
</i>#!/bin/sh
awk 'BEGIN { CMD = "ping -DOl1 172.31.255.40" while (CMD | getline line > 0) { split(line, a, "\\[|\\]") if (!match(line, "Unreachable")) print strftime("%T", a[2]) ":" a[3] a[4] a[5] }
}'

Ausgabe liefert:

<i>
</i>05:10:35: no answer yet for icmp_seq=1
05:10:36: no answer yet for icmp_seq=2
05:10:37: no answer yet for icmp_seq=3
05:10:38: no answer yet for icmp_seq=4
05:10:39: no answer yet for icmp_seq=5
05:10:40: no answer yet for icmp_seq=6
05:10:41: no answer yet for icmp_seq=7
05:10:42: no answer yet for icmp_seq=8
05:10:43: no answer yet for icmp_seq=9
05:10:44: no answer yet for icmp_seq=10
05:10:45: no answer yet for icmp_seq=11
05:10:46: no answer yet for icmp_seq=12
05:10:47: no answer yet for icmp_seq=13
05:10:47: 64 bytes from 172.31.255.40: icmp_seq=14 ttl=64 time=4.57 ms
05:10:48: 64 bytes from 172.31.255.40: icmp_seq=15 ttl=64 time=1.97 ms
05:10:49: 64 bytes from 172.31.255.40: icmp_seq=16 ttl=64 time=2.06 ms
05:10:50: 64 bytes from 172.31.255.40: icmp_seq=17 ttl=64 time=1.87 ms
05:10:51: 64 bytes from 172.31.255.40: icmp_seq=18 ttl=64 time=1.96 ms
05:10:52: 64 bytes from 172.31.255.40: icmp_seq=19 ttl=64 time=2.20 ms
05:10:53: 64 bytes from 172.31.255.40: icmp_seq=20 ttl=64 time=2.04 ms
05:10:54: 64 bytes from 172.31.255.40: icmp_seq=21 ttl=64 time=1.90 ms
05:10:55: 64 bytes from 172.31.255.40: icmp_seq=22 ttl=64 time=1.95 ms
05:10:57: no answer yet for icmp_seq=23
05:10:58: no answer yet for icmp_seq=24
05:10:59: no answer yet for icmp_seq=25
05:11:00: no answer yet for icmp_seq=26

d.h. ca. 12s bis 17s nach Einschalten des Modems geht IP 172.31.255.40 fuer 10s online und ich kann in der Zeit wueste Sachen mit dem Modem anstellen.

Z.B. einen Subnet Scan anstossen (oder hoffentlich mal eine Firmware hochladen ):

<i>
</i>awk 'BEGIN { CMD = "ping -DOl1 172.31.255.40" while (CMD | getline line > 0) { split(line, a, "\\[|\\]") if (!match(line, "Unreachable")) print strftime("%T", a[2]) ":" a[3] a[4] a[5] if (match(line, "bytes from")) exit }
}'
nmap -sP 172.31.255.0/24

liefert:

<i>
</i>05:44:02: no answer yet for icmp_seq=1
05:44:03: no answer yet for icmp_seq=2
05:44:04: no answer yet for icmp_seq=3
05:44:05: no answer yet for icmp_seq=4
05:44:06: no answer yet for icmp_seq=5
05:44:07: no answer yet for icmp_seq=6
05:44:08: no answer yet for icmp_seq=7
05:44:09: no answer yet for icmp_seq=8
05:44:10: no answer yet for icmp_seq=9
05:44:11: no answer yet for icmp_seq=10
05:44:12: no answer yet for icmp_seq=11
05:44:13: no answer yet for icmp_seq=12
05:44:14: no answer yet for icmp_seq=13
05:44:14: 64 bytes from 172.31.255.40: icmp_seq=14 ttl=64 time=2.61 ms
Starting Nmap 7.40 ( https://nmap.org ) at 2018-05-27 05:44 CEST
Nmap scan report for 172.31.255.20
Host is up (0.0022s latency).
MAC Address: 02:10:18:10:B7:12 (Unknown)
Nmap scan report for 172.31.255.40
Host is up (-0.099s latency).
MAC Address: 02:10:18:10:B7:12 (Unknown)
Nmap scan report for 172.31.255.70
Host is up (0.0016s latency).
MAC Address: 02:10:18:10:B7:12 (Unknown)
Nmap scan report for 172.31.255.31
Host is up.
Nmap done: 256 IP addresses (4 hosts up) scanned in 3.00 seconds

dieser Test zeigt, dass das Modem in der fraglichen Zeit ein Interface mit 3 IP Adressen (172.31.255.20, 172.31.255.40 und 172.31.255.70) online bringt (die 172.31.255.31 bin ich selbst).

das witzige dabei ist die MAC des Modems (hier: 02:10:18:10:B7:12) erzeugt es immer wieder neu (nach jedem Reboot)

vielleicht reicht es ja wenn man dem Teil per tftp eine entsprechende Firmware Datei irgendwohin schiebt :smile:

 

[sparkie]

hinter den 3 IPs verbergen sich folgende TCP/UDP Services:

172.31.255.20:

<i>
</i>Starting Nmap 7.40 ( https://nmap.org ) at 2018-05-27 06:04 CEST
Nmap scan report for 172.31.255.20
Host is up (0.0091s latency).
Not shown: 997 closed ports
PORT STATE SERVICE
80/tcp open http
443/tcp open https
8080/tcp filtered http-proxy
MAC Address: 10:62:D0:45:67:89 (Unknown)
Nmap done: 1 IP address (1 host up) scanned in 3.67 seconds
Starting Nmap 7.40 ( https://nmap.org ) at 2018-05-27 06:04 CEST
Warning: 172.31.255.20 giving up on port because retransmission cap hit (1).
Nmap scan report for 172.31.255.20
Host is up (0.0033s latency).
Not shown: 288 open|filtered ports
PORT STATE SERVICE
26/udp closed unknown
44/udp closed mpm-flags
54/udp closed xns-ch
84/udp closed ctf
92/udp closed npp
117/udp closed uucp-path
136/udp closed profile
154/udp closed netsc-prod
161/udp open snmp
228/udp closed unknown
238/udp closed unknown
285/udp closed unknown
MAC Address: 10:62:D0:45:67:89 (Unknown)
Nmap done: 1 IP address (1 host up) scanned in 6.17 seconds

172.31.255.40:

<i>
</i>Starting Nmap 7.40 ( https://nmap.org ) at 2018-05-27 06:00 CEST
Nmap scan report for 172.31.255.40
Host is up (0.0011s latency).
Not shown: 997 closed ports
PORT STATE SERVICE
80/tcp open http
443/tcp open https
8080/tcp filtered http-proxy
MAC Address: 10:62:D0:45:67:89 (Unknown)
Nmap done: 1 IP address (1 host up) scanned in 3.50 seconds
Starting Nmap 7.40 ( https://nmap.org ) at 2018-05-27 06:00 CEST
Warning: 172.31.255.40 giving up on port because retransmission cap hit (1).
Nmap scan report for 172.31.255.40
Host is up (0.0058s latency).
Not shown: 289 open|filtered ports
PORT STATE SERVICE
22/udp closed ssh
69/udp open tftp
91/udp closed mit-dov
131/udp closed cisco-tna
132/udp closed cisco-sys
160/udp closed sgmp-traps
161/udp open snmp
174/udp closed mailq
211/udp closed 914c-g
289/udp closed unknown
294/udp closed unknown
MAC Address: 10:62:D0:45:67:89 (Unknown)
Nmap done: 1 IP address (1 host up) scanned in 5.84 seconds

172.31.255.70:

<i>
</i>TBD (ich muss jetzt fuer ein paar STunden offline gehen)

 

[robert_s]

Also soweit ich das sehe, wird eine per TFTP reingeschobene "eroutercfg.bin" gelesen, geflasht (cmsMgm_saveConfigToFlash) und dann dem CM per RPC Bescheid gesagt.

Kann es sein, dass die passende Datei sogar schon "in der Community" vorhanden ist?

Das Modem lädt als erstes die Docsis Config Datei "tc4400v4.cfg"
In der Config Datei stehen dann die Angaben "FW Datei" und TFTP Server Adresse.

Da könnte man mal "wagemutig" probieren, diese "tc4400v4.cfg" (ggf. mit angepasster TFTP Server Adresse) als "eroutercfg.bin" in das Modem reinzupushen, und zu schauen, ob man dann vielleicht eine Anfrage nach der Firmware-Datei auf seinen TFTP-Server bekommt... Ist aber nicht ganz ungefährlich, denn mit dem Flashen werden ja offenbar persistente Änderungen vorgenommen - dann ist das Modem also nach an/aus nicht mehr "wie vorher"...

 

[Andreas1969]

Da könnte man mal "wagemutig" probieren, diese "tc4400v4.cfg" (ggf. mit angepasster TFTP Server Adresse) als "eroutercfg.bin" in das Modem reinzupushen, und zu schauen, ob man dann vielleicht eine Anfrage nach der Firmware-Datei auf seinen TFTP-Server bekommt...

So müsste das dann aussehen:

TFTP/LINUX Server LOGS
Jan 30 11:18:00 localhost dhcpd: @@ Software Version: SR70.12.25a
Jan 30 11:18:00 localhost dhcpd: @@ Model Number: TC4400
Jan 30 11:18:03 localhost dhcpd: DHCPACK on 172.22.8.155 to 48:00:33:c3:fe:94 via 172.22.8.1
Jan 30 11:18:06 localhost in.tftpd[21663]: RRQ from 172.22.8.155 filename tc4400v4.cfg
Jan 30 11:18:06 localhost in.tftpd[21663]: Client 172.22.8.155 finished tc4400v4.cfg
Jan 30 11:18:13 localhost in.tftpd[21668]: RRQ from 172.22.8.155 filename DORGKLDT_SR701230a_JK_84-E.img
Jan 30 11:19:40 localhost in.tftpd[21668]: Client 172.22.8.155 finished DORGKLDT_SR701230a_JK_84-E.img
Jan 30 11:22:00 localhost dhcpd: @@ Software Version: SR70.12.30a
Jan 30 11:22:00 localhost dhcpd: @@ Model Number: TC4400

 

[JPDribbler]

Also soweit ich das sehe, wird eine per TFTP reingeschobene "eroutercfg.bin" gelesen, geflasht (cmsMgm_saveConfigToFlash) und dann dem CM per RPC Bescheid gesagt.

Kann es sein, dass die passende Datei sogar schon "in der Community" vorhanden ist?

Das Modem lädt als erstes die Docsis Config Datei "tc4400v4.cfg"
In der Config Datei stehen dann die Angaben "FW Datei" und TFTP Server Adresse.

Da könnte man mal "wagemutig" probieren, diese "tc4400v4.cfg" (ggf. mit angepasster TFTP Server Adresse) als "eroutercfg.bin" in das Modem reinzupushen, und zu schauen, ob man dann vielleicht eine Anfrage nach der Firmware-Datei auf seinen TFTP-Server bekommt... Ist aber nicht ganz ungefährlich, denn mit dem Flashen werden ja offenbar persistente Änderungen vorgenommen - dann ist das Modem also nach an/aus nicht mehr "wie vorher"...

@Robert:

Willst du ein Modem zum Spielen haben? Bald sollte ich wieder eins (von 3) bekommen, allerdings wird dann dort wahrscheinlich schon die Labor Firmware drauf sein - die finale kommt aber bald...

 

[sparkie]

Nachlieferung fuer

172.31.255.70:

<i>
</i>Starting Nmap 7.40 ( https://nmap.org ) at 2018-05-27 12:33 CEST
Warning: 172.31.255.70 giving up on port because retransmission cap hit (1).
Nmap scan report for 172.31.255.70
Host is up (0.0020s latency).
Not shown: 1498 closed ports
PORT STATE SERVICE
80/tcp open http
443/tcp open https
MAC Address: 10:62:D0:45:67:89 (Unknown)
Nmap done: 1 IP address (1 host up) scanned in 10.27 seconds
Starting Nmap 7.40 ( https://nmap.org ) at 2018-05-27 12:30 CEST
Warning: 172.31.255.70 giving up on port because retransmission cap hit (1).
Nmap scan report for 172.31.255.70
Host is up (0.0029s latency).
Not shown: 386 open|filtered ports
PORT STATE SERVICE
1/udp closed tcpmux
2/udp closed compressnet
3/udp closed compressnet
4/udp closed unknown
5/udp closed rje
9/udp closed discard
10/udp closed unknown
32/udp closed unknown
83/udp closed mit-ml-dev
153/udp closed sgmp
161/udp open snmp
215/udp closed softpc
291/udp closed unknown
380/udp closed is99s
MAC Address: 10:62:D0:45:67:89 (Unknown)
Nmap done: 1 IP address (1 host up) scanned in 8.20 seconds

nun habe ich gesehen das Modem erzeugt ca. 27s nach PowerOn fuer kurze Zeit (ca. 1s) an seinem Interface noch eine IP 172.31.255.45:

<i>
</i>12:35:44: no answer yet for icmp_seq=1
12:35:45: no answer yet for icmp_seq=2
12:35:46: no answer yet for icmp_seq=3
12:35:47: no answer yet for icmp_seq=4
12:35:48: no answer yet for icmp_seq=5
12:35:49: no answer yet for icmp_seq=6
12:35:51: no answer yet for icmp_seq=7
12:35:52: no answer yet for icmp_seq=8
12:35:53: no answer yet for icmp_seq=9
12:35:54: no answer yet for icmp_seq=10
12:35:55: no answer yet for icmp_seq=11
12:35:56: no answer yet for icmp_seq=12
12:35:57: no answer yet for icmp_seq=13
12:35:58: no answer yet for icmp_seq=14
12:35:59: no answer yet for icmp_seq=15
12:36:00: no answer yet for icmp_seq=16
12:36:01: no answer yet for icmp_seq=17
12:36:02: no answer yet for icmp_seq=18
12:36:03: no answer yet for icmp_seq=19
12:36:04: no answer yet for icmp_seq=20
12:36:05: no answer yet for icmp_seq=21
12:36:06: no answer yet for icmp_seq=22
12:36:07: no answer yet for icmp_seq=23
12:36:08: no answer yet for icmp_seq=24
12:36:09: no answer yet for icmp_seq=25
12:36:10: no answer yet for icmp_seq=26
12:36:11: no answer yet for icmp_seq=27
12:36:11: 64 bytes from 172.31.255.45: icmp_seq=28 ttl=64 time=7.62 ms
12:36:13: no answer yet for icmp_seq=29
12:36:14: no answer yet for icmp_seq=30
12:36:15: no answer yet for icmp_seq=31

was die fuer eine Funktion haben soll ist mir unklar

 

[robert_s]

So müsste das dann aussehen:

Kann man Deine Config-Dateien (tc4400v4.cfg und tc4400Boot.cfg) eigentlich irgendwo herunterladen? Ich sehe übrigens gerade:

Software Upgrade TFTP server:172.31.255.40
Software Upgrade FilenameORGKLDT_SR701230a_JK_84-E.img

Das ist ja auch eine spannende Variante: Das Modem die Firmware vom eigenen TFTP-Server laden zu lassen. Wenn das klappt, könnte man ganz ohne eigenen tftp-Server auskommen, indem man das Script von @sparkie nur leicht ergänzt:

<i>
</i>tftp << !
status
verbose
connect 172.31.255.40
binary
status
get hardware_id.txt
get version.txt
put DORGKLDT_SR701230a_JK_84-E.img
put tc4400Boot.cfg eroutercfg.bin
quit
!

Edit: Hatte vergessen, dass das Configfile auf dem Modem ja "eroutercfg.bin" heißen muss. Habe das ergänzt.

 

[sparkie]

wie ist denn der Mechanismus mit dem das Modem etwas vom tftp laedt?

Es sieht so aus als muesste die fragliche Datei, die vom Modem geholt werden soll erst auf den Modem-eigenen tftp Server (hinter 172.31.255.40) geladen werden. Von dort holt sich das Modem ueber seine IP 172.31.255.45 per tftp Zugriff die Datei.

Denn:
Wenn ich fuer meine eigene IP Adresse (des Testsystems) genau die 172.31.255.40 vergebe und darauf ebenfalls noch einen tftp-Service starte, dann greift ca 27s nach Modem-PowerOn das Modem ueber seine 172.31.255.45 auf meine 172.31.255.40 zu. Die 172.31.255.40 ist zu dem Zeitpunkt natuerlich 2x im System vorhanden, denn das Modem hat ja seinen eigenen tftp ebenfalls darauf laufen. Man sieht aber sporadisch (trotz duplicate IP) den Zugriff des Modems im Log meines Testsytems:

<i>
</i>May 27 12:54:38 fire-a in.tftpd[2911]: connect from 172.31.255.45 (172.31.255.45)
May 27 12:54:38 fire-a tftpd[2912]: tftpd: trying to get file: version.txt
May 27 12:54:38 fire-a tftpd[2912]: tftpd: serving file from /srv/tftp

dieser Hack funktioniert auch nur dann, wenn ich von meinem Testsystem (testweise konfiguriert auf 172.31.255.40) einen heftigen Echo-Request auf das Modem loslasse:

<i>
</i>ping -W 0 -i 0.3 172.31.255.45

dann gelangen anscheinend nen paar ftp-request Pakete zu meinem Testsystem tftp statt auf den Modem-tftp

 

[sparkie]

Das ist ja auch eine spannende Variante: Das Modem die Firmware vom eigenen TFTP-Server laden zu lassen. Wenn das klappt, könnte man ganz ohne eigenen tftp-Server auskommen, indem man das Script von @sparkie nur leicht ergänzt:

kannst du Gedanken lesen? :smile:

du hast die ANtwort auf meine Frage gegeben, bevor ich sie zu Ende formuliert hatte. Es ist in der Tat so, dass die Modem IP 172.31.255.45 die Dateien vom Modem-eigenen tftp-Server auf 172.31.255.40 holen will. Die IP 172.31.255.45 ist nur fuer sehr kurze Zeit ping-bar (siehe oben). Aber dann waere zumindest die Funktion der 172.31.255.45 geklaert.

 

[sparkie]

Leute, es ist zwar wahnsinnig spannend, aber es ist Sonntag und ich muss wieder fuer ein paar Stunden offline gehen. Ich bekomm' sonst einen wahnsinnigen Aerger an den Hals :brüll:

 

[robert_s]

dieser Hack funktioniert auch nur dann, wenn ich von meinem Testsystem (testweise konfiguriert auf 172.31.255.40) einen heftigen Echo-Request auf das Modem loslasse:

Normalerweise werden IPv4-Adresskonflikte (also doppelt vergebene IPv4-Adressen) vermieden. Windows-Rechner schicken z.B. erst mal einen ARP-Request, um sicherzustellen, dass da niemand darauf antwortet, es also die Adresse nicht schon gibt. Das scheint das Modem nicht aktiv zu tun, aber mit Deinem "Dauerping" drückst Du ihm wohl Deine Adresszuweisung in den ARP-Cache.

Eine bereits vergebene IPv4-Adresse sollte sich dann nicht mehr an den eigenen Netwerkadapter binden lassen. Entsprechend könnte die Konsequenz sein, dass der tftp-Server auf dem Modem gar nicht mehr startet.

Ich bin mir aber nicht sicher, dass das beabsichtigt ist, dass man den tftp-Server so "nach extern umbiegen" kann. Das scheint mir eher ein von den Entwicklern unerwarteter Effekt zu sein.

Übrigens habe ich nicht herausgefunden, welcher der Teil der Firmware die Datei "version.txt" via tftp lädt...

 

[sparkie]

Ich bin mir aber nicht sicher, dass das beabsichtigt ist, dass man den tftp-Server so "nach extern umbiegen" kann. Das scheint mir eher ein von den Entwicklern unerwarteter Effekt zu sein.

ich habe das natuerlich nur testweise gemacht! Sonst wuesste ich ja gar nicht, dass die 172.31.255.45 ueber diesen Mechanismus auf 172.31.255.40 zugreift. Ich kann ja auf dem Modem keinen 'tcpdump' starten. Ich werde mein Testsystem natuerlich sofort wieder auf eine ungefaehrliche IP (z.B. 172.31.255.31) umkonfigurieren.

Bin aber leider erst mal wech..

 

[Andreas1969]

Eigentlich sollte das doch alles recht einfach per SNMP durchzuführen sein:

SnmpMibObject docsDevSwAdminStatus.0 Integer 2; 
SwUpgradeServer 172.22.0.13; 
SwUpgradeFilename "DORGKLDT_SR701230a_JK_84-E.img"; 

Speziell für die Labor FW müsste wohl noch folgendes Objekt mitgegeben werden. da die FW auf einer neuen Architektur aufbaut:

SnmpMibObject enterprises.4413.2.99.1.1.2.2.10.1.0 HexString 0x3140;

 

[robert_s]

Eigentlich sollte das doch alles recht einfach per SNMP durchzuführen sein:

Also SNMP-Befehle + einen TFTP-Server aufsetzen finde ich deutlich weniger "einfach" als mit einem tftp-Client 2 Dateien auf das Modem zu pushen...

 

[Andreas1969]

Also SNMP-Befehle + einen TFTP-Server aufsetzen finde ich deutlich weniger "einfach" als mit einem tftp-Client 2 Dateien auf das Modem zu pushen...

Vielleicht reicht es ja, nur die FW auf's Modem zu pushen.
Jenachdem, wo die dann abgelegt wird.
Sollte die im FW Verzeichnis abgelegt werden, kuckt das Modem da selbst nach und startet den Update Prozess.

If the kernel requests a binary firmware image, /sbin/stbhotplug will
look for it in this directory.
rootfs\lib\firmware\

TFTPHOST=rennslxcomp35
TFTPPATH=tc4400_ref
PLAT=3390b0-dcm
VERSION=3.14.28-rgProd_6.1.2

 

[sparkie]

so, bin zurueck.

Habt ihr eure Kisten nun mit der neuen Firmware am Laufen oder gibt's noch nen Problem?

 

[Andreas1969]

Der TAB scheint sich wohl am 2 März 2016 eingeschlichen zu haben

TCH_FIX_END 02-March-2016 - VLM - TC4400GEN-1093:Update Sysdescr format about HW Layout.Model.BOM

Und das Modem kann auch V6 sprechen

PRIVATE_SOURCE_IP_HUB="172.31.255.20"	PRIVATE_SOURCE_IP_RG="172.31.255.40"	PRIVATE_SOURCE_IP_CM="172.31.255.45"	PRIVATE_SOURCE_IP_STB="172.31.255.70"	PRIVATE_SOURCE_IPV6_HUB="fe80::ffff:172.31.255.20"	PRIVATE_SOURCE_IPV6_RG="fe80::ffff:172.31.255.40"	PRIVATE_SOURCE_IPV6_CM="fe80::ffff:172.31.255.45"	PRIVATE_SOURCE_IPV6_STB="fe80::ffff:172.31.255.70"

 

[Andreas1969]

Habt ihr eure Kisten nun mit der neuen Firmware am Laufen

Nö, noch noch nicht :traurig:
Wir scheinen aber auf einem guten Weg zu sein

 

[sparkie]

was ich aber noch anmerken moechte:

falls der Firmware-Upgrade wirklich auf die simple Tour funktionieren sollte, was machen wir mit dem CMTS?

es sollte natuerlich sichergestellt sein, dass "tobsen" nicht auf seinen Kosten sitzenbleibt.

Ich fuerchte wenn das Verfahren ohne CMTS erst mal bekannt gemacht wird, dann will ploetzlich keiner mehr sich an den Kosten fuer das CMTS beteiligen. Und das faende ich jetzt nicht so toll.

 

[Andreas1969]

falls der Firmware-Upgrade wirklich auf die simple Tour funktionieren sollte,

Noch hat sich niemand getraut :radio:

 

[raichlerockt]

Ich fuerchte wenn das Verfahren ohne CMTS erst mal bekannt gemacht wird, dann will ploetzlich keiner mehr sich an den Kosten fuer das CMTS beteiligen. Und das faende ich jetzt nicht so toll.

also wenn das wirklich ohne funktionierte und ich könnte mir sowohl Modem-lose Zeit, als auch den Hin- und Rückversand sparen,
dann wäre das für mich mehr als Grund genug, mich trotzdem an den Kosten des CMTS zu beteiligen.

man weiß auch nie, wofür so ein Fallback-CMTS in Zukunft noch gut sein könnte...