All Users Must Frequently Reconnect to Hear Each Other

[Locust]

Hi everyone I'm having a very strange problem with my Murmur server that's been happening for about 8 months now. Here's the basic breakdown:

 

• Sometimes everyone currently connected to the server will be unable to hear anyone else speaking and will have to reconnect to fix it.
• Any new connections work fine but those who are still connected won't work.
  
• This problem first occurred for us while running Murmur 1.2.3 but after updating to 1.2.8 the problem still persists.
  
• I've combed through the logs and found nothing to indicate why this is happening.

 

The only thing I see in the logs that might indicate a problem is a decent amount of these lines during the days when people were complaining of seeing the issue:

2014-11-30 23:21:56.786 1 => <235:N(-1)> Requesting crypt-nonce resync

2014-11-30 23:21:56.802 1 => <234:D(8)> Requesting crypt-nonce resync

2014-11-30 23:21:56.802 1 => <236:V(4)> Requesting crypt-nonce resync

2014-11-30 23:22:00.702 1 => <237:(-1)> New connection: **.***.***.**:51580

2014-11-30 23:22:00.780 1 => <237:(-1)> Client version 1.2.5 (Win: 1.2.5)

2014-11-30 23:22:00.827 1 => <237:M(6)> Authenticated

2014-11-30 23:22:01.872 1 => <224:M2(-1)> Requesting crypt-nonce resync

2014-11-30 23:22:02.231 1 => <229:L(9)> Requesting crypt-nonce resync

2014-11-30 23:22:06.661 1 => <232:M3(-1)> Requesting crypt-nonce resync

 

Has anyone else had this problem? Any idea how to fix it? We've tried other mumble servers and haven't seen the issue.

[ngollan]

That looks like the result of a bad connection dropping a lot of UDP packets. People not being able to speak without rejoining is a bit weird too. Are you by chance running the server on a connection with a dynamic IP address, behind a NAT router, or a potentially broken firewall?

[Locust]

That looks like the result of a bad connection dropping a lot of UDP packets. People not being able to speak without rejoining is a bit weird too. Are you by chance running the server on a connection with a dynamic IP address, behind a NAT router, or a potentially broken firewall?

The server is running on a Nuclear Fallout gaming VM located at 66.151.138.123. Windows Firewall is disabled but they have their own firewalls gating it. I don't have any control over what they do with their routers. The UDP packets I can live with if it's just some interrupted speech but the forced reconnect in order to hear people is what's driving everyone nuts.

[fwaggle]

Does the problem go away for users who force TCP mode?

If yes, quite likely a UDP network problem.

I've no idea about running a server on Windows - are there any sort of buffers that could be filling up? I wonder if there's anything useful in Windows' Event Viewer?

[pp5858]

Not sure if mine is same, but it is similar and has been also long time.

So I have server 24/7 in internet and us it for gaming and "in house intercom" :)

Everything else works well but if user has been in a channel longer time (autologin at windows startup) and not talked anything he/she is not able to hear others until speaks something. I have not tried to force TCP.

There is NAT + FW from client -> server but server is completely open. It seems that at least there is no keepalive kind of feature in the protocol or it is not working in my case.

It would be great to have fix so that this issue would disapear, any help apriciated and will post here if I found solution.

--Edit, env details:

Clients on Windows 1.2.3 -> 1.2.8, OSX, Plumble(android) problem at least in Windows clients

Server Linux: murmur used to be "./murmur.x86 -- Compiled Feb 9 2010 17:43:49" and is now "./murmur.x86 -- 1.3.0~447~g7d434bb~snapshot"

Problem was on old and new murmur. Server now Debian Gnu Linux 7, 3.2.58-grbfs

[Locust]

Does the problem go away for users who force TCP mode?

If yes, quite likely a UDP network problem.

I've no idea about running a server on Windows - are there any sort of buffers that could be filling up? I wonder if there's anything useful in Windows' Event Viewer?

Nothing visible in Event Viewer. The problem of being forced to reconnect to hear anyone goes away if users force TCP mode but then any user that forces TCP mode begins to break up constantly and become hard to hear.

My hosting service already moved the VM to new hardware and the problem persists. Right now I have to restart the server in the middle of games just for people to be able to hear each other.

[fwaggle]

if users force TCP mode but then any user that forces TCP mode begins to break up constantly and become hard to hear.

 

Yeah, that sounds really broken at the OS level I reckon.

TCP mode will definitely lead to a substandard experience, but if users are breaking up constantly and they don't have like... zero-sized jitter buffers, then that means there's a heap of packet loss and retransmits going on. TCP typically leads to lag and the occasional break-up, it shouldn't be constant breaking up, AFAIK.

Are you restarting the Murmur process or the entire VM to cure the problem?

What's the process list/CPU usage look like when it's misbehaving?

[pp5858]

I'm still btw. experiencing this same even though clients are on TCP.

I will have to look from eventviewer of clients, have not done that yet.

It seems that a lot of people are actually having this same issues, there is like 5-10 that I have seen in this forum so there must be at least hundreds of them.