Would like some guidance for troubleshooting connectivity issues with a Smart Appliance
-
I have a Midea Smart Air Conditioner that keeps flapping between an Offline and online state in the manufacture's app making it almost impossible to control or set up schedules via the app.
I've reached out to the vendor but haven't had much success.
I suspect it's likely internet connectivity related and would like some strategies and guidance for narrowing down the exact cause.
According to the AP's it's wireless signal is strong and there haven't been any observable drops.
Things I've tried doing.- Having the phone and device on the same VLAN.
- Moving the device to a different AP
- Connecting the device to wifi via an ASUS router (in AP mode)
- Changing the 2.4GHZ band channel
- Connected the device to a wifi SSID that's only assigned to one AP and wouldn't attempt to roam.
- Creating a rule that allows ALL outbound traffic from the device.
- Temporarily enabling UPNP for that VLAN
- Factory resetting the device.
- Temporarily clearing SNORT blockilist and disabling SNORT service.
One of the things I'm still planning to do is set up a phone as a hotspot, connecting the AC and another phone to it and seeing if the behavior persists with PFsense out of the equation.
-
Pfsense doesn't know the difference between a wireless client or a wired client.. Are you having issues with any other devices? Maybe its wireless is just flaky?
Does the device answer ping? Get a constant ping going to it, and see if it drops, or you have packetloss, etc.
-
@johnpoz
No other devices have issues and this device has a pretty stable wifi signal < 45dBm
I've placed a dedicated AP and SSID next to it (to rule out it being some sort of issue if it's roamed between APs), connected with 25DBm and had the same issues.The application seems to primarily communicate over the internet rather within the LAN but I'm not positive on that at this specific moment. I'm wondering if it's some sort of UPNP port mapping issue where the device needs to have a port forwarding setup for it but am not certain how I would peruse that possibility. It did not seem like T1 tech support at Midea was privy to this type of into.
What would be the most effective method to log traffic and activity from a specific device for diagnostic purposes?
-
@gawainxx said in Would like some guidance for troubleshooting connectivity issues with a Smart Appliance:
UPNP port mapping issue where the device needs to have a port forwarding setup
No that would be a horrible setup.. None of the iot devices I have, or have ever seen would require that... If I did run across some POS like that, it would be back to the store as fast as I could box it up.. If I didn't discover it until return date past for some reason, or whatever - it would just go in the trash.. because that is what it is..
I have a bunch of so called "smart" things in my home.. none of them require such nonsense. They might connect to the mothership sure.. But they don't need to allow for unsolicited inbound traffic to be able to control them.. Again if they did - you wouldn't want it on your network.
To log traffic you can just setup a firewall rule to log where it goes, just setup an allow rule above the default any rule with it its source IP, and set the rule to log.
Other option would be to do a packet capture under the diagnostic menu, set source IP in the capture for all traffic.. And set the packet limit to 0 (zero).. It will not capture until you stop it... Then you can open that capture in say wireshark and see what is going on... You could always post it if you want someone to take a look at it..
-
@johnpoz Thanks,
The device began to have other issues so the manufacturer is sending me a new wifi module for it. I will run diagnostics and logging if the device continues to have issues after swapping the module.
-
Replaced the wifi module module in the device, issues persist.
Looks like the device (when working properly) communicates via a web relay.
I'll see if I can gather some packet data on a few occasions when It's not working correctly.21:47:57.862264 ARP, Request who-has 192.168.5.120 tell 192.168.5.117, length 42
21:48:14.301210 IP 192.168.5.120.40035 > 54.187.154.65.443: tcp 0
21:48:14.316062 IP 54.187.154.65.443 > 192.168.5.120.40035: tcp 0
21:48:14.427301 IP 192.168.5.120.40035 > 54.187.154.65.443: tcp 0
21:48:16.282199 IP 192.168.5.120.40035 > 54.187.154.65.443: tcp 0
21:48:16.288500 IP 192.168.5.120.40035 > 54.187.154.65.443: tcp 424
21:48:16.303365 IP 54.187.154.65.443 > 192.168.5.120.40035: tcp 0
21:48:16.308668 IP 54.187.154.65.443 > 192.168.5.120.40035: tcp 168
21:48:16.918670 IP 192.168.5.120.40035 > 54.187.154.65.443: tcp 424
21:48:16.922538 IP 192.168.5.120.40035 > 54.187.154.65.443: tcp 0
21:48:16.924250 IP 192.168.5.120.40035 > 54.187.154.65.443: tcp 0
21:48:16.933494 IP 54.187.154.65.443 > 192.168.5.120.40035: tcp 0
21:48:17.109382 IP 192.168.5.120.40035 > 54.187.154.65.443: tcp 0
21:48:17.112091 IP 192.168.5.120.40035 > 54.187.154.65.443: tcp 54
21:48:17.112113 IP 192.168.5.120.40035 > 54.187.154.65.443: tcp 150
21:48:17.126924 IP 54.187.154.65.443 > 192.168.5.120.40035: tcp 0
21:48:17.126933 IP 54.187.154.65.443 > 192.168.5.120.40035: tcp 0
21:48:17.128326 IP 54.187.154.65.443 > 192.168.5.120.40035: tcp 150
21:48:17.132520 IP 192.168.5.120.40035 > 54.187.154.65.443: tcp 0
21:48:17.134053 IP 192.168.5.120.40035 > 54.187.154.65.443: tcp 0
21:48:17.134706 IP 192.168.5.120.40035 > 54.187.154.65.443: tcp 118
21:48:17.149256 IP 54.187.154.65.443 > 192.168.5.120.40035: tcp 150
21:48:17.155600 IP 192.168.5.120.40035 > 54.187.154.65.443: tcp 0
21:48:17.157694 IP 192.168.5.120.40035 > 54.187.154.65.443: tcp 118
21:48:17.189562 IP 54.187.154.65.443 > 192.168.5.120.40035: tcp 166
21:48:17.196036 IP 192.168.5.120.40035 > 54.187.154.65.443: tcp 0
21:48:17.198395 IP 192.168.5.120.40035 > 54.187.154.65.443: tcp 134
21:48:17.213882 IP 54.187.154.65.443 > 192.168.5.120.40035: tcp 182
21:48:17.215156 IP 192.168.5.120.40035 > 54.187.154.65.443: tcp 0
21:48:20.925484 IP 54.187.154.65.443 > 192.168.5.120.40035: tcp 134
21:48:20.959087 IP 54.187.154.65.443 > 192.168.5.120.40035: tcp 150
21:48:21.025187 IP 192.168.5.120.40035 > 54.187.154.65.443: tcp 0
21:48:21.060555 IP 192.168.5.120.40035 > 54.187.154.65.443: tcp 0
21:48:22.068585 IP 192.168.5.120.40035 > 54.187.154.65.443: tcp 150
21:48:22.100289 IP 54.187.154.65.443 > 192.168.5.120.40035: tcp 150
21:48:22.409772 IP 192.168.5.120.40035 > 54.187.154.65.443: tcp 0
21:48:22.606703 IP 192.168.5.120.40035 > 54.187.154.65.443: tcp 150
21:48:22.669157 IP 54.187.154.65.443 > 192.168.5.120.40035: tcp 0
21:48:24.129476 IP 192.168.5.120.40035 > 54.187.154.65.443: tcp 150
21:48:24.144809 IP 54.187.154.65.443 > 192.168.5.120.40035: tcp 0
21:48:26.166028 IP 54.187.154.65.443 > 192.168.5.120.40035: tcp 150
21:48:26.196737 IP 192.168.5.120.40035 > 54.187.154.65.443: tcp 0
21:48:26.303065 IP 192.168.5.120.40035 > 54.187.154.65.443: tcp 150
21:48:26.317932 IP 54.187.154.65.443 > 192.168.5.120.40035: tcp 0
21:48:26.663699 IP 54.187.154.65.443 > 192.168.5.120.40035: tcp 134
21:48:26.665256 IP 54.187.154.65.443 > 192.168.5.120.40035: tcp 150
21:48:26.809771 IP 192.168.5.120.40035 > 54.187.154.65.443: tcp 0
21:48:26.845009 IP 192.168.5.120.40035 > 54.187.154.65.443: tcp 0
21:48:27.326186 IP 54.187.154.65.443 > 192.168.5.120.40035: tcp 150
21:48:27.377423 IP 54.187.154.65.443 > 192.168.5.120.40035: tcp 150
21:48:27.425384 IP 192.168.5.120.40035 > 54.187.154.65.443: tcp 0
21:48:27.428816 IP 192.168.5.120.40035 > 54.187.154.65.443: tcp 0
21:48:27.661938 IP 54.187.154.65.443 > 192.168.5.120.40035: tcp 150
21:48:27.663644 IP 192.168.5.120.40035 > 54.187.154.65.443: tcp 0
21:48:27.669771 IP 54.187.154.65.443 > 192.168.5.120.40035: tcp 134
21:48:27.672584 IP 192.168.5.120.40035 > 54.187.154.65.443: tcp 0
21:48:27.953005 IP 192.168.5.120.40035 > 54.187.154.65.443: tcp 150
21:48:27.967868 IP 54.187.154.65.443 > 192.168.5.120.40035: tcp 0
21:48:28.051571 IP 192.168.5.120.40035 > 54.187.154.65.443: tcp 150
21:48:28.066366 IP 54.187.154.65.443 > 192.168.5.120.40035: tcp 0
21:48:28.151545 IP 192.168.5.120.40035 > 54.187.154.65.443: tcp 150
21:48:28.166436 IP 54.187.154.65.443 > 192.168.5.120.40035: tcp 0
21:48:28.251006 IP 192.168.5.120.40035 > 54.187.154.65.443: tcp 150
21:48:28.266028 IP 54.187.154.65.443 > 192.168.5.120.40035: tcp 0
21:48:29.291553 IP 192.168.5.120.40035 > 54.187.154.65.443: tcp 150
21:48:29.306419 IP 54.187.154.65.443 > 192.168.5.120.40035: tcp 0
21:48:29.321082 IP 54.187.154.65.443 > 192.168.5.120.40035: tcp 150
21:48:29.368724 IP 192.168.5.120.40035 > 54.187.154.65.443: tcp 0
21:48:30.801418 IP 54.187.154.65.443 > 192.168.5.120.40035: tcp 150
21:48:30.902633 IP 192.168.5.120.40035 > 54.187.154.65.443: tcp 150
21:48:30.905039 IP 192.168.5.120.40035 > 54.187.154.65.443: tcp 0
21:48:30.961189 IP 54.187.154.65.443 > 192.168.5.120.40035: tcp 0
21:48:31.010917 IP 192.168.5.120.40035 > 54.187.154.65.443: tcp 150
21:48:31.025470 IP 54.187.154.65.443 > 192.168.5.120.40035: tcp 0
21:48:31.458278 IP 54.187.154.65.443 > 192.168.5.120.40035: tcp 150
21:48:31.499292 IP 54.187.154.65.443 > 192.168.5.120.40035: tcp 150
21:48:31.517385 IP 192.168.5.120.40035 > 54.187.154.65.443: tcp 0
21:48:31.526630 IP 54.187.154.65.443 > 192.168.5.120.40035: tcp 134
21:48:31.557664 IP 192.168.5.120.40035 > 54.187.154.65.443: tcp 0
21:48:31.557682 IP 192.168.5.120.40035 > 54.187.154.65.443: tcp 0
21:48:31.568955 IP 54.187.154.65.443 > 192.168.5.120.40035: tcp 118
21:48:31.570536 IP 192.168.5.120.40035 > 54.187.154.65.443: tcp 0
21:48:31.617365 IP 192.168.5.120.40035 > 54.187.154.65.443: tcp 150
21:48:31.631916 IP 54.187.154.65.443 > 192.168.5.120.40035: tcp 0
21:48:31.716918 IP 192.168.5.120.40035 > 54.187.154.65.443: tcp 150
21:48:31.731470 IP 54.187.154.65.443 > 192.168.5.120.40035: tcp 0
21:48:32.440759 IP 54.187.154.65.443 > 192.168.5.120.40035: tcp 150
21:48:32.472708 IP 54.187.154.65.443 > 192.168.5.120.40035: tcp 134
21:48:32.540768 IP 192.168.5.120.40035 > 54.187.154.65.443: tcp 0
21:48:32.542028 IP 192.168.5.120.40035 > 54.187.154.65.443: tcp 0
21:48:32.860326 IP 192.168.5.120.40035 > 54.187.154.65.443: tcp 166
21:48:32.874968 IP 54.187.154.65.443 > 192.168.5.120.40035: tcp 0
21:48:32.962022 IP 192.168.5.120.40035 > 54.187.154.65.443: tcp 150
21:48:32.976418 IP 54.187.154.65.443 > 192.168.5.120.40035: tcp 0 -
Yeah that is just to talking to something in aws
ec2-54-187-154-65.us-west-2.compute.amazonaws.com.
-
Why do you think it's a WiFi problem? Is there some indicator that says it's failed?
-
@JKnott said in Would like some guidance for troubleshooting connectivity issues with a Smart Appliance:
Why do you think it's a WiFi problem? Is there some indicator that says it's failed?
I don't believe it's a WiFi problem, I suspect it's likely something related to pfsense that the device doesn't agree with. My first thought was Snort but I tried disabling it with no change... I'll try disabling snort and rebooting pfsense later today to see if the issue persists.
The units smart connectivity is built into a single USB dongle, the vendor sent me a replacement dongle under their suspicion the issue may be due to it being faulty.
It's wifi connection is strong and stable and the device remains connected to my APS when it stops responding. I've tried giving it a dedicated AP from a different vendor incase it was somehow getting roamed between APS and having issues as a result of that.
The device seems to how as online and reports the status when I press buttons on the unit but doesn't respond to changes via the app.
I'm going to do some more tinkering later today but it appears what is happening is it's able to send traffic outbound but something is happening with inbound traffic where it's not getting through all of the time. Forcing the unit to reconnect to Wifi will resolve the behaviour for ~ 15 minutes or so. -
What device exactly is this - your more likely to get help if people know excactly your working with.. Its quite possible someone here or even multiple also have said device, etc.
-
@johnpoz said in Would like some guidance for troubleshooting connectivity issues with a Smart Appliance:
What device exactly is this - your more likely to get help if people know excactly your working with.. Its quite possible someone here or even multiple also have said device, etc.
It's a Midea Air Conditioner unit (Specifically a MAW12V1QWT). All of their units use the same usb dongle (Smart Kit) for wireless connectivity and control.
I was able to capture some packet data while the unit was not responding correctly within the app or to Alexa.
There were a lot of packets that were flagged as Duplicate ACK, Retransmission or even ZeroWindow during the times it was acting up. I do not currently understand TCP/IP well enough to know what those mean though. I will begin reading up on those but am hopeful someone may be able to point me in the right direction? Here is a snippet of the data I captured.
Link to the full capture.
https://drive.google.com/file/d/1ub1DPkhVyS2Y1pWo5KFUJl2Xh3pTfaOG/view?usp=sharing22 33.330943 54.187.154.65 192.168.5.120 TCP 188 443 → 40007 [PSH, ACK] Seq=687 Ack=853 Win=35376 Len=134 [TCP segment of a reassembled PDU]
23 33.736263 54.187.154.65 192.168.5.120 TCP 338 [TCP Retransmission] 443 → 40007 [PSH, ACK] Seq=537 Ack=853 Win=35376 Len=284
24 34.600176 54.187.154.65 192.168.5.120 TCP 338 [TCP Retransmission] 443 → 40007 [PSH, ACK] Seq=537 Ack=853 Win=35376 Len=284
25 35.094502 192.168.5.120 54.187.154.65 TCP 56 40007 → 443 [ACK] Seq=853 Ack=687 Win=7260 Len=0
26 35.141130 192.168.5.120 54.187.154.65 TCP 56 [TCP ZeroWindow] 40007 → 443 [ACK] Seq=853 Ack=821 Win=0 Len=0
27 35.141132 192.168.5.120 54.187.154.65 TCP 56 [TCP Window Update] 40007 → 443 [ACK] Seq=853 Ack=821 Win=8192 Len=0
28 35.141134 192.168.5.120 54.187.154.65 TCP 56 [TCP Dup ACK 26#1] 40007 → 443 [ACK] Seq=853 Ack=821 Win=8192 Len=0 -
Where did you sniff that? On pfsense? You can see some retrans were sent, ie device not answering..
But from that posting. Pfsense did what was suppose to and sent traffic on to client.. Client didn't answer or didn't get it?
-
@johnpoz said in Would like some guidance for troubleshooting connectivity issues with a Smart Appliance:
Where did you sniff that? On pfsense? You can see some retrans were sent, ie device not answering..
But from that posting. Pfsense did what was suppose to and sent traffic on to client.. Client didn't answer or didn't get it?
This was captured on pfsense with the IF in promiscuous mode.
The TCP re transmissions seem to go both ways in the capture. From what I've read so far this could suggest packet loss but I'm not seeing any signs of packet loss on the wan IF or on my APs. Although packet loss wouldn't necessarily explain why the issues seem to occur going both directions?The full packet capture i linked to has some other odd behaviour between the client and web server.
-
This post is deleted! -
All of that looks like just network connectivity issues..
Again pfsense has no clue to if its wireless or wired, if it was ding something weird then all your other clients would be having sim problems.
retrans and dup are what you see when devices don't see each other replies... Your problem is not pfsense... The problem is connectivity of the device.. Be it wireless, be it the nic on the device.
Is there anyway to hardware the device? They have a wifi dongle, do they have a ethernet dongle?
-
@johnpoz
Looking closer at the capture, I see the DHCP traffic in the same timeframe now.Unfortunately there isn't a way to hardwire it.
I'm however going to adjust the channel settings of my APs to see if that resolves it. If that fails I'm going to drop a hardwired AP immediately under it to see if it has any improvement. -
If you want to prove to yourself its not pfsense.. If it was pfsense the problem would be between your wan an lan.. ie traffic hit your wan in answer, but pfsense didn't send it on.. Or traffic from the device to the internet didn't get sent out the wan.
So sniff on the wan and the lan at the same time and then compare the sniff - is there traffic that is suppose to go to device that pfsense didn't send on? Is there traffic that hit pfsense lan side that didn't go out the wan?
-
@johnpoz said in Would like some guidance for troubleshooting connectivity issues with a Smart Appliance:
If you want to prove to yourself its not pfsense.. If it was pfsense the problem would be between your wan an lan.. ie traffic hit your wan in answer, but pfsense didn't send it on.. Or traffic from the device to the internet didn't get sent out the wan.
So sniff on the wan and the lan at the same time and then compare the sniff - is there traffic that is suppose to go to device that pfsense didn't send on? Is there traffic that hit pfsense lan side that didn't go out the wan?
So basically do a simultaneous capture of the WAN and LAN interface and then compare the two for differences or any unusual delay such as packets getting held up by a filter ?
I'll do that next after I've tested how the device behaves with a hardwired AP with a discrete SSID stationed close to it as I can.
-
Ok so I think I may have resolved the issue.
While I don't have access to the device end of things, I "Think" what's happening is that the device is not only very sensitive to any sort of 2.4ghz interference, it was trying to flip flop between WAPs and went offline for an extended period of time whenever it roamed itself.It seemed to be acting normally when I took spare ASUS router that I had in AP mode, hardwired via ethernet and placed it directly underneath if on the next floor down, giving it a dedicated SSID.
I've since adjusted the WiFi channel that the closest AP uses and created a SSID that's only on that AP which I bonded the device to. I've yet to see the behavior return over the last 19 hours since doing this. (crosses fingers)
-
Well normally a device switching to an AP shouldn't cause a problem with connectivity.. Unless your AP are actually natting.. Since your device would still have the same IP just roaming between AP.
Unless sure it was having connectivity issues.
