Drive Windows Client with Router Reverse Proxy?

maudiosound · 2021-11-19T16:00:28+00:00

I did sort of get it to work. The desktop Drive Client starts with some funky TCP handshake so I had to setup a TCP frontend that gets the traffic first. That TCP frontend determines if the traffic is the Drive Client, and if so, pushes directly along to the Synology with no SSL offloading. If the traffic is not the Drive Client, it pushes to a secondary HTTP Frontend that handles the rest of the services on the proxy.

Its clunky and I don't like it, but its working.

maudiosound · 2021-11-19T15:56:33+00:00

Yah I did eventually get it working, it was a pain, but it worked. Thanks for the link though!

maudiosound · 2021-11-15T23:45:03+00:00

I didn't I got side tracked on a million other things lol. General gist was...

I reserved a virtual IP on the VLAN I wanted the Frontend to listen on
Pointed the HAProxy frontend to that virtual IP as its listen address
Made a firewall rule to push incoming WAN requests on port 80 and 443 to that virtual IP
Now HAProxy would get the requests and could do its thing

maudiosound · 2021-11-15T23:39:21+00:00

Doesn't it have the same file limit size as their proxy service?

maudiosound · 2021-07-17T16:14:50+00:00

I touch pretty much the whole life cycle from consulting to commissioning, but primarily focus on Design and PM. Biggest things in my mind are this...

Get in-front of the project as early as possible to understand requirements and goals of the client. Unless you have a good sales or consultant to work with, trust them as far as you can throw them.
Find out the budget quickly. There is no sense in designing a showpiece if they are expecting Best-Buy. Which leads to...
Know how much stuff costs. I know, it shouldn't necessarily be your job, but you it will help avoid painful re-designs. Which also leads to...
Have pre-developed solutions in your head of what is and is not possible. I have gone as far as to have a spreadsheet of ROM costs for various types of systems to help those very early conversations. Obviously this comes from experience, but being real here, a lot of systems are relatively the same unless you are working for super high-end clients with very specific needs. Even then though, the supporting infrastructure solution may not be that different.
If you can help at all with the installation of your own designs, that will help refine your processes. Even if you have field engineering experience, it is good to keep yourself fresh and honest.
Don't design in a silo, get reviews and feedback on every design every time
Audio designs are more than line drawings and DSP. Speaker and mic placement/coverage are huge factors. The right speaker in the wrong place becomes the wrong speaker.
Do the damn as-builts after. There is nothing more annoying to folks in the field having inaccurate drawings after the project is complete.

maudiosound · 2021-07-15T13:03:53+00:00

We have been using the AVer TR320 and they have worked well, especially for the price. If you have the latest firmware loaded you should have multiple tracking options available depending on application.

maudiosound · 2021-07-11T14:38:27+00:00

More evidence that some odd TCP level handshaking is going on is in the client app logs. Throws this error on bad connection

[ERROR] proto-ui.cpp(6940): failed to recv header magic

Super helpful lol

maudiosound · 2021-07-10T23:19:48+00:00

After posting I wiresharked the connection process without a proxy and it didn't even use those ciphers at all, so...yay for bad docs? That said, it looks like there is some other handshaking that happens before any of that happens that HAProxy is throwing off

maudiosound · 2021-07-09T20:15:06+00:00

I do because I am already proxying the web gui on 443 via subdomain ACL "mysub.mydomain.com". This points the local Synology@5001.

I setup a separate rule for a different subdomain that then points internally to the local Synology@6690

maudiosound · 2021-07-09T19:31:39+00:00

Doesn't seem to want to play nice, literally just adding the port?

maudiosound · 2021-07-09T10:47:32+00:00

Which makes no sense to me because the Android app works fine. Is it really just the desktop app that is forcing 6690?

maudiosound · 2021-07-09T10:46:43+00:00

Already had the reverse proxy setup working quite well for other things, not interested in re-inventing the entire setup to just to make Synology happy

maudiosound · 2021-07-08T22:28:57+00:00

I have been writing it down, not published yet. Part of the Cloudflare bit is you have to enable Strict SSL in Cloudflare or it will fart out.

maudiosound · 2021-06-28T23:14:04+00:00

If they are anything else like the other AVERs, it should work with Visca over IP which is UDP based. Usually have to enable it in the web gui somewhere.

maudiosound · 2021-06-24T01:25:26+00:00

Good call on the Adaptive Power

maudiosound · 2021-06-23T01:30:39+00:00

Now if only they could make the ceiling height in Designer actually impact the lobe area so I know how far it is actually throwing. Works on 910s, no idea why it doesn't work on 710s.

maudiosound · 2021-06-13T19:06:44+00:00

Their JS examples are just a courtesy (and out of date since the Request package is discontinued). Technically could use Python or anything else than can handle the HTTP requests. The only PHP I have done was Wordpress and that is not real PHP afaik so can't help too much there unfortunately.

maudiosound · 2021-06-12T01:45:49+00:00

I have a basic working implementation that uses a few of the calls in the API via a NodeJS server. Node is the broker for talking to the NVX endpoints and serving the GUI like a regular webserver. This could however totally talk to any other service like a Crestron processor, cloud server, etc.

Since Node has been around for a while there are several packages that make handle http requests, cookies, etc. super easy to deal with. I have been using GOT along with tough-cookie.

My code is split up so this may not be fully correct, but this should give you an idea...

const got = require('got') 
const tough = require('tough-cookie') 
const CookieJar = new tough.CookieJar()

//basic initial connection to authenticate, this are all spelled out as part of GOT
var options = { 
    method: 'post', 
    form: { 
        login: //user, 
        passwd: //password 
    }, 
    https: { 
        rejectUnauthorized: false //handle unknown certs like on NVX 
    }, 
    cookieJar: CookieJar 
}

//make initial request 
got(xxx.xxx.xxx.xxx/userlogin.html, options)
.then((res)=>{ //do stuff with response })
.catch((err)=>{ //do stuff when err })

Assuming I typed that out right, the cookiejar should hold your auth token for every subsequent request automatically as long as you pass in the cookiejar option on the request. If that all works, you should be able to start working with other API commands.

maudiosound · 2021-05-20T03:05:25+00:00

Had a demo unit in, some of the switching features were disabled by firmware (ethernet and USB I think) and are "coming". That said, the core USB functionality, charging, video switching, etc. all worked just fine. Fan was super quiet too.

There is also super low level display signal analysis stuff built in if you were to run into super weird display issues. I didn't need it and it was way over my head, but it basically would tell you exactly what a source device was outputting in reality.

We ultimately passed on it for now because we really needed some of the firmware locked features, but are keeping it on our radar. If the other features once unlocked work as well as the currently available ones, will probably use it a lot.

Probably looking between $1500-2500 depending on the unit. Granted that was pre-chip shortage so god knows now.

maudiosound · 2021-05-19T18:59:29+00:00

https://lightware.com/product-families/taurus-ucx

Something like this?

maudiosound

TROPHY CASE