Wyzecam App Issues - Display freezing and constant load

support

#21

Small update for this - the issue seemed to resolve itself over the course of a few days… now… yet again I am trying to connect to my camera to check on our pup as its quite hot today and we want to make sure she is doing ok… and I have been cycling through the connection steps for the last 30 minutes. I have received a few single frames and constant drops. During this process, I am receiving motion and sound detection updates that I am able to retrieve without issue all the time. I also don’t know about anyone else… but I feel like I have only viewed about 5 minutes of total stream time… and somehow I have used almost 2GB of data. I wouldn’t think 12 second clips would add up to that much… so I am wondering if I am “streaming” the camera feed without being able to see anything in the app? It would be great to be able to get a live feed on a web browser going, so I don’t use up data on something I can’t use on my phone anyway. Open up some kind of an API even, then I can hook my cameras up on my own local server for remote viewing.

Something has to give at some point… It would be great to know what the parameters are to connect to this stream in order to know how/what we can troubleshoot further on these LTE networks.

-end rant.

EDIT: I should also be clear that I have 2 cameras. One I can seem to connect to more than the other. Both purchased on the same day, setup within minutes of each other with the same firmware. I can connect to one camera more than the other, but both seem to hang more often than not.


#22

FWIW the only info Wyze has posted about network ports is here, but it doesn’t specify the destination for each type of traffic:

https://www.wyzecam.com/what-ports-open-firewall-for-wyzecam-work/

 


#23

Yeah I had tried that, on top of setting up an entirely new router… and neither seemed to have stabilized it. Having assigned IPs or dynamic doesn’t change a thing either. I have wracked my brain with anything I can think of on my internal network and cannot come up with a solid solution. I feel like this has to do with the authentication route and it blocking attempts after a while… or not being able to handle enough connections. If these AWS servers are where the auth is happening and it’s using NGINX, there should be more than enough child processes available to handle authentication and connectivity all the time.

My main guess when I cannot obtain a camera stream from outside my home network, is that a constant handshake needs to be maintained for authentication purposes (between the remote IP from my cell phone/provider and the Amazon Servers WYZE uses) and when a connection cannot be obtained, it locks up. Then when I am home, the public IP registered for my Camera and the public IP my phone is coming from would match… possibly allowing a passthrough rather than it needing to copy my credentials and keep a handshake going… thats a stretch though.


#24

As another quick note. I just let that loop issue run through on my phone for 9 minutes straight… and my phones data tracker (the stock built in Android one from my Pixel XL) and it states I used up 18MB of data in those 9 minutes. 18MB of data without viewing a single frame from the camera seems quite odd.


#25

I’m at the point now where I am ready to give up on this camera. Although picture quality is stellar it rarely works when I want to watch live stream on my video. Lag is awful and then it freezes and restarts. Tried reverting firmware and that didn’t work and now I’m trying to upgrade firmware to latest version and won’t work. Just sits at 0%. Great.


#26

Have you tried moving the camera closer to your wifi router to see if that’s the issue?


#27

It appears it has something to do with being on LTE versus Wi-Fi. When I’m on Wi-Fi, no matter where I am, it works fine. ButBwut I’m on LTE, and I have very fast LTE, it just doesn’t work properly. So right now it’s working great.


#28

I’m having this same issue. I can’t view a live stream remotely, but I can do things like reboot the camera remotely (on cellular data and from my work office), but I can’t view my camera remotely at all. When I’m at home I don’t have any problem, so it’s not my WiFi. Motion-triggered recordings work fine every time, but that’s different because that footage is being retrieved from the cloud, not directly from the camera. I’m a network engineer so I thought I would do some investigation into what exactly is going on here. I took a look at the IP addresses being used for the WYZE cam communication and I found something that is really concerning. I’ll try to keep this as short and brief as I can.

My phone was connected to my office wifi, so the internet connection in use would be my company’s internet. Solid connection, but of course there are things like firewall policies etc. that could come into play there the could effect it. So, I also used 4G LTE as the secondary connection to eliminate the company firewall. So in both cases I just tried to view the live stream. When I look at my firewall traffic logs here is what I see: When I attempt to access the live stream connected to my company’s wifi, the firewall log shows the Wyze cam attempting to initiate a connection with my company’s public IP address, AND with the IP address my phone has on my companies wifi. This would NEVER work. There is no possible way that traffic would get to my phone, being initiated FROM the wyze cam TO my phone. So I disconnected from wifi so I would be on 4G LTE and tried again. The exact same result. There is no possible way that traffic could get to my phone across the internet.

This is a major flaw in design. Apparently the Wyze service is using some sort of secure link to the wyze ‘cloud’ to inform the cameras of my private and public IP addresses so the cameras then attempt to initiate a connection to my IP addresses (and attempts public and private as a shortgun approach???), but that methodology could never work remotely. I would work on a home network since the local IP address would be reachable, but as soon as you cross a NAT boundary (internet) that methodology falls apart. For something like this to be reliable, it would need to have a proxied connection through an outside entitiy (wyze cloud?) to have a secure tunnel to the cameras and be able to keep the pathway open for live view. It seems to me that based on other functionality that DOES work (rebooting the camera) that some functionality DOES work through a secure connection like an HTTPS connection, but other bandwidth-intensive tasks like viewing a live stream are not.

It’s possible I don’t know another piece of the puzzle, but from a raw network capture, that is my take on what is happening, and why it isn’t working.

The fact that it ‘kind of works’, makes me think there is something wrong in their firmware, and maybe what I’m seeing is normal functionality and normally that’s just the first attempt and there is a fallback that should be reliable…but at least in my experience since having the wyze cams for about a month, but remote live view just plain doesn’t work for me. I’ll be reviewing this on my YouTube channel soon.


#29

I agree with this… there is definitely something odd going on. The fact that this is working in a roundabout fashion is concerning for stability. They say that the connection is direct from your device to your network (unless retrieving a video from the cloud)… but at that point, there should be the same result from a connection no matter where you are. I don’t know how authentication would work based on it going straight to our own network. I have a feeling this is a connection issue between LTE/external WiFi networks and their authentication/connectivity handling on what I assume to be Amazon servers. I have too many client projects on the go right now to test further regarding what this is trying to do to bring the stream up, but I am close to my return timeline and have not heard anything back from Wyze regarding this issue. I sent them a message over the weekend to address the issue… so we will see what happens. Typical responses of whether I have tested my WiFi, moved my camera to a better location etc is simply not good enough anymore. Something is wrong and it needs to be discussed. My connectivity is hit and miss on LTE as well. This morning I could connect from my office desk without issue… now I am completely locked out again sitting at the authentication step. Not a single factor has changed. I have remote access to my router, no change in signal, speeds, packet drops etc. Hopefully someone at Wyze can discuss this - I am seeing more and more of these comments popping up lately.’

Another item worth noting… while trying to test and get this to work via LTE, I burned through nearly 4GB of data from this app. Would be great to be able to pop in to the Wyze app, stream for a few seconds to make sure everything is ok… and then close it out. Right now I am relying heavily on these 12 second clips that keep downloading. It’s also concerning that I burned through 17MB of data (I think) the other day just while testing what was going on when this auth issue was happening. (posted it above in this thread).


#30

Thanks for taking the time to trace the network logs Keith! In case it helps or anyone wonders, below are the firewall logs from my router showing a typical/working connection to my Wyze Cam v2 from a public WiFi hotspot:

Aug 13 12:39:54 ACCEPT IN=br0 OUT=eth0 <1>SRC=192.168.1.143 DST=35.163.180.168 <1>LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=43723 DF PROTO=TCP <1>SPT=57456 DPT=8443 SEQ=4130897516 ACK=0 WINDOW=14600 RES=0x00 SYN URGP=0 OPT (020405B40402080A00F8D4A70000000001030304) 
Aug 13 12:40:30 ACCEPT IN=br0 OUT=eth0 <1>SRC=192.168.1.143 DST=50.19.254.134 <1>LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=16764 DF PROTO=TCP <1>SPT=58405 DPT=443 SEQ=4030047175 ACK=0 WINDOW=14600 RES=0x00 SYN URGP=0 OPT (020405B40402080A00F8E2BB0000000001030304) 
Aug 13 12:40:30 ACCEPT IN=br0 OUT=eth0 <1>SRC=192.168.1.143 DST=my.pub.lic.ip <1>LEN=68 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=UDP <1>SPT=59568 DPT=36602 LEN=48 
Aug 13 12:40:30 ACCEPT IN=br0 OUT=eth0 <1>SRC=192.168.1.143 DST=my.wi.fi.ip <1>LEN=68 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=UDP <1>SPT=59568 DPT=46194 LEN=48 
Aug 13 12:40:30 ACCEPT IN=br0 OUT=eth0 <1>SRC=192.168.1.143 DST=my.wi.fi.ip <1>LEN=68 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=UDP <1>SPT=59568 DPT=46194 LEN=48 
Aug 13 12:40:30 ACCEPT IN=br0 OUT=eth0 <1>SRC=192.168.1.143 DST=my.wi.fi.ip <1>LEN=72 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=UDP <1>SPT=59568 DPT=46194 LEN=52 
Aug 13 12:40:31 ACCEPT IN=br0 OUT=eth0 <1>SRC=192.168.1.143 DST=my.wi.fi.ip <1>LEN=68 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=UDP <1>SPT=59568 DPT=46194 LEN=48 
Aug 13 12:40:31 ACCEPT IN=br0 OUT=eth0 <1>SRC=192.168.1.143 DST=my.wi.fi.ip <1>LEN=68 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=UDP <1>SPT=59568 DPT=46194 LEN=48 
Aug 13 12:40:31 ACCEPT IN=br0 OUT=eth0 <1>SRC=192.168.1.143 DST=my.wi.fi.ip <1>LEN=72 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=UDP <1>SPT=59568 DPT=46194 LEN=52

Note, “192.168.1.143” is the private IP of my Wyze Cam v2, and I replaced the public IP of the WiFi hotspot with “my.pub.lic.ip” and my WiFi IP address with “my.wi.fi.ip” because reasons.

What I was actually doing in the Wyze app to generate this traffic:

  1. Open the Wyze app on my phone (while connected to a public WiFi hotspot).
  2. Tap on my camera.
  3. Wait through the 3 steps of authentication/connection, now I can see the live stream from my Wyze Cam.
You can see from the logs that the first connection is from my camera to an Amazon server on port 8443 (according to Wyze, TCP 8443 = Cloud API).

Next, it contacts a different Amazon server on port 443 (TCP 443 = Cloud data transfer).

Third, it establishes a UDP stream directed to the WiFi hostpot’s public IP on port 33602 (UDP = Heartbeat and streaming).

Fourth, it attempts to start a UDP stream 6 times to my private IP on the WiFi hotspot (which as Keith noted will never work because that’s a NAT’d non-routable IP).

 

So the first 3 steps seem to line up with my actions within the app:

  1. Open Wyze app = perform auth/lookup via Amazon Cloud API
  2. Tap camera = download thumbnail/settings(?) via Amazon Cloud data transfer
  3. View live stream = UDP stream to public IP (routable)
But it does seem odd that it also tries to stream directly to my private IP as if I were on the same LAN as the camera. I wonder if matching private subnets on different LANs might confuse the camera into thinking it's on the same LAN as the phone. For example, most consumer routers use the 192.168.1.0/24 or 192.168.1.0/24 subnets, so if my camera is at 192.168.1.143 on my home network and I'm on my buddy's WiFi with an IP of 192.1.68.1.160, the camera might think I'm on the same subnet even though I'm on a completely different LAN.

If I can get a tcpdump of the actual packets I will, then I can see approximately how much data is actually being streamed from the camera vs from the AWS servers.

 


#31

Great stuff! I see all of the same communication in my logs. I’m still unsure how the traffic would work destined to the public IP from where you are originating. Traffic that is initiated from your Wyze cam to the public IP of the hostpot would not know how to get to your device, nor would it be part of an existing session to be allowed as part of a stateful session. That’s the piece I’m not fulling grasping. It appears the Wyze API acts as a middleman to tell the cameras what IP to try and talk to, but it seems the camera is initiating the connection directly to the end host, which seems as though that would always be a problem across the internet because of NAT and typical ACLs or security policies that block unexpected traffic initiating from the ‘outside’. However, every once in a while I’ll catch a one frame glimpse of my live feed before it fails again and goes through the ‘connecting’ steps again, so I’m not sure how that is even working with what we see in the logs.


#32

That UDP stream may be the reason why it’s so unreliable on remote networks. It’s my understanding that many routers will allow UDP NAT traversal when it’s first negotiated by a middleman server (Wyze Cloud API?) and each peer has sent at least one UDP packet to each other’s public IP and mapped NAT port. But I imagine many corporate firewalls would interfere with that.

I definitely feel like I’m missing an important piece and I don’t trust the level of detail in my router’s logs, so I’ll have to see if I can capture the packets (ideally on both ends) and analyze from there.


#33

All of a sudden I’ve seen an improvement in my remote viewing from remote wifi and LTE. Anyone else experienced the same?


#34

I would say that I had been experiencing the same improvement up until this morning. Suddenly I can’t download notifications or connect to the stream, but works fine via wifi and I am still getting alert push notifications. Not too sure what’s going on… I was tweeting with them a week or so ago and mentioned they should make some form of announcement but I have yet to see anything.

Tweet stated:
“We’re sorry, Brad. We’ve been looking into this but we don’t have the answer yet. If you’re still running into this, we would love to see app and firmware logs! I can send you instructions if you’re interested.”

So they are aware of it, but have not acknowledged via any of the forum posts from what I can see. It would be great to have a bit of transparency on the issue to know what they are doing and how we may be able to help.


#35

Yes my remote viewing started working a few days ago and still working great. Wyze must have done something on their end as I didn’t change anything I knew they would get it fixed.


#36

Great to hear! I think mine may even be working better on wifi internal, and remote viewing seems to work equally as good. I think they have corrected something as well.


#37

I had no difficulty setting up my WYZE Cam v2, but I couldn’t get my WYZE Cam Pan to work until I changed my WiFi security settings from the default WPA/WPA2-PSK TKIP/AES to WPA2-PSK AES. As soon as I upgraded security settings, my WYZE Cam Pan downloaded the latest software update, and has been working fine since.