Meross strip mss425f does not try to reach the MQTT broker
Closed this issue · 12 comments
I just tried the latest version (PreRelease dev-491917321) on a new strip I just received.
Unfortunately, the strip does not try to connect to the MQTT broker at all. It works fine with the Meross utility.
This is a mss425f ver 4.0.0, chip MT7686, FW 4.1.6.
It is correctly configured, connects to the WiFi (and gets 192.168.10.97) and does not try to connect to the broker.
When forcing a reconnect on my AP, it sends multicast messages and for a reason I ignore, desperately tries to get info about the IP 192.168.10.72 (the network is mine (192.168.10.0/24), the IP does not exist)
16:02:57.950199 ARP, Request who-has 192.168.10.97 tell 192.168.10.97, length 46
16:02:57.950199 ARP, Request who-has 192.168.10.97 tell 192.168.10.97, length 46
16:02:57.986535 IP 192.168.10.97 > 224.0.0.2: igmp leave 224.0.0.251
16:02:57.986535 IP 192.168.10.97 > 224.0.0.2: igmp leave 224.0.0.251
16:02:58.487409 IP 192.168.10.97.5353 > 224.0.0.251.5353: 0 [1n] ANY (QU)? mt7687.local. (46)
16:02:58.487409 IP 192.168.10.97.5353 > 224.0.0.251.5353: 0 [1n] ANY (QU)? mt7687.local. (46)
16:02:58.557764 IP 192.168.10.97.5353 > 224.0.0.251.5353: 0 [1n] ANY (QU)? MSS425F-8967._hap._tcp.local. (73)
16:02:58.557764 IP 192.168.10.97.5353 > 224.0.0.251.5353: 0 [1n] ANY (QU)? MSS425F-8967._hap._tcp.local. (73)
16:02:58.813136 IP 192.168.10.97.5353 > 224.0.0.251.5353: 0 [1n] ANY (QM)? MSS425F-8967._hap._tcp.local. (73)
16:02:58.813136 IP 192.168.10.97.5353 > 224.0.0.251.5353: 0 [1n] ANY (QM)? MSS425F-8967._hap._tcp.local. (73)
16:02:59.058851 IP 192.168.10.97.5353 > 224.0.0.251.5353: 0 [1n] ANY (QM)? MSS425F-8967._hap._tcp.local. (73)
16:02:59.058851 IP 192.168.10.97.5353 > 224.0.0.251.5353: 0 [1n] ANY (QM)? MSS425F-8967._hap._tcp.local. (73)
16:02:59.208062 IP 192.168.10.97.5353 > 224.0.0.251.5353: 0*- [0q] 2/0/2 (Cache flush) PTR mt7687.local., (Cache flush) A 192.168.10.97 (115)
16:02:59.208062 IP 192.168.10.97.5353 > 224.0.0.251.5353: 0*- [0q] 2/0/2 (Cache flush) PTR mt7687.local., (Cache flush) A 192.168.10.97 (115)
16:02:59.310425 IP 192.168.10.97.5353 > 224.0.0.251.5353: 0*- [0q] 4/0/1 (Cache flush) TXT "c#=1" "ff=2" "id=50:17:CA:7D:2A:56" "md=MSS425F" "pv=1.1" "s#=1" "sf=1" "ci=7" "sh=Nn4N/g==", PTR _hap._tcp.local., PTR MSS425F-8967._hap._tcp.local., (Cache flush) SRV mt7687.local.:5010 0 0 (227)
16:02:59.310425 IP 192.168.10.97.5353 > 224.0.0.251.5353: 0*- [0q] 4/0/1 (Cache flush) TXT "c#=1" "ff=2" "id=50:17:CA:7D:2A:56" "md=MSS425F" "pv=1.1" "s#=1" "sf=1" "ci=7" "sh=Nn4N/g==", PTR _hap._tcp.local., PTR MSS425F-8967._hap._tcp.local., (Cache flush) SRV mt7687.local.:5010 0 0 (227)
16:03:00.210991 IP 192.168.10.97.5353 > 224.0.0.251.5353: 0*- [0q] 6/0/3 (Cache flush) TXT "c#=1" "ff=2" "id=50:17:CA:7D:2A:56" "md=MSS425F" "pv=1.1" "s#=1" "sf=1" "ci=7" "sh=Nn4N/g==", PTR _hap._tcp.local., PTR MSS425F-8967._hap._tcp.local., (Cache flush) SRV mt7687.local.:5010 0 0, (Cache flush) PTR mt7687.local., (Cache flush) A 192.168.10.97 (318)
16:03:00.210991 IP 192.168.10.97.5353 > 224.0.0.251.5353: 0*- [0q] 6/0/3 (Cache flush) TXT "c#=1" "ff=2" "id=50:17:CA:7D:2A:56" "md=MSS425F" "pv=1.1" "s#=1" "sf=1" "ci=7" "sh=Nn4N/g==", PTR _hap._tcp.local., PTR MSS425F-8967._hap._tcp.local., (Cache flush) SRV mt7687.local.:5010 0 0, (Cache flush) PTR mt7687.local., (Cache flush) A 192.168.10.97 (318)
16:03:02.211209 IP 192.168.10.97.5353 > 224.0.0.251.5353: 0*- [0q] 6/0/3 (Cache flush) TXT "c#=1" "ff=2" "id=50:17:CA:7D:2A:56" "md=MSS425F" "pv=1.1" "s#=1" "sf=1" "ci=7" "sh=Nn4N/g==", PTR _hap._tcp.local., PTR MSS425F-8967._hap._tcp.local., (Cache flush) SRV mt7687.local.:5010 0 0, (Cache flush) PTR mt7687.local., (Cache flush) A 192.168.10.97 (318)
16:03:02.211209 IP 192.168.10.97.5353 > 224.0.0.251.5353: 0*- [0q] 6/0/3 (Cache flush) TXT "c#=1" "ff=2" "id=50:17:CA:7D:2A:56" "md=MSS425F" "pv=1.1" "s#=1" "sf=1" "ci=7" "sh=Nn4N/g==", PTR _hap._tcp.local., PTR MSS425F-8967._hap._tcp.local., (Cache flush) SRV mt7687.local.:5010 0 0, (Cache flush) PTR mt7687.local., (Cache flush) A 192.168.10.97 (318)
16:03:06.246613 IP 192.168.10.97.5353 > 224.0.0.251.5353: 0*- [0q] 6/0/3 (Cache flush) TXT "c#=1" "ff=2" "id=50:17:CA:7D:2A:56" "md=MSS425F" "pv=1.1" "s#=1" "sf=1" "ci=7" "sh=Nn4N/g==", PTR _hap._tcp.local., PTR MSS425F-8967._hap._tcp.local., (Cache flush) SRV mt7687.local.:5010 0 0, (Cache flush) PTR mt7687.local., (Cache flush) A 192.168.10.97 (318)
16:03:06.246613 IP 192.168.10.97.5353 > 224.0.0.251.5353: 0*- [0q] 6/0/3 (Cache flush) TXT "c#=1" "ff=2" "id=50:17:CA:7D:2A:56" "md=MSS425F" "pv=1.1" "s#=1" "sf=1" "ci=7" "sh=Nn4N/g==", PTR _hap._tcp.local., PTR MSS425F-8967._hap._tcp.local., (Cache flush) SRV mt7687.local.:5010 0 0, (Cache flush) PTR mt7687.local., (Cache flush) A 192.168.10.97 (318)
16:11:22.782673 ARP, Request who-has 192.168.10.72 tell 192.168.10.97, length 46
16:11:22.782673 ARP, Request who-has 192.168.10.72 tell 192.168.10.97, length 46
16:26:40.212840 IP 192.168.10.72.26590 > 192.168.10.97.80: Flags [S], seq 2447270603, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
16:26:40.466561 IP 192.168.10.72.26591 > 192.168.10.97.80: Flags [S], seq 1920900150, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
16:26:43.216655 IP 192.168.10.72.26590 > 192.168.10.97.80: Flags [S], seq 2447270603, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
16:26:43.481077 IP 192.168.10.72.26591 > 192.168.10.97.80: Flags [S], seq 1920900150, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
16:26:44.940737 ARP, Request who-has 192.168.10.97 (48:e1:e9:2e:89:67) tell 192.168.10.72, length 46
16:26:45.949048 ARP, Request who-has 192.168.10.97 (48:e1:e9:2e:89:67) tell 192.168.10.72, length 46
16:26:46.947005 ARP, Request who-has 192.168.10.97 (48:e1:e9:2e:89:67) tell 192.168.10.72, length 46
16:26:49.217066 ARP, Request who-has 192.168.10.97 tell 192.168.10.72, length 46
16:26:49.217066 ARP, Request who-has 192.168.10.97 tell 192.168.10.72, length 46
16:26:49.949314 ARP, Request who-has 192.168.10.97 tell 192.168.10.72, length 46
16:26:49.949314 ARP, Request who-has 192.168.10.97 tell 192.168.10.72, length 46
I do not think that this is a problem with meross_pair, the behaviour with spiderweb's utility is the same. It may mean that Meross changed something in their firmware and the way it connects.
(for the record, output from spiderweb's app):
Setting up device with IP 10.10.10.1
Setting MQTT servers [ { host: '192.168.10.2', port: '8883' } ]
sending payload { header:
{ method: 'SET',
namespace: 'Appliance.Config.Key',
messageId: 'd48320fa6f9e52cef208cd3239eef727',
timestamp: 1611412706,
sign: '3cf8adfe613b4a57fbd2ca7286f716d7' },
payload:
{ key:
{ gateway: { host: '192.168.10.2', port: '8883' },
key: '',
userId: '' } } }
sending payload { header:
{ method: 'SET',
namespace: 'Appliance.Config.Wifi',
messageId: 'd75067a84748245ef10a280e45a6b504',
timestamp: 1611412707,
sign: 'c631942f09800719033b520379c40eeb' },
payload:
{ wifi:
{ ssid: 'VzI=',
password: 'bREDACTEDz' } } }
Got response: { header:
{ messageId: 'd75067a84748245ef10a280e45a6b504',
namespace: 'Appliance.Config.Wifi',
method: 'SETACK',
payloadVersion: 1,
from: '/appliance/2008272372203290827148e1e92e8967/publish',
timestamp: 84,
timestampMs: 111,
sign: '72d054e75bbe6a814f3ee1dc268b3129' },
payload: {} }
This is basically what I see with my MSL420HK as well.
It doesn't appear to be making an NTP request (or at least not one that succeeds) with a custom MQTT server, and as we've seen before (with other devices) if that doesn't complete, it will refuse to connect to any MQTT server. The multicast messages are it blasting out broadcasts for homekit devices I believe.
It doesn't appear to be making an NTP request (or at least not one that succeeds) with a custom MQTT server, and as we've seen before (with other devices) if that doesn't complete, it will refuse to connect to any MQTT server.
It does not try to reach anything (I ran the tcpdump before plugging it in).
What surprises me is that the other strips I have (the same model - I am not sure about the versions, or the FW) work fine. I bought the one that does not work yesterday, and the previous one was maybe 2 weeks ago - so there must have been some change in the meantime.
All of them are on the same network and the DHCP server does provide an NTP server.
@wsw70 I just had a breakthrough this evening with my MSL420.
Using bytespider's app, I configured it as normal except that I specified a userid and a key (which I haven't had to do for the smart plugs or strips), and now it connects to my MQTT server properly!
@wsw70 I just had a breakthrough this evening with my MSL420.
Using bytespider's app, I configured it as normal except that I specified a userid and a key (which I haven't had to do for the smart plugs or strips), and now it connects to my MQTT server properly!
Oh nice! Thanks. How did you provide these values (and what are they?)
Just pass --user=1 --key=2 and confirm that they are sent in the payload. It means that if you're generating the sign value in your requests you'll need to use those values as well (I'm just hardcoding the sign/messageid/timestamp in every request).
@andrew-schofield thanks for the details (I also realized that your information is for devices that do not connect at all and not the ones that do not re-connect -- this is very valuable information anyway, I was just confused by the weirdness of this reconnection issue that seemed to depend on yet one more unrelated variable)
Can you link the device you have @wsw70 I might look at buying one to help resolve your issue.
@bytespider this is https://www.meross.com/product/19/article/
I am surprised by how the firmware differs between the devices. I did a walkthrough of the options at bytespider/Meross#13 (comment) and will re-pair all my strips today with the latest branch of your utility you mentioned at the end of that thread.
It looks like the most reliable way to get all devices to connect (and stay connected) is to always send both the primary and secondary MQTT servers and a user ID + key.
I guess we just got lucky with the smart plugs which are happy with a "minimalist" config.
@bytespider I just tried the dev branch of your utility, passing one --mqtt mqtts://the.fqdn.of.my.server:8883 (I was always passing the IP before).
- the config went fine, two brokers were sent (both the same) → the strip connected in ~5 seconds
- I disconnected the broker for 30 seconds (just so that the strip loses connection), then back on → reconnection in ~5 seconds
- I disconnected the broker for 10 minutes, then back on → reconnection in ~5 seconds
THANK YOU VERY MUCH EVERYONE, obviously @bytespider but also all the folks who were trying hard and had wonderful visions on how to fix the issues @andrew-schofield @Skyleiger @albertogeniola
I am closing the issue and will redirect all the other ones I mentioned the issue in over here.
Thanks goes especially to @andrew-schofield for testing and finally discovering the secret sauce
A small utility I wrote to simplify the management of these devices: https://github.com/wsw70/meross-local-mqtt