Connection to murmur server 1.3.4 with serverpassword not possible

[karstengit]

Description

I installed "mumble-server 1.3.4-1" in Debian 11 (bullseye) via package on an internal server.
In the config mumble-server.ini the serverpassword is set.

I can connect with an client 1.3.4 without problems.
On another PC the client asked for the server password and afterwards the login works.

Now a friend tries to login from outside with a client 1.3.0 and the connection is always refused.
There is no pop-up window asking for the server password!

Where this server password is stored for the client?
It cannot be found in any settings in the client?

Steps to reproduce

1.Enter the needed informations for the server connection for a new server
2. Try to connect
3. Connection always fails

Mumble version

1.3.0 for the client
1.3.4 for the server

Mumble component

Client / Server combination

OS

Linux

Reproducible?

Yes

Screenshots

As you can see in the screenshot the connection works with the same client and server configuration, but with an older server version 1.2.18-1~bpo8+1 running on an different server that is in migration.

[Krzmbrzl]

I can connect with an client 1.3.4 without problems.
On another PC the client asked for the server password and afterwards the login works.

Does that mean that the 1.3.4 client connected successfully without having asked for the password?

Where this server password is stored for the client?
It cannot be found in any settings in the client?

You could try using SuperUser as the username. Normally that should convince the connect-dialog to show you an additional password field when editing your server's entry in your favorites. Maybe that allows to enter a different password (or clear any password that might be restored in there to (hopefully) prompt Mumble to re-ask you).

And just to make sure that the issue is actually the password set on the server: Could you check if the mentioned client is able to connect to your server if the serverpassword is removed?
(Note that in order to remove the password from the server again, it might be necessary to use Ice, change the server's DB manually or delete the DB - a simple change in the ini might not be enough (the ini usually only provides defaults for server configuration))

[karstengit]

Thanks for the quick reply!

I can connect with an client 1.3.4 without problems.
On another PC the client asked for the server password and afterwards the login works.

Does that mean that the 1.3.4 client connected successfully without having asked for the password?

Yes - my client did not ask and the connection did work.
But my user is Admin.

The other client that works is on Debian 10 with client V 1.3.0

You could try using SuperUser as the username. Normally that should convince the connect-dialog to show you an additional password field when editing your server's entry in your favorites. Maybe that allows to enter a different password (or clear any password that might be restored in there to (hopefully) prompt Mumble to re-ask you).

This works in my client.
Is ask my friend to try this hack.

And just to make sure that the issue is actually the password set on the server: Could you check if the mentioned client is able to connect to your server if the serverpassword is removed? (Note that in order to remove the password from the server again, it might be necessary to use Ice, change the server's DB manually or delete the DB - a simple change in the ini might not be enough (the ini usually only provides defaults for server configuration))

In my client there is no password shown in the hidden field.
After altering the user back it still connects.

Can you explain this concept?

[Krzmbrzl]

But my user is Admin.

Admin as in SuperUser or as in "has Write ACL permission?

In my client there is no password shown in the hidden field.
After altering the user back it still connects.

So you mean that you changed your username to SuperUser but the password field that showed up was empty but when changing your username back again you were still able to connect?

[karstengit]

But my user is Admin.

Admin as in SuperUser or as in "has Write ACL permission?

I must research, because i have simply copied the mumble-server.sqlite from the old system i created 5 years ago and altered the config file of the new system ... :-)

My user is not the superuser, it has user_id 1.
My user is member of the group admin.

This superuser has an user password - is this the password that is entered in the setup of the server in the client?

But this cannot be identical with the server password!?

In my client there is no password shown in the hidden field.
After altering the user back it still connects.

So you mean that you changed your username to SuperUser but the password field that showed up was empty but when changing your username back again you were still able to connect?

Yes. When i alter my username to superuser the password field appears. It is empty.

The friend says that the field password does not appear in his client.
I asked him to send an screenshot.

[Krzmbrzl]

This superuser has an user password - is this the password that is entered in the setup of the server in the client?

Yes

But this cannot be identical with the server password!?

It probably can be, but I guess that in general it is not. (Note that what you are seeing in the DB is only the password's hash)

Alright, I guess to further proceed, it would probably be best, if you were to remove the password from your server again and then check whether your friend is able to connect to your server.
Also, please ask them to start Mumble from the console and then copy&paste the stuff that gets written to it when he tries to connect to your server, but is refused. Maybe the logs can tell us something interesting 🤔

[karstengit]

Hmmm - all the time there was no problem with the serverpassword, that keeps the server login privat.

So where is this serverpassword stored in the client?
Or is it not stored and only transmitted once to the server, for allowing the registration process of the key of the user?
Then the server must ask active for the serverpassword?

Today i am hopefully able to check the output on the console of the client of my friend.
I will report the result.

[Krzmbrzl]

I think the client always sends the last used PW for a given server (which would indicate that it is stored in the client's DB) and when the connection fails, the user should be prompted for a (new) password.

[karstengit]

Something generally is going wrong in the new version of murmur.

Here is the console output when i connect with my user and client to the new server:

$ mumble
Cannot connect to server socket err = Datei oder Verzeichnis nicht gefunden
Cannot connect to server request channel
jack server is not running or cannot be started
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock
<W>2021-12-27 10:28:20.663 JackAudioSystem: unable to open client due to 2 errors:
<W>2021-12-27 10:28:20.663 JackAudioSystem: JackFailure - overall operation failed
<W>2021-12-27 10:28:20.663 JackAudioSystem: JackServerFailed - unable to connect to the JACK server
<D>2021-12-27 10:28:21.698 libopus 1.3.1 from libopus.so.0
<W>2021-12-27 10:28:21.700 CELT bitstream 8000000b from /usr/lib/mumble/libcelt0.so.0.7.0
<W>2021-12-27 10:28:21.705 Theme: "Mumble"
<W>2021-12-27 10:28:21.705 Style: "Lite"
<W>2021-12-27 10:28:21.705 --> qss: ":themes/Mumble/Lite.qss"
<W>2021-12-27 10:28:21.712 Locale is "de_DE" (System: "de_DE")
<W>2021-12-27 10:28:21.754 Database SQLite: "3.34.1"
<W>2021-12-27 10:28:21.774 Updating application palette
<W>2021-12-27 10:28:21.796 GlobalShortcutX: Using XI2 2.3
<W>2021-12-27 10:28:22.345 AudioInput: Opus encoder set for VOIP
<W>2021-12-27 10:28:22.345 AudioInput: 40000 bits/s, 48000 hz, 480 sample
<W>2021-12-27 10:28:22.346 PulseAudio: Starting input alsa_input.pci-0000_04_06.0.analog-stereo
<W>2021-12-27 10:28:22.346 PulseAudio: Starting output: alsa_output.pci-0000_04_06.0.analog-stereo
<W>2021-12-27 10:28:22.347 AudioOutput: Initialized 1 channel 48000 hz mixer
<W>2021-12-27 10:28:22.352 AudioInput: Initialized mixer for 1 channel 48000 hz mic and 0 channel 48000 hz echo
warning: The VAD has been replaced by a hack pending a complete rewrite
<W>2021-12-27 10:28:31.263 Database SQLite: "3.34.1"
<W>2021-12-27 10:28:31.263 OpenSSL Support: 1 (OpenSSL 1.1.1k  25 Mar 2021)
<W>2021-12-27 10:28:31.372 ServerHandler: TLS cipher preference is "TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:AES256-SHA:AES128-SHA"
<W>2021-12-27 10:28:31.399 ServerHandler: connection attempt to [2001:4dd0:af1b:3a0f:ca0e:14ff:fee6:a090]:64738 failed: Verbindung verweigert (0); trying next server....

As you can see the connection is rejected and then works with a "next server".

With the older server V 1.2.18 this message does not appear:

<W>2021-12-27 10:32:36.579 QSqlDatabasePrivate::removeDatabase: connection 'ServerHandler' is still in use, all queries will cease to work.
<W>2021-12-27 10:32:36.579 QSqlDatabasePrivate::addDatabase: duplicate connection name 'ServerHandler', old connection removed.
<W>2021-12-27 10:32:36.587 Database SQLite: "3.34.1"
<W>2021-12-27 10:32:36.587 OpenSSL Support: 1 (OpenSSL 1.1.1k  25 Mar 2021)
<W>2021-12-27 10:32:36.624 ServerHandler: TLS cipher preference is "TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:AES256-SHA:AES128-SHA"

Trying the same with the older client of the friend (Debian 10) the message of trying a next server does not appear and the connection keeps failing.
So what is here a "next server" and why the connection only works to this "next server"?

[Krzmbrzl]

Are you perhaps running multiple virtual servers within a single process? Check by looking in the servers table in your server's database

[karstengit]

Are you perhaps running multiple virtual servers within a single process? Check by looking in the servers table in your server's database

There is only one process running:

mumble-+ 142930 1 0 Dez23 ? 00:00:07 /usr/sbin/murmurd -ini /etc/mumble-server.ini

In pstree there are no other dependent processes.
Everything is standard configuration.

[Krzmbrzl]

That is why I said multiple virtual servers within a single murmur process. Every murmur-process can create and serve (in theory) infinitely many virtual server instances

[karstengit]

That's fine and how can i get control over the infinite virtual servers? :-)
Why the first connection is always rejected?

[Krzmbrzl]

First, check if you even have multiple vServers running 👀

Why the first connection is always rejected?

Impossible to tell without further info - potentially because they are configured differently

[karstengit]

First, check if you even have multiple vServers running eyes

Where this can be seen?

Here is the used configuration of the server:

; Murmur configuration file.
;
; General notes:
; * Settings in this file are default settings and many of them can be overridden
;   with virtual server specific configuration via the Ice or DBus interface.
; * Due to the way this configuration file is read some rules have to be
;   followed when specifying variable values (as in variable = value):
;     * Make sure to quote the value when using commas in strings or passwords.
;        NOT variable = super,secret BUT variable = "super,secret"
;     * Make sure to escape special characters like '\' or '"' correctly
;        NOT variable = """ BUT variable = "\""
;        NOT regex = \w* BUT regex = \\w*

; Path to database. If blank, will search for
; murmur.sqlite in default locations or create it if not found.
database=/var/lib/mumble-server/mumble-server.sqlite

; Murmur defaults to using SQLite with its default rollback journal.
; In some situations, using SQLite's write-ahead log (WAL) can be
; advantageous.
; If you encounter slowdowns when moving between channels and similar
; operations, enabling the SQLite write-ahead log might help.
;
; To use SQLite's write-ahead log, set sqlite_wal to one of the following
; values:
;
; 0 - Use SQLite's default rollback journal.
; 1 - Use write-ahead log with synchronous=NORMAL.
;     If Murmur crashes, the database will be in a consistent state, but
;     the most recent changes might be lost if the operating system did
;     not write them to disk yet. This option can improve Murmur's
;     interactivity on busy servers, or servers with slow storage.
; 2 - Use write-ahead log with synchronous=FULL.
;     All database writes are synchronized to disk when they are made.
;     If Murmur crashes, the database will be include all completed writes.
;sqlite_wal=0

; If you wish to use something other than SQLite, you'll need to set the name
; of the database above, and also uncomment the below.
; Sticking with SQLite is strongly recommended, as it's the most well tested
; and by far the fastest solution.
;
;dbDriver=QMYSQL
;dbUsername=
;dbPassword=
;dbHost=
;dbPort=
;dbPrefix=murmur_
;dbOpts=

; Murmur defaults to not using D-Bus. If you wish to use dbus, which is one of the
; RPC methods available in Murmur, please specify so here.
;
;dbus=system

; Alternate D-Bus service name. Only use if you are running distinct
; murmurd processes connected to the same D-Bus daemon.
;dbusservice=net.sourceforge.mumble.murmur

; If you want to use ZeroC Ice to communicate with Murmur, you need
; to specify the endpoint to use. Since there is no authentication
; with ICE, you should only use it if you trust all the users who have
; shell access to your machine.
; Please see the ICE documentation on how to specify endpoints.
#ice="tcp -h 127.0.0.1 -p 6502"

; Ice primarily uses local sockets. This means anyone who has a
; user account on your machine can connect to the Ice services.
; You can set a plaintext "secret" on the Ice connection, and
; any script attempting to access must then have this secret
; (as context with name "secret").
; Access is split in read (look only) and write (modify)
; operations. Write access always includes read access,
; unless read is explicitly denied (see note below).
;
; Note that if this is uncommented and with empty content,
; access will be denied.

;icesecretread=
icesecretwrite=

; If you want to expose Murmur's experimental gRPC API, you
; need to specify an address to bind on.
; Note: not all builds of Murmur support gRPC. If gRPC is not
; available, Murmur will warn you in its log output.
;grpc="127.0.0.1:50051"
; Specifying both a certificate and key file below will cause gRPC to use
; secured, TLS connections.
;grpccert=""
;grpckey=""

; Specifies the file Murmur should log to. By default, Murmur
; logs to the file 'murmur.log'. If you leave this field blank
; on Unix-like systems, Murmur will force itself into foreground
; mode which logs to the console.
logfile=/var/log/mumble-server/mumble-server.log

; If set, Murmur will write its process ID to this file
; when running in daemon mode (when the -fg flag is not
; specified on the command line). Only available on
; Unix-like systems.
pidfile=/run/mumble-server/mumble-server.pid

; The below will be used as defaults for new configured servers.
; If you're just running one server (the default), it's easier to
; configure it here than through D-Bus or Ice.
;
; Welcome message sent to clients when they connect.
; If the welcome message is set to an empty string,
; no welcome message will be sent to clients.
welcometext="<br />Willkommen auf dem <b>Murmur Server</b>.<br/>Viel Vergnügen!<br/>"

; Port to bind TCP and UDP sockets to. (64738)
port=64738

; Specific IP or hostname to bind to.
; If this is left blank (default), Murmur will bind to all available addresses.
host=192.168.1.3

; Password to join server.
serverpassword=mypassword

; Maximum bandwidth (in bits per second) clients are allowed
; to send speech at.
bandwidth=72000

; Murmur and Mumble are usually pretty good about cleaning up hung clients, but
; occasionally one will get stuck on the server. The timeout setting will cause
; a periodic check of all clients who haven't communicated with the server in
; this many seconds - causing zombie clients to be disconnected.
;
; Note that this has no effect on idle clients or people who are AFK. It will
; only affect people who are already disconnected, and just haven't told the
; server.
;timeout=30

; Maximum number of concurrent clients allowed.
users=33

; Where users sets a blanket limit on the number of clients per virtual server,
; usersperchannel sets a limit on the number per channel. The default is 0, for
; no limit.
;usersperchannel=0

; Per-user rate limiting
;
; These two settings allow to configure the per-user rate limiter for some
; command messages sent from the client to the server. The messageburst setting
; specifies an amount of messages which are allowed in short bursts. The
; messagelimit setting specifies the number of messages per second allowed over
; a longer period. If a user hits the rate limit, his packages are then ignored
; for some time. Both of these settings have a minimum of 1 as setting either to
; 0 could render the server unusable.
messageburst=5
messagelimit=1

; Respond to UDP ping packets.
;
; Setting to true exposes the current user count, the maximum user count, and
; the server's maximum bandwidth per client to unauthenticated users. In the
; Mumble client, this information is shown in the Connect dialog.
allowping=true

; Amount of users with Opus support needed to force Opus usage, in percent.
; 0 = Always enable Opus, 100 = enable Opus if it's supported by all clients.
;opusthreshold=100

; Maximum depth of channel nesting. Note that some databases like MySQL using
; InnoDB will fail when operating on deeply nested channels.
;channelnestinglimit=10

; Maximum number of channels per server. 0 for unlimited. Note that an
; excessive number of channels will impact server performance
;channelcountlimit=1000

; Regular expression used to validate channel names.
; (Note that you have to escape backslashes with \ )
;channelname=[ \\-=\\w\\#\\[\\]\\{\\}\\(\\)\\@\\|]+

; Regular expression used to validate user names.
; (Note that you have to escape backslashes with \ )
;username=[-=\\w\\[\\]\\{\\}\\(\\)\\@\\|\\.]+

; If a user has no stored channel (they've never been connected to the server
; before, or rememberchannel is set to false) and the client hasn't been given
; a URL that includes a channel path, the default behavior is that they will
; end up in the root channel.
;
; You can set this setting to a channel ID, and the user will automatically be
; moved into that channel instead. Note that this is the numeric ID of the
; channel, which can be a little tricky to get (you'll either need to use an
; RPC mechanism, watch the console of a debug client, or root around through
; the Murmur Database to get it).
;
;defaultchannel=0

; When a user connects to a server they've already been on, by default the
; server will remember the last channel they were in and move them to it
; automatically. Toggling this setting to false will disable that feature.
;
;rememberchannel=true

; Maximum length of text messages in characters. 0 for no limit.
;textmessagelength=5000

; Maximum length of text messages in characters, with image data. 0 for no limit.
;imagemessagelength=131072

; Allow clients to use HTML in messages, user comments and channel descriptions?
;allowhtml=true

; Murmur retains the per-server log entries in an internal database which
; allows it to be accessed over D-Bus/ICE.
; How many days should such entries be kept?
; Set to 0 to keep forever, or -1 to disable logging to the DB.
;logdays=31

; To enable public server registration, the serverpassword must be blank, and
; this must all be filled out.
; The password here is used to create a registry for the server name; subsequent
; updates will need the same password. Don't lose your password.
; The URL is your own website, and only set the registerHostname for static IP
; addresses.
; Location is typically the country of typical users of the server, in
; two-letter TLD style (ISO 3166-1 alpha-2 country code)
;
; If you only wish to give your "Root" channel a custom name, then only
; uncomment the 'registerName' parameter.
;
;registerName=Mumble Server
;registerPassword=secret
;registerUrl=http://www.mumble.info/
;registerHostname=
;registerLocation=

; If this option is enabled, the server will announce its presence via the
; bonjour service discovery protocol. To change the name announced by bonjour
; adjust the registerName variable.
; See http://developer.apple.com/networking/bonjour/index.html for more information
; about bonjour.
;bonjour=True

; If you have a proper SSL certificate, you can provide the filenames here.
; Otherwise, Murmur will create its own certificate automatically.
;sslCert=
;sslKey=

; If the keyfile specified above is encrypted with a passphrase, you can enter
; it in this setting. It must be plaintext, so you may wish to adjust the
; permissions on your murmur.ini file accordingly.
;sslPassPhrase=

; If your certificate is signed by an authority that uses a sub-signed or
; "intermediate" certificate, you probably need to bundle it with your
; certificate in order to get Murmur to accept it. You can either concatenate
; the two certificates into one file, or you can put it in a file by itself and
; put the path to that PEM-file in sslCA.
;sslCA=

; The sslDHParams option allows you to specify a PEM-encoded file with
; Diffie-Hellman parameters, which will be used as the default Diffie-
; Hellman parameters for all virtual servers.
;
; Instead of pointing sslDHParams to a file, you can also use the option
; to specify a named set of Diffie-Hellman parameters for Murmur to use.
; Murmur comes bundled with the Diffie-Hellman parameters from RFC 7919.
; These parameters are available by using the following names:
;
; @ffdhe2048, @ffdhe3072, @ffdhe4096, @ffdhe6144, @ffdhe8192
;
; By default, Murmur uses @ffdhe2048.
;sslDHParams=@ffdhe2048

; The sslCiphers option chooses the cipher suites to make available for use
; in SSL/TLS. This option is server-wide, and cannot be set on a
; per-virtual-server basis.
;
; This option is specified using OpenSSL cipher list notation (see
; https://www.openssl.org/docs/apps/ciphers.html#CIPHER-LIST-FORMAT).
;
; It is recommended that you try your cipher string using 'openssl ciphers <string>'
; before setting it here, to get a feel for which cipher suites you will get.
;
; After setting this option, it is recommend that you inspect your Murmur log
; to ensure that Murmur is using the cipher suites that you expected it to.
;
; Note: Changing this option may impact the backwards compatibility of your
; Murmur server, and can remove the ability for older Mumble clients to be able
; to connect to it.
;sslCiphers=EECDH+AESGCM:EDH+aRSA+AESGCM:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:AES256-SHA:AES128-SHA

; If Murmur is started as root, which user should it switch to?
; This option is ignored if Murmur isn't started with root privileges.
uname=mumble-server

; By default, in log files and in the user status window for privileged users,
; Mumble will show IP addresses - in some situations you may find this unwanted
; behavior. If obfuscate is set to true, Murmur will randomize the IP addresses
; of connecting users.
;
; The obfuscate function only affects the log file and DOES NOT effect the user
; information section in the client window.
;obfuscate=false

; If this options is enabled, only clients which have a certificate are allowed
; to connect.
certrequired=True
sslCiphers=EECDH+AESGCM:AES256-SHA

; If enabled, clients are sent information about the servers version and operating
; system.
;sendversion=True

; You can set a recommended minimum version for your server, and clients will
; be notified in their log when they connect if their client does not meet the
; minimum requirements. suggestVersion expects the version in the format X.X.X.
;
; Note that the suggest* options appeared after 1.2.3 and will have no effect
; on client versions 1.2.3 and earlier.
;
;suggestVersion=

; Setting this to "true" will alert any user who does not have positional audio
; enabled that the server administrators recommend enabling it. Setting it to
; "false" will have the opposite effect - if you do not care whether the user
; enables positional audio or not, set it to blank. The message will appear in
; the log window upon connection, but only if the user's settings do not match
; what the server requests.
;
; Note that the suggest* options appeared after 1.2.3 and will have no effect
; on client versions 1.2.3 and earlier.
;
;suggestPositional=

; Setting this to "true" will alert any user who does not have Push-To-Talk
; enabled that the server administrators recommend enabling it. Setting it to
; "false" will have the opposite effect - if you do not care whether the user
; enables PTT or not, set it to blank. The message will appear in the log
; window upon connection, but only if the user's settings do not match what the
; server requests.
;
; Note that the suggest* options appeared after 1.2.3 and will have no effect
; on client versions 1.2.3 and earlier.
;
;suggestPushToTalk=

; This sets password hash storage to legacy mode (1.2.4 and before)
; (Note that setting this to true is insecure and should not be used unless absolutely necessary)
;legacyPasswordHash=false

; By default a strong amount of PBKDF2 iterations are chosen automatically. If >0 this setting
; overrides the automatic benchmark and forces a specific number of iterations.
; (Note that you should only change this value if you know what you are doing)
;kdfIterations=-1

; In order to prevent misconfigured, impolite or malicious clients from
; affecting the low-latency of other users, Murmur has a rudimentary global-ban
; system. It's configured using the autobanAttempts, autobanTimeframe and
; autobanTime settings.
;
; If a client attempts autobanAttempts connections in autobanTimeframe seconds,
; they will be banned for autobanTime seconds. This is a global ban, from all
; virtual servers on the Murmur process. It will not show up in any of the
; ban-lists on the server, and they can't be removed without restarting the
; Murmur process - just let them expire. A single, properly functioning client
; should not trip these bans.
;
; To disable, set autobanAttempts or autobanTimeframe to 0. Commenting these
; settings out will cause Murmur to use the defaults:
;
;autobanAttempts=10
;autobanTimeframe=120
;autobanTime=300

; You can configure any of the configuration options for Ice here. We recommend
; leave the defaults as they are.
; Please note that this section has to be last in the configuration file.
;
[Ice]
Ice.Warn.UnknownProperties=1
Ice.MessageSizeMax=65536

[karstengit]

For my own connections it makes no difference when the serverpassword is commented out in the configuration file.
So here is definitely a problem / bug and this is not only a problem of support.

[karstengit]

Bug reported to Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1002723

[crknadle]

I'm the maintainer for Mumble in Debian.

This initially looks to me like it might be an IPv6 vs IPv4 issue, because in the error when the connection fails I see an IPv6 address:

<W>2021-12-27 10:28:31.399 ServerHandler: connection attempt to [2001:4dd0:af1b:3a0f:ca0e:14ff:fee6:a090]:64738 failed: Verbindung verweigert (0); trying next server....

but in the configuration file it looks like the host is a local LAN IPv4 address:

; Specific IP or hostname to bind to.
; If this is left blank (default), Murmur will bind to all available addresses.
host=192.168.1.3

So that's the first thing I'd like to point out because I didn't see that discussed in the bug.
It's still possible the setup might be valid if perhaps there's some kind of 6-to-4 translation going on in a router, but again I'd expect to see that mentioned somewhere in the bug if so.

[karstengit]

Thank you for your answer, the idea sounds good, but is there any chance to debug the reason for it?

The router is an Fritzbox 7360 and IPV6 has been activated for test purposes to use IPV6 now.
There are massive problems to use XMPP over port 5222 to, because there is always the message "no route to host".
It's interesting that there is IPV6 for such a long time, but it seems not really possible to analyze what is going on.
Recently i found out that there is no difference with static / nonstatic IP's in IPV6.
Up to now i could not identify IPV6 as reason / problem for these "effects".

Do you have any other idea to switch of IPV6 in the Fritzbox?

[ppfeufer]

Check in your FritzBox's web interface if it says something like this:

If so, you're pretty much out of options, a DS-Lite tunnel prevents your network from being reachable from the internet, even prevents port forwarding. Unfortunately, a lot of providers do that nowadays ...

It also means, you don't have an IPv4 address anymore and everything IPv4 related is tunnelled...

[karstengit]

Check in your FritzBox's web interface if it says something like this:

If so, you're pretty much out of options, a DS-Lite tunnel prevents your network from being reachable from the internet, even prevents port forwarding. Unfortunately, a lot of providers do that nowadays ...

No - there is an IPV4 and IPV6 address that can be used over DynDNS:

Internet
IPv4, verbunden seit 01.01.2022, 10:38 Uhr
IP-Adresse: 89.97.159.231 Internet

IPv6, verbunden seit 01.01.2022, 10:38 Uhr
IPv6-Adresse: 2009:4cd0:af5a:d939:Fa0d:14ff:fea6:a190

I have tested to disable IPV6 and then there is only one connection directly opened over IPV4.
I must test if the older client of the friend can connect without IPV6 ...

Now i am asking me if IPV6 has 'only' disadvantages, specially regarding the firewall and routing?
I already did not update the firmware of the Fritzbox, because newer versions don't allow a distinct NAT of ports.
I should take the time and compile a freetz for the box to get root privileges and more tools.

[karstengit]

Now i am asking me if IPV6 has 'only' disadvantages, specially regarding the firewall and routing?

The answer seems to be yes - specially when using a Fritzbox with activated Firewall.
There was a missing portforwarding for IPV6, but after configuring the needed ports for IPV6 and a reboot of the fritzbox, the portforwarding still does not work with IPV6 - the firmware is rubbish!
So IPV6 is deactivated now again.
More and more it seems to be a good idea to use the fritzbox only as modem and make the rest with an dedicated server.

[stale]

This support-issue has been automatically marked as stale because it has not had recent activity. If no further activity occurs, the issue will be automatically closed as we'll assume your problem to be fixed.

[Krzmbrzl]

Closing as resolved