VTO2000A-C Nachfolger: VTO4202F

@Lithium07
vielen Dank! Bin mir auch sicher, dass die passen wird.

Die Dateistruktur der Firmware ist anders als bei der VTO2000. Kann mir jemand bei der Erstellung der Commands.txt helfen? Die Datei pd-x.squashfs.img fehlt zum Beispiel.

1587799314858.png
 
Wie sieht denn deine Commands.txt aktuell aus? Poste die mal.

@Lithium07 Da deine VTO4202F ja noch "gut" ist, könntest du mal einen Wireshark Trace beim Upgrade über VDPconfig mitlaufen lassen? Das würde uns dann wohl die Reihenfolge der Partitionen beim Upgrade zeigen - evtl. auch die Kommandos.
 
Aktuell sieht sie so aus, wobei ja die pd-x.squashfs.img in der Dateistruktur fehlt.

Code:
run dr
run dk
run du
run dw
run dd
run dc
tftp 0x82000000 pd-x.squashfs.img; flwrite
tftp 0x82000000 .FLASHING_DONE_STOP_TFTP_NOW
sleep 5
 
Im Image gibts in der Install Datei die Commandos:
Code:
"Commands" : [
      "burn dhboot.bin.img bootloader",
      "burn kernel.img kernel",
      "burn partition-x.cramfs.img partition",
      "burn romfs-x.squashfs.img rootfs",
      "burn data-x.squashfs.img data",
      "burn web-x.squashfs.img web"
   ],
Die Commands.txt könnte also so aussehen:

;run db //bootloader - aber den würde ich erstmal ganz weglassen
run dk //kernel
run dp //partition
run dr //romfs
run dd //data
run dc //check
tftp 0x82000000 sign.img; flwrite
sleep 5

Probier mal so. Aber wie gesagt, den Bootloader würde ich erst mal außen vor lassen. Der ist gefährlich in Bezug auf bricken und wird mit großer Wahrscheinlichkeit gar nicht vom Signatur-Check beachtet.
 
Was ist mit:
run dw
für das WebIf ?
 
Sorry - dürfe ich wohl übersehn habn.

;run db //bootloader - aber den würde ich erstmal ganz weglassen
run dk //kernel
run dp //partition
run dr //romfs
run dd //data
run dw //web
tftp 0x82000000 sign.img; flwrite
sleep 5

Das Check.img kann man wohl getrost weglassen - da stehn nur Infos für das Flashtool an sich drinnen.
 
Habe es ausprobiert, bekomme dabei folgende Fehlermeldungen:

Auszug: TFTPServer
Code:
accepting requests..
Open TFTP Server MultiThreaded Version 1.64 Windows Built 2001

starting TFTP...
alias / is mapped to root\
permitted clients: all
server port range: all
max blksize: 65464
default blksize: 512
default timeout: 60
file read allowed: Yes
file create allowed: No
file overwrite allowed: No
thread pool size: 1
Listening On: 192.168.254.254:69
Client 192.168.1.108:2548 root\upgrade_info_7db780a713a4.txt, 1 Blocks Served
Client 192.168.1.108:3900 root\sign.img, 1 Blocks Served
Client 192.168.1.108:3084 root\failed.txt, File not found or No Access

Auszug ncat
Code:
Ncat: Version 7.40 ( https://nmap.org/ncat )
Ncat: Listening on 192.168.254.254:5002
Relocation Offset is: 1f6ef000
Relocating to 9feef000, new gd at 9fa4eef0, sp at 9fa4eed0
LogMagicNum:0 gBootLogPtr:9fa4f008.
NAND:  Check Flash Memory Controller v100 ... Found
SPI Nand ID Table Version 2.7
SPI Nand(cs 0) ID: 0xc8 0xd1 Name:"5F1GQ4UBYIG"
Block:128KB Page:2KB OOB:64B ECC:8bit/512
Chipsize:128 MiB
MMC:
In:    serial
Out:   serial
Err:   serial
Net:   eth0can't find corresponding entry
can't find corresponding entry
partition file version 2
rootfstype squashfs root /dev/mtdblock11
can't find corresponding entry
can't find corresponding entry
partition file version 2
rootfstype squashfs root /dev/mtdblock11
can not search bootargs settings
fail to parse bootargsParametersV2.text info
gSwitchBootPart = 0
SDUPDATE_init
SD_parseBootargs
SD_update:   Hisilicon ETH net controler
find 88e6020 switch !
phy_addr=1, phy_id=3625cc6
 phy BCM54811 init
eth0 : phy status change : LINK=UP : DUPLEX=FULL : SPEED=100M
Using eth0 device
TFTP from server 192.168.254.254; our IP address is 192.168.1.108; sending through gateway 192.168.1.1Filename 'upgrade_info_7db780a713a4.txt'.Default Load Address: 0x82000000,Download to address: 0x82000000
Loading: file size: 186 Bytes   time: 0.307s    speed: 0 Bytes/s
done
Bytes transferred = 186 (ba hex)
cmdListNode->cmd = run dk
cmd:(run dk) is not support!
cmdListNode->cmd = run dp
cmd:(run dp) is not support!
cmdListNode->cmd = run dr
cmd:(run dr) is not support!
cmdListNode->cmd = run dd
cmd:(run dd) is not support!
cmdListNode->cmd = run dw
cmd:(run dw) is not support!
cmdListNode->cmd = tftp 0x82000000 sign.img; flwrite
Hisilicon ETH net controler
find 88e6020 switch !
phy_addr=1, phy_id=3625cc6
eth0 : phy status change : LINK=UP : DUPLEX=FULL : SPEED=100M
Using eth0 device
TFTP from server 192.168.254.254; our IP address is 192.168.1.108; sending through gateway 192.168.1.1Filename 'sign.img'.Default Load Address: 0x82000000,Download to address: 0x82000000
Loading: file size: 128 Bytes   time: 0.003s    speed: 41 KiB/s
done
Bytes transferred = 128 (80 hex)
[ERR0002:]over read addr!
flwrite - flwrite - write data into FLASH memory


Usage:
flwrite DestAddr
    - write data into DestAddr(0xA0000000~0xA4000000)
cmd Failed tftp 0x82000000 sign.img; flwrite!
can't find corresponding entry
can't find corresponding entry
partition file version 2
rootfstype squashfs root /dev/mtdblock11
get bootargs info failed
cmdLine mem=128M console=ttyS0,115200 root=/dev/mtdblock11 rootfstype=squashfs
AUF_sendLog size = 16384
Hisilicon ETH net controler
find 88e6020 switch !
phy_addr=1, phy_id=3625cc6
eth0 : phy status change : LINK=UP : DUPLEX=FULL : SPEED=100M

Die Firmware Files liegen alle wie benötigt im root Verzeichnis des TFTP Servers.
:confused:
 
Das mit dem Wireshark Trace muss ich die Tage mal schauen. Aktuell ist die VTO im neuem Haus, aber ich wohn noch nicht da. Evtl bau ich sie morgen mal aus und nehm sie mit heim
 
Das ist spannend.
Offenbar haben sich die Commandos für den Bootloader mit der neuen HW-Platform (Gen2=hi3516cv500) auch leicht geändert. Das "run" vor den Abkürzungen (dr,dc,..) mag der neue Bootloader nicht (mehr).
Hab mal den Bootloader zerlegt und durchforstet und bin dabei auf folgendes gestoßen:
Code:
bootargs=mem=128M console=ttyS0,115200 root=/dev/mtdblock12
rootfstype=squashfs
bootcmd=kload 0x82000000;
bootm 0x82000000
bootdelay=2
baudrate=115200
ethaddr=00:12:34:56:78:9A
ipaddr=192.168.1.108
serverip=192.168.1.1
gatewayip=192.168.1.1
netmask=255.255.255.
bootfile=uImage arch=arm cpu=armv7 board=hi3516cv500 board_name=hi3516cv500 vendor=hisilicon soc=hi3516cv500
wifiaddr=00:12:34:56:78:91
ID=000000000000000000
da=tftp 0x82000000 dhboot.bin.img; flwrite;tftp dhboot-min.bin.img;flwrite
dr=tftp 0x82000000 romfs-x.squashfs.img; flwrite
dk=tftp 0x82000000 kernel.img; flwrite
du=tftp 0x82000000 user-x.squashfs.img; flwrite
dw=tftp 0x82000000 web-x.squashfs.img; flwrite
ds=tftp 0x82000000 dsp-x.cramfs.img; flwrite
dp=tftp 0x82000000 partition-x.cramfs.img;flwrite
dc=tftp 0x82000000 custom-x.squashfs.img; flwrite
up=tftp 0x82000000 update.img; flwrite
tk=tftp 0x82000000 uImage; bootm
dh_keyboard=1
appauto=1
sysbackup=1
loglevel=4
autosip=192.168.254.254
autolip=192.168.1.108
autogw=192.168.1.1
autonm=255.255.255.0
backupsip=192.168.1.100
nfssip=192.168.1.109
dpd=tftp 0x82000000 pd-x.squashfs.img; flwrite
dfw=tftp 0x82000000 firmware-x.squashfs.img;flwrite
mp_autotest=0
Also schick die Commandos mal ohne das "run" los und poste das Ergebnis:
Code:
dk
dp
dr
dd
dw
Wenn das auch nicht funzt, dann einfach die Kommandos ohne Abkürzungen, also "tftp...;flwrite". Das muss dann auf jeden Fall funktionieren, außer es gefallen dem Loader irgendwelche Steuerzeichen in der Textdatei nicht.

Was mir noch aufgefallen ist: Im uboot steht sogar eine Typenbezeichnung:
Code:
root@sys77:/home/rio/Dahua-Firmware-Mod-Kit# strings u-boot.bin | grep VTO
VTO2202F
VTO2202F
Interessanterweise war das der Loader des VTO4202F Images...
 
Zuletzt bearbeitet:
  • Like
Reaktionen: kuzco-ip
Hi Leute,

so ich melde mich auch mal wieder. Meine Lieferungen haben extrem lange gedauert aber habe jetzt endlich alles da und bereits installiert. Funktioniert auch alles wundervoll wenn man mal dahinter kommt wo man was eintragen muss, die Anleitung von Dahin stimmt nämlich garnicht....

Frage:
habt ihr mal den Kamera Winkel versucht zu ändern? ich hätte die Kamera gerne um 5-10grad mehr nach links geneigt.

Frage 2:

warum versucht ihr die Software zu aktualisieren? Ich habe das nicht ganz begriffen. Welche neuen Features gibt es die ich verpasst habe?
 
Soooo, melde mich mal mit einer positiven Nachricht zurück :)

Die Kommandos ohne "run" hatten auch nicht geklappt.
Also habe ich danach die Commandos.txt wie von dir vorgeschlagen angepasst:

tftp 0x82000000 kernel.img; flwrite
tftp 0x82000000 partition-x.cramfs.img;flwrite
tftp 0x82000000 romfs-x.squashfs.img; flwrite
tftp 0x82000000 data-x.squashfs.img; flwrite (habe ich im zerlegten Bootloader nirgends gesehen?)
tftp 0x82000000 web-x.squashfs.img; flwrite
tftp 0x82000000 sign.img; flwrite
sleep 5

Das hat dann etwas gedauert - der ncat hatte sich mittendrin aufgehangen, deshalb kann ich das Log nicht posten.
Im VDPConfig war die VTO danach wieder sichtbar. Also habe ich dort noch einmal ein Firmwareupdate durchgeführt.
Nun läuft auch alles auf Deutsch, auch die Sprachansagen.

Vielen Dank an euch @riogrande75, @Lithium07 und @kuzco-ip für eure Unterstützung.
Ich werde heute Abend mal eine kurze Anleitung schreiben. Falls das gleiche jemandem anderen passiert :)

Somit kann die von Lithium07 gefundene Firmware auch in die Firmware Link-Sammlung hinzugefügt werden.



@Adun
zu 1: Soweit ich weiß kann man bei der neuen VTO4202 den Kamerawinkel nicht ändern. Das konnte man noch bei der "alten" VTO2000.
zu 2: Ich wollte die Sprachansagen auf Deutsch haben.
 
Ein Kollege hat sich die VTO3211D-P geholt. Die Sprachansage von der VTO auf Deutsch ist echt..... Sehr sehr speziell.......
 
Ich kann auch bestätigen, dass die von mir gefundene Firmware Version auf der VTO4202f funktioniert. Neben der Mehrsprachigkeit kenn ich jetzt aber keine Unterschiede. Gibt's bei Dahua irgendwo Changelogs/Release Notes?
 
Also nochmal zusammengefasst für alle die eine falsche Firmware auf ihre VTO4202 geflasht haben oder aus anderen Gründen eine Firmware über TFTP flashen wollen:

  • VTO4202 Firmware downloaden (wird denke ich auch bald in die Firmware Sammlung von riogrande75 aufgenommen ;-) )
  • Die Anleitung Dahua IPC EASY unbricking / recovery over TFTP durchlesen und an die einzelnen Schritte halten
    • dabei die commands.txt wie folgt anpassen:
      Code:
      tftp 0x82000000 kernel.img; flwrite
      tftp 0x82000000 partition-x.cramfs.img;flwrite
      tftp 0x82000000 romfs-x.squashfs.img; flwrite
      tftp 0x82000000 data-x.squashfs.img; flwrite
      tftp 0x82000000 web-x.squashfs.img; flwrite
      tftp 0x82000000 sign.img; flwrite
      sleep 5
  • Danach sollte die VTO in VDPConfig wieder sichtbar sein. Gegebenenfalls sollte man noch einmal das Firmwareupdate über VDPConfig durchführen.

@Lithium07
Ich sehe auch keine weiteren Unterschiede zur vorherigen Firmware.
 
Hab mein Problem mit der fehlenden RTPMAP nochmal getestet. Anscheinend ist der Fehler mit der neuen Version behoben, zumindest gibt mir Asterisk im Debug Log nun alle notwendigen Codecs an. Vorher hat die Zeile a=rtpmap:101 telephone-event/8000 gefehlt. Damit kann ich nun auch einen ungepatchten Asterisk mit PJSIP verwenden :)

Code:
From: <sip:[email protected]>;tag=432a08849f710772f82545fa5bc1654e
Max-Forwards: 70
To: <sip:[email protected]:5060>
User-Agent: Dahua UAC/3.0 VTO4202F V4.410.0.4
Via: SIP/2.0/UDP 192.168.77.80:5060;rport;branch=z9hG4bK0cd9b7a5dfcce0e8d5e26cfbb52d93dd

v=0
o=- 1587938653 2 IN IP4 192.168.77.80
s=Dahua VT 1.5
c=IN IP4 192.168.77.80
t=0 0
m=audio 20000 RTP/AVP 101 0 97
a=rtpmap:0 PCMU/8000
a=rtpmap:97 PCM/16000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv
m=video 20001 RTP/AVP 96
a=framerate:25.000000
a=rtpmap:96 H264/90000
a=sendrecv
 
Weils mich noch interessiert: Payload Typ "101/telphone-event" ist für die DTMF Töne. Brauchst du eigentlich nur, wenn du von 3rd Pty SIP Device die Tür öffnen willst.
Was hat da bei dir vorher nicht funktioniert bzw. wie sah da die SDP aus?
 
Ich habe (erfolgreich) versucht, meine VTO dazu zu bringen, meine Home Assistant Instanz anzurufen. Da Home Assistant ja eine web basierte GUI hat, hab ich mir eine auf WebRTC basierte SIP Lösung reingebastelt. Das hat soweit funktioniert, Anruf per SIP und Bild per Stream.
Ich musste allerdings beim Asterisk auf die PJSIP Implementierung wechseln, da das alte Chan SIP kein WebRTC Sessions unterstützt.PJSIP hat aber eine sehr strikte RTPMAP Implementierung, die aussteigt, wenn nicht alle Codecs definiert sind. Und hier hat die alte Firmwareversion keinen Eintrag für 101 geliefert, daher hat PJSIP gestreikt. Als Workaround hab ich mir eine Asterisk Version ohne diesen Check kompiliert, damit klappte dann der Anruf.
 
Eine Frage noch, kann ich auf die 4202 auch via nicht dahua tablet zugreifen (via wifi). Ich überlege gerade ob ich auf jeden Stockwerk einen Aufputz Monitor benötige oder ob ich in Wohnzimmer nicht eine mobile Einheit habe. In forum habe ich dazu (dahua wifi) nichts gefunden.
 
Das ist meines Wissens nicht möglich. Du kannst lediglich eine App auf dem eigenen Tablet installieren und Dich dann via Push informieren lassen.
 
Was leider seit dem Update auf die neue Firmware nicht mehr funktioniert :)
 

Zurzeit aktive Besucher

Keine Mitglieder online.

Statistik des Forums

Themen
244,840
Beiträge
2,219,267
Mitglieder
371,543
Neuestes Mitglied
Brainbanger
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.