KuWfi 830D - Which "target"?

There is usually a serial port header on the circuit board itself, inside the device. Possibly pins or solder points.

But no external serial port like in the old days....

Using that serial port on the circuit board for monitoring the early boot process log output is practically the only way to debug the boot loader process which initialises the actual operating system.

1 Like

And in the unprobable event that I find this serial port on the device, to what I will connect it to ? No laptop with serial device in this world.

Anyway, I tried to upload my OpenWrt built (Yuncore 830 target). The web inerface of the existing firmware seems requiring a UBIN file, and refuses to upload my Squash file (.bin) . Any clue ?

Your thinking of RS232, you won't be needing that.

You will be needing a USB to Serial Adaptor (UART) and some soldering and wires. The serial adaptor usually needs to support 3.3V or you will damage your router.


Something like this

You only need to conect TX , RX and GND and select 3.3V

The easier way would be to be able to create a UBIN file (including the uBoot as far as I understand) to update teh device, no ?
My buillt of OpenWrt is without uboot, how to enable it ?

I asked the supplier a firmware upgrade, that I applied.

WHen accessing /cgi-bin/luci, I get to an old Luci page (attached). So it means OpenWrt already on.

The supplier refuses to give root password. How to crack it ?Screenshot%20from%202019-01-31%2023-20-56

Unix passwords arguably "can't" be cracked. Unlikely that the seller will comply with GPL requirements either.

If the vendor didn't disable failsafe mode, that would be a path to try.

Did you buy it direct from the factory? Or has a third party set it up?

How did you get to the firmware upload page if you don't know the password?

Have you tried the reset button to reset to default settings? That should remove the password.

Serial console is really what you need here. You might be able to log in with no password on the serial. Or go into through the bootloader and completely replace whatever firmware it is.

"QSDK" suggests that this is closely related to an example firmware from Qualcomm. The GUI style looks like an older version of OpenWrt.

@Jeff : How to reach teh failsafe mode ?
@mk24 : It looks like the supplier updated the OpenWrt with his own web interface besides Luci . The web interface has a user "admin" which access the function in the said interface. The reset button reset the passwords in deed , but to the default values decided by the seller (so I can login with admin in the web interface, but I can not login with root, and ssh/telnet is disabled by the seller)

  • Try the current method of depressing a switch when the status LED indicates
  • Try whatever the method was for "ancient" versions of OpenWrt, as that UI suggests that it was based on something several years old (no, I don't recall how to activate failsafe in, say White Russian)
  • Lookup what Qualcomm's QDSK says for getting root access, or into failsafe mode, if that is available without a Qualcomm developer agreement

This is the bottom line. Serial access is current standard practice for embedded systems, when it's available. It's worlds better than JTAG or the like.

I press "reset" button while powering up. The device gets obviously in a different state.
I connect my device by a ethernet cable to my laptop (with a fixed IP)

Tcpdump shows me that "" is trying to conenct to "" -> I guess that a TFTP client is trying to get a file

How to setup the TFTP server on Archlinux with the logs to see what file is begin looked for ?

That's a good sign!


oho :
11:32:05.053989 IP > gjlaptop.tftp: 30 RRQ "upgrade.bin" octet timeout 5

The device takes the "upgrade.bin" (the one I built), then reboot but firmware stays unchanged :frowning:

It looks like my TFTP server if not responding to the Ethernet ... (so the device fails to receive the upgrade.bin)
ANy clue why ? (I have no firewall)

I tried from my home server. Somehow, the TFTP works but is extremely slow (29sec to transfer the 3Mb openwrt), and most probably, the device timesout before.
(I am on Gigabit LAN)

This is the log from my TFTP server

Feb 01 13:24:45 gjlaptop atftpd[10242]: socket may listen on any address, including broadcast
Feb 01 13:24:45 gjlaptop atftpd[10242]: Serving upgrade.bin to
Feb 01 13:24:45 gjlaptop atftpd[10242]: timeout option -> 5
Feb 01 13:24:46 gjlaptop atftpd[10242]: Server thread exiting

It looks like the manufacturer forces the TFTP to fail

If I increase the verbositiy (debug), the transfer seems actually passing through

Feb 01 14:46:56 gjlaptop atftpd[13698]: Creating new socket:
Feb 01 14:46:56 gjlaptop atftpd[13698]: Serving upgrade.bin to
Feb 01 14:46:58 gjlaptop atftpd[13698]: End of transfer
Feb 01 14:46:58 gjlaptop atftpd[13698]: Server thread exiting

so somehow, my .bin is not accepted. Is there a specific option in OpenWrt compilation for such upgrade ?

The correct question is "what does your device's version of u-boot TFTP check and expect as the correct format, checksum, image magic etc."?

1 Like

To refine the search, what formats are possible from OpenWrt side ?

I see on https://openwrt.org/inbox/firmware_image_names a "factory" image. Which I do not have. (only "sysupgrade")

How to have this produced by the 'make' ? Can't find it either in