I have a Debian Buster system, not behind NAT, but acting with existing virtual apache and prosody names. I installed jitsi, following the quick install install document and it all seemed to go very smoothly, and I saw the the inital page, and can create a test meeting from a client, but when I try to join that meeting from another client, but client meetings show an ‘Unfortunately something went wrong’ message and try to reconnect
On the server I have, in jvb.loc, whether clients are connected or nor, a constant stream of
2020-03-28 19:02:47.887 INFO: [23] [hostname=localhost id=shard] MucClient.lambda$getConnectAndLoginCallable$7#648: Logging in.
2020-03-28 19:02:47.887 SEVERE: [23] RetryStrategy$TaskRunner.run#198: org.jivesoftware.smack.sasl.SASLErrorException: SASLError using SCRAM-SHA-1: not-authorized
org.jivesoftware.smack.sasl.SASLErrorException: SASLError using SCRAM-SHA-1: not-authorized
at org.jivesoftware.smack.SASLAuthentication.authenticationFailed(SASLAuthentication.java:292)
The prosody server log shows
callcontrol.jitsi.mydomain:component warn Component not connected, bouncing error for:
which I suspect is related.
The main thing where I differ from the instructions is that I have not changed /etc/hostname to match the jitsi alias of the machine, as I fear changing it will break a number of other things.
I would like to understand what that step really does before I try that.
This means that jvb uses wrong password to connect to prosody, not sure where did the install process failed, but I tested clean install on Debian 10 and it was working fine … if you can think of some detail that can break it … which version of prosody do you use?
Does password in prosody and jvb config match?
That is not important … This is the component that can be used for jigasi, did you also install and jigasi?
Have you done any other steps then those described in the quick install guide? What jitsi-meet version did you had installed before that? Any custom changes?
I’m trying to figure out what’s wrong …
We install jigasi after we read your comment but nothings change. We follow every steps in quick install.
You can see our installed packages below:
jitsi-meet/stable,now 1.0.4335-1 all [installed]
jitsi-meet-prosody/stable,now 1.0.3928-1 all [installed,automatic]
jitsi-meet-web/stable,now 1.0.3928-1 all [installed,automatic]
jitsi-meet-web-config/stable,now 1.0.3928-1 all [installed,automatic]
jitsi-videobridge2/stable,now 2.1-157-g389b69ff-1 all [installed,automatic]
jvb log:
2020-03-29 19:02:09.647 INFO: [23] [hostname=localhost id=shard] MucClient.lambda$getConnectAndLoginCallable$7#648: Logging in.
2020-03-29 19:02:09.647 SEVERE: [23] RetryStrategy$TaskRunner.run#198: org.jivesoftware.smack.sasl.SASLErrorException: SASLError using SCRAM-SHA-1: not-authorized
org.jivesoftware.smack.sasl.SASLErrorException: SASLError using SCRAM-SHA-1: not-authorized
at org.jivesoftware.smack.SASLAuthentication.authenticationFailed(SASLAuthentication.java:292)
at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader.parsePackets(XMPPTCPConnection.java:1100)
at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader.access$300(XMPPTCPConnection.java:1000)
at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader$1.run(XMPPTCPConnection.java:1016)
at java.lang.Thread.run(Thread.java:748)
By the way, when we try to install to install jitsi on clean Ubuntu OS with your following quick install guide, we cant install turnserver. This machine does not have nginx before installation and any other web server application. So our 443 port is not in use and has no conflict. To fix this issue we install jitsi with “apt install --no-install-recommends jitsi-meet” this command.
Lastly, we had been working with the previous version of jitsi-meet and we had no problems at all. With the new release that timestamp of 2020-03-27 21:57 we started to have the above installation problems.
I did try installing and then removing jigasi, so that is probably left over from that. I did not have jitsi-meet installed before. My prosody setup was installed under stretch, some time ago, and upgraded with the system to buster, so it could differ from a clean prosody install.
I first installed in my local network as explained in the quick install guide: everything ok, I can call from PC to PC
I purged the installation, changed the hostname and reinstalled:
I had to change the ssl port to 4443, otherwise nginx complain about some service listening on 443 (which service I don’t know, “ss -tlnp” shows nothing)
I can start the conference but I don’t see any media or I can do anything, neither close the connection; after some time disconnect and reconnect, etc.
I get the following error in jvb.log (every few seconds):
2020-03-29 19:00:23.541 INFORMAZIONI: [19] Videobridge.createConference#326: create_conf, id=626b20db847d86c5 gid=null logging=false
2020-03-29 19:00:23.552 INFORMAZIONI: [19] Health.doRun#294: Performed a successful health check in 12ms. Sticky failure: false
2020-03-29 19:00:25.013 INFORMAZIONI: [24] [hostname=svezia.dlinkddns.com id=shard] MucClient.lambda$getConnectAndLoginCallable$7#648: Logging in.
2020-03-29 19:00:25.013 GRAVE: [24] RetryStrategy$TaskRunner.run#198:
org.jivesoftware.smack.sasl.SASLErrorException: SASLError using SCRAM-SHA-1: not-authorized
at org.jivesoftware.smack.SASLAuthentication.authenticationFailed(SASLAuthentication.java:292)
at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader.parsePackets(XMPPTCPConnection.java:1100)
at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader.access$300(XMPPTCPConnection.java:1000)
at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader$1.run(XMPPTCPConnection.java:1016)
at java.base/java.lang.Thread.run(Thread.java:834)
I already double checked Prosody password for user jvb@svezia.dlinkddns.com
I can’t found any other error in the log files. Let’s encrypt certificate ok (using bundled script).
There is some other information I can send to help find the error?
I am not sure what fixed it in the end, unfortunately. I fired up an internal test VM, using KVM on my home machine - with slightly mixed results - I suspect as it did not have a real certificate (and being on a 192.168 address behind NAT, but with other systems already using the 443 port it would be tricky to get one. I compared its clean install values with those on my externally hosted server, and could not see anything which could be the problem, so I rebooted my server and after the reboot it seems to be working, so I am going to start inviting people to meetings to test
I have the exact same problem on a linux mint 18.3 machine. Trying to run it next to an existing website as meet.radioloogonline.nl.
Tried installing it on a seperate server also running mint 18.3 with same result.
Hi, guys, thanks for your support so far. I’ve ran in to this issue as well after the upgrade from jvb to jvb2 (stable debian packages) and indeed prosody passwd resolved this error. However, a new one arose: The jvb log now shows:
org.jivesoftware.smack.SmackException: No supported and enabled SASL Mechanism provided by server. Server announced mechanisms: . Registered SASL mechanisms with Smack: [SASL Mech: GSSAPI, Prio: 100, SASL Mech: SCRAM-SHA-1-PLUS, Prio: 100, SASL Mech: SCRAM-SHA-1, Prio: 110, SASL Mech: DIGEST-MD5, Prio: 200, SASL Mech: CRAM-MD5, Prio: 300, SASL Mech: PLAIN, Prio: 400, SASL Mech: X-OAUTH2, Prio: 410, SASL Mech: EXTERNAL, Prio: 500, SASL Mech: ANONYMOUS, Prio: 500]. Enabled SASL mechanisms for this connection: null. Blacklisted SASL mechanisms: [SCRAM-SHA-1-PLUS].
The end result by the way is just the same: No video bridge, so no video conference. Participants get kicked out.
This happens on an (upgraded) debian stable package (now with videobridge2).
Our setup is using SSL offloading at the loadbalancer so the prosody does not have the ‘real’ certificate, just a bunch of snakeoil - Feels like that might be related. I did set org.jitsi.videobridge.xmpp.user.shard.DISABLE_CERTIFICATE_VERIFICATION=true
Hope the community can provide a hint as to how I can resolve this?