MSG100 (garage opener) stopped working after a firmware update (3.2.3)

[franza83]

Hi,

first of all, thanks for your job @krahabb

My MSG100 integration stopped working yesterday after a firmware update on the garage opener.

I tried to delete the integration and restart HA server

HA now discovers a generic "Meross LAN" integration (name and code of the hardware are not displayed)

and when I try to add/configure it, i get this error message

I checked the local assigned IP and it is correct.

My device data:
Firmware version 3.2.3
Hardware version 3.5.0

Debug log

2021-07-19 11:58:10 DEBUG (MainThread) [custom_components.meross_lan] MerossHttpClient(192.168.0.114): HTTP POST method:(GET) namespace:(Appliance.System.All)
2021-07-19 11:58:10 DEBUG (MainThread) [custom_components.meross_lan] MerossHttpClient(192.168.0.114): HTTP Response ({"header":{"messageId":"abc6144df0ec45bc9e81d582ba621821","namespace":"Appliance.System.All","method":"ERROR","payloadVersion":1,"from":"/appliance/1909032918797890800248e1e951406a/publish","timestamp":1626688690,"timestampMs":820,"sign":"9ea66f8bc516bc2b49b0a41be26cf51b"},"payload":{"error":{"code":5001,"detail":"sign error"}}}
)
2021-07-19 11:58:10 DEBUG (MainThread) [custom_components.meross_lan] Key error on 192.168.0.114 (GET:Appliance.System.All) -> retrying with key-reply hack
2021-07-19 11:58:10 DEBUG (MainThread) [custom_components.meross_lan] MerossHttpClient(192.168.0.114): HTTP Exception (Server disconnected)
2021-07-19 11:58:10 DEBUG (MainThread) [custom_components.meross_lan] Error (Server disconnected) connecting to meross device (host:192.168.0.114)

[krahabb]

Hello @franza83,
That looks bad!
Since the msg100 is still paired with the meross cloud it uses a secret key (account related) to sign protocol headers.
As you can see in the log the first response from the device reports a "sign error" and that is 'normal' so my integration tries to hack the protocol/device with a trick so to be able to communicate without even knowing this 'secret' key.
Maybe, the last firmware did fix this 'hole' in the protocol so now, on my 'key-reply-hack' attempt, it just closes the connection to avoid being fooled/hacked.
If you can retrieve the real key you could try use it in meross_lan device entry configuration. I guess you should use some 'curl' in order to get the key. It is not that difficult: basically you just login to the meross api with your credential and the repsonse will contain your account info: the key is there.
I've discussed it a bit here #35.
Short link to relevant api usage: https://github.com/albertogeniola/MerossIot/wiki/HTTP-APIs

[franza83]

I retrieved the "account key" by using https://github.com/albertogeniola/MerossIot and I used it in device entry configuration.
Resut: Connection established and my MSG100 has been immediately recognized.

I hope you can find an alternative way to connect to Meross devices in which the "key reply hack" doesn't work ... ;)

Thank you again!

[pearlythepirate]

Would you be willing to share the code you used to extract the account key? I have been trying to modify the basic script found in the documentation but have been unsuccessful.

[franza83]

I simply modified the readme.py in examples folder, by setting my cloud credentials on lines 7 and 8 and adding the following line after line 26:

print(http_api_client.cloud_credentials.key)

The output will contain the account key ;-)

[jaytea33]

Thank you! I wish I came across this hours ago before I wasted my entire Saturday haha. I hadn't updated the firmware for a while and assumed the 3.2.3 firmware had been out for quite some time so I proceeded, then thought I might be screwed. Thanks to editing those few lines, I was able to retrieve my device key when absolutely nothing else was budging.

[krahabb]

Ah, well,
I will probably add the feature 'in code' to extract the key from the Meross api (that would require you as HA user to enter your Meross credentials in my integration in order to be able to extract these info at least once). I don't see any other option, expecially since the 'hack' I've implemented is not mine but is a nice suggestion from @nao-pon (see #7 (comment))
I have no 'hacker mindset' to be honest ;)

[emufan]

I will probably add the feature 'in code' to extract the key from the Meross api

This would be more than great. Currently my one is still working, but I'm luckely still in the old FW. If this will be cut, most probably I will not be able to get the key, because from the current description, I don't get it how to get this. Not that experienced in this things.

[rhasselbaum]

I have two MSG100 garage door openers with the FW update (up to v3.2.5 now). I used the MerossIot library to extract the device key from my account, but no matter what I try, I cannot get either device to talk to my MQTT broker. I run meross-setup and everything looks fine in the output. The device connects to my home wifi for just a moment (long enough to get a DHCP lease), but then drops off immediately and goes back to pairing mode. Nothing shows up in MQTT log. I'm using a domain name for the MQTT broker and the same name is set as the CN in the certificate so I don't think it's a cert problem. (Other clients can connect.)

Curious if anyone has gotten one of these devices to pair and connect to local MQTT with firmware >= 3.2.3. If so, what process did you follow?

[rhasselbaum]

Of course, the cert is self-signed. I'm guessing these devices don't actually verify the certificate chain, though, since the docs don't mention installing a root CA cert.

[krahabb]

Hello @rhasselbaum,
Welcome to MQTT pairing mess!
From your post I cannot extrapolate which kind of mqtt environment you have. I guess you're using the HA mosquitto addon so I can link you to this discussion which was the last (to my knowledge) partly working. If you instead are using your 'own' mosquitto setup you can check this wiki
I don't think the original (account) device key is needed for the configuration procedure since you could use any as far as you use the same key in meross_lan in order to communicate with the device (the meross-setup actually sets the key you provide into the device configuration and then meross_lan should use the same key in order to correctly communicate).
If you're not seeing any connection attempt to the mqtt broker (check the mosquitto logs) it could be really bad since the dveice is not even trying to connect.
One reason for this 'not even trying' could be the device is not able to get a proper NTP configuration at boot. This can happen if you completely filter the device traffic from the internet. If that's the case, try to open it up in full and retry the procedure, you can then refine the firewall rules in order to just allow outbound NTP from the Meross(s).
This 'need' for NTP queries going through your firewall is not set in stone: in my experience I had 1 smart hub needing to connect to NTP before connecting to MQTT (no way it could work if I had blocked all the outbound traffic for the device) while any other device was able to work and connect even if completely firewalled from internet

[rhasselbaum]

Thanks for the reply, @krahabb!

I am using the Mosquitto HA add-on and have already read the discussion you linked. Mosquitto seems to be working fine in general, since HA itself connects to it using the secure (8883) port and certificate. I can send/receive test messages via the HA add-on configuration GUI and all looks fine.

In meross-setup, I've tried using a random key, the key extracted from my Meross (eHomeLife) account, and no explicit key at all (no -k parameter). All resulted in the same behavior: momentary connection to home wifi, DHCP lease acquired (viewable from my router), and then the device drops off without connecting to local MQTT (no new messages in the Mosquitto add-on log).

I don't block outbound traffic so if the device is trying to reach an Internet-based NTP server, nothing should be preventing that.

Appreciate the tips. I will try poking at it some more. If get really adventurous, I might try without TLS if the device supports that just to see if it gets any father that way.

[rhasselbaum]

FWIW, I switched to using HTTP mode with the device key extracted from my Meross account. Not ideal, but it works.

[krahabb]

I'm very sorry for your need to fallback, especially since we can't get a clear picture of where the issue lies. We're always scared a bit of firmwares (current or future) which would break in some way the custom private pairing procedure.
We don't know for sure at the moment