Echo Show 5 not working.....

[rook]

@Monocle, Robert

First of all… thanks for your response.

• checked nslookup /openssl from a different workstation. ALL PASS

• same VLAN.

• I have to admit that this raspberry also runs the “PiHole DNS”, but I don’t think this is the root cause. I actually disabled PiHole while I was debugging.

The “Camera Feed History” is interesting, I didn’t see it untill you told me.

[
  {
    "timestamp": "2019-07-17T17:29:59.373Z",
    "request": "InitializeCameraStreams",
    "response": [
      {
        "uri": "rtsp://192.168.1.101:554/live.sd",
        "proxy": "rtsp://a08d6cc4-cd8e-4062-a197-54b260e71af1.mproxy.io:443/STREAM:c11faadd-9d51-4d08-b677-1fc1d4f6c2fe?session=c802e93c-6b32-4459-bf40-5a53469e6c86",
        "resolution": {
          "width": "1920",
          "height": "1080"
        },
        "authorizationType": "NONE",
        "videoCodec": "H264",
        "audioCodec": "NONE",
        "protocol": "RTSP"
      }
    ]
  }

Or other cam (unknown china cam)

[
  {
    "timestamp": "2019-07-17T17:34:39.060Z",
    "request": "InitializeCameraStreams",
    "response": [
      {
        "uri": "rtsp://192.168.1.56:554/user=admin_password=_channel=1_stream=1.sdp",
        "proxy": "rtsp://a08d6cc4-cd8e-4062-a197-54b260e71af1.mproxy.io:443/STREAM:b89dc1e5-ad5d-4d0a-a8c7-d2d99af010d9?session=b6280471-a3dc-40ee-bbad-6538f9162204",
        "resolution": {
          "width": "192",
          "height": "192"
        },
        "authorizationType": "NONE",
        "videoCodec": "H264",
        "audioCodec": "NONE",
        "protocol": "RTSP"
      }
    ]

Nevermind. I will get a an Echo Spot when it is on sale.
Thanks again for your support.

[Monocle]

@rook said in Echo Show 5 not working.....:

Thanks again for your support.

I understand the frustration … Amazon does not make it easy to diagnose problems like this. I think we have done just about everything I can think of … apart from network packet sniffing the Alexa device to see if she is actually attempting to make the TCP connection to the gateway.

A couple of other users a reporting similar problems, I just hope its not a change on Amazon’s side that is preventing this from working in some way. It’s still fully working for me on all my test devices – including the new Echo Show 5, but this is a concern.

Thanks, Robert

[rook]

@Monocle
Hi Robert,

I had to retry it with an Echo 2. (the big screen).
And actually one CAM (no name china cam) got a response without the gateway. Even though it is puffering all the time. At least I was able to get a single screenshot.

VIVOTEK, FOSCAM are still failing. Nevermind, I will close this project for myself now :)

[lux4rd0]

Came here with the same issue of my new Echo Show 5 not connecting while my new Echo Show (2nd Gen) and Echo Spots all worked. I’ve been using a Docker deployed Gateway because of using UBNT Unifi cameras and at first thought it was resolution issues - but alas - as mentioned up above - using “@tunnel” as a tag in the camera config and all is good now. Just dropping a note here to say Thank You!! :)

_DS

[mattp]

I’ve been messing around for hours now trying to figure out what’s going wrong with getting my echo show 5 to display feeds from my ubiquiti cameras. Looking @ the logs and following all the steps, all appears to be working (DNS address is fine and pingable, my gateway initialises the RTSP stream, however it appears to get some kind of host unreachable error from the show 5, which is weird given the echo is on the same subnet / network as the gateway and unifi-video servers and all is working via VLC when I plug in the streams. I’ve even tried reducing the resolution to the lowest setting given the suggestions in this thread.

Any ideas?

06T12:58:08.751044149Z 

06T12:58:08.751061632Z -------------------------------------------------

06T12:58:08.751064484Z INITIALIZE RTSP STREAM:  Back Door

06T12:58:08.751066569Z -------------------------------------------------

06T12:58:08.751068787Z  - NAME  : Back Door

06T12:58:08.751083956Z  - LABEL : PRIMARY

06T12:58:08.751091893Z  - URL   : rtsp://192.168.0.100:7447/5c7265ffe4b0726382487c31_2

06T12:58:08.751094483Z  - UUID  : STREAM:77f8f0e6-7b02-4673-9863-2d713920028a

06T12:58:08.751111689Z  - SESS  : b393918e-b80e-4abb-92d1-5dc379bbe711

06T12:58:08.751136049Z  - MODIF : Tue Aug 06 2019 12:56:55 GMT+0000 (UTC)

06T12:58:08.751157795Z  - TAGS  : @tunnel

06T12:58:08.751177706Z -------------------------------------------------

06T12:58:08.751194189Z 

06T12:58:09.165839306Z 2019-08-06T12:58:09.165Z [INFO]  [192.168.0.89:57646 <SyFwYlvXr>] RTSP CLIENT SOCKET CONNECTED

06T12:58:09.293504008Z 2019-08-06T12:58:09.293Z [INFO]  [192.168.0.89:57646 <SyFwYlvXr>] RTSP CLIENT ATTACHED TO STREAM: Back Door (STREAM:77f8f0e6-7b02-4673-9863-2d713920028a)

06T12:58:12.299903221Z 2019-08-06T12:58:12.299Z [ERROR] [192.168.0.89:57646 <SyFwYlvXr>] [RTSP ENDPOINT SOCKET ERROR] [192.168.0.89:57646 <SyFwYlvXr>] Error: connect EHOSTUNREACH 192.168.0.100:7447

06T12:58:12.299978751Z [ '[192.168.0.89:57646 <SyFwYlvXr>]',

06T12:58:12.299984323Z   '[RTSP ENDPOINT SOCKET ERROR]',

06T12:58:12.299986603Z   '[192.168.0.89:57646 <SyFwYlvXr>]',

06T12:58:12.299988879Z   { Error: connect EHOSTUNREACH 192.168.0.100:7447

06T12:58:12.299991177Z     at Object._errnoException (util.js:1031:13)

06T12:58:12.299993332Z     at _exceptionWithHostPort (util.js:1052:20)

06T12:58:12.299995504Z     at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1195:14)

06T12:58:12.299997618Z     errno: 'EHOSTUNREACH',

06T12:58:12.299999637Z     code: 'EHOSTUNREACH',

06T12:58:12.300001559Z     syscall: 'connect',

06T12:58:12.300003473Z     address: '192.168.0.100',

06T12:58:12.300005492Z     port: 7447 } ]

06T12:58:12.300082757Z 2019-08-06T12:58:12.300Z [ERROR] PROXY ENDPOINT ERROR; Error: connect EHOSTUNREACH 192.168.0.100:7447

06T12:58:12.300173362Z [ 'PROXY ENDPOINT ERROR;',

06T12:58:12.300181113Z   { Error: connect EHOSTUNREACH 192.168.0.100:7447

06T12:58:12.300183682Z     at Object._errnoException (util.js:1031:13)

06T12:58:12.300185843Z     at _exceptionWithHostPort (util.js:1052:20)

06T12:58:12.300188030Z     at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1195:14)

06T12:58:12.300190347Z     errno: 'EHOSTUNREACH',

06T12:58:12.300192333Z     code: 'EHOSTUNREACH',

06T12:58:12.300194333Z     syscall: 'connect',

06T12:58:12.300196226Z     address: '192.168.0.100',

06T12:58:12.300198478Z     port: 7447 } ]

06T12:58:12.300214210Z 2019-08-06T12:58:12.300Z [INFO]  [192.168.0.89:57646 <SyFwYlvXr>] RTSP ENDPOINT SOCKET CLOSED [192.168.0.89:57646 <SyFwYlvXr>]

06T12:58:39.294438531Z 2019-08-06T12:58:39.294Z [WARN]  [192.168.0.89:57646 <SyFwYlvXr>] RTSP CLIENT SOCKET TIMEOUT

06T12:58:39.304254638Z 2019-08-06T12:58:39.304Z [INFO]  [192.168.0.89:57646 <SyFwYlvXr>] RTSP CLIENT SOCKET CLOSED

06T12:58:39.304269048Z 2019-08-06T12:58:39.304Z [INFO]  [192.168.0.89:57646 <SyFwYlvXr>] RTSP CLIENT DETACHED FROM STREAM: Back Door (STREAM:77f8f0e6-7b02-4673-9863-2d713920028a)

[Monocle]

@mattp

Well that error is a little different than the usual posts here :-)

It appears from the log file that the gateway is unable to establish a TCP connection to IP address “192.168.0.100” on port “7447”.

I assume the answer is YES, but let’s just verify that this is the correct IP address of the camera and the correct RTSP port? (Most cameras use RTSP port 554.)

Thanks, Robert

[mattp]

@Robert,

It’s the address of my unifi video server, which manages all the unifi cameras centrally, and essentially takes over their interfaces and sends out its own RTSP streams for the cameras on port 7447. The rest of the URL points to the RTSP stream for that particular camera and resolution. It’s an ubiquiti thing.

I can’t stream direct off the camera without un-managing it, which isn’t going to work given it defeats the purpose of the unifi-video platform.

[Monocle]

@mattp

This error is just odd. It’s telling us that the TCP connection is failing. So it’s not even getting to the RTSP application layer protocol.

Can you try running this command from the same host that the Monocle Gateway is running on?

telnet 192.168.0.100 7447

Basically we just want to see if TELNET can establish a socket connection to the Unifi server.

If you have FFMEPG installed, you can also test the RTSP stream like this:

ffplay -rtsp_transport tcp "rtsp://192.168.0.100:7447/5c7265ffe4b0726382487c31_2"

Thanks, Robert

[mattp]

@Monocle

Ok, I think i might be getting close now. The host is fine, but I’m using a docker with a MACVLAN network which I forgot won’t allow connectivity to the host’s IP (the .100 IP) by design.

As this was throwing errors using the bridge network and I needed to move it onto a MACVLAN to get it to work, it looks as if the caveat on the docker monocle container is that it needs to use host net, which I can’t as I use host 443 for something else and proxy pass the gateway to the docker instance.

I’ll install the gateway on a spare RPI tomorrow and change my apache config to pass to that, and see if that solves it.

[mattp]

Couldn’t help myself and installed it now. Working fine on the RPI, so it was the docker networking. Whilst it would have been neat to keep it all together with my other home automation stuff, the RPI works fine and I’ll leave it.

Thanks a lot for your help, the answer was right there staring me in the face the whole time!

[Monocle]

@mattp

One snag on the RPi plan. The gateway will need direct access to port 443. Meaning it can’t sit behind an Apache or NGINX server as a proxy. Those web servers won’t proxy RTSP properly as well as the gateway presents it own SSL certificate fully managed inside the gateway. So it will need a dedicated IP interface. You could (via Linux config) add a secondary IP address to the network interface on the RPi and then have Apache use one IP and Monocle Gateway use the other. Some custom configuration for the gateway would need needed, but that is pretty minor.

Seems like the Docker approach could be made to work … somehow?

-Robert

[mattp]

My apache server is proxying the gateway no problems (it’s on another box) using the mod_ssl ignore settings:

SSLProxyCheckPeerName off
SSLProxyCheckPeerExpire off
SSLProxyCheckPeerCN off

This tells apache to ignore downstream certificates as my apache server does the SSL termination.

My setup is an apache virtual host with it’s own certificate for monocle --> gateway on the PI --> unifi video container.

I’ve got no doubt I can work around the docker, there’s a bunch of good stuff on various forums on how to hack around the MACVLAN issue but to be honest it’s all just too hard to remember the next time I have to troubleshoot something, compared to the PI.

[Monocle]

@mattp

OK, I have not personally fully tested trying to run Apache as a proxy server. So if there is a way to get it fully working, I would love to understand the steps.

If Apache is performing the SSL termination, then are you using a custom FQDN setting in the Monocle Gateway’s properties to override the auto-generated DNS hostname? If not, then I don’t understand how Apache is delivering the correct certs to the requesting Alexa devices.

Thanks, Robert

[lux4rd0]

@mattp Will keep watching this space to see if you happen to come across a path forward on this. Fortunately I have enough hosts to run Docker on that one of them has an open port 443 to use against host networking. But it would be nice to define a different port. I expect it also has something to do with the Amazon devices not having any flexibility on that port as well. It’s not expecting to have something in the middle :)

Thanks!!

_DS

[Monocle]

@lux4rd0

The ONLY requirement for port 443 is Amazon. They only allow Alexa devices to establish connections to RTSP encrypted endpoints on port 443. This was not always the case, but is now with most current FireTVs and Alexa Shows. They also only allow connections to publicly resolvable DNS hosts, no direct IP addresses or private DNS hosts.

[Monocle]

@lux4rd0

I posted more detail about my Docker image using macvlan on a Synology NAS here:
https://forum.monoclecam.com/topic/255/using-synology-surveillance-station-and-docker

Hope it helps!

Thanks, Robert

[mattp]

@lux4rd0, to Robert’s point my config works because Amazon is expecting a valid certificate and 443 connection.

This is more an Amazon thing as I’ve got the same requirements on some other automation work I’ve written custom Alexa skills for. In each case 443 for any API connections is the go.

To your question, Robert, the Apache proxy works fine as from what I can see in the traffic it’s only accepting http connections to 443 and isn’t proxying the RTSP stream, which is going direct from the echo show to the internal server via the DNS rebind?

I’ve posted a pic of my config to demonstrate…

Apache proxy is working as per the above directives and using a virtual-host for the monocle.<myFQDN> and a valid certificate for that domain.

Either way this setup is functionally the same as docker and macvlan with the relevant work around to attach to my host’s network (as the docker container for unifi, and the apache server run on the same box.) You could do the same with VM’s as well if that’s your cup of tea.

At least this proves the following:

• Apache Reverse proxy works (providing you use the directives I listed in my previous posts)

• Docker macvlan can work, but just remember without working around the designed docker behaviour if your monocle gateway is trying to communicate with your RTSP server on the same IP as the host running Docker, it won’t work.

• Unifi-Video RTSP streams on their weird port work, so the assumption there is that non-standard RTSP ports are ok.

• Nothing is ever simple and I seem to find a way to complicate everything…

• Me and Alexa are friends again.

[mattp]

@Monocle Have added the working reverse proxy conf for my setup in case it helps anyone as well:

#Virtual Host Setup in Apache as Monocle expects to use port 443
#This setup uses LetsEncrypt (https://letsencrypt.org/) and a dynamic DNS setup with a host entry for monocle
#Either add to your apache conf file or create a new monocle.conf file and include that in the bottom of your apache conf.
<VirtualHost *:443>
  ServerName monocle.<your FQDN here>
  SSLProxyEngine On
  SSLProxyCheckPeerName off
  SSLProxyCheckPeerExpire off
  SSLProxyCheckPeerCN off
  ProxyPreserveHost On
  ProxyRequests off
  ProxyPass / https://<address of monocle gateway>:443/
  ProxyPassReverse / https://<address of monocle gateway>:443/

# Haven't tested if you need this for Monocle, but in prior experience not changing websocket traffic also plays havoc on API calls. I've left it in but remove 
# and experiment as you need.
  RewriteEngine on
  RewriteCond %{HTTP:Upgrade} =websocket [NC]
  RewriteRule /(.*)  ws://<address of monocle gateway>:443/$1 [P,L]
  RewriteCond %{HTTP:Upgrade} !=websocket [NC]
  RewriteRule /(.*)  https://address of monocle gateway>:443/$1 [P,L]
 
# The below comes from letsencrypt and should be generated automatically if you follow the instructions on the letsencrypt web site
# I've left this in to show where you'd put your certificate files
  SSLCertificateFile <path to your SSL cert file.pem>
  SSLCertificateKeyFile <path to your keyfile.pem>
  Include <your apache ssl conf file here>
  SSLCertificateChainFile <path to your ChainFile
</VirtualHost>

#Redirect anything to https
<VirtualHost *:80>
  ServerName monocle.<your FQDN here>
  Redirect permanent / https://monocle.<your FQDN here>/
</VirtualHost>

[Monocle]

@mattp

Thanks for all the details. I’m still sorting it all out in my head, but do have a couple of notes.

When using the Monocle Gateway with a camera that is tagged with any of these: @tunnel, @proxy or @proxy-tcp the RTSP stream is initiated from the Alexa device directly to the Monocle Gateway. Not directly to the camera or in your case the Docker Unifi Video server. (So it would be the Monocle Gateway that actually communicates RTSP to the Unifi server.)

I see now that you are generating your own LetsEncrypt certificate and that is allowing you to terminate it on your Apache server. That makes sense now. Just a note, if you already have your own domain name and SSL certificate, you should be able to override the DNS hostname that Monocle Gateway uses. See the Monocle Gateway Configuration topic here. There is no magic here, you just need a publicly resolvable DNS host entry that points to an IP address where the Monocle Gateway is listening (or via Apache proxy in your case.)

I was under the impression that the RTSP protocol was not able to be proxied via an Apache or NGINX server. But I guess I got that wrong somewhere. Maybe the TCP only streams are OK, not sure it would work with UDP streams. I’ll have to play with this setup again when I have some time. The SSL termination could be difficult for some people, but for advanced users this could be a nice alternative.

You probably don’t need to worry about the proxy handling any web sockets, at least not at this time – that may change in the future as we plan on adding a Monocle Gateway Web GUI with access to logs, etc. Today only outbound secure web sockets are used to communicate with the Monocle servers over the Internet.

Thanks, Robert