any way to specify the client ip?

[hradec]

No description provided.

[hradec]

I was wondering is there's any way to setup an specific client IP on the ALVR Server.

I've tried to add the ip to the user config file, in here:

<setting name="autoConnectList" serializeAs="String">
         <value>[192.168.10.190]</value>
</setting>

but every time I start ALVR server it seems to ignore that ip, and resets it the value back to []. According to the source, it should read the list back, but maybe the value here is not just the IP address?

anyhow... I need this because I want to run ALVR server on a cloud machine on google cloud computing and have it connecting on my Oculus GO over zerotier, but without using a openwrt router.

I can ping the oculus go IP from the google machine without problem (I'm using IP tables on a machine on my local lan to route the packets to the oculus), but since the ALVR server doesn't known about the 192.168.10.0/24 subnet, it never finds it.

If I could just "force" it to try and connect to the specific IP, everything should be sorted out without an openwrt router!! Much simpler!

any ideas?

[fxsrt10]

Did you end up making headway on this? I'm doing the same but using azure

[hradec]

YES!

1. I ended up hacking the code initially, hard-coding the google cloud VM ip address directly into the ALVR Client, and opening the UDP 9944 port in the VM as well... Worked like a charm, and I've played Elite:Dangerous for hours using it and parsec for my keyboard and mouse!

Having it connecting DIRECTLY to the internet IP address over UDP gives you a much faster connection than using zerotier, btw! Pretty much the same as running locally!

I'm planning to add some UI in the ALVR Client to setup the server IP, but not sure when... no time to do it now!

---

2. Alternatively, I ended up using a little linux utility called uredir, which essentially allows you to redirect multicast UDP packets (which is what ALVR is throwing out in the local network) coming on a specific port to any IP address!

This way, I can use the ALVR from the oculus store (no code changing) and have my linux machine (which is the one I'm using to play) redirecting the UDP packets to the google cloud VM.

Again, it's pretty much the same as ALVR connecting directly to google... no lag, really fast!

---

3. Using uredir I was also able to get the Nolo Home (I own a nolo cv1) app for the oculus go connect to the google cloud machine as well. Since the Nolo Home essentially have ALVR built in it, I just had to redirect an extra UDP port used by the PC Nolo Home server to initiate the connection with the oculus. I was able to have SteamVR being streamed to the Oculus Go correctly, but unfortunately the actual nolo devices wasn't recognized by the PC server, for some reason... I'm in talks with the Nolo dev team to figure out if theres an extra port that needs to be redirected, etc; so hopefully, we will get full head/controller tracking with Oculus Go in the cloud! ;)

Conclusion:

Summing up, I would recomend you to go the uredir route, to be honest... simpler, fast and cleaner!
https://github.com/troglobit/uredir

just clone it, configure and make and you will have it! (if you're in linux that is... ;)

to redirect the UDP 9944 port, you can use this command line:

uredir -n :9944 <vm internet ip address>:9944

Since you have to re-run the command line when you close Oculus ALVR, I actually use this little bash one-liner to keep re-running uredir in case it exits:

 while true ; do echo 1 ;  echo $( sudo nice -n -19 uredir -n :9944 <vm internet ip address>:9944 ) ; done

this way if uredir closes, the while starts it again and you don't have to bother... just leave it open in a minimized shell.

I'm also using sudo nice -n 19 to force uredir to run with the highest priority possible in linux, preventing any loss of packets due to high processing or high I/O.

If you want to try with the Nolo Home, to redirect the extra UDP port, use this command:

 while true ; do echo 1 ;  echo $( sudo nice -n -19 uredir -n :13789 <vm internet ip address>:13789 ) ; done

don't forget to open up/forward the UDP ports to your VM, or else the VM will never receive the data sent from uredir!

if you have any more question, let me known!

---

btw, how much are you paying for the azure gpu machine?

It costs around USD 0.8/Hour for a 4 core/15GB ram/NVidia P4 Workstation machine at google due to the expensive nvidia vGPU license fee they charge for the "workstation" gpu version, and the expensive Windows Server license fee.

I was actually able to boot Windows from a Linux VM (so no windows server license fee) using GRUB chainloader, so that can push the cost down to USD 0.268/Hour, using the same 4 core/15Gb ram/Nvidia P4 (no workstation, so no vGPU license fee either). But without the vGPU license, I'm limited to 1280x720 resolution... and NVEncoder performance is not that good.

An option to get full resolution without paying for license is to get a 180 days trial license directly from Nvidia for they vGPU and run my own license server. But this way I have to re-new the license key every 30 days I think, for a maximum of 180 days... a bit sketchy and high maintenance! (And I didn't do it yet... no time)

I'm currently using the LinuxVM (booting windows through grub chainloader), but switch the GPU to the "P4 Workstation" gpu, which comes with the vGPU license server. That push the price up to USD 0.457/Hour, which is still cheaper than a Parsec VM, But I get full resolution and encoder speed!

USD 0.468/Hour is still cheaper than getting a parsec VM though...

But my goal is to go full blow USD 0.268/Hour!! :)

PS: those prices include 200GB storage space!

[fxsrt10]

Mind if you can direct me to where you modified the ip address? I'd love to see if I can pull it off

and here's the pricing: It's overkill mainly because we're trying to see if we can scale up for enterprise
NV6

Also THANK YOU SO MUCH FOR THE RESPONSE,I've been trying to solve this for awhile now!

[hradec]

sure, here it is:

just change 234.10.20.45 to your Azure VM IP address!

the file is this:
app/src/main/java/com/polygraphene/alvr/UdpReceiverThread.java

I've used the actual 2.3.1 released source code for ALVRClient, since the server on the PC is 2.3.1 version!
https://github.com/polygraphene/ALVRClient/archive/v2.3.1.tar.gz

[jorgeazevedo]

@hradec thanks for the great information here! I've been trying to replicate your uredir based setup using the official v2.4.0-alpha4 binaries (I can't get the android client to compile for some reason, so I can't hardcode the IP directly).

I'm very close to getting it working. I can see in Wireshark the UDP packets from my Quest arrive in my windows VM. The headset shows up in the ALVR GUI, I can click the connect button and it goes through OK. The GUI presents the IP address, the resolution etc for the Quest. So it's all good except when I boot SteamVR and the driver loads, it doesn't connect to my Quest.

The reason is the memory mapped file that the UI uses to communicate with the SteamVR driver doesn't have the device information there. If I go to the Debug tab and click GetConfig, the dump says

Connected 0
Client 0.0.0.0:0
ClientName
Streaming 0
[...]

Which is odd because in my Server tab I can see the IP and Port and everything. So the UI is definitely loading it, it's just not committing it to the file properly. Did you experience this behaviour at all in your setup?

[hradec]

did you started steamvr by clicking "stark server" in the alvr ui?

…

On Tue, May 28, 2019 at 16:54 Jorge Azevedo ***@***.***> wrote: @hradec <https://github.com/hradec> thanks for the great information here! I've been trying to replicate your uredir based setup using the official v2.4.0-alpha4 binaries (I can't get the android client to compile for some reason, so I can't hardcode the IP directly). I'm very close to getting it working. I can see in Wireshark the UDP packets from my Quest arrive in my windows VM. The headset shows up in the ALVR GUI, I can click the connect button and it goes through OK. The GUI presents the IP address, the resolution etc for the Quest. So it's all good except when I boot SteamVR and the driver loads, it doesn't connect to my Quest. The reason is the memory mapped file that the UI uses to communicate with the SteamVR driver doesn't have the device information there. If I go to the Debug tab and click GetConfig, the dump says Connected 0 Client 0.0.0.0:0 ClientName Streaming 0 [...] Which is odd because in my Server tab I can see the IP and Port and everything. So the UI is definitely loading it, it's just not committing it to the file properly. Did you experience this behaviour at all in your setup? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#232?email_source=notifications&email_token=AAGE6VYB5NAOE6XP2DI345TPXXAZ3A5CNFSM4GL7BQC2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWNYOSQ#issuecomment-496731978>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAGE6V4SS4AQZESAVKJP72LPXXAZ3ANCNFSM4GL7BQCQ> .

[jorgeazevedo]

Good shout! I did, in theory the callback for that button should save the configuration correctly before booting Steam. I wonder if something is making it skip that step

[jorgeazevedo]

OK I've dug around a bit more and I can see I've misunderstood the problem a bit. uredir redirects the UDP to my VM alright, but somehow the packets that arrive there have a unique random SRC port assigned rather than 9944. So ALVR thinks every packet comes from a different device! That's why the driver doesn't connect, it's waiting for a hello packet to come in with a rando port number that never comes.

Any idea what could be doing this? I'm not sure if uredir is changing it, or if it's my router or...

[jorgeazevedo]

After digging around in the source for uredir, I suspect it's because I'm running it on a raspberry pi and the project was focused on x86. I've reverted backed to arm wrestling with the Android client and I got it to work!! Thanks for sharing your patch!

[Zetaphor]

@jorgeazevedo This is a brilliant idea I never would have considered. Once you get things in a proper working state, I (and I'm sure others) would be willing to make a Patreon donation or a bounty payment for you to setup an install script and make the VM setup and management process as automated as possible

What kind of latency are you getting? What is your connection speed?

[leonardodtang]

Could you explain how hard coding the IP address into the ALVR client directly allowed you to send UDP packets through port 9944 to the server? Or how uredir manages to achieve a similar situation?

From what I understand, ALVR uses multicast UDP packets to detect clients, so the server and the client normally have to be on the same local network in order to communicate. To run ALVR on a cloud machine, that would require putting the multicast UDP packets on the public internet, which isn't usually possible without a tunnel.

Lately I've been trying to run the ALVR Client v2.4.0-alpha5 on an Oculus Quest connected to the Internet by an LTE server along with the ALVR server v2.4.0-alpha5 on a Windows 10 machine connected by 5Ghz wifi. Since uredir is a Linux utility, I've been trying to hardcode the Windows 10 machine's public IP into app/src/main/java/com/polygraphene/alvr/UdpReceiverThread.java at the line specified by @hradec, but when starting the modified ALVR client on the Quest, it doesn't show up on the ALVR server. If I switch from the LTE server to the wifi network, the Quest is able to communicate with the server. On the wifi network, I've opened up ports 9943 and 9944, and I was able to see UDP packet activity on those ports, but I don't know if the multicast UDP packets were being broadcast from the server or from the client.

[hradec]

hardcoding the IP only works in a local network or if you known how to redirect ports from the local network to another remote one. What I did was change the broadcast IP to the actual IP of the machine that is going to forward the packets to another one, remotely on the WAN. You can't hardcode an internet IP address directly, since the internet doesn't do multicast UDP. But you can hardcode the IP to a machine on your local LAN, and have that one forwarding the packets to the ip/port of the remote machine, direcly. That's where uredir comes in... you need to use uredir to redirect those UDP packets from the local lan machine to the remote one.

…

On Tue, Jul 2, 2019 at 3:00 PM leonardodtang ***@***.***> wrote: Could you explain how hard coding the IP address into the ALVR client directly allowed you to send UDP packets through port 9944 to the server? Or how uredir manages to achieve a similar situation? From what I understand, ALVR uses multicast UDP packets to detect clients, so the server and the client normally have to be on the same local network in order to communicate. To run ALVR on a cloud machine, that would require putting the multicast UDP packets on the public internet, which isn't usually possible without a tunnel. Lately I've been trying to run the ALVR Client v2.4.0-alpha5 on an Oculus Quest connected to the Internet by an LTE server along with the ALVR server v2.4.0-alpha5 on a Windows 10 machine connected by 5Ghz wifi. Since uredir is a Linux utility, I've been trying to hardcode the Windows 10 machine's public IP into app/src/main/java/com/polygraphene/alvr/UdpReceiverThread.java at the line specified by @hradec <https://github.com/hradec>, but when starting the modified ALVR client on the Quest, it doesn't show up on the ALVR server. If I switch from the LTE server to the wifi network, the Quest is able to communicate with the server. On the wifi network, I've opened up ports 9943 and 9944, and I was able to see UDP packet activity on those ports, but I don't know if the multicast UDP packets were being broadcast from the server or from the client. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#232?email_source=notifications&email_token=AAGE6VYC7J554N7RHYSYE6LP5PFXFA5CNFSM4GL7BQC2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZCVO4Q#issuecomment-507860850>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAGE6V5BFH2PPTEFIE3PEBLP5PFXFANCNFSM4GL7BQCQ> .

[leonardodtang]

So I would need to spin up a linux VM on any machine on the same local network as the Oculus Quest, and use uredir to redirect the UDP packets on port 9944 of the local network to the 9944 port of the public IP of another remote machine for computation?

From looking at Wireshark, the UDP packets are only sent after the server successfully finds the Oculus on the local network and you click start server. This would suggest that the ALVR server on the PC and the ALVR client on the Oculus still have to be on the same local network. Was your google cloud machine purely for computational power, or did you have SteamVR and the ALVR server running on the cloud machine? I was attempting to run the ALVR client on a completely different local network than the machine with the ALVR server and SteamVR, so that may be why I haven't been seeing any success.

In the case that the server and client are on the same local network and the cloud machine is purely for computation, what code is running on the remote machine to achieve this?