Unitymedia Technicolor TC4400 FW Update Wie?

[Leseratte10]

Das TC baut die Verbindung zum TFTP-Server wohl zwingend immer über das Kabel-Interface, nicht über LAN auf.

 

[Andreas1969]

Das TC baut die Verbindung zum TFTP-Server wohl zwingend immer über das Kabel-Interface, nicht über LAN auf.

Jo, so ist es.

 

[Andreas1969]

Unter den Tech Specs steht TFTP..?

Edit: Vielleicht hab ich mich falsch ausgedrückt, ist auch etwas her dass ich damit hantiert habe.. wahrscheinlich läuft kein TFTP Server, warum auch, er soll ja nur die Datei per TFTP bekommen. Ergo sollte, so wie es auch im technischem Datenblatt steht, ein Client vorhanden sein. Man muss also "nur" raus finden, wie man diesen dazu kriegt die Update Datei zu erhalten und zu verarbeiten..

Ich hab in der Firmware diesbezüglich noch etwas gefunden

# The following are bootp specific options
# next server to use in bootstrap
#siaddr 192.168.0.22 # default: 0.0.0.0 (none)
# tftp server name
#sname zorak # default: none
# tftp file to download (e.g. kernel image)
#boot_file /var/nfs_root # default: none

 

[#DiRK]

Unter den Tech Specs steht TFTP..?

Edit: Vielleicht hab ich mich falsch ausgedrückt, ist auch etwas her dass ich damit hantiert habe.. wahrscheinlich läuft kein TFTP Server, warum auch, er soll ja nur die Datei per TFTP bekommen. Ergo sollte, so wie es auch im technischem Datenblatt steht, ein Client vorhanden sein. Man muss also "nur" raus finden, wie man diesen dazu kriegt die Update Datei zu erhalten und zu verarbeiten..

Ich hab in der Firmware diesbezüglich noch etwas gefunden

# The following are bootp specific options
# next server to use in bootstrap
#siaddr 192.168.0.22 # default: 0.0.0.0 (none)
# tftp server name
#sname zorak # default: none
# tftp file to download (e.g. kernel image)
#boot_file /var/nfs_root # default: none

Zitierst du bitte auch die Fundstelle und den Kontext. Alleine bringt das herzlich wenig, bzw. die FW ist voll mit "Andeutungen". ;-)

 

[Andreas1969]

Zitierst du bitte auch die Fundstelle und den Kontext. Alleine bringt das herzlich wenig, bzw. die FW ist voll mit "Andeutungen". ;-)

Eventuell lässt sich per BootP ja während des Bootvorgangs des Modems das FW Image per TFTP übertragen. :kratz:

 

[der-tim]

Magst du vielleicht trotzdem noch mal den Link für das Firmware Update posten..? Wäre sehr nett, danke

 

[Wechseler]

Das TC baut die Verbindung zum TFTP-Server wohl zwingend immer über das Kabel-Interface, nicht über LAN auf.

Dazu ist erforderlich, daß DOCSIS läuft. Bei einem TFTP-Boot ist das nicht der Fall, da läuft nur der Bootloader. Auch bei einem DSL-Modemrouter kann der Provider die Firmware per TR-069ff. anliefern, aber nur wenn schon bereits eine läuft. Bei einem reinen Bootstrap hast du schlicht noch keinen Sync.

 

[Andreas1969]

Bei einem TFTP-Boot ist das nicht der Fall, da läuft nur der Bootloader.

Genau :super:

Bei einem reinen Bootstrap hast du schlicht noch keinen Sync.

Und genau da ist der Ansatz, das müsste beim TC4400 gehen.

 

[Andreas1969]

Folgende Angaben könnten auch noch interessant sein:

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

 

[der-tim]

Hat schon mal jemand sich im Webinterface die ftplite.html angeschaut? Damit scheint ein put möglich zu sein

 

[y0r]

Hat schon mal jemand sich im Webinterface die ftplite.html angeschaut? Damit scheint ein put möglich zu sein

Ja, habe ich schon versucht. Da kommt am Server nix an. Habe tcpdump am ETH mitlauschen lassen. Da kommt nicht mal ein SYN.

 

[rv112]

Hier sieht man ja sämtliche IP's die das Modem hat, bzw. auf die es zugreift: http://192.168.100.1/arpview.cmd
Was wenn man die IP und MAC des TFTP faked im Netzwerk? Was ist das Interface "privbr"?

Ich habe bei DSL Reports zu einem anderen D3.1 Modem folgendes gefunden:

"During bootup it also attempts to contact 172.31.255.40 and initiate some sort of reverse-TFTP transfer; if there's no answer it boots right up, but if something answers the boot then hangs for a bit. During this time it responds to SNMP from the LAN side."

Quelle: http://www.dslreports.com/forum/r31219835-SB8200-32x8-DOCSIS-3-1-cable-modem-Feedback-and-Results-thread~start=660

Der Abschnitt ist auch äußerst interessant: http://www.dslreports.com/forum/r31219835-SB8200-32x8-DOCSIS-3-1-cable-modem-Feedback-and-Results-thread~start=690
Die IP 172.31.255.45 taucht auch in meinem TC4400 auf.

 

[der-tim]

Schade..

Ich finde die Dateien ohne weitere Dokumentation leider auch schwer nachzuvollziehen. Ich frage mich welches initscript nun eigentlich läuft, ich tippe ja mal auf rcS und (siehe Z.71) somit auch alle rcS.*.. Was aber von den ganzen ifs tatsächlich ausgeführt wird und auch was genau jeder einzelne Command bewirkt.. sehr Interessant finde ich die rcS.util..

SSHD scheint ja nicht zu laufen.. es wird zwar ein Derivat irgendwo erwähnt aber die Binary scheints ja nirgends zu geben. telnetd existiert, lässt das Teil darüber mit sich reden? Sonst ist das aus der Ferne echt schwer zu beurteilen... :kratz:

@rv112: die IPs scheinen ebenfalls in rcS.util konfiguriert zu sein!

 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"

Edit: den Ansatz würde ich ebenfalls mal verfolgen, TFTP Server auf der Adresse aufsetzen und dann an den ersten Port verbinden und booten..!

 

[Andreas1969]

Edit: den Ansatz würde ich ebenfalls mal verfolgen, TFTP Server auf der Adresse aufsetzen und dann an den ersten Port verbinden und booten..!

Hat das schon jemand probiert :kratz:
Also TFTP Server an der Adresse 172.31.255.40 aufsetzen und schauen, ob das Modem versucht, sich während des Bootvorgangs anzumelden (kann man ja dann im Log des TFTP Servers sehen)
Wenn das der Fall wäre, könnten wir das Modem dann darüber ganz normal provisionieren incl. FW Download :super:
Also genau so, wie es vom ISP auch angestossen wird mit einem selbst erstellten Docsis Configfile

 

[MartinP_Do]

 PRIVATE_SOURCE_IP_HUB="172.31.255.20"
..	PRIVATE_SOURCE_IPV6_HUB="fe80::ffff:172.31.255.20"
..

Die Punkte in der IPv6 Adresse kamen mir spanisch vor, aber laut Wikipedia erlaubt ...

https://de.wikipedia.org/wiki/IPv6

Ebenfalls darf für die letzten vier Bytes (also 32 Bits) der Adresse die herkömmliche dezimale Notation verwendet werden. So ist ::ffff:127.0.0.1 eine alternative Schreibweise für ::ffff:7f00:1. Diese Schreibweise wird vor allem bei Einbettung des IPv4-Adressraums in den IPv6-Adressraum verwendet.

Wieder was gelernt ...

 

[der-tim]

Also TFTP Server an der Adresse 172.31.255.40 aufsetzen und schauen, ob das Modem versucht, sich während des Bootvorgangs anzumelden (kann man ja dann im Log des TFTP Servers sehen)

ip addr add dev privbr $PRIVATE_SOURCE_IP_RG/24

Z. 133, 139 u. 144: diese IP wird dem Modem zugewiesen... (Edit: in der rcS.net)

Bleiben also

 PRIVATE_SOURCE_IP_HUB="172.31.255.20"	PRIVATE_SOURCE_IP_CM="172.31.255.45"	PRIVATE_SOURCE_IP_STB="172.31.255.70"

Die Datei rcS.ba könnte hilfreich sein... ich tippe somit auf die 172.31.255.45 :kafffee: :winken:

Die binary rprogramstore die in der rcS.ba aufgerufen wird scheint unser Mittel zum Zweck zu sein. Ein Auszug was die binary ausspucken kann:

 *** Vendor Extension *** - EstbSwUpgrade_InProgress - NOT IMPLEMENTED - Returning default value: true! *** Vendor Extension *** - EstbSwUpgrade_IsUpgradePermittedNow - NOT IMPLEMENTED - Returning default value: true! *** Vendor Extension *** - EstbSwUpgrade_IsMonolithicImageHeaderValid - NOT IMPLEMENTED - Returning default value: true! *** Vendor Extension *** - EstbSwUpgrade_IsMonolithicImageValid - NOT IMPLEMENTED - Returning default value: true! Monolith download success eCM download success Downloaded failure reported, no update will take place Unrecognized download notification update_command_dispatch Monolith header lacks proper magic number 0x%x read compared to 0x%x desired rProgramStore Host rProgramStore Host: ethInterfaceUp error: rProgramStore Host (1): Waiting for eth interface '%s' to come up. %d seconds elapsed rProgramStore Host (2): Timeout expired and eth interface still unavailable...exiting %s -c IMG_START -p %s -s %d /bin/progstore %s -c IMG_END -p %s -s %d %s -c MLTH_START %s -c MLTH_END %s -c CONFIRM_COMPLETE %s unsupported command: %d -z Unsupported command: %d, exiting... Invalid Monolith header Error running update script Program Store Header CRC failure Unexpected end of image /tmp/update Pipe open failed, exiting write to pipe 0x%x failed: %s Error - Image CRC could not be validated! Computed CRC = %8x does not match CRC value in the program header = %8x Usage: rprogramstore -i <interface>
optional: -s <myipaddress>
optional: -d <destipaddress> i:s:d:f:h rProgramStore Host (6): error: Eth interface never came up...exiting rProgramStore Host (7): error: could not configure eth interace %s rProgramStore Host (8): Couldn't bind command socket ip %s port %d! rProgramStore Host (9): Couldn't bind response socket ip %s port 0! Failed to allocate memory for socket receive buffer setsockopt SO_RCVBUF error: %s Bailing... rProgramStore Host (10): Could not configure ethernet interface %s rProgramStore Host (11): Socket Receive Error error Failed to allocate memory for pPreStorageBuffer rProgramStore Host (13): WRITE operation return size did not match specified size specified size: %d command returned: %d send eCM response to indicate write error rProgramStore Host (14): Could not send message via response socket rProgramStore Host (15): Could not send message via response socket Sw upgrade available. Sw upgrade permitted. crcfailure: %u flashfailure: %u rProgramStore Host (16): Could not send message via response socket DLOAD_SUCCESSFUL: Notifying progstore, progstore will reboot when flash update is complete **DEBUG**> MONOLITHIC IMG DLOAD FAILED rProgramStore Host (17): Did not understand command! rProgramStore Host (12): Could not send message via response socket file open failed, exiting bytesDone: %d sent: %d Error running update script - PROGSTORE_COMMAND_CONFIRM_COMPLETE,

Und noch ein edit.. verzeiht es mir, aber nur fürs Protokoll: der sshd der erwähnt wird heißt dropbear (rcS.stb ab Z31), aber die binary wie auch die Config fehlt. Ich denke hier handelt es sich um überbleibsel die uns nicht weiterhelfen können..

 

[Andreas1969]

ich tippe somit auf die 172.31.255.45

Kann das eventuell schon mal jemand testen, also TFTP Server auf diese Adresse aufsetzen :smile:

 

[Andreas1969]

Ich hab jetzt mal einen TFTP Server auf der Adresse 172.31.255.45 aufgesetzt, da gibt es schon mal einen Adressen Konflikt.
Die 172.31.255.45 scheint also schon vom Modem benutzt zu werden.

Jetzt hab ich die Adresse mal auf 172.31.255.40 geändert, da gibt´s schon mal keinen Adressen Konflikt. :super:
Ich hab momentan nur keine Möglichkeit das Modem neu zu booten, dann gibt es hier Unfrieden.

 

[rv112]

Also wenn das Modem frisch gebootet wurde, lauscht es definitiv über diese Adresse am WAN Interface, nicht am HF.

 

[Andreas1969]

Als nächstes habe ich jetzt mal mit dem Excentis DOCSIS Config File Editor eine Docsis Config File für das TC4400 mit sämtlichen benötigten Angaben erstellt
und als binary Boot File "tc4400Boot.cfg" gespeichert.
Das Erzeugte Boot File "tc4400Boot.cfg" und die FW Datei "DORGKLDT_SR701230a_JK_84-E.img" hab ich beide in´s Root Verzeichnis des TFTP Servers "172.31.255.40" gelegt.
Wenn alles glatt läuft, sollte das Modem sich beim nächsten Boot Vorgang das Boot File automatisch laden (Provisionierung) und anschließend den FW Download während
des angestossenen Provisionierungs-Prozesses vom TFTP Server herunterladen, es sind ja alle nötigen Angaben im Config File inklusive der CVC´s für die signierte FW hinterlegt.

Hier mal der Inhalt des erzeugten Docsis Config Files

Network Access Controln
SNMP MIB Object(docsDevSwAdminStatus.0):1.3.6.1.2.1.69.1.3.3.0, Integer, 2
Software Upgrade TFTP server:172.31.255.40
Software Upgrade FilenameORGKLDT_SR701230a_JK_84-E.img
Privacy Enablen
Network Access Controln
Maximum Number of CPEs:5
Downstream Service Flow Encodings
Service Flow Reference:1
Quality of Service Parameter Setrovisioned admitted active
Traffic Priority:3
Downstream Maximum Sustained Traffic Rate:0
Maximum Traffic Burst:15220
Upstream Service Flow Encodings
Service Flow Reference:2
Quality of Service Parameter Setrovisioned admitted active
Traffic Priority:7
Upstream Maximum Sustained Traffic Rate:0
Maximum Traffic Burst:24044
Maximum Concatenated Burst:24044
Service Flow Scheduling Type:Best Effort
SNMP MIB Object(docsDevNmAccessIp.1):1.3.6.1.2.1.69.1.2.1.2.1, IP Address, 0.0.0.0
SNMP MIB Object(docsDevNmAccessIpMask.1):1.3.6.1.2.1.69.1.2.1.3.1, IP Address, 0.0.0.0
SNMP MIB Object(docsDevNmAccessCommunity.1):1.3.6.1.2.1.69.1.2.1.4.1, Octet String, public
SNMP MIB Object(docsDevNmAccessControl.1):1.3.6.1.2.1.69.1.2.1.5.1, Integer, 3
SNMP MIB Object(docsDevNmAccessInterfaces.1):1.3.6.1.2.1.69.1.2.1.6.1, Octet String, 0xC0
SNMP MIB Object(docsDevNmAccessStatus.1):1.3.6.1.2.1.69.1.2.1.7.1, Integer, 4
Manufacturer Code Verification Certificate:308203743082025CA0030201020210472FB3E9F5043E6B8C41DFE40D83BDEE300D06092A864886F70D0101050500306F310B3009060355040613024245311F301D060355040A131674436F6D4C616273202D204575726F2D444F4353495331153013060355040B130C4361626C65204D6F64656D73312830260603550403131F4575726F2D444F43534953204361626C65204D6F64656D20526F6F74204341301E170D3132303432363030303030305A170D3232303432353233353935395A3061310B300906035504061302555331143012060355040A130B546563686E69636F6C6F7231143012060355040B130B4575726F2D444F4353495331263024
Manufacturer Code Verification Certificate:0603550403131D436F646520566572696669636174696F6E20436572746966696361746530820122300D06092A864886F70D01010105000382010F003082010A0282010100FC7D31F87CD647F235D15FA68DAB8F4950676067D4450BB7D55808771FCADF3B5ECFD9B04B70F7E42720B8F93A7A00FB75EBB9FAB197DEA423306C6042083C58CC2DF934387E75D08011E4FBF43F4D7B7F80AC9163A9F7CF1D19EE322B604624C6CE287E40D181ED44B490CE63C7C6DE7E03C6C326B93EE83436F769F04E1AEBA973B1357B5BAA399E897E034A7B6BBFB0D93ABF3DB20ADF7BE1A4B69FACCCEAA7519EB24A22A4E0D7E46F4A46D9E883FCA2B0F380FDEFD399
Manufacturer Code Verification Certificate:F79D6C8D5E546FE25C085F10E5963C506B397CDEA0F5BF891E8B019C01BE9C9946B4176AD08994415DB044301C7335C489B4FF503BDD3F9FB7BA1CA8FFEC38C2902B21C3C24FC70203010001A31A301830160603551D250101FF040C300A06082B06010505070303300D06092A864886F70D0101050500038201010094087D982413F4A4EA6C07C995A3334D3D037D09A10AC95E35E781D6742FE2F9649DA024F960FA5E93A5044A7614F453E7CB38741D589C98570F1AD6F460F5F38A1D3CABE6737A48038F5DA4A06AD09B8D5C092B6EFCFBC78A21731808D422F45588BD93AFBA49F68586E773AFC04E49B734CCB449BCB20F57EA64004856C94AD43C
Manufacturer Code Verification Certificate:9A06BC68559C29BA511BB564984F7B377D062910118E8C1DBECC145CCF865360F4170A0D4036FD2E6FA32DD268353ED3433C904E43A065127A8B0D5867E9A05E0658A9E03095BD96E24CCC6707CCF10E7D0B7EF284B28A4D7115F6D6E28604E5DC88BF56D984506B11DDF441643426B12E65EEBF862C3259EE5FB782CCA6

 

[perryair]

Bin gespannt

 

[Andreas1969]

Bin gespannt

Ich auch.
Mist, jetzt hab ich aus Versehen auf den gelöst Button geklickt.
Kann man anscheinend nicht rückgängig machen. :traurig:

 

[perryair]

Der reboot Button währe aber der richtige gewesen

 

[rv112]

Viel Glück Andreas und saubere Arbeit!

 

[Andreas1969]

So, gerade war der Zeitpunkt günstig für einen Reboot.
Leider hat es noch nicht so ganz geklappt.

Im Log des TFTP Servers taucht folgendes auf:

Connection received from 172.31.255.45 on port 49153 [01/01 11:50:59.042]
Unexpected request 4 from peer [01/01 11:50:59.052]
Returning EBADOP to Peer [01/01 11:50:59.052]
Warning : received duplicated request from : [01/01 11:50:59.052]
Connection received from 172.31.255.45 on port 49153 [01/01 11:50:59.302]
Warning : received duplicated request from : [01/01 11:50:59.302]
Unexpected request 4 from peer [01/01 11:50:59.312]
Returning EBADOP to Peer [01/01 11:50:59.312]
Connection received from 172.31.255.45 on port 49153 [01/01 11:50:59.552]
Warning : received duplicated request from : [01/01 11:50:59.552]
Unexpected request 4 from peer [01/01 11:50:59.562]
Returning EBADOP to Peer [01/01 11:50:59.572]
Connection received from 172.31.255.45 on port 49153 [01/01 11:50:59.803]
Unexpected request 4 from peer [01/01 11:50:59.803]
Returning EBADOP to Peer [01/01 11:50:59.803]

Wie man sieht, hat das Modem selbst die 172.31.255.45 und versucht über Port 49153 mit dem TFTP Server (172.31.255.40) zu kommunizieren.
Hat noch jemand ne Idee :kratz: