Real Time Streaming Protocol (RTSP)

I would argue that this is not a solution - that means you need to setup 2 reservations, 2 port forwards, and if you use RTSP with another software solution (i.e. Zoneminder), you need 2 cameras with one being dormant for 90% of the time but only when the camera does not bind the DHCP address does it not cause an issue.

As I don’t know if it is caused upon reboot of the camera, or when the DHCP lease expires, it still leaves a pretty big issue from a security standpoint as well. I’m not worried about the MAC address spoofing, but more of the fact that if you open a port and another device then takes that IP address after the lease expires, that you then have a device with a direct port to the internet that is directly related to the Wyze cam.

1 Like

@ElectroStrong what firmware are you using? I though you actually wrote that but I couldn’t find it in a post. I am curious if this is an issue with both .40 and .41 of the RTSP firmware.

I will care to guess that ALL firmware has this issue, as I have a V1 that this happens to, so I don’t think it’s related to the RTSP firmware, but in fact that is where it counts the most - people are recording the RTSP stream and when the IP changes you get screwed. Unless @WyzeGwendolyn could confirm that this MAC issue was dealt with at some point with a firmware release or releases for all V1,V2,Pan…

@teredactle I have the .41 firmware (did document it above). I also believe this is an issue that’s been around for some time as I see posts on reddit that go back 2+ years on the topic :expressionless:

Completely agree with your argument. It seems the only simple solution for the time being is to switch from Wyze to Dafang Hacks so you can directly control the IP address.


I’m new to Wyze cams (just bought two Wyze Cam Pans) but have been long time user of Foscam cameras and planning to replace some of my older Foscams as they wear out with Wyze.

I was using the native firmware until I read about the RTSP firmware and just installed it yesterday and have some questions as to the configuration/use of it.

  1. How do I the change the RTSP port on the Wyze cam? It defaults to 554. I have two Wyze Cams and using Blue Iris and TinyCam Pro (Android phone), I can view them both while on the home Wi-Fi but if I want to view them remotely outside of the home, I need to open up ports. But my router (Netgear Orbi AX) doesn’t allow me specify two entries of 554 ports to be opened. For example, on my Foscam cameras, I have each Foscam camera on different port instead of the default 80 (e.g. 9000, 9001, 9002, etc.).

  2. Using Blue Iris, I noticed every few minutes, Blue Iris would briefly report “No Signal” for a few seconds on one of my Wyze cams even though I can have a continous ping going to the IP of the Wyze Cams and it hasn’t dropped a single ping. Blue Iris is running on a desktop PC that’s hardwired Ethernet. I am not seeing this issue with my Foscams.

  3. Is there a way to specify a configure a static IP on a Wyze Cam other than assigning a DHCP reservation on my router (Netgear Orbi AX)?


security concerns aside for a second, you shouldnt need to change the port of the cam from 554. just use a different WAN port on your router to forward from. e.g on your port forward have WAN port 30554 pointing towards internal IP port 554. then use your public ip / fqdn and port 30554 to access it externally.
in saying that, you wouldnt want to have any external port directly forwarding to your cam, because people will try to hack it and RTSP authentication is pretty simplistic. you especially wouldnt want to have a known port number (i.e. RTSP 554) forwarding from a public internet to your internal camera. set up some endpoint security or something to protect the RTSP channel. many routers have basic VPN setup that may work better than a port forward in this case.

That’s half right. David is already willing to expose his cameras, and there is password security for each cam as far as I understand. The other omission to your point is that he can redirect two different WAN ports, e.g., 30554 to camera 1 port 554 and 30555 to camera 2 port 554.

Also, I suspect that with the Dafang version you will be able to set a different LAN listening port on the camera if desired.

As to uptime, I finally tried TinyCam and I still can’t keep a reliable stream to my camera more than 10-15 hours at best. (Not using RTSP mode yet.)

@dtay_us, in short

2.Poorly written code for the RTSP implementation by the developers
3.No and even with IP reservations it’s not guaranteed due to how the firmware is written and the bootup process.

Sorry for the bad news. All of the above though, ironically, would be doable with 3rd party/hack firmware, that’s already been mentioned. It’s ironic because these are basic expected options when implementing RTSP, but the RTSP implementation from wyze is unsupported.

we obviously have a different perception of “security”.

RTSP is a plain text password with an unencrypted stream. its very easy to hack if you can be bothered. if you expose this flaky security mechanism directly to the internet, you may as well pull your blinds up with the lights on at night. there are way too many bored people online that can be bothered trying to hack you just for kicks.

and as to your second point on using two different WAN ports, this is exactly what I was saying when I also used the words different WAN port.

I don’t get the additional point you are trying to make, but if that’s your value add then thumbs up. just don’t go misinforming people on security, because it will end up being their problem, not yours.

I thought I read that the Netgear router you have supports openVPN, so set up a server and when you need, VPN in to home and you don’t need to mess around with port forwarding etc.

With all due respect, bull. Your obscure port idea is insanely less secure than simply having a decent password. And you didn’t mention using the second WAN port, so I was trying to fill in what you had left out of your otherwise valid suggestion. I’ve quoted you below for reference - your use of “different” was between the local and WAN port numbers, not two different WAN port numbers. So your latest assertion is simply a lie.

Additionally, you really think the “bored people” are unlikely to hammer at a service they found running on port 30554? The hits on my obscure port ssh servers say otherwise. (Fail2ban is your friend.). Your second post is making misinformed and dangerous assertions. You really shouldn’t do that. The poster to whom you responded already had Foscams and Blue Iris and was well aware of how RTSP worked and what he or she did and did not want exposed over the Internet. A VPN tunnel would be helpful but may not be strictly required for him or her.

I dont know why I am bothering to reply since you obviously lack the self awareness to see the gaps in logic of your own argument, but here goes.

firstly, you talk about “due respect”, but it was your lack of respect that prompted me to reply in the first place. security is generally not a right or wrong answer, its a risk position. your presumption in taking the intellectual high ground and making determinations on what is ‘right’ or ‘half right’ is the only dangerous assumption being made by anyone here.

me talking about the single example of using different port numbers in a forwarding rule assumes that one can make the connection between having multiple concurrent port forwards active on the same router. if you feel the need to specify that this can be done multiple times when I didnt call it out, then youre really dumbing down the conversation and assuming people are at a beginner level.

but at the same time, you seem to assume that everyone here knows the details of the RTSP protocol in that they know its unencrypted with plain text authentication, so all the sudden the audience you determined is people who dont know how to port forward between non-matching ports, yet know RTSP well enough to validate it’s level of security and put it on the open internet. you see where I am going here?

then you also assume that I am saying there should only be a different port and no authentication. the whole time I have been talking about hacking, and plain text passwords… so why would I suddenly be saying there should be no authentication on an unencrypted video stream with just an obscure port number as the only measure of security? its not hacking if you simply discover someones video stream, the “hack” implies needing to break into something, therefore having an existing authentication mechanism in place.

there are a lot of bored people out there. many people all over the world are stuck at home due to the COVID-19 pandemic (hint: I am one of the ones in COVID lockdown, which is why I have time to waste on you), and my snort server shows all manner of bizarre intrusion attempts. I also know for a fact that there are script kiddie apps for hacking RTSP streams that search networks and brute force the plain text passwords. what I am trying to say is that you can never be too careful, since RTSP is not considered a secure protocol. there is no misinformed or dangerous assertion there, its simple fact.

the only person here that “shouldnt be doing” something, is you giving people bad lessons in security. at the end of the day, I will be fine being overly cautious (if thats how you view it), whereas people that listen to your contradictory nonsense may end up with some real life problems as a result.

Sir or madam I wasn’t disrespecting you at all, just trying to point out that your well intentioned suggestion was incomplete. You seem to have taken somewhat ridiculous offense at the thought that your post was only “half right” (the only remotely critical part of my first response), but carry on then. Nice wall of words though.


Thanks for the feedback. The comments were insightful and definitely constructive.

I discovered that I didn’t have to deal with the port 554 issue. In Tiny Cam Pro, when I set up the Wyze cams via the Cloud settings and then check the camera status option in the app, it actually shows me the settings of the ports being used:

Advanced info:
P2P mode - LAN
Camera IP;
Camera Port: 4xxxx

Second Wyze Cam Pan:

Advanced info:
P2P mode - LAN
Camera IP;
Camera Port: 3xxxx

When I added those ports into my router, it worked! Since they’re unique, I have less worry than the standard default 80/554 settings that most IP cams have.

I am still able to use my Echo Show to view the camera (“Alexa, show me kids playroom”) even with the RTSP firmware installed and I was surprised that it still allowed me to set it up as a cloud based configuration on TinyCam Pro. I had the impression that the RTSP firmware would have disabled all these features? Best of both worlds?

Blue Iris still worked (even though it still intermittently reports “No Signal”) and I was also able to connect my Synology NAS Surveillance Station to the Wyze Pan Cams.



That’s great news then. Yeah the big bonus of the Wyze RTSP firmware (versus Dafang) is that it keeps the Wyze side operational too. I’ve seen mixed reports on the whole thing. Good luck with it.

Last heads-up - I may have found a way around this if you’re using Windows Server for DHCP. In the DHCP scope you can setup Policies that are applied to a scope. With this I have been able to setup 2 MAC addresses for the same IP address :slight_smile:

In my situation, the secondary MAC issue happens when the DHCP lease expires. By setting a policy that uses both addresses, I have been able to solve the IP address issue that we documented earlier in this thread.


That is a great workaround - thanks! Of course few people will be running Windows Server at home, but still.

I wonder if extremely long lease periods would be similarly effective.

1 Like

It looks like you may be able to do it with dhcpd as well:

1 Like

Some great workarounds (and thanks for posting) to an issue that should not even exist and is in my opinion very poorly written firmware.

The wifi IC has a built-in MAC address in the hardware. The firmware changes that on startup to one in Wyze’s registered MAC address block, but apparently something can cause the wifi IC to reset. This then resets the MAC address back to the hardware-coded one. That the firmware isn’t catching the reset and re-applying the change is annoying, but nothing insurmountable. And a reset will fix it, so it’s not that bad.