Internet access required ?

rickgitdone commented 2 years ago

I installed the SD CARD made all the rtsp edits and booted up ... seems this still requires access to wyze for authorization before anything else works?

Is this possible to run local only on home subnet w/o any Internet access to the CAM?

gtxaspec commented 2 years ago

as far as I know, yes internet access is required. I haven't done any testing without internet access at all.

shamlord commented 2 years ago

For setting up without the Wyze App, it may be possible. This thread has some details on the QR code setup process: https://github.com/HclX/WyzeHacks/issues/146

As for offline use, I've been working to set up my four v3 cams with wz_mini_hacks today. Unintentionally, they did have internet access until just about 30 minutes ago. I didn't realize that adding another interface to my router for this second network would automatically created PASS rules to WAN until this thread prompted me to double check.

I have my cameras on a dedicated wifi network that has no access to my main network or the internet. I plan to grab the most recent updates tomorrow (RTSP sub streams? Awesome!) but I'll report back if they get into reboot loops. My cameras currently have firmware 4.36.9.131 loaded internally.

rickgitdone commented 2 years ago

my hope is setup wifi with config file and launch the rtsp server v4l2rtspserver and ssh server ( dropbear) and leave iCamera and all the monitor processes down to allow local only system... wired ethernet is good also ...

gtxaspec commented 2 years ago

currently wz_mini needs iCamera. We hook the functions coded inside of iCamera to pass video to the rtsp server, so all the magic is done inside iCamera, without it nothing works. You could look to the T31 SDK to program your own video program, but that is outside the scope of this project.

shamlord commented 2 years ago

Just following up on my isolated camera network experience.. The cameras functioned overnight after being cut off of IP or DNS access. This afternoon I updated the cameras to use the more recent build of wz_mini_hacks available earlier today, and afterwards they cycled between streaming RTSP and not. Mostly not.

After giving the cameras IP and DNS access again, they stayed online.

If there is any way to spoof iCamera into not rebooting the cameras repeatedly without internet access that would be neat.

evanheckert commented 2 years ago

Very interested in this as I'll be using this in a vehicle.

gtxaspec commented 2 years ago

I will run a test on a spare camera, and see if I can examine the logs to see what it uses as a check for internet access to prevent reboots.

gtxaspec commented 2 years ago

does anyone have an approximate time (hours?) of when the camera will reboot?

gtxaspec commented 2 years ago

quickly checking the logs...

May 16 16:42:45 iCamera: [init.c:565]gateway recovery ok...
May 16 16:42:46 iCamera: [DN:829]err: (getaddrinfo) fail:-2(Name or service not known), (domain: www.google.com)
May 16 16:42:46 iCamera: [netservice.c:896][test_conn_cloud_by_url]err: get_ip_addr_by_domain fail:1
May 16 16:42:46 iCamera: [DN:829]err: (getaddrinfo) fail:-2(Name or service not known), (domain: api.wyzecam.com)
May 16 16:42:46 iCamera: [netservice.c:896][test_conn_cloud_by_url]err: get_ip_addr_by_domain fail:1
May 16 16:42:48 iCamera: [DN:829]err: (getaddrinfo) fail:-2(Name or service not known), (domain: www.google.com)
May 16 16:42:48 iCamera: [netservice.c:896][test_conn_cloud_by_url]err: get_ip_addr_by_domain fail:1
May 16 16:42:48 iCamera: [DN:829]err: (getaddrinfo) fail:-2(Name or service not known), (domain: api.wyzecam.com)
May 16 16:42:48 iCamera: [netservice.c:896][test_conn_cloud_by_url]err: get_ip_addr_by_domain fail:1

so if anyone wants to try these commands via ssh:

echo -e "127.0.0.1 www.google.com\n127.0.0.1 api.wyzecam.com" > /tmp/hosts ; mount --bind /tmp/hosts /etc/hosts

and see if the camera stays up

shamlord commented 2 years ago

It's much less than an hour. If the camera starts up and does not have internet access, it seems to reboot almost constantly.

I just cut off access and rebooted an easy to access camera. Once I can get into SSH on the camera I'll give this a shot.

shamlord commented 2 years ago

I can't seem to get the camera to even respond to pings, let alone allow me to SSH in.

I just added the commands to the end of run_mmc.sh to see if that works.

gtxaspec commented 2 years ago

no pings even on LAN? hmm... can you share the run_mmc.log in the log dir when you have a chance?

shamlord commented 2 years ago

Its odd, after one power cycle the camera started responding to pings almost immediately. After another, it didn't start responding to pings for several minutes, responded to about 20 pings, then stopped responding again. I was able to SSH in long enough during another window of responsiveness, but the connection dropped before I could do anything.

I just pulled the SD card and grabbed the requested log: run_mmc.log

shamlord commented 2 years ago

I'm looking through the log and if I read this correctly:

+ grep 'inet addr'
+ ifconfig wlan0
          inet addr:10.42.0.190  Bcast:10.42.0.255  Mask:255.255.255.0

The camera is being configured with an IP not in my network's range. I'm using 192.168.2.0/24. This specific camera has a DHCP reservation for 192.168.2.17, which does show up later in the logs.

gtxaspec commented 2 years ago

can you check your router? maybe there is a stale dhcp static lease or something. perhaps you can check the logs too to see if and why it's giving out that 10.x ip.

shamlord commented 2 years ago

Its similar to an IP range I used years ago (10.42.69.0/24 .. heh) but I currently use 172.16.0.0/16 for my home network and 192.168.2.0/24 for my camera network. I have confirmed the ranges on my router's DHCP server (pfSense), and both of my Wifi APs are Asus routers in AP mode running the Merlin firmware.

A DHCP diagnostic utility on a windows laptop connected to my camera Wifi is not getting replies, interestingly, so I'm troubleshooting that now.

Edit: Still troubleshooting. I think it is an issue with the AP I'm using for the cameras.

Edit 2: Not my Wireless AP. On my Linux machine, apparently Network Manager will assign the address 10.42.0.1 to any network adapter that's active but not configured for DHCP or Static addressing, and then responds to DHCP requests from that address. This is without dhcpd installed. Jeez. I'll get back to you later regarding the camera rebooting issue.

shamlord commented 2 years ago

Its been a few months, but this thread is interesting with regard to the camera failing to stay online based on DNS and NTP connection failures: https://forums.wyzecam.com/t/wyze-cam-v3-connection-time-out-during-setup-when-ntp-being-forwarded/150908/3

shamlord commented 2 years ago

so if anyone wants to try these commands via ssh:

echo -e "127.0.0.1 www.google.com\n127.0.0.1 api.wyzecam.com" > /tmp/hosts ; mount --bind /tmp/hosts /etc/hosts

and see if the camera stays up

I added this to the end of run_mmc.sh on one camera, it caused it to frequently drop its connection. The camera would drop 2-3 pings once every 15 to 20 seconds. The log file run_mmc.log just shows Blue Iris repeatedly reconnecting.

I removed this line and rebooted the camera, it hasn't dropped since. My other cameras have not been restarting, but were not blocked from WAN.

gtxaspec commented 2 years ago

this was for a camera with LAN access, but no internet right?

shamlord commented 2 years ago

Yes. It has the same behavior with internet access as well.

gtxaspec commented 2 years ago

i'll do more testing, but heres what i did:

start camera up with network, then change dns server to 0.0.0.0 to simulate internet down

camera pings LAN, RTSP works, but no internet access in or out of the camera.

run echo -e "127.0.0.1 www.google.com\n127.0.0.1 api.wyzecam.com" > /tmp/hosts ; mount --bind /tmp/hosts /etc/hosts

check 4 hours later, camera still online, rtsp server still working.

shamlord commented 2 years ago

On my network, the camera seemed to drop its connection every 15-20 seconds, but I think now that it does not actually reboot. My SSH connection would freeze, but then seemed to start responding again after a few moments. The connection would not drop, and whatever I was doing was not lost (i.e. nano was still running with run_mmc.sh open). Its possible the camera may be disabling and reenabling its interface or something similar.

The way I blocked the camera's access was in the router, disallow everything from the camera network except the camera's access to the router's IP on that network (192.168.2.1). DNS would still be working, but the camera would not be able to make a ICMP, TCP or UDP connection to anything outside of the network.

I can do some more troubleshooting tomorrow.

shamlord commented 2 years ago

There is a huge thread on the Wyze Forums about using the RTSP firmware and isolating the cameras from the Internet, what they try to access, and the experiences people have had trying to run the cams without Internet access: https://forums.wyzecam.com/t/beta-testing-for-wyze-cam-v3-rtsp-firmware-now-available/196922/622

I tried the following so far today. The router interface the cameras are attached to is set to default DENY all traffic except for what I have allowed for each test. After making a change to my firewall rules, the camera was restarted with the reboot command via SSH. When the cameras disconnect, they are unreachable for about 3 to 5 seconds.

Test 1:

Allow only UDP 123 from the cameras to WAN (No DNS or anything else) Result: Cameras drop connection about every 60 to 70 seconds

Test 2:

Allow UDP 123 from cameras->WAN
Allow All ports/protocols including DNS to the router's IP (but nothing to WAN) Result: Cameras drop connection about every 4 minutes

FWIW, here are the NTP servers the camera tries to reach. I've not had success yet redirecting them to my router's NTP server via the hosts file on the camera. The hosts file does redirect the name resolution for the NTP servers but timesync fails to sync the time. The hostnames are hardcoded into the /system/bin/timesync binary:

clock.fmt.he.net
ntp0.cornell.edu
time-a.nist.gov
time.windows.com
time-b.nist.gov

I pkilled the timesync process and restarted it to capture the following output, ending with me allowing NTP access again and the process syncing the time. timesync.log

The camera apparently also tries to make connections to the following additional addresses based on the router/DNS log files of a few other users in the thread linked above:

api.wyzecam.com
wyze-membership-service.wyzecam.com
wyze-general-api.wyzecam.com
www.google.com
kinesisvideo.us-west-2.amazonaws.com - possibly for video processing or machine vision
wyze-iot.s3-us-west-2.amazonaws.com - retrieving/storing something in an S3 bucket
c1ybkrkbxxxxxx.credentials.iot.us-west-2.amazonaws.com
m-756xxxxx.kinesisvideo.us-west-2.amazonaws.com
r-fd5xxxxx.kinesisvideo.us-west-2.amazonaws.com

The addresses with the "xxxxx" at the beginning of the domain were partially redacted as the commenter was worried they might uniquely identify them.

I'm not super familiar with the Wyze cameras, but I'm learning as I go. If you have any insight that might help point me in a troubleshooting direction that would be neat. To get these camera's truly offline I think they will at least need to be redirectable to a local NTP server, and then their connections to other web services would need to be redirected to a lightweight web server (nginx, Lighttpd, etc) supplying the camera firmware with whatever response makes it happy.

shamlord commented 2 years ago

Something I forgot to add. According to Wyze documentation, the cameras need the following access to the Internet:

shamlord commented 2 years ago

Interesting.. I see that according to that table they want TCP 123 not UDP. Oof. Let me try that again..

EDIT: Nope.. setting the following in my camera's hosts file:

192.168.2.1 clock.fmt.he.net
192.168.2.1 ntp0.cornell.edu
192.168.2.1 time-a.nist.gov
192.168.2.1 time.windows.com
192.168.2.1 time-b.nist.gov

And allowing both TCP and UDP access to port 123 causes the following output from timesync:

[root@WCV3-NUM4:etc]# pkill /system/bin/timesync; timesync
[timesync_utility.c:ip_validate::69] ip address obtained

[main.c:time_sync_process::276] time sync process running!
[main.c:time_sync_ntp::65] ntp_worker_handler time_zone:21600
[main.c:time_sync_ntp::106] ntp ip: 192.168.2.1
[main.c:time_sync_ntp::106] ntp ip: 192.168.2.1
[main.c:time_sync_ntp::163] two consecutive ntp requests differ more than 15 minutes, try next NTP server!
[main.c:time_sync_ntp::106] ntp ip: 192.168.2.1
[main.c:time_sync_ntp::134] select timeout
[main.c:time_sync_ntp::106] ntp ip: 192.168.2.1
[main.c:time_sync_ntp::134] select timeout
[main.c:time_sync_ntp::106] ntp ip: 192.168.2.1
[main.c:time_sync_ntp::134] select timeout
[main.c:time_sync_ntp::106] ntp ip: 192.168.2.1
[main.c:time_sync_ntp::134] select timeout
[main.c:time_sync_process::293]  try 1, ntp_worker_handler() failed:-1
[main.c:time_sync_ntp::65] ntp_worker_handler time_zone:21600
[main.c:time_sync_ntp::106] ntp ip: 192.168.2.1
[main.c:time_sync_ntp::134] select timeout
[main.c:time_sync_ntp::106] ntp ip: 192.168.2.1
[main.c:time_sync_ntp::106] ntp ip: 192.168.2.1
[main.c:time_sync_ntp::134] select timeout
[main.c:time_sync_ntp::106] ntp ip: 192.168.2.1
[main.c:time_sync_ntp::134] select timeout
[main.c:time_sync_ntp::106] ntp ip: 192.168.2.1
[main.c:time_sync_ntp::134] select timeout
[main.c:time_sync_ntp::106] ntp ip: 192.168.2.1
[main.c:time_sync_ntp::134] select timeout
[main.c:time_sync_process::293]  try 2, ntp_worker_handler() failed:-1
[main.c:time_sync_process::308] ntp synchronization failed after 2 try(s), consecutive failure: 1
[main.c:time_sync_process::346] ntp failed, checking the time from the checkpoint file!
[main.c:time_sync_process::351] file_extracted_time: 1652912161 read from the checkpoint
[main.c:time_sync_ntp::65] ntp_worker_handler time_zone:21600
[main.c:time_sync_ntp::106] ntp ip: 192.168.2.1
[main.c:time_sync_ntp::106] ntp ip: 192.168.2.1
[main.c:time_sync_ntp::134] select timeout
[main.c:time_sync_ntp::106] ntp ip: 192.168.2.1
[main.c:time_sync_ntp::134] select timeout
[main.c:time_sync_ntp::106] ntp ip: 192.168.2.1
[main.c:time_sync_ntp::134] select timeout
[main.c:time_sync_ntp::106] ntp ip: 192.168.2.1
[main.c:time_sync_ntp::134] select timeout
[main.c:time_sync_ntp::106] ntp ip: 192.168.2.1
[main.c:time_sync_ntp::134] select timeout
[main.c:time_sync_process::293]  try 1, ntp_worker_handler() failed:-1
[main.c:time_sync_ntp::65] ntp_worker_handler time_zone:21600
[main.c:time_sync_ntp::106] ntp ip: 192.168.2.1
[main.c:time_sync_ntp::106] ntp ip: 192.168.2.1
[main.c:time_sync_ntp::134] select timeout
[main.c:time_sync_ntp::106] ntp ip: 192.168.2.1
[main.c:time_sync_ntp::134] select timeout
[main.c:time_sync_ntp::106] ntp ip: 192.168.2.1
[main.c:time_sync_ntp::134] select timeout
[main.c:time_sync_ntp::106] ntp ip: 192.168.2.1
[main.c:time_sync_ntp::134] select timeout
[main.c:time_sync_ntp::106] ntp ip: 192.168.2.1
[main.c:time_sync_ntp::134] select timeout
[main.c:time_sync_process::293]  try 2, ntp_worker_handler() failed:-1
[main.c:time_sync_process::308] ntp synchronization failed after 2 try(s), consecutive failure: 2
[main.c:time_sync_process::346] ntp failed, checking the time from the checkpoint file!
[main.c:time_sync_process::351] file_extracted_time: 1652912161 read from the checkpoint
[main.c:time_sync_ntp::65] ntp_worker_handler time_zone:21600

mrlt8 commented 2 years ago

Have you tried disabling all motion/sound detection/recording/notifications? Each of those events probably tries to phone home.

From what I can tell the problematic one is probably AWS IOT core (MQTT on 8443) which is also what all the unofficial wyze SDKs use to communicate with the camera over the wyze web api.

shamlord commented 2 years ago

Thank you! I never set up any detection rules, but I have just gone through and checked/set the following on each camera:

Detection Settings -> Detection Zone: Off
Event Recording    -> Detects Motion: Off
Event Recording    -> Detects Sound: Off
Event Recording    -> Smart Detection -> All: Off
Notifications      -> Notifications: Off
Alarm Settings     -> All: Off
Rules              -> None
Sharing            -> None

Some of the cameras did have Event Recording and Smart Detection enabled. Annoying since with each new camera it prompts you to start a Wyze Plus trial and I don't see a way to opt out.

I'll try isolating the cameras again to see how they react with their new settings.

mrlt8 commented 2 years ago

Actually, I wonder if touch /tmp/aws_iot/rooCAok might be enough to keep it from looping?

capncybo commented 2 years ago

So Just to clarify... Does this problem STILL affect the cameras EVEN if using them in WebCam mode???

gtxaspec commented 2 years ago

webcam mode disables everything. it's just a plain dumb webcam

capncybo commented 2 years ago

Well then, That's Fantastic... It's readily available, fairly in-expensive, & unlike most webcams has a speaker built-in. Nearly Perfect for say a Raspberry PI or such a computer. Although I'm not "YET" sure if the camera's speaker would be accessible via WebCam mode...

rickgitdone commented 2 years ago

have you tested web cam mode without internet access? if we could get the mode set and run the rtsp server we'd have an offline cam ...

gtxaspec commented 2 years ago

webcam mode does not work with rtsp as it does not run iCamera.

rickgitdone commented 2 years ago

EDIT: only V2 or Pan can be loaded with WebCam firmware per Wyze... V3 is a no go. I have a V3

in webcam mode does ssh also not come up?

process shows rtsp server using /dev/video1 454 1 root S 83144 88.8 0 1.9 /media/mmc/wz_mini/bin/v4l2rtspserver -C 1 -a S16_LE /dev/video1,hw:Loopback,0 -U noadmin:noadmin -P 8554

** when I look at the processes it looks like rtspserver relies on /dev/video1 to stream

I believe iCamera sets up the GPIO and some hardware during its startup... the kernel should load the devtree ( hopefully )

if we get the hardware up and /dev/video1 available we possibly can get the rtsp server to run?

gtxaspec commented 2 years ago

webcam mode switches the USB mode in the camera to client mode, which means no network access at all to the camera unless you have a dhcp server running on your PC, most people don't. so no ssh .

webcam mode does not provide access to the video stream, so loading the loopback module for /dev/video1 won't work either. simply put, webcam mode works as a plain USB video class webcam, only.

these camera's use a unique implementation for video using ingenic's libibmp. iCamera uses the library to create 3 "framesource" nodes in /dev, /dev/framechan0 1 and 2. these are locked by mutex to iCamera.

iCamera does all the setup. Without it, we have no video. in webcam mode, there is no iCamera, but "uCamera". uCamera does all the setup for the video and USB magic.

gtxaspec commented 2 years ago

I don't run my camera's offline, so I am not too familiar with what everyone is trying to achieve here. What i understand is:

Desire to run these cameras on a local LAN, with no internet access
Access the RTSP streams on the camera from another device on the LAN

But, there are some blockers to achieving the above:

the camera from reboots automatically after x amount of time due to lack of internet access
packet loss ( from cpu load?) due to lack of internet access

is this correct?

capncybo commented 2 years ago

I can't speak for everyone but... -If you can somehow "prevent these camera's from automatically rebooting" after the NO-internet time-out that would be HUGE. I think some people may be trying to avoid the WYZE eco system & subscription services. And It would be really nice if we could use these devices independently without a continuous internet connection. What many companies forget is... their devices & the customers are often still around after a cloud-based service is terminated. And these types of devices are effectively made useless. Unless Modified or upgraded to work independently.

Curious... as to why (or if) CPU Load increases dramatically with a lack of internet access. Is it because the Cameras become super busy trying to use WYZE remotely hosted options & upload data etc???

mrlt8 commented 2 years ago

Has anyone tried touch /tmp/aws_iot/rooCAok? I'm pretty sure it's the camera trying to pull the AWS certificates since those get removed and pulled at every boot.

gtxaspec commented 2 years ago

I'll test it tonight

shamlord commented 2 years ago

I don't run my camera's offline, so I am not too familiar with what everyone is trying to achieve here. What i understand is:

Desire to run these cameras on a local LAN, with no internet access

Access the RTSP streams on the camera from another device on the LAN

But, there are some blockers to achieving the above:

the camera from reboots automatically after x amount of time due to lack of internet access

packet loss ( from cpu load?) due to lack of internet access

is this correct?

For me, this is correct.. though I do not know if the packet loss is due to CPU load or something else.

There is some speculation on forum threads I've read about the camera possibly resetting its interface or rebooting when it doesn't have internet access. Those users would have been likely using the official Wyze RTSP beta firmware so the root cause may not be the same.

It begs the question, why go through all the effort of cobbling together a RTSP solution out of a Wyze cam rather than just buying another camera that readily supports RTSP or ONVIF without all the trouble. For me, nothing matches the image quality and flexibility of the Wyze cameras in their tiny size. Last but not least, the window mount for these cameras is the number one reason why I chose the Wyze v3. I have to move with my job and they are so much easier to set up and take down than a bunch of wired bullet or dome cameras.

The problem is I do not want these cameras anywhere near the internet unless it is through my NVR and VPN.

virmaior commented 2 years ago

What's weird is that I've had my 5 V3s running without internet for months until this project came along. So this must be version dependent (my cameras are on 4.36.2.5). So what version started generating this requirement?

shamlord commented 2 years ago

I don't know from personal experience which version started causing this, My cameras came with a fairly new firmware as I bought them recently. I would like to try older versions to see if they do not have this issue, but Wyze took them down.

Edit: Seems like the links were just removed, most of the files are still there.

virmaior commented 2 years ago

I can confirm that they keep recording and don't die without internet at least through 4.36.2.5 ... but mine were running wyzeHacks and something breaks on versions of wz_mini_hacks after the 2022-05-12 where it says "waiting for wlan0 ..." (This could be an incompatibility arising from wzyeHacks + wz_mini_hacks )

I think versions after 4.36.3.18 have the new root password, which made wyzeHacks unusable, but this has no impact on wz_mini_hacks

gtxaspec commented 2 years ago

@virmaior, can you confirm on 4.36.2.5 cam had WLAN, just no internet access?

virmaior commented 2 years ago

yes most definitely. Isolated non-internet connected wifi wlan.

using wyze_hacks, I was downloading the video every hour to process (https://github.com/virmaior/zakkun-the-wyze). primary issue was having to manually set the time if the cameras ever rebooted. Been running this way since February and wyze's forced firmware attempts. Two cameras still not switched over to direct usb are still running this way right now.

obviously no access to the cameras via wyze app when running in non-internet connected mode. they do seem to aggressively re-request DHCP leases so I've actually got my router restarting wifi every day at noon (my application is for a nocturnal flying squirrel so that's the time he won't be awake!)

rickgitdone commented 2 years ago

so I also downloaded 4.36.2.5 firmware and reloaded it as a downgrade and can confirm where I have blocked internet access and the Camera stays up... there are consistent times when ping responses goes from milliseconds to seconds and then back to milliseconds periodically however the Cam doesn't fully reboot how it does with newer firmware and wz_mini is running throughout.

Watching the stream on VLC I do see skips during the high ping response times and this seems to correlate when/where iCamera or whatever underlying process is trying to reach home and getting no response. so this version doesn't fully reboot however I am not calling this stable... its usable but not for any security purposed yet...

gtxaspec commented 2 years ago

So, it looks like what iCamera does, if connectivity tests fail, it cycles the WiFi chip off and back on, over and over again periodically, probably explaining the packet loss you guys are seeing.

if we replace wpa_supplicant with a fake, for example: touch /opt/wz_mini/bin/wpa_supplicant_fake; chmod +x /opt/wz_mini/bin/wpa_supplicant_fake;mount --bind /opt/wz_mini/bin/wpa_supplicant_fake /bin/wpa_supplicant

edit: we actually already include a fake wpa_cli.sh for using usb ethernet, so the right command would be: mount --bind /opt/wz_mini/bin/wpa_cli.sh /bin/wpa_cli this achieves the same as replacing the supplicant.

the wifi no longer gets cycles off and on... no more packet loss. Note this command has to be run AFTER the wifi has connected, or it wont ever connect to your network due to our fake programs.

I did a brief test on my local isolated lan, which has NO internet connectivity or DNS resolution, and it seems to work. you can put this in a script and see if it works for you, feel free to test and report back.

virmaior commented 2 years ago

raising and lowering the interface explains why those cameras make so many DHCP requests. Looking at my records, I think they do this approximately every 200 seconds on one of my cameras and every 578 seconds (oddly specific?) on another one.

capncybo commented 2 years ago

@virmaior Good Lord how in the world could WYZE engineering think so many DHCP requests were acceptable? Not very WISE for WYZE Guys ;-) @gtxaspec & thanks AGAIN for sorting all this out... you REALLY ARE making these cameras Better & Better.

I'm learning a ton via this project... from Linux OS functionality & networking into Video encoding, decoding, streaming etc etc... Really Neat Stuff.

rickgitdone commented 2 years ago

so I also downloaded 4.36.2.5 firmware and reloaded it as a downgrade and can confirm where I have blocked internet access and the Camera stays up... there are consistent times when ping responses goes from milliseconds to seconds and then back to milliseconds periodically however the Cam doesn't fully reboot how it does with newer firmware and wz_mini is running throughout.

Watching the stream on VLC I do see skips during the high ping response times and this seems to correlate when/where iCamera or whatever underlying process is trying to reach home and getting no response. so this version doesn't fully reboot however I am not calling this stable... its usable but not for any security purposed yet...

gtxaspec / wz_mini_hacks

Internet access required ? #38