Weird half-assed connection for some users

[pianojoe]

I’m running a Jamulus Server in the cloud with a fixed IP address. I’m using it for choir rehearsals. Approx. 150 clients connect to the server every week (but obviously not at the same time).
5% of my clients experience a strange behaviour: They can connect, they can listen to the mix and can be heard by the others. However, the mixing console never appears, so they can’t make any adjustments.
Even weirder: Some of them can see the mixing console when connected to their own router via WLAN, but not via LAN.
This is strange. The server has a domain name and is reachable over IPv4 and IPv6. Jamulus ports are open in the server’s firewall.
If you’d like to give it a try, the server’s here: pianojam.de:31385

[chrisrimple]

I'm able to connect (from Seattle, WA, USA) via wifi with no issues. Haven't tried wired yet.

My guess is that there's (1) something about your port number that's revealing a bug in the Jamulus client or there's (2) something about their routing (wired in particular) that is causing the Jamulus client to initiate the connection, but fail to think that it's "complete", maybe having missed an ACK or similar from the Jamulus server. So the connection is "open" but not "complete", and the Mixer is never drawn.

A dev will have to duplicate your issue in debug mode to see what's happening, I think.

[hoffie]

Connecting works for me (Germany/Vodafone Cable).

5% of my clients experience a strange behaviour:

Does this always affect the same people or is it random?

However, the mixing console never appears, so they can’t make any adjustments.

This sounds like some protocol messages may not get through. Jamulus uses UDP, so packets may get lost, but Jamulus has some integrated checks to handle that (protocol-level ACKs).
The mixer board is populated by PROTMESSID_CONN_CLIENTS_LIST messages. This message will be sent each time sometime joins, so a client has multiple chances to catch up. I therefore suspect that something systematically prevents this message from getting through.

Thinking about it further, I can come up with the following reasons:

Size
This is one of the larger protocol messages as it will increase based on the number of clients. From a quick glance, one client might add a worst-case size of 52 bytes of content (+ protocol frame) to this message (with name and city set to the maximum length). 11 concurrent clients would make such a message longer than 550 bytes which seems to be the cutoff for using SPLIT messages.

550 bytes is not a lot. I initially suspected an MTU-related problem which would lead to small packets making it through and larger ones being dropped. Common limits would be around ~1400 to 1500 bytes, so it seems rather unlikely. WLAN vs. LAN could still be a hint.

Can you (as the server operator) successfully ping the client's IP? If you can, are you still able to do that when forcing a larger size (ping -s 500 $CLIENTIP)? This may provide hints, but might not cover the whole path as you will likely ping their router and not their actual machine running Jamulus. The best test would be if they could run that ping command. Not sure if you can get your user to do that.

Another indicator may be the welcome message. This is also a larger message. Do clients with have the mixerboard-not-appearing-problem see the welcome message? Do they see long chat messages?

IPS
Intrusion prevention systems or "firewalls" might block specific packets based on pattern matching. Your port seems uncommon for Jamulus, but I do not see a well-known diffferent interpretation for it which would support this theory. The packet structure might still trigger certain security systems and force them to block such packets.

[pianojoe]

I can confirm that the users with connection problems can see the long welcome message.

[hoffie]

Can you try the ping test(s)?

[dcorson-ticino-com]

I tip on local network problems. Do the users with problems all have the same provider and/or router?
Note that the difference between LAN and WLAN is the local in house connection between the computer and the router, it will make no difference behind the router. This makes me think there is something in the router setup that is causing problems.

From here in Switzerland I have no problems connecting to your server. Both with LAN and WLAN, it works fine.

[pianojoe]

Thanks for all the input.

Note that the difference between LAN and WLAN is the local in house connection between the computer and the router, it will make no difference behind the router. This makes me think there is something in the router setup that is causing problems.

I think people can have distinct setups for each network interface. Maybe IPv6 is enabled for WLAN connections, but not for LAN, etc. I’ll make a survey what ISPs/routers are used.

[dcorson-ticino-com]

Please note that, at the present, Jamulus does not support IPv6.

[pianojoe]

I know. I was just giving an example how network adaptors can be configured differently while on the same machine, and may thus behave in strange ways.

[pianojoe]

UPDATE: The problem occurs on Macs as well as Windows PCs. Two users say that they can connect to any other server on the public server list, and can see the mixing board just fine, it’s just my server that chokes. This means that it is not a problem with the Jamulus software per se. There must be a glitch in my server configuration, but I can’t figure it out.

[pianojoe]

Just another thought: Could this in any way be related to a rDNS issue?

[hoffie]

Could this in any way be related to a rDNS issue?

I don't think so. DNS will only play a role when connecting by name (and then, only forward DNS and not reverse DNS).

[gene96817]

Maybe this is related.... my users had a problem connecting to my server...
The firewall port and the server port were out of sync. I am guessing that everything was working with the default port... then the server was restarted and when the Jamulus opened up 22124 again(or the new startup) the port at the firewall was already so it mapped 22142 into 1024. Lots of confusion until I got the firewall and the server ports back in sync.