I´m trying to connect to a RCP-Server via Remote-Client on another device using the same network.
There was no problems connecting using localhost and 127.0.0.1 as host-address, but as soon as I try using another IP in the same network, I can´t establish a connection.
Even using the IP (192.168.1.100 in this case) on the same computer the rabbit is running on doesn´t work. Switching to the IP of my WiFi-Adapter doesn´t work either.
Are you sure you don’t have an antivirus running, or something that can block?
Is remotes are pinging each other?
Have you try to use MAC address instead?
Yes, I’m sure.
I deactivated my third party AV, Windows Defender firewall, the routers firewall.
I can ping my local network-device via IP, my iPhone via PC, my PC via iPhone.
Mac-Address as hostname in browser doesn´t work either…
The only thing running is localhost/127.0.0.1
so let’s try to be very specific. here is what i do:
run beta40, open Rabbit helppatch
on same PC run firefox, open the webclient hit “Connect”
→ works
run beta40, open Rabbit helppatch, change 0.0.0.0 to actual IP (192.168.0.5)
on same PC run firefox, open the webclient, use actual IP as set in helppatch, hit “Connect”
→ works
run beta40, open Rabbit helppatch
on mobile on same wifi run firefox, open the webclient, use actual IP of PC running vvvv, hit “Connect”
→ works
regarding firefox:
note this message on the client:
also note: latest update to firefox mobile doesn’t allow you to run about:config. so either use an older ff or use latest firefox beta, which still allows you to change the setting.
I used Chrome and Edge instead of FF on PC and Chrome/Safari on my phone.
Doesn´t work. There doesn´t seem to be a chrome://flags - item to allow insecure ws and the alert does only show the first paragraph of the Firefox-message you posted.
In the end it seems to have something to do with my PC or the routers settings.
I am not quite sure, what I am missing, though.
I checked any usual suspects like firewall-stuff etc.
I´ll be back to office tomorrow (home-office right now) and see, if I get it up and running in a different network and with another PC.
I didn´t get rcp up and running by any means.
As I think, this problem needs a proper reinstall of my pc and I am not able to do this, I ´ll gave up on rcp and switched to mqtt. This lead me to another problem I will post to another thread in a moment: seems like I can´t connect to a secure mqtt broker within vvvv :-(
After installing Update 2004 today, I now can connect to rabbit within firefox using my IP.
Still no luck using any other device within my network, though.
I just used tablet and telephone with different browsers and didn´t get any connection, as this is, what i´d need to be able to use. I switched to mqtt instead and besides having some problems with ssl it´s working fine. Couldn´t figure out, what the problem using rcp was in the end, but that´s kinda okay at the moment.
did you try mobile “firefox beta” as i described above? it still allows you to run about:config to set the mentioned https flag. would be interesting to hear if that works for you.
You need to allow insecure connections, this actually pretty good case study why any web server still allow that but the one started on vvvv, I think vvvv side should provide some more headers to browser
@joreg currently waiting for a beta-key for testdrive to be able to use ff beta in my iPhone and I am setting up an old android to check back either.
@anthokhio actually not, as I did set all the possible flags before the update and it didn´t work then. It´s more like a detective story now. ;-)
As it seems to correspond with my other question concerning secure websocketbased mqtt:
wouldn´t the right way to go be trying to find possibilities to use secure connections?
I am not the one to really know, but secure websocket seems to be a possible thing in IoT via mqtt
At least Chrome doesn´t seem to be going back to allow insecure connections.
And that´s quite a wide spread browser. So if you want to use this for let´s say an audience to poll or control some stuff, it won´t work the way it does right now…
…doesn´t mean it´s not a problem with my network settings being f§$%&ed up too in this case… ;-)
absolutely! the right way to go about this is figure out secure websocket support for rcp. it is only that there was no time yet to do this. just in case: rcp is all opensource, so if you have the means…we accept pullrequests!
