Unitymedia Technicolor TC4400 FW Update Wie?

[MartinP_Do]

Etwas google zu den Meldungen

Da kommt anscheinend ein ACK, welches als Request interpretiert wird

https://stackoverflow.com/questions/11698761/tftp-c-not-receiving-ack


Dieser hier noch:
http://reboot.pro/topic/6822-pxe-booting-error-from-server/

 

[Andreas1969]

Mal schauen, zumindest scheint das schon mal die Hintertür zu sein. :zwinker:

 

[Andreas1969]

Nächste Schritte:

1. Analyse per Wireshark, was da genau passiert
2. Lässt sich das Modem auf der 172.31.255.45 auch per Telnet / SSH ansprechen
3. Funktioniert SNMP auch über die 172.31.255.45
4. Lässt sich das TC4400 mit dem Thomson Router/Modem Upgrade Tool über die 172.31.255.45 flashen?


Ich denke, da wird noch was gehen....
Ohne Testgerät wird es schwierig, da ein Zeitfenster für weitere Versuche zu finden.

 

[rv112]

Wenn es blöd läuft, verweigert das Modem den Flash via RJ45 natürlich. Wissen die Hobbyjungs vielleicht mehr diesbezüglich?

 

[Andreas1969]

Wenn es blöd läuft, verweigert das Modem den Flash via RJ45 natürlich.

Das hoffe ich jetzt mal nicht, zumal ja auch irgendwelche Anfragen zum TFTP Server laufen.

 

[Andreas1969]

Hier mal ein Ausschnitt aus Wireshark

 

[Andreas1969]

Sieht so aus, als wenn das Modem nicht nur auf die 172.31.255.40 zugreifen wollte, sondern auch auf die 172.31.255.20 :kratz:

 

[rv112]

Das könnte auch ein DHCP Server sein den es sucht.

 

[Andreas1969]

Das könnte auch ein DHCP Server sein den es sucht.

Das wäre sogar denkbar, dass das Modem hier nach einem DHCP Server für die Firmwarebetankung sucht.
Ich könnte mir sogar vorstellen, dass die Erstbetankung im Werk auch so durchgeführt wird. :kratz:

 

[der-tim]

Könnten die Angaben in der brcmstb.conf vielleicht helfen?

TFTPHOST=rennslxcomp35
TFTPPATH=tc4400_ref

brcmstb.conf kommt wohl von stblinux

Die Syntax wird ab Z.53 beschrieben:

# hostname of TFTP server (defaults to the build machine)
TFTPHOST	:= $(shell hostname)
# root directory of TFTP server
TFTPBOOT	:= /tftpboot
# full (local) TFTP path, where "make install" will copy the images.
# Typical usage: user overrides TFTPDIR on the command line, and
# this Makefile will derive the correct TFTPPATH from TFTPDIR/TFTPBOOT
TFTPDIR	:= $(TFTPBOOT)/$$USER
# relative (remote) TFTP path under $(TFTPBOOT), for use by the TFTP client
TFTPPATH	:= $(subst $(TFTPBOOT)/,,$(TFTPDIR))

 

[Andreas1969]

Könnten die Angaben in der brcmstb.conf vielleicht helfen?

Könnte passen, darüber bin ich ja auch schon gestolpert.
Die Frage ist, wie man das jetzt genau einrichtet / realisiert :kratz:

 

[der-tim]

Also, ganz stumpf würde ich jetzt mal versuchen meinem TFTP Server den hostname rennslxcomp35 zu geben und dann das Update img in den Ordner tc4400_ref packen, der Ordner sollte im ROOT des tftp Servers und dann mal sehen... bin mir aber auch unsicher ob das Erfolg haben kann oder schon zu blöd ist.

 

[Andreas1969]

bin mir aber auch unsicher ob das Erfolg haben kann oder schon zu blöd ist.

Das wäre ja fast schon zu blöd :smile:

 

[der-tim]

Nach den Regeln der Quantenphysik..... D: quatsch bei Seite, ich würd es halt mal probieren. /bin/stbutil existiert, somit bekommt die config Gewicht und der Sourcecode steht ja auf github.. ganz so abwägig ist das vielleicht nicht...

 

[der-tim]

Ich sehe gerade das stbutil sogar nur ein Shellscript ist
Schau dir das mal an, Z.273-274:

 if tftp_fetch $tftphost $tftppath/$rem_img /tmp/rootfs.img; then	ubiformat $mtd --yes --flash-image=/tmp/rootfs.img

Z.752-774

stbutil v5.00 - Settop configuration utility
Copyright (C) 2009 Broadcom Corporation
Usage: stbutil [ -d <local_dir> ] [ -a <selection> ] [ <tftphost>[:<dir>] ]
Options:	-b	Configure for hypervisor image installation (on 7145/3385/3390 platforms) (can be combined with all other options)	-d <local_dir>	Fetch images from LOCAL_DIR instead of tftp'ing	them over the network	-a <selection>	Use SELECTION as the menu item selection,	instead of prompting the user	-H <disk>	Use hard drive DISK (default sda)	<tftphost>	TFTP server hostname	<dir>	Directory (relative path) on TFTP server
Examples:	stbutil	stbutil linuxsrv:2631-1.0	stbutil -d /mnt/usb	stbutil -a1	stbutil -a 1	stbutil -d /mnt/usb -a 1	stbutil -H sdb

Z.816 bindet auch die conf File ein. Ich find das wird immer heißer

 

[Andreas1969]

Das ist ja fast schon zu einfach, mal sehen.

 

[der-tim]

Na eben nur fast Bin gespannt was du berichten kannst!

 

[Andreas1969]

Könnten die Angaben in der brcmstb.conf vielleicht helfen?

TFTPHOST=rennslxcomp35
TFTPPATH=tc4400_ref

Ganz so einfach ist es wohl nicht.
Zumindest hat sich nichts geändert.
Eventuell muss man den Standard Port des TFTP Servers noch anpassen :kratz:

 

[der-tim]

 Line 71: tftp	69/tcp	Line 72: tftp	69/udp	Line 328: tftp-mcast	1758/tcp	Line 329: tftp-mcast	1758/udp

aus der /etc/services.. scheint mir der Standard zu sein..

 

[Andreas1969]

Jo, ist alles auf Standard.
Jetzt ist guter Rat teuer, wie könnte man das jetzt noch bewerkstelligen :kratz:

 

[der-tim]

Da weiß ich so auf Anhieb auch nichts mehr.. :^

Um sicher zu gehen: die Ordnerhierarchie in der das .img liegt ist genau wie von dem Script gefordert und für den tftp daemon auch lesbar? Alle IP's ausprobiert? Direkte Verbindung ohne was dazwischen? Auf den Kopf gestellt und drei mal laut simsalabim gesagt beim boot? :kratz: Du hattest auch keine serielle Konsole angeschlossen oder?

 

[Andreas1969]

Alle IP's ausprobiert?

Meinst Du statt der .40 mal die .20 probieren :kratz:

 

[der-tim]

Was kann schon schief gehen?

Edit: es könnte auch am Dateinamen liegen. Vielleicht sucht er nach einem bestimmten, findet den nicht, und bricht deswegen ab.. in der stbutil sind die alle mit irgendwelchen variablen gefüllt...

rem_img=ubifs-$(($flash_erasesize / 1024))k-$(($flash_writesize))-${plat}-RG.img

Edit2: probier mal den Dateinamen ubifs-3390b0-dcm-RG.img

 

[#DiRK]

Hier mal ein Ausschnitt aus Wireshark
WS.JPG

Andreas,

kannst du auch mal bitte die Details der einzelnen Zeilen posten? Was steht denn bspw. bei den Details zu "Illegal TFTP Operation"?

Am besten legst mal das PCAP File zum D/L?!?!

 

[#DiRK]

Was kann schon schief gehen?

Edit: es könnte auch am Dateinamen liegen. Vielleicht sucht er nach einem bestimmten, findet den nicht, und bricht deswegen ab.. in der stbutil sind die alle mit irgendwelchen variablen gefüllt...

rem_img=ubifs-$(($flash_erasesize / 1024))k-$(($flash_writesize))-${plat}-RG.img

Edit2: probier mal den Dateinamen ubifs-3390b0-dcm-RG.img

Eine Anmkerkung dazu: das "stbutil" Skript dient auch unter anderem zum Schreiben einer erhaltenen Datei auf das Flash (Dateisystem: ubifs). Falls dabei die Datei nicht die richtige ist, dann schreibt er Müll auf das Root-FS im Flash und dann haste das Modem direkt "gebrickt".

"Unsere" erhaltenen Firmware enthält lt. binwalk nämlich mehrere Bestandteile:
- ubifs (in dem wir die meisten Hinweise gefunden haben)
- vermutlich: ein Kernel-Image
- vermutlich: Device-Tree Dateien
- Sonstige BLOBs, welche binwalk nicht eindeutig identifizieren kann, und welche m.E. ein Hypervisor und sonstige Laufzeit-Komponenten sind (d.h. wir haben es hier mit einer virtualisierten Maschine zu tun)

Die müssten m.E. alle in ihre richtigen Bereiche geschrieben werden, sonst tut das nicht.

Darüber hinaus, siehst du in den rc.S, rc.util und allen anderen rc Skripts immer Verweise auf das sog. Subsystem. (oben bspw. die Variable "$plat"). Die Firmware ist vermutlich für unterschiedliche Geräte von Technicolor geeigent und erst bei Runtime wird (in der rc.util) evaluiert, welche Plattform / Subsystem vorhanden ist und dann entsprechend in den weiteren Skripten darauf rerenziert. Also auch die stbutil zeigt auch verschiedene Varianten, abhängig von der Plattform / Subsystem.

Leider habe ich (mangels Zeit) derzeit auch keine besseren Ideen. Will nicht Bedenkenträger sein - aber auch vor voreiligen Aktionen warnen.