Foscam R2 with Lenovo Smart Tab [SOLVED]
-
I opened up a port forwarding rule for port 443
Edited the config and adjusted the host with my current public IP****************************************************************** * __ __ ___ _ _ ___ ___ _ ___ * * | \/ |/ _ \| \| |/ _ \ / __| | | __| * * | |\/| | (_) | .` | (_) | (__| |__| _| * * |_| |_|\___/|_|\_|\___/ \___|____|___| * * * ****************************************************************** ------------------------------------------------- MONOCLE RUNTIME ENVIRONMENT ------------------------------------------------- VERSION = 0.0.4-3 OS/ARCH = win32\x64 PROCESS = monocle-gateway (PID=31116) TIMESTAMP = 2020-01-24T18:33:24.579Z ------------------------------------------------- MONOCLE GATEWAY SERVICE (Version: 0.0.4-3) ------------------------------------------------- [Monocle Starting] [Monocle Connecting] [Monocle Started] [RTSP Server Starting] [RTSP Server Listening] 0.0.0.0:8555 (RTSP) [RTSP Server Listening] 0.0.0.0:443 (RTSP-TLS) [RTSP Proxy Started] (PID=34472) [RTSP Server Listening] 0.0.0.0:8554 (PROXY) [RTSP Server Started] [Monocle Connected] [RTSP Server Registered] ------------------------------------------------- MONOCLE RTSP SERVICE - INITIALIZED ------------------------------------------------- FQDN = 46224620-b4e1-424d-abce-1ddb866d01f8.mproxy.io HOST = 108.231.61.93 PORT = 443 -------------------------------------------------
DNS is showing correct for internal and external
C:\>nslookup 46224620-b4e1-424d-abce-1ddb866d01f8.mproxy.io Server: ubnt Address: 192.168.1.1 Name: 46224620-b4e1-424d-abce-1ddb866d01f8.mproxy.io Address: 108.231.61.93 C:\>nslookup 46224620-b4e1-424d-abce-1ddb866d01f8.mproxy.io 8.8.8.8 Server: dns.google Address: 8.8.8.8 Non-authoritative answer: Name: 46224620-b4e1-424d-abce-1ddb866d01f8.mproxy.io Address: 108.231.61.93
I will wait a couple hours to make sure DNS propagates before testing. I will produce some pcap files as well from the access point
-
Boooom! we have Demo Proxy working
-
WOW. Just WOW. I can’t believe they are proxying the stream like this. This is not the case for any other Alexa devices that we have worked with. This of course adds latency and is potentially very undesirable from a security standpoint as your audio and video data is getting passed through some server. The packets are encrypted, but still.
Is it working now for your real Foscam camera stream? Make sure to use
@tunnel
and the camera has “Foscam” listed as the manufacturer in the Monocle web portal.I have a dynamic IP address assigned to my public interface. I use a Dynamic DNS provider. Can I use a namespace instead of the public address since it will change when DHCP refreshes?
Not without some changes – but it should be possible. The Alexa system will only connect to DNS hostnames with valid SSL certificates. Do you want to setup a real SSL certificate for your domain? Apart from acquiring the SSL certificate, we would also need to provide some configuration method to allow your to include your own certificate and private key to the Monocle gateway on startup.
Thanks, Robert
-
Very interesting indeed and ironically different than any other alexa device is even more boggling.
thank you for working with me on this, i really appreciate it.
I think a simpler solution would be to configure my IP with a static. I think direction i would go with this. I keep getting these nagging monthly mails to update my DNS record etc… so it would do away with that.
I expect more of these devices like this to come out though. Would be nice to see continued development on this. At least we have a workaround at this point.
-
Yes btw the foscam works!!!
-
Glad to hear the Foscam is working.
If we are going to leave port 443 open to the Internet it would be prudent for us to add some form of authentication to the monocle service to prevent unauthorized access. The current exposure is pretty limited but security by obscurity is really not a good solution. At the moment any consumer would need to know the unique STREAM ID and SESSION ID to be able to get access to any camera streams but a proper authentication mechanism would be better.
Thanks, Robert
-
Yes i agree. I will work on adding the Static IP address to my internet plan. I am assuming that auth would be handled on the gateway which would mean the a new version would need to be developed by you?
If i can assist in any way by testing or whatever you need, i happy to do so. I really appreciate the help in getting this to work.
Many Thanks!
Ryan -
Yes we will need to add support for this in the software … let me look into this next week and maybe we can get a copy out to test with .
Thanks, Robert
-
Thanks, i have most of cameras working now. My doorbird is not working and then a few combined views from BlueIris but i haven’t spent time investigating.
I created a couple other support threads in the lenovo forums
https://forums.lenovo.com/t5/Lenovo-Smart-Tablets-with-Amazon/Lenovo-smart-tab-m10-Camera-Streaming/m-p/4633642/highlight/falseWe will see if the can escalate this and resolve this as well although we have a workaround.
No rush, but once you have a version you would like to test let me know here and i will give it a go.
-
Just a small update … we have added support for a configuration property to automatically detect your public IP address instead of you having to manually define it.
Please see: https://forum.monoclecam.com/topic/485/access-cameras-from-2nd-site-solved/10Plan on looking into the authentication improvement this week.
Thanks, Robert
-
Thank you for tagging me here. I implemented this and it seems to be working with that new function.
Looking forward to testing whenever you are ready. Thanks for following up
-
Im not seeing a way to get the log file. I saw the article on this but the logfile is not created
-
Well … its should be creating a log file (
monocle-gateway.log
) adjacent to (in the same folder as) themonocle-gateway.exe
when running on a Windows machine. That is if you are running it as a service. If you are just launching the executable directly, then there is no log file but the same contents should be printed on screen while the executable is running in a command shell.Thanks, Robert
-
-
Well, that is confusing :-)
I wonder if it’s getting written to a working directory instead. Can you do a search for “monocle-gateway.log” and see if its getting written somewhere else?
It’s possible it’s not getting written anywhere, but that is a function of the “nssm.exe” utility that turns this monocle-gatesway.exe into a service.PS, working on gateway authentication and security today.
Thanks, Robert
-
I will do a search, i was thinking it was being written somewhere else.
-
a search didn’t find it but please don’t worry about this. Its very minor. Don’t want to distract you from the auth piece :)
-
As an alternative, you can always just stop the service and run the
monocle-gateway.exe
from the command line to see the output logging.Thanks, Robert
-
Yeah thats what i did when troubleshooting cams / network stuff
-
Progress update on monocle-gateway authentication …
I now have an optional authentication mechanism in place in both an updated (experimental) version of monocle-gateway as well as the server side infrastructure. I’m finishing up some testing and will post a link for you to download it soon.
The way it works is you add your own textual string as a private authentication key in your
monocle.properties
file. We then share this private key with the monocle servers (via encrypted channel) and use this key to create a unique one-way encrypted hash/signature for each RTSP request from Alexa to your instance of the Monocle Gateway. This way the private key is never included in the public request and never shared with Amazon/Alexa devices. Every unique Alexa request for a camera stream will have a new and unique auth hash/signature such that previously generated authentication hash/signatures are not reusable. The Monocle gateway will only enforce this hash/signature validation if a private key has been optionally configured.This is only really needed in cases where the Monocle Gateway is exposed to the Internet / publicly accessible on the Internet (via port 443). All traffic is already encrypted using SSL/TLS, but this new authentication method will further ensure security in that each an every Alexa request signature is authenticated and validated. If configured with this private key, the Monocle Gateway will not accept any inbound RTSP requests that fail to provide the authentication hash/signature or any invalid authentication hash/signatures.
Thanks, Robert