Connection loss with Murmur on a raspberry pi

[celavie]

Hi,

I have the following problem; I would like to run mumble as an intercom service in my house, i.e. I want to run a permanent murmur server with a small number of clients permanently connected, 24/7. I run Murmur on a Raspberry Pi 3 that is also acting as a client. The server application runs fine, and the RPi connects smoothly to the server. Other clients can connect at times, but drop the connection randomly, sometimes also having trouble to reconnect, to the point where the clients seem to "give up" and just stay disconnected. I have tested both the 1.3.0 MacOS client and the 1.2.9 Win64 client, I see consistent behavior across. Here is an excerpt from the log from the MacOS client;

 

[17:39:57] Connecting to server 192.168.178.29.
[17:39:59] Connected.
[17:40:04] Server maximum network bandwidth is only 16 kbit/s. Audio quality auto-adjusted to 8 kbit/s (40 ms)
[17:40:23] UDP packets cannot be received from the server. Switching to TCP mode.
[17:40:57] Server connection failed: Server is not responding to TCP pings.
[17:41:07] Reconnecting.
[17:41:09] Connected.
[17:41:09] Server maximum network bandwidth is only 16 kbit/s. Audio quality auto-adjusted to 8 kbit/s (40 ms)

and so on.

The server log reads;

[...]
<W>2019-07-31 17:39:57.779 1 => <20:(-1)> New connection: 192.168.178.22:52606
<W>2019-07-31 17:40:00.100 1 => <20:(-1)> Client version 1.3.0 (OSX: 1.3.0-rc2)
<W>2019-07-31 17:40:00.149 1 => <20:tester(-1)> Authenticated
<W>2019-07-31 17:40:57.742 1 => <20:tester(-1)> Connection closed: The remote host closed the connection [1]
<W>2019-07-31 17:41:08.132 1 => <21:(-1)> New connection: 192.168.178.22:52608
<W>2019-07-31 17:41:09.337 1 => <21:(-1)> Client version 1.3.0 (OSX: 1.3.0-rc2)
<W>2019-07-31 17:41:09.390 1 => <21:tester(-1)> Authenticated

I noticed that the port in the server log changes every time, but I don't know if this of significance.

Both systems are connecting via a WLAN router and a repeater. I had thought this this might be related to complete connection loss to the RPi system (e.g. some problem with the repeater), but I noticed that SSH connections survive through the mumble drops, so that can't be it. I also thought about port forwarding settings in the router, but to my understanding, this is not necessary as this is only the local network. Plus, if it was that, I would be able to connect to begin with.

I have disabled QoS in the client settings, this is the server settings I use;

database=/var/lib/mumble-server/mumble-server.sqlite
logfile=/var/log/mumble-server/mumble-server.log

pidfile=/run/mumble-server/mumble-server.pid

defaultchannel=0

welcometext="<br /><b>Murmur</b>.<br />Enjoy your stay!<br />"

port=64739

host=

serverpassword=****

bandwidth=16000

users=100

messageburst=5
messagelimit=1

allowping=true

uname=mumble-server

[ice]
Ice.Warn.UnknownProperties=1
Ice.MessageSizeMax=65536

The server version is 1.3.0 (1.3.0~git20190125.440b173+dfsg-2).

Do you have any suggestion for me? Thank you very much for your help.

[kissaki]

This is not a configuration issue of the client or server, or network routing for connectivity.

SSH connections are way more forgiving, with higher timeouts, than Mumble AFAIK.

So SSH not dropping but Mumble does not necessarily mean there was no connection loss.

Mumble does not receive TCP ping answers, so there's definitely some packet loss going on.

In the Client you can check the Server Information dialog for some statistics about packet loss - at least for as long as you are connected.

Are you sure the server/rpi can handle the load? Resource wise? Network wise?

Did you check resource usage on the rpi?

[celavie]

Hi kissaki,

Thanks for your reply and your suggestions. I think the load on the Rpi (3) is fine, but I guess you are right that it is a connection issue, as I see some packet loss in the server information dialogue.

I will try to improve on that.

Thank you!

[celavie]

Hi, just as an update; I played around with the wifi environment, basically placing the RPi 3 directly next to the router. It turned out that there are two different problems. One is indeed related to connectivity and results in the clients losing connection to the server from time to time. The other problem, however, is that I have trouble to reconnect, because it sometimes takes 30 or more tries to successfully connect. I could not resolve this problem by messing with the wifi connection; it seems unrelated to me. For example, I could run a stable connection for about 24 hours in one case. The connection broke for some reason; immediately afterwards, I tried to reconnect, and failed for about 40 times, always with the log entry shown above, although the wifi connection was good.

What I did in the end is I moved the mumble server to a different machine; now the RPi 3 only runs the client. The problem has now completely vanished - every now and then, I get a reconnect because of the wifi signal in the place where the client is sitting now, but these reconnects work fine.

So, in the end I could not figure out what the problem is, but it is not the wifi signal alone. I also don't think it was the load on the RPi 3, as I got something like 0.3-0.5 load in top, and there is plenty of other people using a RPi 3 for murmur. I giving you this update just in case this comes up somewhere else as well.

[kissaki]

When reconnecting fails and the client log does not tell you much, the server log may have more info on why connection was denied or that it failed.