@Walter

OK, I was able to reproduce a similar error. Although it may have been because I did not have a monocle.token file in place when the service was installed.

After making sure my monocle.token file did exist at /etc/monocle/monocle.token and making sure that file did contain valid token data (file was not empty), I was able to use the following commands to get the daemon updated on the system and working:

First, I used the --uninstall flag to remove the daemon/systemd config

sudo monocle-gateway --uninstall

Next, I used the --install flag to reinstall the daemon/systemd config

sudo monocle-gateway --install

And finally, I was able to start and view the Monocle Gateway

monocle-gateway --restart monocle-gateway --tail

If you are still getting those “condition check” errors, use this command and post what it prints out:

systemctl status monocle-gateway.service

As for this specific error:

****************************************************************** * __ __ ___ _ _ ___ ___ _ ___ * * | \/ |/ _ \| \| |/ _ \ / __| | | __| * * | |\/| | (_) | .` | (_) | (__| |__| _| * * |_| |_|\___/|_|\_|\___/ \___|____|___| * * * ****************************************************************** pkg/prelude/bootstrap.js:1183 throw error; ^ Error: EISDIR: illegal operation on a directory, read at Object.fs.readSync (fs.js:634:3) at Object.fs.readSync (pkg/prelude/bootstrap.js:555:32) at tryReadSync (fs.js:474:20) at Object.fs.readFileSync (fs.js:515:19) at Object.fs.readFileSync (pkg/prelude/bootstrap.js:684:36) at Object.<anonymous> (/snapshot/monocle-gateway/lib/monocle/MonocleGateway.js:1:2954) at Module._compile (pkg/prelude/bootstrap.js:1259:22) at Object.Module._extensions..js (internal/modules/cjs/loader.js:711:10) at Module.load (internal/modules/cjs/loader.js:610:32) at tryModuleLoad (internal/modules/cjs/loader.js:549:12)

I get this if the /etc/monocle/monocle.token path is a directory and not a file. It should be a file.

You can list the path like this and make sure its a file.

ls -la /etc/monocle/ total 16 drwxrwxr-x 3 root monocle 4096 Jul 26 16:37 . drwxr-xr-x 109 root root 4096 Jul 26 16:13 .. -rw-r--r-- 1 root root 285 Jul 26 16:14 monocle.token

Using the file command the output should not be a “directory”.

file /etc/monocle/monocle.token /etc/monocle/monocle.token: directory

Using the file command the output should be a “ASCII text” file.

file /etc/monocle/monocle.token /etc/monocle/monocle.token: ASCII text

Thanks, Robert

@Monocle

Just an update to this thread. Some users have had success getting the hacked firmware of the Yi cameras working with Alexa & Monocle.

Please see: https://forum.monoclecam.com/category/43/yi

@hulkyto

I just moved it to a new “Yi” category.
https://forum.monoclecam.com/category/43/yi

@pedenfield

Also, some routers will allow you to simply override a DNS host to a fixed address of your choosing. This could also be an option for you if your router allows that. You would just use the hostname 2b49b758-a6fd-4a36-a6ac-29b674ff1ce5.mproxy.io and have it pointed to the gateway’s IP address (192.168.0.110). So instead of the router actually resolving the address from a public DNS record, it just returns the overridden IP locally.

Thanks, Robert

@carteriii

Glad to see this works! You might notice that Alexa shuts down the stream after a few minutes. That does happen on some stream we lie about. If you want to dig deeper, you can try playing with the camera’s H.264 settings, profiles and H.264+ enabled/disabled state depending on what options your camera firmware offers. Its a bit of a guessing game, but you may find a combination that Alexa accepts and you would not have to use the @fake-fmtp tag.

Thanks, Robert

@schmaddi

Glad you were able to get it resolved. Sorry I did not see this thread sooner !

Thanks, Robert

@jannnfe

Please see:

https://monoclecam.com/monocle-gateway/install/docker https://hub.docker.com/r/monoclecam/monocle-gateway https://github.com/MonocleCam/monocle-gateway-docker

You can move your existing gateway with the same monocke.token file into a docker container. If you keep the same monocle.token file, your DNS hostname will stay the same. When a new IP is registered, it will get updated in the public DNS registry and will get propagated across the Internet. This may take several minutes or up to an hour to propagate. You may have to reboot your Alexa devices to get the updated IP as Alexa seems to cache DNS entries for a long time.

You can also generate a new token file to speed the migration up, but then you would also need to update Fritz with a new DNS hostname.

Thanks, Robert

@JasonS
Thanks for bumping the thread. I sometime miss new posts. Let me review that thread and I’ll comment there.

Thanks, Robert

Well… I tested all possible tag combinations

@proxy, @noaudio
@tunnel
@tunnel, @noaudio
@proxy-tcp
@proxy-tcp, @noaudio

and nothing worked… :(

I am back to @proxy that gives me 5-7 sceonds worth of footage and hope someone comes up with a solution to this problem.

@gorillabeard

I’ll need a more complete look at the log … feel free to PM me with it using the “Chat” feature in this forum.

Thanks, Robert

@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

@mightyjoe

Other potential workarounds:

1.) If you router provides the ability to either run a DNS server or DNS forwarder, it might provide the ability for you to define fixed DNS hostnames. If it does you can simply define your gateway’s unique *.mproxy.io DNS hostname and map it to your local IP address of the gateway.

2.) If you router allows you to override and assign specific DNS servers to the DHCP clients, you may be able to simply set a public DNS server such as Google (8.8.8.8, 8.8.4.4) as the default DNS server to be given to devices on your network. (rather than the router acting as the DNS server/forwarder)

3.) You can run your own DNS server such as PiHole and manually define the DNS entry for your gateway. You would need to configure your router’s DHCP server to give out the address of this DNS server.

4.) If you can expose port 443 on your router and forward that internally to the gateway, this could be an option. Some ISP don’t allow serving on port 443, so you might have to check that. Some custom configuration will also be needed for Monocle Gateway to associate your public IP address with the gateway’s unique *.mproxy.io DNS hostname. (Not, this solution is not ideal long term, because it is exposing port 443 outside your private network – but may be temporarily suitable for testing.)

Hi, having had chance to look at this it does appear to be the DNS rebinding issue, having had a dig around it appears that my modem/router doesn’t allow me resolve this, any recommendations on a good router/modem that will allow me to solve this, im on BT infinity using their standard hub5 at the moment

To specially answer your question, I’m not sure I have a suggestion for what would be best in the UK under BT ISP. I personally use a PFSense router as it affords a ton of customization features and is a bit more robust than an off the shelf router. Of course that also comes with more complexity :-)

@stardeo ,

OK, no problem at all. Just let me know if you want to pursue this again down the road.

It looks like some sort of networking issue where the Alexa device is unable to connect to the Monocle Gateway. We would expect additional line of information in the log when Alexa attempts to connect and start the RTSP session.

Thanks, Robert

Hi Robert,

Thanks for getting back tom me.

Just tried a few things. Disabled Firewall completely, both on the Gateway and on my Router.

Unfortunately I receive the same output.

Fire TV Cube is on the same network, as the Cameras, (all wired, no wifi needed.), the Echo show is also on the same network, but this is wireless.

I have a Virgin Media Super Hub 3 (https://wikidevi.com/wiki/Virgin_Media_Super_Hub_3). from this router i have also put the gateway as a DMZ and so should be fine for internal and external traffic.

Unfortunately, I’m still facing the same issue.

Do you by any chance have a network diagram of ports used for the whole process?

Thanks
Jason

@Monocle said in RTSP Socket Timeout - Alexa Cant Connect to RTSP Stream:

Let’s start with a few basics.
The gateway is detecting IP address 192.168.0.25. Is this correct for this Windows machine?
Basically, the gateway is up and running (no startup errors).
I see your camera is tagged because the gateway received the camera streaming request.
What’s missing is the Alexa device establishing a TCP connection to the gateway.
This could be Windows Firewall blocking access to port 443? Try disabling the firewall to test.
If you Alexa devices are on a separate network (i.e. Guest Wifi Network) they may not be able to reach the gateway server.
It could be a routing issue. What type of router do you have? Some routers block the DNS hostname due to DNS REBINDING.
If you have a PFSense router or Fritzbox, this is highly likely the case!
Thanks, Robert

Hi Robert, thanks for your reply. You were right, the underlying reason was outside the Monocle.

For some reason adding NVR messed up the gateway. When I removed it, I can see the IP camera like before. Thanks.

I was getting the same thing. I am using the gateway software on a PC and it gives you some information when you try to connect. Ultimately I had to use the @proxy tag to get it working.