Some genres unpopulated unless using VPN #2150
Replies: 2 comments 1 reply
-
If you'd like to see the protocol in action, try a protocol analyser like Wireshark or tcpdump. If you're able to do this at both the client and private server ends, you could compare them and see what's going wrong here. Q1: That's pretty much it, yes. The directory server actually sends two copies of the list - a compact version and a full version - for reasons we'll see in a minute. And when it receives a request for the list, it also tells each server registered with it to send the client an empty message, to help get NAT table entries set up correctly. (The code for this is in I'll suggest another theory: the directory server is sending a response, but it's getting somewhere along the way to you. Any Genre 1/2 and Classical/Folk currently have very large lists of registered servers - the full response that Classical/Folk is sending back right now is about 3000 bytes, and the compact response is about 1600 bytes. The other directory servers have smaller lists. The problem with this is that each network link between you and the directory server will have a maximum packet size (MTU) that it can support, and that's typically less than 1500 bytes. When the sending server or an intermediate router receives a packet that's bigger than it can fit into its outgoing link, it'll fragment it into multiple smaller packets. This can happen multiple times - for example, the full response I get from Classical/Folk at the moment totals 2991 bytes, but it's broken into five packets of 1464, 16, 1464, 16 and 31 bytes by the time it reaches me - i.e. it's been fragmented twice along the way. If something goes wrong with this process - e.g. a router discards a big packet rather than fragmenting it - then the whole original message is lost, and you won't see any servers in the list. And a 4G link has a fair chance of having a smaller MTU than normal, or having other unusual things going on in terms of how IP packets are being carried over the mobile network. So the reason the server sends a compact version of the list is to increase the chance of it getting through without fragmentation - but that's still not enough to avoid fragmentation problems on the bigger directories at the moment. (I do wonder if it might be worth people running directory servers deliberately configuring a very conservative MTU on their network interfaces - e.g. 1300 bytes - then they're likely to be doing all the necessary fragmentation at the source...) Q2: Connecting through a VPN means you're coming from a completely different source address (that's why enabling the VPN while connected to a server results in two of you - you look like a new client to the server). This has potential to cause various problems - e.g. if you're connecting to a server behind NAT, then the NAT priming step that happens as part of the directory list request won't have happened for your new address. Again, looking at the packets with a protocol analyser is likely to be helpful here. |
Beta Was this translation helpful? Give feedback.
-
This is usually down to routing issues between the client ISP and the server ISP. I get it from time to time (for some servers, most of the time - i.e. their ISPs seem problematic) on all the directories. Jamulus Explorer shows servers I can't see without running the client with |
Beta Was this translation helpful? Give feedback.
-
A friend is experiencing weird things when connecting to Jamulus via a 4G router (previously on a wired connection this did not happen).
When connecting normally, they can see all genres, but Any Genre 1 & 2 and Classical/Folk are unpopulated (i.e. not even a single server is shown), while Any Genre 3, Rock, Jazz & Choral/Barbershop are fine (and they can connect to any of the servers listed).
If they switch on their VPN [any country], everything goes back to normal, but the ping times understandably become unusably slow.
Whether the VPN is on or off, they can go to https://explorer.jamulus.io to find a chosen server's IP number and port (in any genre, including the 'invisible' ones), and can use the ip:port address to connect directly to it. When they initially connect they see themselves doubly connected, but that sorts itself after a minute or two.
If they connect to a private server (containing a Central Server and two subsidiaries, Server 1 and Server 2), with VPN off they see Central/1/2 fine... but if they switch the VPN on, they still see Central/1/2 but the ping times for 1 & 2 go blank, and they cannot connect to them. They can connect fine to Central regardless of whether the VPN is on or off.
Now we've finally tested all the permutations, we have a workaround (i.e. on the private server, only use Central, and on public servers, check explorer.jamulus.io first then connect via ip:port)... but something's clearly not working.
Q1: How does the list of servers in each genre get populated? Is it e.g. as follows?
If that hypothesis is correct, then either the 4G router's IP no. is for some reason being blacklisted by all Genre1/Genre2/ClassicalFolk servers so they don't respond to pings, or it's being for some reason blacklisted by the directory server with regard to sending the requested list of Genre1/Genre2/ClassicalFolk servers. Both theories seem rather weird.
Q2: Why would some servers switch to having blank ping times etc. when a VPN is on? (If anything, I'd have expected the opposite.)
TIA
Beta Was this translation helpful? Give feedback.
All reactions