VLAN Support

[mimik13]

Hi. Does this integration require the vacuum to be on the same VLAN as Home Assistant or will it work across VLANs?

Thanks.

[jdejaegh]

Not tested across VLAN but it works across networks: vacuum connected to a 4G mobile hotspot and HA on my DSL residential connection.
So this should work across VLAN as well.

As the integration relies on Roborock's cloud it should work as long as both HA and the vacuum can access the cloud, no matter if the are on the same network.

[bobzer]

Would it be possible to not rely on the cloud ?
local control would be great

[jdejaegh]

The robot is locally broadcasting some data over UDP every 5 seconds or so. Here is what it looks like in Wireshark from my laptop.

Network capture

Frame 115: 121 bytes on wire (968 bits), 121 bytes captured (968 bits) on interface \Device\NPF_{93C6F631-8590-4D0E-ADCA-466509D492A4}, id 0
  Section number: 1
  Interface id: 0 (\Device\NPF_{93C6F631-8590-4D0E-ADCA-466509D492A4})
  Encapsulation type: Ethernet (1)
  Arrival Time: Jan  9, 2023 19:51:56.238974000 Paris, Madrid
  [Time shift for this packet: 0.000000000 seconds]
  Epoch Time: 1673290316.238974000 seconds
  [Time delta from previous captured frame: 0.500144000 seconds]
  [Time delta from previous displayed frame: 24.986688000 seconds]
  [Time since reference or first frame: 26.723092000 seconds]
  Frame Number: 115
  Frame Length: 121 bytes (968 bits)
  Capture Length: 121 bytes (968 bits)
  [Frame is marked: False]
  [Frame is ignored: False]
  [Protocols in frame: eth:ethertype:ip:udp:data]
  [Coloring Rule Name: UDP]
  [Coloring Rule String: udp]
Ethernet II, Src: BeijingR_3b:5f:7a (b0:4a:39:3b:5f:7a), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
  Destination: Broadcast (ff:ff:ff:ff:ff:ff)
  Source: BeijingR_3b:5f:7a (b0:4a:39:3b:5f:7a)
  Type: IPv4 (0x0800)
Internet Protocol Version 4, Src: 192.168.42.24, Dst: 192.168.42.255
  0100 .... = Version: 4
  .... 0101 = Header Length: 20 bytes (5)
  Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
  Total Length: 107
  Identification: 0x0000 (0)
  010. .... = Flags: 0x2, Don't fragment
  ...0 0000 0000 0000 = Fragment Offset: 0
  Time to Live: 64
  Protocol: UDP (17)
  Header Checksum: 0x641a [validation disabled]
  [Header checksum status: Unverified]
  Source Address: 192.168.42.24
  Destination Address: 192.168.42.255
User Datagram Protocol, Src Port: 38145, Dst Port: 58866
  Source Port: 38145
  Destination Port: 58866
  Length: 87
  Checksum: 0x8b6c [unverified]
  [Checksum Status: Unverified]
  [Stream index: 5]
  [Timestamps]
  UDP payload (79 bytes)
Data (79 bytes)
  Data: 312e300000000100020040c3850de14011b6eeb723971516ac15329f2e3d92f96654b87c…
  [Length: 79]

Using PCAPdroid I was able to see once a TCP connection between my phone and the robot locally. I was not recording the PCAP file and I can't get it to do it again. Blocking DNS or removing Internet access prevents the app from opening.

[jdejaegh]

I managed to make the app connect locally to the robot again. I disabled DNS resolution for the robot (using Pi-Hole and setting all address as blocked) but left my phone with full Internet access. I captured the traffic using PCAPdroid.

The app connects to the robot on port 58867/tcp (which is discovered as open by nmap). They then exchange gibberish (i.e. the data does not translate to plain ASCII text) over that TCP connection. The data does not seem to be encrypted as the payloads seem very similar to each other and have a low entropy.

Here is an example of the first payload sent by the app to the robot

0000   00 00 00 15 31 2e 30 00 00 00 00 00 00 00 00 00   ....1.0.........
0010   00 00 00 00 00 00 00 00 1e                        .........

I now have a PCAP dump of the TCP connection that happened between the app and the robot with me changing mop and vacuum settings. I am not sure that everything between the robot and the app went through that TCP connection as the robot may have some DNS cache and may have kept a connection to Roborock's servers. During the recording, the app kept an active connection to Roborock MQTT server and was constantly sending data.

I don't have time to reverse engineer the network protocol but I can share the PCAP file of that local TCP connection. The file contains 1550 packets and spans over 472 seconds.

[StaleLoafOfBread]

I see you got it working again but FYI my findings show that in order for the app to open it needs internet. Once you "enter" the robot, you can unplug your modem (or fw rules) and it will communicate locally. I can't recall if this only works for a limited amount of time or not.

[humbertogontijo]

I've tried using tuya protocol directly in port 58867 using device duid and local key, but, unfortunately, had no success

[shred86]

Has anyone tried this to see if they're able to obtain any more information on how the Roborock app connects to the device locally? I suppose you would need to setup the app in an iOS or Android development environment on a computer to capture that main.bundle file.

[humbertogontijo]

I managed to execute a command offline! I'll be adding a offline.py file to repository https://github.com/humbertogontijo/python-roborock

[Lash-L]

Okay I got an old mac, got airtool2 and wireshark on it.

Whenever I hit any of these captures, it opens wireshark, but only shows 802.11 protocol request. On my other wireshark instance I set it up to go through my wifi access point, should I do the same with airtool 2? How do you start yours typically?

[humbertogontijo]

You need to plug an iPhone to the Mac and go to "Capture iPhone Packet Trace"

[Lash-L]

Ah -I see. that got it, thanks

[Lash-L]

Okay been playing around a bit -

If you install pyshark, you can load the pcap file from wireshark directly into python and it makes it a bit easier to do some bulk experiments.

capture = pyshark.FileCapture('wireshark.pcapng', 'rb')
for packet in capture:
    if hasattr(packet, "ip"):
        if packet.ip.dst == local_ip or packet.ip.src ==local_ip:
            if hasattr(packet, "DATA"):
                if hasattr(packet.DATA, "data"):
                    f = client._decode_msg(
                        bytes.fromhex(
                            packet.DATA.data),
                        local_key)

You end up getting a handful that have incorrect starts - which I just ignore. But then you also have a few that have an incorrect cr32 - including the call to get the ip/ mac.

Doesn't really help with the map issue, but I'm starting to get an understanding of everything

[Lash-L]

Okay - additional piece of info. It appears as if protocol 5 can sometimes have data - but its payload length is described at a different location? Not sure - you may have a better idea of how to figure this out. Right now, when it unpacks, it gets a payload len of 0. Even though there are dozens if not hundreds of extra bytes after :19.

Here's an example set of bytes that are protocol 5, and definitely have a payload(and fall other under criteria such as unencrypted tcp and has data.data

In the newest system, these will never run, as they have a payload length of 0. Any tips on how to go about reverse engineering this?

b"1.0\x00\x00[\t\x00\x00\x1bXd'\x8d\xde\x00\x05\x00\x00\x00\x111.0\x00\x01/\xec\x00\x00\x1bYd'\x8d\xde\x00\x05\x00\x00\x00g1.0\x00\x00\x1d$\x00\x00\x1bZd'\x8d\xde\x00\x04\x00P%+\x1c \xe4D\x18\x11\xbc\xa6\xaa\xbe\xb0>\xe9\x10\xb7\x95u\xe6\xb8~\x84\xa0\x88\x935\xc9\xbc\xa2\xe7b7\x91Wr\x80\x10\xccY\xd2\xb3.\xf2\x8du\xf841\x00\xc9k\xad\xc1\x04\xb2\xc6\r\xc1\xa8Y\x18\xfc{X\x91\xf2\x06:\xf4\xe4\x83\x80\xfa=qE\xdfu\xf6\x98f\xa2\x12\x00\x00\x00g1.0\x00\x00\x1d%\x00\x00\x1b[d'\x8d\xde\x00\x04\x00P%+\x1c \xe4D\x18\x11\xbc\xa6\xaa\xbe\xb0>\xe9\x10\xb7\x95u\xe6\xb8~\x84\xa0\x88\x935\xc9\xbc\xa2\xe7b\xb2g\x91\xa3\xec\xa6\x19!\x14p\xfa>c\x85gTt\x8e\x8e\xf6g\xf6\xa8\xf9\xf0\xd4T\xa2\x0c\xad\xd0\xde\xa1n\x0c\x93i \xb1(\x01\x90\x93\x1c\r\xcd\rP\xc1\x0f\xdcC"