Recent MSS110 Firmware Update Broke meross_lan #456
Comments
|
Enabling diagnostic entities on this firmware populates three new sensors: Judging by |
|
I'm still able to issue some commands to the
But these result in an immediate socket hangup (I've validated that these same commands still work on the older firmware):
|
|
This could explain a similar issue as in #430 (comment). I think it would need some reverse engineering on the app <-> device communication in order to extract the eventual 'key' needed for correctly setting up those failing requests/responses. I could guess the header would need some extra field carrying an added signature or the standard signature algorithm has been updated to a new version. |
|
Yup, looks like the same exact behavior. I tried sniffing traffic last night but couldn’t get my Mac to pick up the eapol packets for some reason. I’ll try running tcpdump on my UniFi router and/or access point to see if I can grab the traffic that way. There are also two new capabilities for encryption listed; one to return the encryption suite, and the other presumably for initial key exchange. |
|
Not looking good, seems like the payload and header are both completely encrypted now. Here's what the traffic looks like between my app and the plug when toggling power: |
|
I'm going to request that Meross roll back my firmware to the previous version on these plugs. But my other question is: why isn't cloud connectivity working? The |
|
Hello @brianschrameck , |
|
Hi @krahabb , Communication with local devices is required but only if the device exposes the encryption ability within the GET ABILITIES command. Note that mqtt is not affected and should continue working in clear text. Feel free to get inspiration from my repo 🙂 |
|
Hello @brianschrameck, Or, take inspiration if you want to try 'manually' encode/decode payloads and see if everything fits. It looks as even if ECDHE256 is mentioned as 'ka' (key algorithm ?) encryption is basically an AES CBC with a 'parameterized' key and a fixed iv. Meross uses this techninque here and there to compute secrets based off some unique/intrinsic device properties (uuid/mac) and the device/account key (signature key). The fix itself is pretty simple and you'll easily check the diff in #2920018 (mainly in httpclient.py) |
|
That was fast! I pulled the dev branch and things look to be working well. 👍 Thanks! |
|
Awesome ;) |
|
Do you have an ETA on when you will make a release with this? Asking so I can make sure I check back and update :) Thanks! |
|
Hello @rxin. Else I think I could release an official version in the next weekend |
|
|
|
I moved to 5.3.0-alpha.2 but my issues with the mini plugs on hardware platform 7.0 is still no go. |
|
This is puzzling me a bit. By the look of it the issue is strictly connected to this incoming new fw for v7 hw which is introducing (mandatory?) encryption for HTTP traffic which is the default meross_lan uses. What I don't understand is why the patch (5.3.0-alpha.2) worked for @brianschrameck and is not working for others exposing the same kind of issue/behavior. If I could get a 'Download diagnostic' (with 5.3.0-alpha.2) from any of these devices I could try better figure out. |
|
FWIW I had completely removed and reinstalled the integration, so that would seem to make sense for the need to reconfigure. |
|
This is the raw data from one of the devices that is not working in Alpha 2 { |
|
By the way I tried uninstalling the HACS intergration and rebooting and re-adding. No change. |
|
First I had an old Version (don't know the Version) manually installed. After that I had HACS. So I removed the old version manually and installed the beta 2 via HACS and restarted HA. Now I noticed that there comes a additional popup wenn I hit the "Configure?" button on the device. I clicked the "Configure?" button in the first popup and the second popup is the same then as in the old version I had. I then submitted as you sayed without changing something. Doesn't work. I checked all the Connectiontypes. MQTT can't be submitted. Auto/Http made no difference. |
|
@JosephRDawson: |
|
Hi ... I closed 467 because it was a duplicate to this issue and I wanted to respect the bug tracking. I didn't close it because it was resolved. The log data may look better but the end result is the same... Not working. :) |
|
Do I need to open an own issue? Thought it was the same as here ^^ |
|
Ok... I turned on debug and flicked it on and off a few times and downloaded the diagnostics. { |
|
Oh you get the debug logs when you turn debug off! Ok I have them. |
|
I question if this item should be flagged as "fixed" ;) |
|
@JosephRDawson,
So it looks like after installing 5.3.0-alpha.2 somehow you reverted to 5.2.2 which is obviously not working |
Hello @stefmde, |
|
LOL good catch! Ok after I did the uninstall and reinstall I didn't know beta was turned off. Ok so new logs and debug info from alpha2. Still not working... home-assistant_meross_lan_2024-06-28T21-46-28.428Z.log |
|
Hello @JosephRDawson, In the log you've posted, there are many connections errors about other mss110 devices but these errors look different ("Connect call failed") than the typical error due to wrong encryption ("Server disconnected"). Also, these other devices are not replying on MQTT too so it looks like they're internally 'stalling' not being able to reply to any query from any protocol. |
|
Hi @krahabb, I power cycled a plug that is not working just to be sure and no change. Let me give you more information. The plug I tested just then was August Connect Front and it's Entity ID ends with eab_outlet when you look at the logs. In the log data I am providing you now using your integration tried to turned on and off the plug in HA 5 times. And it says in HA that it is working but the device is NOT changing state. Then I also turn it on and off five times locally via HomeKit. And you could see in your integration that it is capturing the change and showing it going on and off. So your integration even when I was using 5.2.2 was always seeing state changes in the plugs without issue. Something that I think is odd if it wasn't doing encryption before. Unless viewing state is still done without encryption and changing state requires encryption. I would have thought both would have and when they made that change you wouldn't see anything. But your integration has always see state changes just no ability to control. The device is working in HA using the the https://github.com/albertogeniola/meross-homeassistant/issues integration that works via the cloud. (But obviously as a HA user I want it done locally.) The fact the devices have always worked via every method of control made me think that rebooting wouldn't help but i did it anyway just to make 100% sure and give you as good a chance as possible. I hope this additional information is helpful. Here are the new logs. If you need something else please let me know. I assume you don't have any of the newer plugs yourself or you would have tried this. ;) meross_lan-d00445cae8a6103543a229f958e5b76c-August Connect Front-62fa7daf6730043e0a4f3463430feb19.json |
Yes, this is explained by the fact that MQTT traffic is not being encrypted in new fw so it is correctly decoded even in 5.2.2. Regarding encryption, at the moment it is only being enforced over HTTP, and, by the look of your traces it seems working...just the commands are not executed at the device so maybe there's an another issue..I'll further investigate those toggle commands being accepted by the device but not sorting any effect.. |
|
@krahabb Ok sir... Just giving you all the info i know for now. If their is anything additional i can provide don't hesitate to ask. All the best, Joe |
|
Hello @JosephRDawson, Since you have the Meross cloud profile setup, we could try force the protocol to (cloud) MQTT in order to see if the issue is in the HTTP transport or somewhere else:
When configured this way you might incur throttling in 'message rate' (maximum 6 messages over a 1 minute span) but, unless you're repeatedtly 'fast switching' your plug this shouldn't occur very often ;) |
|
Hi @krahabb ... I assume your talking about this set of options in the cloud version.
All three methods work equally as well. |
|
Hello @JosephRDawson , |
|
Ok I just installed 5.3.0-beta.0 Still not working but I assume you have more logging information. It is now faster to notice that it is NOT working and the LOGBOOK next to each device when you flick it is not showing success. So Meross LAN now knows it is NOT working. I made a short video so you could see it. To the right is my Home Kit so you can see HomeKit the device is not moving and at the end i turn off and on in HomeKit and Meross LAN shows it working. https://www.youtube.com/watch?v=KRDaTtKV63g home-assistant_meross_lan_2024-07-01T12-23-52.212Z.log |
|
@krahabb ... Ok I thought you wanted to know if making that change in their integration broke their system. Turning on and off the MQTT configuration in 5.3.0-beta.0 has no change that i can see. |
|
Thank you @JosephRDawson, At any rate, I've tried gambling with this fix but I wasn't really confident...my old mss310 accept both the previous version and this new one but in general, and the @albertogeniola integration does that too, the 'supposed correct way' was the previous one. Now, this is no more an issue about encryption since it looks very stable overall..just this 'toggle command' which is not working. Right now we should consider the 5.3.0-beta.0 as surely buggy (with this new implementation) so I'll revert that fix rightaway. At the moment I'm like 'bumbing my head into the wall' (not sure if this is the correct way to say that...) In the HA 'SERVICES' UI select the
The payload is the one which usually worked (swapping "onoff" -> 0/1 for toggling) and is the one used in 5.3.0-alpha.2 or any previous version. The device should reply with a SETACK and an empty payload (this too is the usual reply when the command works). Beside trying issuing that command for toggling (I'm expecting it gets replied with SETACK meaning success - but the device doesn't really toggle...) what I would test now is to try this payload: Also, since you're there, try issuing those messages by setting the |
|
I am showing you the HTTP tries but the MQTT results are the same no effect but here is the data. You should pick up a plug so you can try yourself they are dirt cheap. What country are you in and do you have Amazon Prime?
|
Sure that's no issue.. |
|
@krahabb The Meross cloud system is always sending to Meross cloud. So I guess they are using a dedicated system with extra authentication to Meross. And now you need that... perhaps they are using the users password with the local authentication now and maybe that has changed and is causing it to be broken. I just hate to think this integration will get dropped once they update the firmware on all devices. You put so much work into it... it will be sad to see it go. Also is this normal? To have it show no devices here? |
The 'no devices' is ok since that config entry is just a kind of 'connector' to the Meross api in order to query devices config and broker addresses.
I don't think so. Everything else is working, just the issued commands which are somehow ignored (even though the device accepts it with the SETACK confirmation). We'll further investigate |
|
I see you made another 5.3.0-beta.1... :) No change.. I will keep trying as long as you have things you want me to try. |
|
Yep..the beta.1 is just reverting the toggle command to what it was before...since the implementation in beta.0 was just a 'drastic' attempt. |
|
Any progress? |
|
Hello @JosephRDawson, |
|
I see a new update for it was released a few hours ago. No change in it not working... Should I open a new ticket as you think it maybe unrelated? |
|
Hello @JosephRDawson, |
Version of the custom_component
5.2.1
Configuration
Configured using UI with cloud login.Describe the bug
I have a number of mss110 devices. Some are hardware version 4.0.0, some are 7.0.0. Recently, a firmware update for hardware 7.0.0 was rolled out. The firmware notes said something like "improve security of local control". After updating, meross_lan can no longer control these devices at all. My hardware version 4.0.0 devices (firmware 4.2.14) are still working.
Debug log
The text was updated successfully, but these errors were encountered: