Adding ios to existing http stf

[tobinwbx]

I have an existing stf device farm running on linux for Android devices. I am attempting to add ios devices using a Mac Mini. I appreciate that the instructions say none-ssl is possible but not supported so I have attempted to modify the coordinator file to use the port and IP of my existing device farm
`package main

import (
"fmt"
"os"
"strings"
log "github.com/sirupsen/logrus"
)

func proc_stf_provider( o ProcOptions, curIP string ) {
o.binary = o.config.BinPaths.IosVideoStream

serverHostname := o.config.Stf.HostName
clientHostname, _ := os.Hostname()
serverIP := "192.168.1.XXX"

location := fmt.Sprintf("macmini/%s", clientHostname)
if o.config.Stf.Location != "" {
    location = o.config.Stf.Location
}
        
o.startFields = log.Fields {
    "client_ip":       curIP,
    "server_ip":       serverIP,
    "client_hostname": clientHostname,
    "server_hostname": serverHostname,
    "location": location,
}
o.binary = "/usr/local/opt/node@12/bin/node"
o.args = []string {
    "--inspect=127.0.0.1:9230",
    "runmod.js"      , "provider",
    "--name"         , location,
    "--connect-sub"  , fmt.Sprintf("tcp://%s:7100", serverIP),
    "--connect-push" , fmt.Sprintf("tcp://%s:7100", serverIP),
    "--storage-url"  , fmt.Sprintf("https://%s", serverHostname),
    "--public-ip"    , curIP,
    "--min-port=7400",
    "--max-port=7700",
    "--heartbeat-interval=10000",
    "--server-ip"    , serverIP,
    "--no-cleanup",
}
o.procName = "stf_ios_provider"
o.startDir = "./repos/stf-ios-provider"
o.stdoutHandler = func( line string, plog *log.Entry  ) (bool) {
    if strings.Contains( line, " IOS Heartbeat:" ) {
        return false
    }
    return true
}
proc_generic( o )

}`

Whilst there might not be any answers about plain HTTP I could do with some guidance on the following questions:

1. IS communication to the stf server done from the phone or routed via the Mac? If I have the mac on a VPN but not the phone should this work?
2. I have setup the device provider but I am not sure how to start the coordinator. Should this be run as a separate service or will it be started by the provider run?
3. What components are needed to connect to remote stf? Do I need to update my STF server with any new components to support the ios provider given it was cloned 6 months ago?
4. I am having the issue with video process ending discussed in another issue but if i update the config to set enabled to false it gives no errors but still does not show in the stf UI

Thank you

[issue-label-bot]

Issue Label Bot is not confident enough to auto-label this issue. See dashboard for more details.

[tobinwbx]

I managed to get the device detected by the existing STF server by editing the coordinator source code and changing all https and wss to http and ws respectively and using quicktime to enable the video streaming. I also had to set the allow remote devices and provider ports in the server startup command.

I do not get any errors in the provide/coordinator but opening the device in STF i get no video. In chrome developer tools i get a websocket error:
WebSocket connection to 'ws://192.168.1.XXX:7215/frames/192.168.1.XXX/8000/x' failed: Error in connection establishment: net::ERR_CONNECTION_REFUSED

Any clues? I am not sure if this is a general issue I am having or if I should just give up and generate self signed certificates.The existing server is restricted to local traffic and I was hoping to avoid risking the existing server access

[nanoscopic]

There have been numerous tickets asking to support using stf_ios_support with plain http STF server.

Initially I entertained these tickets and helped users through the necessary tweaks to make it work. After MUCH back and forth with many users trying to explain how it works I gave up. It is a pointless use of time and effort.

It can be changed to make it work with http. It requires tweaking the code in a few places. Feel free to dredge through the closed tickets about this. Currently I'm not going to exert any effort to help plain http attempts besides tell this.

Eventually I will add support for this myself by way of a configuration flag. I don't think anyone should ever use plain http though, so I'm not going out of my way to do it. It is at the bottom of the priority list of things to do.

I do agree that it is irritating to have to switch to https to get IOS support working if you already have plain http STF server deployed / working. That raises the priority of supporting it, and is why I spent much time and effort helping others try to get it working before.

Not supporting it right now. It will happen in future. Probably 4 months from now or so. I'll leave this ticket open for now. Feel free to add in links to the other tickets I already closed about this. In the short term I need to add this into the main wiki so that users aren't confused and wondering why plain http doesn't work or seem to be supported in any way.

[tobinwbx]

thank you. This makes sense I will look through the tickets to see if anyone has encountered a similar issue with their video being blank whilst the provider displays no errors. If I work it out I will look to document the required changes and consider submitting a PR for making it switchable

[nanoscopic]

Thank you for raising the issue again despite my attempts to silence the calls for http support. Whatever my personal misgivings for it, there is sufficient demand for plain http support and it should be added in because of that.

To help out with your current attempt to make it work, this is what needs to be done off the top of my head to make it work:

1. Everything must be on http, as mixed content / connections is not allowed in browsers these days.
2. The websocket must be changed to be ws instead of wss ( wss = secure, ws = plain )
3. ios_video_stream must listen on plain http ( that is what ultimately serves out the "video" over websocket ) -- It already does to begin with so no change really is needed here.
4. Proper nginx config must be in place, to allow connect from the website through nginx to the ultimate ios_video_stream destination. It is also possible to add headers to allow the mixed connection between the provider versus server, but it is far easier to go through the server via an nginx proxy.

What has tripped up most users attempting this is getting the ports to all match up as well as having the proper path to get matched by the nginx proxy. A lot of users also are hesitant and/or don't want to alter the golang code ( which is understandable )

To test everything working I'd recommend the following:

1. Start up ios_video_stream and ivf_pull yourself with the appropriate options manually apart from coordinator.
2. Access ios_video_stream on port 8000 yourself and hit 'connect' to test out the video there and verify for yourself that you are able to have that work consistently ( many users get stuck on this because their video simply doesn't work; unrelated to http vs. https )
3. If video doesn't work, do reset media services on your device. You can also use ./bin/coordinator -resetVideo ( newly added command that just triggers reset media services
4. Test out https access to the port 8000 interface via your nginx. You can go to the http url and it should forward through to the 8000 interface without issue.
5. Assuming all above tests work, and you changed wss -> ws it should just work.

[nanoscopic]

If you are able to make a PR for it I am happy to review / accept it / tweak to ensure it is good.

What should be done:

1. Add a new config.json parameter for http/https ( I think I may have added one at one point but never made it do anything. A secure:true/false option would make sense, but I'm not opposed to whatever is thought of )
2. Alter the bit that generates wss to change based on that option.
3. Provide a different nginx config example for plain http
4. Edit: ALSO: Alter the ws/wss option for the control connection from frontend to the server ( that allows one to click on the screen amongst other things ) This may also require tweaking the container config / nginx config for how that is routed through. I haven't looked at that part of it yet at all.

It seems simple, but for whatever reason has eluded a wide variety of different users attempting it.

[KostyaSha]

small note, even if somebody use http, nginx still can be used as front and proxy_pass to https, then all mixing will hide behind it and browser will be happy.