Interesting. Haven’t tested it with internet blocked so far except once and it completely fell offline with continual problems until I re-enabled it and then no more problems.
Might be certain settings affect it. (I’m not reading all that above lol. 559 posts just to see if someone mentioned something there, no thanks. Will test it again when I get around to it.)
All the more reason for Wyze to release a ‘no internet’ version of the V3 RTSP firmware then. At least we can ensure the vulnerability doesn’t affect us by walling off the camera, especially if they haven’t/won’t patch that version…
I don’t know how many RTSP users are out there but I’m sure not getting any more unless this is done. At least with other (supposedly less secure) Chinese manufacturers RTSP = RTSP.
ive disabled internet access through my router for the v3 w/rtsp fw, still working as normal w/blue iris and the android app ip cam viewer(v7.4.6). was still working through the wyze app up until i power cycled the cam, then the wyze app states cam is offline.
blue iris and ip cam viewer still working though
I’m unable to locate the v3 RTSP firmware. The Wyze support pages seem to be down. Anyone know where I can locate the firmware?
And now Wyze is forcing us to log into Zendesk to see their support article. Looks like the RTSP page is behind this wall now. What a terrible company.
I just tried the original link for 4.61.01, and it worked for me:
https://download.wyzecam.com/firmware/rtsp/demo_v3_RTSP_4.61.0.1.zip
The current version is 4.61.0.3, but maybe if you install .0.1 it will upgrade itself afterward.
Interesting. I’m even logged in to the support area, but still can’t access any of the RTSP firmware support articles.
what if you just click the link I posted above?
Would also have the RTSP URL info used with the v3?
Clicking the link above in Chrome on a Win10 laptop directly invoked the Win interface option to choose a download destination for the 4.16.0.1.zip file from an about:about URL. No other web interface, link, or landing page involved. Took a few seconds to resolve, but the file is there and accessible directly – al least today about 60 seconds ago.
RTSP firmwares don’t update OTA, you have to manually apply the updates.
You need to download them first.
I’ve never tried this, but one idea that might work is to use multiple DynDNS accounts, e.g. myDNS1.dyndns.org, myDNS2.dyndns.org, etc., all behind the same public IP.
Then you could have myDNS1.dyndns.org:554 forwarded to 192.168.1.101:554, myDNS2.dyndns.org:554 forwarded to 192.168.1.102:554, etc.
It would require a more sophisticated router, but that’s how a lot of virtual web hosting works.
But, as I said, this is just an idea, and I’ve never tried it.
FYI. in blue iris i kept loosing video feed and would just show the last image b4 video loss and would have to restart camera via blue iris.
enabling watchdog in blue iris would enable reconnects to camera but i noticed alot of disconnects. noticed this issue when i moved camera outdoors making it further away from my router. got closer to the camera using my old wifi router connected to my main router,
hardly a disconnect since but i kept watchdog enabled to reconnect.
wyze v3 cameras have a weak wifi signal imo
I’m new to these cams and bought 4 Wyze Cam v3s specifically for their RTSP possibilities and still getting my feet wet. Stumbled across this thread in the process of searching for info and welcome any additional resources of substance on the subject. Seems like everyone is a Beta Tester Expert with a thread.
And this was actually intended as a reply to the deleted post by SeaStream offering some additional support to the successful operation of the RTSP cams without the requirement of constant connectivity to the Wyze cloud.
Anyway, here’s my two cents on the Cam v3 RTSP functionality in an isolated LAN environment. Testing was pretty basic. Set up cams with cloud support (as is absolutely necessary for initial configuration and registration of the devices). Physically disconnect my router from the broadband modem and turn off data service on my Android device containing the Wyze Android app to eliminate any possible way for the devices to call home for anything whatsoever.
RTSP still functions without internet connectivity on a Wyze Cam v3 using the 4.16.0.1 firmware, – as it should, actually. The Android app also still provides RTSP viewing and limited local functionality.
Provisioned RTSP Cam v3s are recognized and can be added to and managed by third party platforms to the extent of the particular platform’s capabilities. My particular exercise was done with TinyCamPro on a v.5 Firestick. Doesn’t get much more basic.
Cameras will survive a soft reboot (power cycle) and eventually come back online, but are desperately looking for a time server for obvious reasons. They will initially display the date and time they were first provisioned and valiantly try to make sense of that for another reboot or two. In my case, they eventually displayed the correct date (which was likely residual), but still needed NTP sync from somewhere (probably anywhere) to ultimately stabilize. They locked right in once they saw a valid NTP source. Would be interesting to know how often that’s required since they are obviously allowed to drift to the extent of having a ‘sync’ feature available in the supporting app/firmware. Regardless, providing a NTP source would be trivial.
Aside from the NTP issue and the occasional firmware upgrade (ahem…), there doesn’t seem to be any obvious reason why the RTSP firmware cams can’t operate independently and indefinitely on private LANs supported by third party solutions.
Has anyone snooped the queries from the cameras? I’m running pfsense 2.4.4 as my edge router, and it has an NTP server built in (you just have to turn it on). If I knew what it was asking for, I’m could probably spoof an NTP response from my pfsense box, and that might make it happy.
Shouldn’t need to spoof anything. A NTP server on the internal network should work if all the cam needs is a response to a query…, unless it’s looking for a specific source. Network Time Protocol (NTP) (Building Internet Firewalls, 2nd Edition)
I wanted to do more testing so I deleted it 
There should be no reason why they can’t since rtsp is meant to be local here.
But, I’m having difficultly getting it to stay working while fully blocking the internet. Rtsp dies within 24 hours if I fully block it.
It might be that I’m blocking too much so am currently trying to test rtsp ports open with those defined.
For some reason, I block the ports here that should connect to the server and Wyze app will continue to connect remotely so am not fully sure what’s going on there. If I take a wide range, it gets blocked. https://support.wyze.com/hc/en-us/articles/360031479511-What-ports-are-necessary-for-Wyze-Cams-to-operate-
(I see someone above shows an 8883 which isn’t on Wyze list there.)
However, rtsp stays working for many hours so I would have expected that its not being blocked. Either way, with the current test, I can reopen rtsp and it works while remote is blocked. So will see what happens probably tomorrow.
It is difficult to say what ports people are letting through as well or whatever and how that’s interacting. If internet is blocked then remote viewing of the cam from cellular data connection shouldn’t happen.
If you’re saying that you remove the outside modem and it keeps working then its likely that I’m getting too much blocked and for whatever reason, its allowed for x amount of hours despite remote not being this way.
However, disconnecting the modem, you will have all ports still functioning. That’s a bit of a different thing. Most people cannot disconnect their internet so the router must block the device. Somewhat invalidates the test.
If you get it to stay working while still having an outside internet connection on the network, let me know how or don’t. Your choice.
By the way, I’m not competing with you as to who’s right and who’s wrong. Just not doing testing that way and I know what I see. Your test is valid under that use. That’s fine. Its good to know 
(Also my test has a router in between and a router at the internet. The cam is connected to the AP router and blocked ports at the internet one. This could also change the results in theory.)
Further info to validate: I rebooted the router and rtsp still works. Remote does not. Thus local only. Tomorrow, will know for sure. As it stands, rtsp is not blocked. If I was wrong previously or not, will update this post, just below this line.
I adjust the ports further to increase openness and it already went offline. Going to try with the other router.
You need some way to tell the camera what NTP server to look for. Which there’s no way to specify with the RTSP beta.
I ran Wireshark once to see what traffic the cam generated, There’s a long list of common NTP servers that they attempt to access when they can’t get to one. I’d have to look again to get the exact list but most are fairly common. So should work assuming that pfsense can redirect a host name (e.g., time.google.com) back to a lookup request from within the network.
