"Trying to Connect" error to my hosted Private Server - Works for others

[moorekw]

I have had a private Jamulus Server hosted on a Google engine for nearly a year but have in the last 3 weeks been mostly unable to connect to my own server. I get an error "Trying to Connect". Other users in the group can still connect to the server, and I can connect to other published servers. I could use some assistance getting this to again work reliably. Here is some additional information.

• I use Linux, however if I boot into Windows-7 I still can not connect to my server, but I can still connect to other published servers.
• If i switch to wireless, sometimes I can connect. Likewise if I switch from wireless to wired, sometimes I can connect. I do not need to reboot, I do not even stop or start Jamulus.
• If I log into the server and run "systemctl status jamulus" I can see my client connected.
• If I run wireshark on the client I see udp packets going out about every 2-3 mSec, but none coming back. These packets look nearly identical to the outgoing packets when Jamulus is connected (same IPS, same Ports, only slightly different data.
• Once connected, I can play music for several hours without problem.
• Rebooting Cable Modem, Router, Switch does not correct problem.
• Firewall in Cable Modem/Router does not appear to be blocking, and has not changed for years.
• Internet provider is Xfinity.

So... it would appear that the UDP packages are not making it back from the Google server to my computer... Does anybody have any suggestions?

Karl

[rdica]

You didn't mention a check of firewall or a run of wireshark/tshark/tcpdump from the server itself. Run these and see if this provides you any further insight.

[moorekw]

When I attempted to connect to the Jamulus server today, I got the same "Trying to Connect" error. I have some simultaneous tcpdump data from both the server and client. Some observations

• Most important, when the connection was failing I did not see any communication from the Server to my client on the client traces. The server traces however showed outgoing packages that never made it to the client.
• On the trace that worked, the server response to the first message was 302 uSec, on the trace that failed it was 227 uSec. I am really not sure of the granularity of that clock... it may not be significant.
• When the connection was working, the client had both server and client messages.
• The Ports 22124(Server),22217(Client) were identical in both the working/failing/server/client traces.
• When the connection was running, the same identical number of packages were recorded on the server & Client (3623, 0 droped)
• When the connection failed, the server had more recorded packages (1765 vs 1727)
• There do not appear to be any firewall limitations on either the server or the client side.
• The delay times all look reasonable if I correct the differences in the clocks... about 13 mSec one way

Any Ideas? I'll collect some more data.

[gene96817]

Since you are able to get TCP data at both the client and server, it would be good to be able to say the problem is not with the network. That is all messages from the client are arriving at the server and all messages from the server are arriving at the client. I don't expect 200-400 microsecond (usec) delays as being meaningful. (To be thorough, are the TCP data collected inside the client and server machines?)

It starts to get interesting (aka puzzling) if we know all the packets are being received in the client and server machines.

[moorekw]

Both the Server Data and the Client data was collected within the machines. I did the following today:
I took some data of the server turn around time mentioned above... there appears to be NO correlation between the initial response time and whether I can connect to the server.
I updated both the server and the client to Jamulus 3.8.1. There is no improvement in my connections. (Nice work on the .deb install files folks!). The problem still persists. I can connect to my server only intermittently, yet connect to others consistently.

[moorekw]

Thank you for the quick response. After dealing with this problem for 3 or 4 weeks, the response from the Jamulus server has worked perfectly for the last two days. I didn't make any changes to my computer or network, so I don't have any confidence that the problem will not return. I would like to keep this open for a few days in case the problem re-occurs.

Thank you for the suggestion about tshark/tcpdump... if my connection fails again they will provide useful information.

Karl

[gilgongo]

I've noticed this in the past too. Some servers (in my case public) just seem to become inaccessible for anything from an hour or so to maybe as much as a week as far as I can tell, then come back fine. I don't know what the prevalence of this is for others though.

[moorekw]

I am still having the problem... one additional piece of information that may be useful is that I can always connect to the private server if I connect through VPN. The VPN introduces longer packets and encryption at my end, however I believe that from the server side it should not make any difference. This is not a good workaround since it adds some delay and jitter to the connection.

[moorekw]

The problem was solved by replacing Cable Modem... After extensive testing on the Servers, connecting directly to the Cable Modem, and testing at neighbors house I decided that the problem was with the old cable modem (Zoom Model 5354), which I replaced with a Net Gear CM1000-100NAS. I do not have any concrete evidence, however I suspect that the recently updated software (Software updates on the Cable Modems are handled by Comcast) probably broke the package.

The UDP packages from the servers were transmitted from the servers, but were never received through the Cable modem. This problem was isolated to small UDP packages.

While it is not absolute proof, I have now been successfully running for 10 days... Jamulus has connected every time.

[rdica]

I'm glad you got it resolved. I still think it's firewall related but have no more evidence to investigate. Replacing the cable modem may have removed a potentially faulty firewall.
In any case, enjoy jamulus!