Video not working - mostly solved

This appears different than “Raspberry pi camera not working” so I started a new thread.

Raspberry Pi 2, with official Pi camera (5 MP version)
Astrobox 0.11.23
Flashforge Creator Pro
Browser is on a Mac Pro running Sierra

I’ve been running OctoPi, but thought I’d try Astrobox again now that dual extruder is supported. I couldn’t get video to work even though both Astrobox and browser are on my local network. I just get the WebRTC startup error and the crying monkey. Still images work.

As a side note, when WebRTC fails, janus becomes a zombie. Parent process (/AstroBox/run) apparently isn’t doing a “wait” to reap the dead PID.

Long story short, the problem was the firewall, even though this is all on the local network. The only thing I could find on firewall requirements is this:

forum.astroprint.com/t/firewall-port-requirements/2931

from 25 days ago. “We simply use port 443 (SSL) same as any https connection”. This appears to be inaccurate. My firewall logs say that Astrobox is trying to connect to “turn.astroprint.com” on UDP port 443, application protocol STUN.

I opened UDP (not TCP) port 443 on my firewall to turn.astroprint.com, allowing application protocol STUN, and now video works perfectly on Safari, Firefox, and Chrome. Video is much better than with OctoPi, especially on my phone.

However, my browser is also trying to connect UDP port 80 to the same IP, as well as tons of high-port UDP being attempted to my public IP. But leaving those blocked doesn’t seem to cause a problem.

I say “mostly solved” because of the extra UDP connections, and the fact that the zombie janus process remains a random problem. When that happens, I have to log in and do a “sudo service astrobox restart” to clear the defunct process or WebRTC won’t start.

root      1109   892  0 02:06 ?        00:00:00 [janus] <defunct>

STUN is a tunneling protocol. Why is a STUN connection required to be opened to do streaming video between my browser and Astrobox on the same local network? Why is the browser trying to do high-port UDP to my public IP when it is streaming locally?

STUN is part of WebRTC, it’s used to find a route between your AstroBox and the browser that wants to stream video so that the date can be delivered directly between the two points.

You are correct, we do also use UDP for that. I’ll investigate if moving to only TCP is an option which will make it easier to add to more networks.

The part I’m not understanding is that my browser is already talking on the local network to the Astrobox. Even though there’s already communication, the Astrobox makes a UDP STUN connection to turn.astroprint.com, and if that is blocked I can’t do streaming on my local network. I’d understand it if the streaming was over the Internet brokered by Astroprint central.

There’s also the attempts at sending UDP to my public IP along with the local UDP traffic, looks like it’s trying to establish a streaming connection that way too instead of just within the local network.

Just trying to understand, and if this is a bug or a feature…

Thanks

Are you on a Safari browser? Apple does not provide HOST candidates ( which would be the local ones ) You could try Chrome or FireFox to see if the y behave the same way

Very interesting… With Chrome and Firefox, I still see the UDP STUN to turn-astroprint-com, but it does not try to send UDP to my external IP. All of the streaming attempts remain on the local network as you’d expect. The STUN to your server request is now showing up on port 80 instead of 443 on all three browsers.

I do have problems with the Firefox tab frequently crashing when I click Start Streaming Video. Safari started acting up too - had a black screen instead of live camera view and hung when I clicked Stop Streaming Video. Force quit, repeated ( duplicated multiple times). I tried doing stills before video, and then it worked.

TCP port 443 is the default port used by HTTPS. If this port is blocked on any server or device from your computer to a given destination, such as www.Microsoft.com, your connection to any https site will fail and your browser will return an error message like “Secure Connection Failed” or “Page Cannot be Displayed” . However, the two most common locations for this failure are at your workstation or router. Moreover, if you can access the html page at your root domain (say https://midomain.com/), but pages in a directory like https://midomain.com/ give you a 404 Not Found error.