search

mrlt8 / docker-wyze-bridge

WebRTC/RTSP/RTMP/LL-HLS bridge for Wyze cams in a docker container
GNU Affero General Public License v3.0
2.64k stars 166 forks source link

Connecting to Cameras on Internet-Blocked IoT (V)LANs #483

Open wirerydr opened 2 years ago

wirerydr commented 2 years ago

Hello there;

I have the bridge up and running properly in a Docker stack, and I can successfully access cameras on the same LAN. However, when I try to bridge a camera that is on a local IoT LAN (actually a VLAN) that has it's internet access blocked, the bridge considers the camera offline and logs IOTC_ER_DEVICE_OFFLINE.

The camera itself is ping'able etc. from the docker host. The docker host itself is on a different VLAN that has internet access. Actual connectivity between the docker host and the camera is completely open, unfiltered, with no NAT etc. going on between the two LANs. So I guess my question is two-part:

  1. Does IOTC_ER_DEVICE_OFFLINE indicate that the bridge is failing to actually connect to the camera? Or does it instead mean the Wyze servers - which are unreachable to/from the camera on the IoT VLAN - have flagged the camera as "offline" and so the bridge isn't actually trying to connect to the camera?

  2. In either case, is there a workaround that can be suggested which might facilitate connecting to this camera under these conditions? Ideally configurable by a per-camera environment variable? I did notice IGNORE_OFFLINE but that sounds like it causes offline cameras to become ignored, not their "offline" status ignored and being connected-to anyway.

Thank you very much!

mrlt8 commented 2 years ago

I haven't done much testing with offline cams, but I believe it should continue to work as long as ENR/IP remain the same on the camera.

Could it be that the camera info is stale on the wyze servers?

wirerydr commented 2 years ago

When I hover over the camera's info widget in the upper left hand corner of the web-ui, it displays the correct IP, which in any event is statically allocated.

However I just discovered @gleep52 's https://github.com/mrlt8/docker-wyze-bridge/issues/167#issuecomment-995435448. I will attempt something similar and then report back...

wirerydr commented 2 years ago

So, I observed the same overall results as @gleep52 when attempting his workaround. Namely, the bridge and camera initially connect just fine with the camera's vlan internet-blocked. However as soon as docker or the bridge is restarted, Wyze reports the camera as "offline" and the bridge fails to reconnect.

I'm going to investigate whether blocking the bridge's access to Wyze (after properly building up a set of tokens) might work, and again report back my findings.

mdabbs commented 2 years ago

I would like to see this work eventually. I am not fond of the cameras phoning home to wyze and would prefer to block them completely from the internet. I block the cameras via mac address at the router and after awhile things get broken. I didn't look too much into it, but if there's a way to make it work, I'd feel a lot better about confining all my stuff to my local LAN.

drjared88 commented 2 years ago

I am seeing the same problem. Works great until I pull internet access to the camera. At that point the bridge loses the camera details and the status goes to 'connecting'.

I don't understand enough on how this bridge works but if there is a way to cache the camera configurations, this would be perfect for what I am trying to accomplish.

mrlt8 commented 2 years ago

You could cache the API results using:

    volumes:
        - ./tokens/:/tokens/

The cameras should continue to work at least until they are rebooted.

bitbucket90 commented 1 year ago

I put mine on a different vlan, blocked internet, over night saw them drop came here to report.

Im going to try with the cache option. I had a power failure, and two dropped, the other two didnt lose power and thus continued to work. So likely have to reconnect the internet, to bring them back online, then turn off again.

Would be great to some how cache the status via a deployment option for thos of us on internet blocking vlans.

When this next kid comes out, ill have some heads down time and review the code and see if I can come up with anything.

mrlt8 commented 1 year ago

I believe the newer firmware attempts to do some AWS IOT Core related setup before it starts the avserver so the bridge can't find the cameras until the camera gets past the setup/boot process. More specifically, I believe the camera gets stuck waiting for the file /tmp/aws_iot/rooCAok.

bitbucket90 commented 1 year ago

I wonder if we can fake the cloud on this one? The apis exist. Sort of like how the roborock was rooted with a fake local cloud.

On Wed, Jan 11, 2023 at 7:33 PM, mrlt8 @.***> wrote:

I believe the newer firmware attempts to do some AWS IOT Core related setup before it starts the avserver so the bridge can't find the cameras until the it gets past the setup/boot process. More specifically, I believe the camera gets stuck waiting for the file /tmp/aws_iot/rooCAok.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>

mrlt8 commented 1 year ago

I'm not very familiar with AWS's iot core, but that could be a potential solution.