Central Server Address: "Default" results in empty server browser, "Default (North America)" works fine

[dingodoppelt]

Jamulus stopped showing servers in the server browser.
I've had the problem before, but it eventually started listing servers again, now the server browser is constantly empty when selecting "Central Server Address: Default"
I can still connect to private Servers.
I'm on Kubuntu 20.04 with Jamulus 3.5.3git

cheers, nils

[Snayler]

Does this also happen in version 3.5.2?

[corrados]

There are already discussions about this in the forums:
https://sourceforge.net/p/llcon/discussion/533517/thread/7c3f490016
https://sourceforge.net/p/llcon/discussion/533517/thread/62f7a65264
Have you read these? There are some internet providers which block certain ports. Maybe this is your issue.

[dingodoppelt]

Does this also happen in version 3.5.2?

yes, just tried.
I tried nmap and see the ports 22124 and 22224 as "open|filtered"
when I set the IP of the Central Server manually into Central Server Address it behaves the same. 22124 = no servers in list
22224 = works fine

There are some internet providers which block certain ports. Maybe this is your issue.

I run a server myself on port 22124 and it works. 22134 works too, as I can receive the Server list from the north american server.
I checked in wireshark if I received any udp traffic from the central server on local port 22134. It works only for the north american central server. I don't get anything back from the central server's port 22124

[dingodoppelt]

I talked to my ISP (vodafone germany) and they didn't know about dividing portranges, as mentioned in the forum threads. Strange thing is that the server list worked fine, then stopped working for a few times but worked properly most of the time and now stopped working completely without me changing anything, that I would know of.

[EDIT] I can join jamulus.fischvolk.de:22124 and play so the ports cannot be blocked

[dingodoppelt]

It just started working again and I see a server list using 3.5.3git from a freshly cloned repo. I didn't change anything, it just started working again. Before I checked back a few versions to no success. The last one I tried was 3.4.4 before compiling the current git version which magically began to work again.

[corrados]

Here is another report of an empty server list: https://www.facebook.com/groups/619274602254947/permalink/647715099410897

[corrados]

It seems to be a temporary thing. Maybe it relates to the filling level of the server list. Maybe the port is temporarily blocked by some router/firewall/internet-provider. A lot of unknowns... Hard to debug this issue. Any help appreciated.

What I can say is that the North America Central Server runs on exactly the same server hardware as the Default Central Server. Just the port number is different, the IP address is the same. So if the user can see the Norh America Central Server, they have access to the IP address of the Jamulus server.

[corrados]

Here is another interesting finding: https://sourceforge.net/p/llcon/discussion/software/thread/f46ca37b94

[corrados]

Here is another problem report: https://sourceforge.net/p/llcon/discussion/533517/thread/360feb12c9

[A5005]

In order to find out the error, it may be useful if the affected users share information about their ISP and router.

In my case (https://sourceforge.net/p/llcon/discussion/software/thread/f46ca37b94/)

ISP: Vodafone Kabel Deutschland
Router: FritzBox 6940 Cable

[dingodoppelt]

ISP: Vodafone Kabel Deutschland
Modem/Router: Arris TG3442DE (Vodafone Standard Gigabit Cable Box) with FritzBox 4040 as Router
@corrados: maybe you can check if the UDP packets arrive from certain IPs that have the empty server list problem as in my case the port 22124 on jamulus.fischvolk.de was reachable as I could join the Jamming Room on the server manually, just the packets containing the servernames and IP s were not received on my end.

[corrados]

If you could enter the room jamulus.fischvolk.de by typing in the address manually, that gives us already the confirmation that the IP address and the port 22124 was not blocked. Otherwise you would not get a successful connection.
The packet which contains the server list is pretty long, since we can have up to 200 servers listed. Maybe the length of the packet is the problem. Or maybe in that packet there are entries which some IP packet filters do not like and sort it out.

[dingodoppelt]

it stopped working again. I can still connect to the server manually, but I don't get a server list.

[corrados]

I can see both lists. Can you see the North America Central Server list now?

[dingodoppelt]

Now the default list is back again. I can see the north american list all the time.
I joined jamulus.fischvolk.de:22124 manually and could hear everybody and saw udp traffic on 22124, but could not receive the packet with the server list.

[lferraro]

I live in Italy and use FastWeb ISP provider. I'm experiencing the same no serverlist problem reported by many users in this thread.

It seems that the no serverlist problem happens only with the EU server, but not with the NA (North American) server. The difference between the two is just a matter of port (EU uses 22124, while NA users 22224, right?).

If the issue would come from the Address plus Port (A+P) technique (as suggested in the mentioned thread), than the no serverlist problems should also happen with both the EU and NA servers randomly, depending on the range of port our ISP assigns to our IP.

Yet, I see that the problem is always with the EU server and never happened with the NA server.
I suspect the Address plus Port (A+P) technique IS NOT the ultimate cause of this behaviour.

I also noticed that, when the server list is populated, some friends of mine do not see my public server in the list, while other friends can see it and join in. Is this another issue or is releated to the same no serverlist problem?

[elliotclee]

I have been having problems with getting Mac users set up on Jamulus and they aren't able to connect to my server directly when it is private. They have their firewall turned off and Jamulus has app permissions to run. No luck.

Now when I rented a Mac VPS from zeromac.com by the hour to try debugging it, I get no server list at all from any central server, 100% reliable. This happens with System Integrity Protection either on or off.

When I run Wireshark in the virtual machine, it shows packets being received back from various servers, and dtruss shows that the Jamulus process is getting 9 bytes of data back successfully from the recvfrom() calls. I suspect a bug in Jamulus itself.

Anyways, if you want to reproduce the problem, I know it happens on the zeromac.com virtual machines reliably.

[corrados]

Here is an interesting finding: https://sourceforge.net/p/llcon/discussion/software/thread/20c89f2a4d

[corrados]

I never had the issue with the empty server list. If anybody has the empty server list, could you please try to start Jamulus with:
Jamulus.exe -p 22125
as reported in that Sourceforge thread and report back here if it also solved your issue. Thanks.

[elliotclee]

Just tried with zeromac.com VM. When I ran with -p 22125, I observed the same behavior - empty server list on both servers but able to connect directly to a server IP/name.

[corrados]

Thanks for testing. I was hoping that this could give me more insight. Maybe the problem has more than just one cause.

[corrados]

Here is an interesting finding: https://sourceforge.net/p/llcon/discussion/533517/thread/0e9aa52428/?page=1&limit=25#51b4

I think the cause of this issue mentioned here is the fragmentation of the UDP packets.
The best way to solve this is to have more different server lists which then will be shorter and therefore do not force a packet fragmentation. Fortunately pljones will host two new central servers. I will do the modifications in the Jamulus software hopefully this weekend. Then the situation should improve.

[corrados]

Status update:
We now have genre-based server lists. I.e. we now have multiple lists. For each list the number of supported servers can be reduced now. This should improve the situation since sometimes only very long lists make issues. Right now the maximum list length is set to 150 but can be reduced further if we still have issues.

There seems to be a problem with UDP packet fragmentation for some routers. There is a separate Issue for that: #255

Since this Issue and #255 are very similar, I will close this issue and we should continue the discussion in the new Issue #255.

[mawess]

If the cause of this issue mentioned here is the fragmentation of the UDP packets.
Then the solution is to use TCP instead.