Dreame X40 Ultra Robot forgets WiFi after reboot

[pborsutzki]

Are you already using Valetudo?

Yes, just started

Your questions

Hi,

first of all many thanks for your effort in creating Valetudo and all the guides that help to install it!

Now, I recently bought a Dreame X40 Ultra. I had it running for a few weeks by just pressing the on-device buttons. So far it worked well. I managed to root the robot using the provided guides and installed Valetudo, which seems to work fine so far (UI works, can control the robot, etc.).

Unfortunately I had to find out that the Robot becomes unreachable over WiFi a few hours after connecting it. I have reconnected the robot (by holding the left and right button, then re-adding the WiFi again) to the WiFi now several times, but after a few hours it again is disconnected from the WiFi.

So I started digging a bit using the root access I now have. I found that the initial reason for the disconnect is a reboot of the robot that sporadically happens every few hours. /data/log/script.log shows such log entries every now an then:

1970-01-01 08:00:24.765155 kernel: [   20.809681] sunxi_i2c_do_xfer()1946 - [i2c2] incomplete xfer (status: 0x30, dev addr: 0x10)
1970-01-01 08:00:24.765160 kernel: [   20.810212] [VIN_DEV_I2C]sc520cs_mipi sensor write retry = 1
1970-01-02 04:14:15.025140 kernel: [72851.069554] [VIN_ERR]tdm0 rx0 frame error! width is 791, height is 1816
1970-01-02 04:14:15.025199 kernel: [72851.069563] [VIN]__sunxi_tdm_reset:tdm0 reset!!!
1970-01-02 04:14:15.029099 kernel: [72851.072392] [sc520cs_mipi]PWR_OFF!
1970-01-02 04:14:15.033138 kernel: [72851.076560] [sc520cs_mipi]ai dvdd gpio low
1970-01-01 08:00:08.858175 kernel: [    0.000000] log_buf_len individual max cpu contribution: 4096 bytes
1970-01-01 08:00:08.858575 kernel: [    0.000000] log_buf_len total cpu_extra contributions: 12288 bytes
1970-01-01 08:00:08.858593 kernel: [    0.000000] log_buf_len min size: 16384 bytes

So I suspect there is some faulty driver/hardware that causes it to reboot. But imho that shouldn't be an issue for the WiFi connection, it could just reconnect after reboot? Well, but it does not. If I reboot it on my own by just typing reboot into the root shell, I get into the same state - disconnected from WiFi until it reconnect it manually again.

Not really sure what to look for I also found these log entries repeatedly in /data/log/script.log (I masked some things with X'es):

1970-01-01 08:00:11.497606 miio_client_helper_nomqtt.sh:119:  method: _internal.request_dinfo
1970-01-01 08:00:11.558856 miio_client_helper_nomqtt.sh:119:  key from private
1970-01-01 08:00:11.617533 wpa_supplicant.sh:119:  ap_info: :
1970-01-01 08:00:11.623831 dmio.sh:119:  skip as not in ap mode or unsupport QRPair
1970-01-01 08:00:11.656123 dmio.sh:119:  /usr/bin/dmio.sh load !!!!
1970-01-01 08:00:11.725712 manager_ap.sh:119:  chk_ap
1970-01-01 08:00:11.734031 miio_client_helper_nomqtt.sh:119:  {"method":"_internal.response_dinfo","params":{"did":XXXXXXXXX,"key":"XXXXXXXXXXXXXXXX","vendor":"dreame","mac":"XX:XX:XX:XX:XX:XX","model":"dreame.vacuum.r2449a","sc_type":[0,1,2,3]}}
1970-01-01 08:00:11.805682 miio_client_helper_nomqtt.sh:119:  method: _internal.req_wifi_conf_status
1970-01-01 08:00:11.816459 miio_client_helper_nomqtt.sh:119:  bind_status:
1970-01-01 08:00:11.827111 miio_client_helper_nomqtt.sh:119:  {"method":"_internal.res_wifi_conf_status","params":0}
1970-01-01 08:00:11.890799 manager_ap.sh:119:  get ssid failed in line: :
1970-01-01 08:00:11.931636 wpa_supplicant.sh:119:  wpa_conf: ctrl_interface=/var/run/wpa_supplicant#012update_config=1
1970-01-01 08:00:12.891284 dm_robot_player.sh:119:  mount --bind /usr/bin/dmr_client /usr/bin/ogg123 success!!!

I found the manager_ap.sh:119: get ssid failed in line: : interesting and found that it retrieves the wifi configuration apparently by calling dreame_release.na -c 7. If I do that manually while being successfully connected to the wifi it returns this (again, things masked with X'es):

[secure storage]
1: ap_info = :
2: MI_KEY = XXXXXXXXXXXXXXXX

So it looks to me like the wifi connection isn't persisted in there. Now I didn't want to manually enter that command that this script uses for persisting the config as I am a bit afraid of bricking the robot by doing that.

Is anyone having a similar problem? Are there any known solutions/workarounds?

A bit about my setup:

• I am using a FRITZ!Box 7490 as WiFi Router, I have the same SSID on 2.4 and 5 GHz and one repeater (FRITZ!Repeater 1200 AX). On 2.4 GHz it uses WiFi 4 802.11g+n. I tried disabling channels 12/13 without success.
• SSID has 14 upper and lowercase letters (a-zA-Z, just regular ascii letters) and an exclamation mark. I tried removing the exclamation mark without success.
• Password has 64 all lowercase alphanumeric characters (a-z0-9, just regular ascii letters/numbers). I tried removing the exclamation mark from the ssid and changed the password to 13 lowercase alphanumeric characters, no success.
• I never connected the robot to the app/a wifi before rooting. So on one hand there were no vendor patches installed. But on the other hand I don't know if the robot would have had similar issues with the stock firmware.

[Hypfer]

See comment here: #2181 (reply in thread)

[pborsutzki]

Thanks for the quick answer! I unfortunately didn't find that thread when searching for help.

Do you still need help debugging the issue? I think I could manage to get a copy of my /data/ directory via UART & USB before and after doing a factory reset. If so, do I understand correctly, you need a diff between the errorneous state directly after a reboot where it cannot connect to the WiFi from before the factory reset and the hopefully working state after the factory reset (+ valetudo installation)?

[pborsutzki]

Problem is resolved, see #2181 (reply in thread)