I've been setting up a Jamulus server and it has worked fine for a while, now it has stopped. The server dialog says it's Registered, and I can see it on the Central Server listing from another computer inside my local network. But other band members do not see it listed. If they use my direct IP address + port (22124) there is no problem connecting to me.
I have port forwarding set up in my router to route port 22124 to the computer with the serer running. But, when I look at the Jamulus Explorer page to look up the address of my server, it is listed but it shows a port number of 1251. That is a port that I forward to another device for a different purpose. I'm attaching screen shots for my router's forwarding table, and the Jamulus Explorer page showing my server, "DustyRoadServer" at 1251.
Is the port mismatch the reason that my band members can't connect? Why does my server show up at port 1251? I can't find any setting that allows chaning the port number. I'm using the MacOS version of Jamulus and Jamulus server.
If it really worked before and nothing has been changed it may just be a caprice of the Internet. Give it an hour and see if it works again. I have seen this once or twice, central servers showing strange things for example, that righted themselves with time.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The central server does right itself after a while. But then it wrongs itself again. It comes and goes. I've been able to verify that when it works, it shows my port as 22124. When my server doesn't show up on the list, the central server shows my port as 1251. But waiting for it to fix itself is not an option. When my band has a practice session, people are not going to sit around for an hour or more waiting fot the central server to maybe fix itself. So we have switched to a private server instead of public. When they use my direct IP address it works great. But there is clearly a bug in how the central servers determines my port number.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Those are network problems, difficult for Jamulus to correct.
BTW you can use the IP address to connect to a public server too.
You can find the IP using the Jamulus Explorer https://explorer.jamulus.io/
I have seen cases where a central server has not responding in my Jamulus, but was responding to the Explorer (which is based in England hence different Internet routing) and also the other way around.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As mentioned in my first post, Jamulus Explorer is where I was looking. Again, when not working, it shows my port as an incorrect number. This should not be a "network problem, difficult for Jamulus to correct". When the Jamulus Server app connects to the central server, it knows what port it is using and sends that information to the central server. If the central server is showing a different port, there is a bug in the software at one end or the other.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Dan,
I gave you a simple work-around for your problem that works.
The problem is intermittent, for me at least rare and short lived, depending on who-knows-what in the Internet.
If my work-around is not good enough for you I suggest that you join with the other developers of Jamulus who use their spare time for free to develop this software that has become so important for us all in these difficult times.
Your active contribution debugging and developing a solution to this problem will certainly be very welcome.
Don
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Dan: I have been seeing similar issues. I think it may have something to do with the way NAT works in the routers. In our situation, we have 4 servers set up using internet link A, and a Custom Central Server set up using internet link B.
Server 1 uses port 22120, Server 2 uses port 22121, Server 3 uses port 22122, and Server 4 uses port 22123. The router for internet link A has each of these ports forwarded to the respective server's internal network address.
The router for internet link B has port 22124 forwarded to the internal network address of the Custom Central Server.
Every 15 minutes, each of the 4 servers will send a registration request to the Custom Central Server. This is shown in the log file for Server-1 as:
Feb 6 03:03:58 Server-1 jamulus[12080]: Server Registration Status update: Registration requested
Then in the Custom Central Server, the log file shows:
Feb 6 00:03:58 CCS jamulus[8642]: Requested to register entry for <external-ip-addr-a>:22120 (<internal-ip-addr-server-1>:22120): Server-1</internal-ip-addr-server-1></external-ip-addr-a>
And finally the log for Server-1 shows:
Feb 6 03:03:58 Server-1 jamulus[12080]: Server Registration Status update: Registered
In this instance, the registration message, transits the router using the port 22120. This is what happens most of the time, and the Server is listed in the Custom Central Server. However, a NAT firewall does not have preserve the port number from an internal device. If the NAT firewall thinks the port is in use, it will find an available port when forwarding the message. This is shown in this log message when the registration request is received on the Custom Central Server:
Feb 6 00:04:05 CCS jamulus[8642]: Requested to register entry for <external-ip-addr-a>:1087 (<internal-ip-addr-server-1>:22120): Server-1</internal-ip-addr-server-1></external-ip-addr-a>
Notice how the port used has changed from 22120 to 1087 on the message that is transitting the public network. The job of the NAT firewall is keep a record of the association it has made between the internal port and IP address and the external port it used so that if a response is returned on port 1087, the router knows to forward the response to port 22120 of the internal ip address for Server 1. Server 1's log shows that it received a registration response, but the Server no longer appears in the list of servers on the Custom Central Server.
TCP sessions have a beginning and an end, so the dynamic association in the NAT firewall between the external ports it uses and the internal ip address and internal port goes on for the duration of the session. However, UDP messages are sessionless. When a UDP message is sent, the network makes best efforts to deliver it, but there are no guarantees. Also there are no requirements for a response to a UDP. But in case there is a response, the NAT firewall router creates an association so it knows how to deliver a response should it occur. But this association is maintained for a certain period of time (the actual time I am not sure - it may be implementation dependent or possibly specified in an RFC).
This timeout is born out by the fact that when the port changes (to 1087 for example), if one were to stop Server-1 and then restart it immediately, Server-1 registrations will continue to use the changed port value (i.e. 1087). However, if Server-1 is stop but not restarted for a period of time (say 5-10 minutes), then the port number will go back to 22120 and Server-1 will reappear in the Custom Central Server list.
I suspect that if the Custom Central Server receives a registration request, its UDP response should be addressed to the server's External-IP-Address using the Internal Port number (in this case 22120, not 1087), as the router has that port configured to receive the response all the time. It will also have to make sure the listing is still maintained.
Cheers
Bill
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've been setting up a Jamulus server and it has worked fine for a while, now it has stopped. The server dialog says it's Registered, and I can see it on the Central Server listing from another computer inside my local network. But other band members do not see it listed. If they use my direct IP address + port (22124) there is no problem connecting to me.
I have port forwarding set up in my router to route port 22124 to the computer with the serer running. But, when I look at the Jamulus Explorer page to look up the address of my server, it is listed but it shows a port number of 1251. That is a port that I forward to another device for a different purpose. I'm attaching screen shots for my router's forwarding table, and the Jamulus Explorer page showing my server, "DustyRoadServer" at 1251.
Is the port mismatch the reason that my band members can't connect? Why does my server show up at port 1251? I can't find any setting that allows chaning the port number. I'm using the MacOS version of Jamulus and Jamulus server.
If it really worked before and nothing has been changed it may just be a caprice of the Internet. Give it an hour and see if it works again. I have seen this once or twice, central servers showing strange things for example, that righted themselves with time.
The central server does right itself after a while. But then it wrongs itself again. It comes and goes. I've been able to verify that when it works, it shows my port as 22124. When my server doesn't show up on the list, the central server shows my port as 1251. But waiting for it to fix itself is not an option. When my band has a practice session, people are not going to sit around for an hour or more waiting fot the central server to maybe fix itself. So we have switched to a private server instead of public. When they use my direct IP address it works great. But there is clearly a bug in how the central servers determines my port number.
Those are network problems, difficult for Jamulus to correct.
BTW you can use the IP address to connect to a public server too.
You can find the IP using the Jamulus Explorer https://explorer.jamulus.io/
I have seen cases where a central server has not responding in my Jamulus, but was responding to the Explorer (which is based in England hence different Internet routing) and also the other way around.
As mentioned in my first post, Jamulus Explorer is where I was looking. Again, when not working, it shows my port as an incorrect number. This should not be a "network problem, difficult for Jamulus to correct". When the Jamulus Server app connects to the central server, it knows what port it is using and sends that information to the central server. If the central server is showing a different port, there is a bug in the software at one end or the other.
Hi Dan,
I gave you a simple work-around for your problem that works.
The problem is intermittent, for me at least rare and short lived, depending on who-knows-what in the Internet.
If my work-around is not good enough for you I suggest that you join with the other developers of Jamulus who use their spare time for free to develop this software that has become so important for us all in these difficult times.
Your active contribution debugging and developing a solution to this problem will certainly be very welcome.
Don
Dan: I have been seeing similar issues. I think it may have something to do with the way NAT works in the routers. In our situation, we have 4 servers set up using internet link A, and a Custom Central Server set up using internet link B.
Server 1 uses port 22120, Server 2 uses port 22121, Server 3 uses port 22122, and Server 4 uses port 22123. The router for internet link A has each of these ports forwarded to the respective server's internal network address.
The router for internet link B has port 22124 forwarded to the internal network address of the Custom Central Server.
Every 15 minutes, each of the 4 servers will send a registration request to the Custom Central Server. This is shown in the log file for Server-1 as:
Feb 6 03:03:58 Server-1 jamulus[12080]: Server Registration Status update: Registration requested
Then in the Custom Central Server, the log file shows:
Feb 6 00:03:58 CCS jamulus[8642]: Requested to register entry for <external-ip-addr-a>:22120 (<internal-ip-addr-server-1>:22120): Server-1</internal-ip-addr-server-1></external-ip-addr-a>
And finally the log for Server-1 shows:
Feb 6 03:03:58 Server-1 jamulus[12080]: Server Registration Status update: Registered
In this instance, the registration message, transits the router using the port 22120. This is what happens most of the time, and the Server is listed in the Custom Central Server. However, a NAT firewall does not have preserve the port number from an internal device. If the NAT firewall thinks the port is in use, it will find an available port when forwarding the message. This is shown in this log message when the registration request is received on the Custom Central Server:
Feb 6 00:04:05 CCS jamulus[8642]: Requested to register entry for <external-ip-addr-a>:1087 (<internal-ip-addr-server-1>:22120): Server-1</internal-ip-addr-server-1></external-ip-addr-a>
Notice how the port used has changed from 22120 to 1087 on the message that is transitting the public network. The job of the NAT firewall is keep a record of the association it has made between the internal port and IP address and the external port it used so that if a response is returned on port 1087, the router knows to forward the response to port 22120 of the internal ip address for Server 1. Server 1's log shows that it received a registration response, but the Server no longer appears in the list of servers on the Custom Central Server.
TCP sessions have a beginning and an end, so the dynamic association in the NAT firewall between the external ports it uses and the internal ip address and internal port goes on for the duration of the session. However, UDP messages are sessionless. When a UDP message is sent, the network makes best efforts to deliver it, but there are no guarantees. Also there are no requirements for a response to a UDP. But in case there is a response, the NAT firewall router creates an association so it knows how to deliver a response should it occur. But this association is maintained for a certain period of time (the actual time I am not sure - it may be implementation dependent or possibly specified in an RFC).
This timeout is born out by the fact that when the port changes (to 1087 for example), if one were to stop Server-1 and then restart it immediately, Server-1 registrations will continue to use the changed port value (i.e. 1087). However, if Server-1 is stop but not restarted for a period of time (say 5-10 minutes), then the port number will go back to 22120 and Server-1 will reappear in the Custom Central Server list.
I suspect that if the Custom Central Server receives a registration request, its UDP response should be addressed to the server's External-IP-Address using the Internal Port number (in this case 22120, not 1087), as the router has that port configured to receive the response all the time. It will also have to make sure the listing is still maintained.
Cheers
Bill