Can't hear anyone in mumble after 5-10 minutes

[danksunshine]

The issue

I join mumble and after 5-10 minutes I can't hear anyone. My sound and recording devices are set properly and work outside of mumble when this happens. I have tried reinstalling and it did not fix the issue. The little green guy next to people's names does not light up. Other people can hear me when this happens too.

Mumble version

1.3.4

Mumble component

Client

OS

Windows

Additional information

No response

[Krzmbrzl]

Have you checked whether this happens on a different server as well?
And speaking of which: what version is the server running (you can figure that out by clicking on the i button while being connected to the server).

Are you able to use some kind of tool to check whether your computer js receiving (UDP) packets from the server while this happens? E.g. by using something like Wireshark

Iirc the last time we received a report like this, it turned out being somehow related to the router (settings). We never figured out what exactly went wrong though

[danksunshine]

This did start happening when I upgraded routers, my old one's wifi was dying due to its age. I got a Netgear R6230 router and updated all the software for it through the phone app.

The mumble server's version is on Protocol 1.3.0 (X11) Debian GNU/Linux 10 (buster)

The issue still happens on other mumble servers.

When the issue first happened, the server owner looked at my connection details, (unsure what exactly), and told me that I was still connected and he said I was still receiving UDP packets, The entire time I was connected I was losing about 1% of packets but he doesn't think that would be enough for me to lose audio. He then said it might be high compared to everyone else on the server, but maybe not enough to lose audio.

[danksunshine]

So I was trying to recreate the issue today and I wasn't able to. Would it be ok if I updated this thread the next time it happens? Or would you like me to open a new issue? I usually have the same issue no matter how many times I reconnect and disconnect when it does happen.

[Krzmbrzl]

Yeah sure, feel free to update this one. In the meantime I'll just mark it as "needs more input" in order to prevent this issue from disappearing into Nirwana ^^

On the packet loss issue: 1% is definitely not enough to lose audio.

Very interesting though, that for you this also appears to be related to some kind of router issue.

What you could also try is to force TCP mode via Mumble's setting (even though I think 1.3 still has a bug that prevents this from working properly). Maybe this is a UDP issue

[wfjsw]

I remember that once I put the Mumble client idling in the background long enough that my ISP starts dropping all of my UDP packets, Mumble wasn't able to detect this and switch to TCP mode. The UDP Packet received metric just stopped ticking. May be related.

[TerryGeng]

Mumble wasn't able to detect this and switch to TCP mode.

This is weird. Mumble periodically sends UDP ping packets and will switch to TCP if ping packets didn't arrive. Is it possible that your ISP drops large voice packets but lets small ping packets pass through?

[wfjsw]

In that case I should still see a tick in UDP Packets counter. But there wasn't one.

[Krzmbrzl]

At which point Mumble should be switching to TCP 👀

[TerryGeng]

In that case I should still see a tick in UDP Packets counter. But there wasn't one.

mumble/src/mumble/ServerHandler.cpp

Lines 622 to 665 in 37c33fe

	} else if (msgType == MessageHandler::Ping) {
	MumbleProto::Ping msg;
	if (msg.ParseFromArray(qbaMsg.constData(), qbaMsg.size())) {
	ConnectionPtr connection(cConnection);
	if (!connection)
	return;
	// Reset in-flight TCP ping counter to 0.
	// We've received a ping. That means the
	// connection is still OK.
	iInFlightTCPPings = 0;
	connection->csCrypt->uiRemoteGood = msg.good();
	connection->csCrypt->uiRemoteLate = msg.late();
	connection->csCrypt->uiRemoteLost = msg.lost();
	connection->csCrypt->uiRemoteResync = msg.resync();
	accTCP(static_cast< double >(tTimestamp.elapsed() - msg.timestamp()) / 1000.0);
	if (((connection->csCrypt->uiRemoteGood == 0) || (connection->csCrypt->uiGood == 0)) && bUdp
	&& (tTimestamp.elapsed() > 20000000ULL)) {
	bUdp = false;
	if (!NetworkConfig::TcpModeEnabled()) {
	if ((connection->csCrypt->uiRemoteGood == 0) && (connection->csCrypt->uiGood == 0))
	Global::get().mw->msgBox(
	tr("UDP packets cannot be sent to or received from the server. Switching to TCP mode."));
	else if (connection->csCrypt->uiRemoteGood == 0)
	Global::get().mw->msgBox(
	tr("UDP packets cannot be sent to the server. Switching to TCP mode."));
	else
	Global::get().mw->msgBox(
	tr("UDP packets cannot be received from the server. Switching to TCP mode."));
	database->setUdp(qbaDigest, false);
	}
	} else if (!bUdp && (connection->csCrypt->uiRemoteGood > 3) && (connection->csCrypt->uiGood > 3)) {
	bUdp = true;
	if (!NetworkConfig::TcpModeEnabled()) {
	Global::get().mw->msgBox(
	tr("UDP packets can be sent to and received from the server. Switching back to UDP mode."));
	database->setUdp(qbaDigest, true);
	}
	}
	}

Nah. My memory was wrong. According to these lines, Mumble would always assume the UDP channel is reachable as long as it received one UDP packet. The in-flight ping packets counter was for TCP channel only.

I think maybe we need to rework this part to make UDP work in the same way. I may think more about this in #4824.

[danksunshine]

Ok so, I started a wireshark capture AFTER I couldn't hear anything, but I can't upload it because of the file type. I am receiving 1 UDP packet every 5 seconds in the capture however until I start talking, but that might be me sending them (idk how networking stuff works so I might be wrong).

I tried seeing if it would happen again but I wasn't able to replicate it.

[danksunshine]

Just as I posted that, it happened again with the same symptoms.

[wfjsw]

You can zip the pcap file first to upload it.

[danksunshine]

MumbleIssue.zip

[ghost]

Have you checked for a firmware upgrade for your replacement router? I realize you have already upgraded it, but there may have been an update that addresses the issue.

[danksunshine]

There is a button to update in the app, and that says it is up to date.

[ghost]

There is a button to update in the app, and that says it is up to date.

Have you tried documenting your config settings and doing a factory reset of the router after doing the update? Since you indicated packet loss, I would suspect a flaky router. A reset of the config would be the last step before I replace it. Netgear stuff is typically a mixed bag unless you are buying their ProSafe stuff (that model has a lifetime warranty).

[davidebeatrici]

Your router appears to be supported by OpenWrt: https://openwrt.org/toh/hwdata/netgear/netgear_r6230

I would install it before investigating further.

[wfjsw]

I see. Assuming 198.24 is the server side, you stopped receiving UDP packet since 809 secs. If you didn't overconfigure your router (average people don't do that) then the most possible reason is that your ISP is actively trying to fuck up your UDP connection via QoS, which leads to the same situation as me. Combining with the issue outlined here #5421 (comment) the Mumble client failed to detect this and switch to TCP mode, causing deafness.

[Krzmbrzl]

That does indeed sounds like a very good explanation 🤔

[danksunshine]

Your router appears to be supported by OpenWrt: https://openwrt.org/toh/hwdata/netgear/netgear_r6230

I would install it before investigating further.

Not sure how to do this, but I think with my expertise buying a new router and returning this replacement would be more efficient.

I see. Assuming 198.24 is the server side, you stopped receiving UDP packet since 809 secs. If you didn't overconfigure your router (average people don't do that) then the most possible reason is that your ISP is actively trying to fuck up your UDP connection via QoS, which leads to the same situation as me. Combining with the issue outlined here #5421 (comment) the Mumble client failed to detect this and switch to TCP mode, causing deafness.

I had a filter on to only check traffic from mumble, but I want to make sure that I'm not receiving any UDPs at all. What else could I use to test this? Discord?

[Krzmbrzl]

I would assume that Discord also uses UDP for voice, yes

[wfjsw]

I don't think you have a problematic filter. You can post it here and I will examine that for you.

[danksunshine]

I don't think you have a problematic filter. You can post it here and I will examine that for you.

Not that it's problematic, but to see whether I'm not getting UDP's at ALL, or if mumble is the only application not receiving them.

[danksunshine]

mumblething3.zip

Here's a log of the issue happening in mumble, and then me joining discord with a friend right after. We talked for about 10-20 seconds before I ended it.

[Krzmbrzl]

I think this can be considered a duplicate of #1031