Failed to flash Auvisio URC-150.app IR Blaster

[tarrychk]

Hi,

I tried flashing an "auvisio URC-150.app" IR blaster. Model is NX-4519-675.
I can get the device to connect, but the flash process ultimately exits with a timeout message.
Any hints what I can try short of using serial usb to flash the device?

smarthack-mqtt.log
smarthack-psk.log
smarthack-udp.log
smarthack-web.log
smarthack-wifi.log

[morlob]

I have the same issue.

In the smarthack-web.log you don't see IP 10.42.42.42 ... there are only 10.42.42.31 and 10.42.42.36.

In start_flash.sh there is a comment (lines 72 -77):

	# !!! IMPORTANT !!!
	# Did your device get an IP address other than 10.42.42.42?
	# That is because it is not running the intermediate firmware
	# The intermediate firmware will request 10.42.42.42
	# Do NOT change this address!!!
	# It will NOT make it install and will break this script
        while ! ping -c 1 -W 1 -n 10.42.42.42 &> /dev/null; do
		printf .
		if (( --i == 0 )); then
			echo
			echo "Timed out while waiting for the device to (re)connect"
			pkill -f smartconfig/main.py && echo "Stopping smart config"
			echo "======================================================"
			echo "Attempting to diagnose the issue..."
			./dr_tuya.sh
			echo "======================================================"
			read -p "Do you want to try flashing another device? [y/N] " -n 1 -r
			echo
			[[ "$REPLY" =~ ^[Yy]$ ]] || break 2
			continue 2
		fi
	done

So, your device has not IP 10.42.42.42 that causes the time out (see while statement behind the comment).

So the question is: Why our devices do not have the IP 10.42.42.42? The comment says it is "intermediate firmware" related. Is there a way to fix that, or workaround?

[phoehnel]

Thanks a lot! That workaround did it for me (my ednet 84334 was on 10.42.42.10)

[a-w]

I have the same issue with this device, and my analysis so far is that the device dies after receiving a few chunks of /files/upgrade.bin. My log files look pretty the same as @tarrychk's, but attaching them anyway:

smarthack-mqtt.log
smarthack-psk.log
smarthack-udp.log
smarthack-web.log
smarthack-wifi.log

At some point we can see in smarthack-web.log:

[I 230123 19:45:31 web:2271] 206 GET /files/upgrade.bin (10.42.42.30) 1.46ms
[I 230123 19:45:38 web:2271] 206 GET /files/upgrade.bin (10.42.42.30) 6880.70ms

Now nothings happens (except that we see the dots displayed on the console), and 30s later, we see the next

[I 230123 19:46:02 web:2271] 200 POST /gw.json?a=tuya.device.upgrade.silent.get&... (10.42.42.30) 6.95ms

followed by

[I 230123 19:46:04 web:2271] 206 GET /files/upgrade.bin (10.42.42.30) 1.29ms

I one does not stop the script, this continues forever, every 30s: POST /gw.json, GET /files/upgrade.bin and so on.

So, I took a WireShark trace.
tuya_convert.pcapng.gz

One can see the first request to /files/upgrade.bin in packet # 1665 with response in packet # 1667: This is a partial download of the first 64 bytes of the files, matching the first entry above from smarthack-web.log. Now in packet # 1673, we see the next request for /files/upgrade.bin, this time with a range request for bytes 253815-505866. Then we see the server serving that request, but after a few packets, we see only TCP retransmissions (packets 1680 to 1714). In the meantime, we see the device starting a new DHCP discovery cycle (packets # 1687 and following).

So, my conclusion is that the device has rebooted while receiving the content of /files/upgrade.bin.

Question: What can we do to fix this?

Update: Device info (printed on the case): REV1_2018_01_11_MF-EB. That looks like a date. So, may be not so super-new (but could have updated firmware, of course).

[Marcel2508]

I had the problem aswell and solved it by using an older RaspberryPI-OS version as mentioned here #1072 and here #999 (comment)

This one worked for me: https://downloads.raspberrypi.org/raspios_lite_armhf/images/raspios_lite_armhf-2021-05-28/

[a-w]

Incredible, but that worked! @Marcel2508 Thank you so much!

I have also tried a newer raspios (bullseye) on the same hardware and it didn't work. It was indeed necessary to go back to buster using the link you have provided. From that link, I have used 2021-05-07-raspios-buster-armhf-lite.zip and applied no updates (needed to say apt-get update though to be able to install git at all). So, it wasn't the hardware, it wasnt't the device having an anti-foreign-flash upgrade, it was the environment which seems not to work in later Debian versions! (the Debian VM on which I have made the first attempts was bullseye too).

Summary: NX-4519-675 devices being currently sold (as of Jan-2023) are still convertable, but one has to use Debian buster.

[tarrychk]

I can also confirm that the flashing worked flawlessly once I did it from a Debian Buster Live Image.

[JanMarcusEskes]

Small update: it seems, that thy updated the software (and possible the hardware too)
Now i get a "could not establish sslpsk socket: [SSL: DECRYPTION_FAILED_OR_BAD_RECORD_MAC] decryption failed or bad record mac"-error which indicates a patched firmware on my URC-150.app

The model reads "REV2_2022_11_03_SK-CM" besides the rated voltage on the underside. It also seems not to be an ESP based controller anymore, but i have to check

[Marcel2508]

The last one I ordered was shipped with a BK7231N instead of an ESP Chip.
However you can still flash a custom firmware with https://github.com/openshwprojects/OpenBK7231T_App
This however requires you to open the device and solder your USB TTL Converter to it...