Bug or misconfiguration of colibri-ws Proxy?

[gjaekel]

On my approval stage currently using v1_1_1.20201124-222400, I just discovered the messages

20201126-103347.534 INFO  [Jetty-QTP-BOSH-55434] [ProxyConnection] ProxyConnection ws://10.10.1.137:8080/colibri-ws/default-id/4795dec25903761b/bae75517?pwd=2k0uanbntvov7f0jot24ln6feh null
20201126-103347.554 ERROR [HttpClient@78d78009-55808] [ProxyConnection] Error: Connection refused
java.net.ConnectException: Connection refused
        at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method) ~[?:1.8.0_262]
        at sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:714) ~[?:1.8.0_262]
        at org.eclipse.jetty.io.SelectorManager.doFinishConnect(SelectorManager.java:355) ~[jetty-io-9.4.28.v20200408.jar:9.4.28.v20200408]
        at org.eclipse.jetty.io.ManagedSelector.processConnect(ManagedSelector.java:232) ~[jetty-io-9.4.28.v20200408.jar:9.4.28.v20200408]
        at org.eclipse.jetty.io.ManagedSelector.access$1400(ManagedSelector.java:62) ~[jetty-io-9.4.28.v20200408.jar:9.4.28.v20200408]
        at org.eclipse.jetty.io.ManagedSelector$SelectorProducer.processSelected(ManagedSelector.java:543) ~[jetty-io-9.4.28.v20200408.jar:9.4.28.v20200408]
        at org.eclipse.jetty.io.ManagedSelector$SelectorProducer.produce(ManagedSelector.java:401) ~[jetty-io-9.4.28.v20200408.jar:9.4.28.v20200408]
        at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.produceTask(EatWhatYouKill.java:360) ~[jetty-util-9.4.28.v20200408.jar:9.4.28.v20200408]
        at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:184) ~[jetty-util-9.4.28.v20200408.jar:9.4.28.v20200408]
        at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:171) ~[jetty-util-9.4.28.v20200408.jar:9.4.28.v20200408]
        at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.produce(EatWhatYouKill.java:135) ~[jetty-util-9.4.28.v20200408.jar:9.4.28.v20200408]
        at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:806) [jetty-util-9.4.28.v20200408.jar:9.4.28.v20200408]
        at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:938) [jetty-util-9.4.28.v20200408.jar:9.4.28.v20200408]
        at java.lang.Thread.run(Thread.java:748) [?:1.8.0_262]

But port 8080 is just bound to localhost for the JVB-JVM.

[gjaekel]

So this was a bug?

[deleolajide]

I don't know. I had the same issue trying to access the colibri rest service for the conference statistics. In the end I used localhost. It is working ok on my dev windows pc as well as pade.chat linux docker instance, so it stays for now until it becomes an issue elsewhere.

The websockets data-channel is not mandatory for JVB2 to work, but the jitsi-meet needs the connection in order to receive conference events like active speaker, etc.

[gjaekel]

I definitely need to support again Jitsi-Meet for iOS and Android as well because it was in common use as long as the newer version don't work with our OFMeet V1.0 / JVB1 instance at production. This happens about start of November. And about mid of last week, Chrome for iOS was also updated and with this any coworker using an iOS device get banned.

For this reason, thank you for the patch.

[gjaekel]

Sorry, please reopen, because I have still problems with the colibri websocket proxy.

The port open to the internet is 443, it is local redirected to 7443. If I request the client's config.js, it shows the right information.

gjaekel@vz370 ~ $ wget -qSO- https://miet.dnb.de/config.js |& grep -i websocket
  "websocket": "wss://eval.xmpp.dnb.de:443/ws/",
  "openBridgeChannel": "websocket",     

But inside the clients js console, I get error messages concerning a try to connect to port 7443.

lib-jitsi-meet.min.js:15686 WebSocket connection to 'wss://eval.xmpp.dnb.de:7443/colibri-ws/default-id/e7d92f32562da35f/ec00fa24?pwd=60v2a3vvc7imquq3jkln9esfrt' failed: Establishing a tunnel via proxy 

Is this caused by a "wrong" upgrade message based on the local view?

[gjaekel]

I found in the server log

20201128-175739.822 INFO  [Thread-88] [o.j.o.p.o.JvbPluginWrapper] INFO: [1] ColibriWebSocketService.<init>#40: Base URL: wss://eval.xmpp.dnb.de:7443/colibri-ws/default-id
20201128-175739.838 INFO  [Thread-88] [o.j.o.p.o.JvbPluginWrapper] INFO: [1] org.eclipse.jetty.util.log.Log.initialized: Logging initialized @1166ms to org.eclipse.jetty.util.log.JavaUtilLog
20201128-175739.950 INFO  [Thread-88] [o.j.o.p.o.JvbPluginWrapper] INFO: [1] ColibriWebSocketService.registerServlet#65: Registering servlet at /colibri-ws/*, baseUrl = wss://eval.xmpp.dnb.de:7443/colibri-ws/default-id

This may be the root cause.

[gjaekel]

Just discovered https://github.com/igniterealtime/openfire-pade-plugin/blob/master/ofmeet/src/java/org/jivesoftware/openfire/plugin/ofmeet/JvbPluginWrapper.java#L79 !

final String public_port = JiveGlobals.getProperty( "httpbind.port.secure", "7443");

That's also the property used for the main https server; i.e. changing this value will affect other things.

I think, we have to change
https://github.com/igniterealtime/openfire-pade-plugin/blob/master/ofmeet/src/java/org/jivesoftware/openfire/plugin/ofmeet/JvbPluginWrapper.java#120

 "      domain = \"" + JiveGlobals.getProperty( "ofmeet.websockets.domain", domain) + ":" + public_port + "\"",

Proposed a patch.

[gjaekel]

This should fix my problem: I simulate it by editing the generated application.conf (replace the port 7443 by 443) and set it read-only. After a restart, the exceptions at the clients vanished.