SOLVED - 386.4 Guest Network Sharing (JRiver/JRemote)

anonimo

Occasional Visitor
I have a few Intel NUC’s running Ubuntu 20.04 LTS or Debian 11 that I used as headless music servers across various locations. They all run JRiver Media Center 27 that I control via JRemote on either an Android phone or iPad, each on their own local network. They are only used on the local network; never from an external site, nor do I use VPN on these systems. Oddly, none now function and the JRemote error shows it “Timed out” on the appropriate address pointing to a firewall issue (same for all OS combinations). Disabled the firewall on the pc(s), but still the same issue. Thought the controlling device (certificate?), but both iPad and Android device fail with the same issue. Checked the router log and no mention of port blocking (as expected with Skynet, the only addon I use). I suspect the devices are no longer permitted to talk to one another on the same network and know the guest networks have been “upgraded” since I was on 384.19, when they all worked. Is this issue from an unknown-to-me router setting or am I missing something else?
 

ColinTaylor

Part of the Furniture
When did this stop working? When you changed something on your router, installed new firmware, etc?

Are any or all of these devices connected to a guest network, if so which one?
 

anonimo

Occasional Visitor
Thank you for the quick response!

I don't leave the systems on, but noticed the issue after I upgraded from 384.19 to 386.4 when I tried one, then the others, yesterday. I don't know if that's related to the issue.

I have each system dedicated to their own guest network band, so they are kept on their own separate local network.

I tried each guest network. Even got another NUC and loaded on Ubuntu/Debian again and tried with iPad/Android on each guest network, but that didn't work either.

In the past I loaded on a minimal install of Ubuntu, JRiver, then connected to the Remote immediately (as long as on the same network).
 

ColinTaylor

Part of the Furniture
There were changes made to the way guest network #1 works on each band which can cause problems. But you said you tried guest network #2 so that should have worked. But avoid using #1 while debugging this problem.

Do you have "Access Intranet" disabled for the guest network? If so try changing that to enabled and see if things start working. Again, I think there is a subtle change regarding this in 386.x.
 

anonimo

Occasional Visitor
Thank you for the suggestion.

I tried "Access Intranet" on a 2.4GHz network, then a 5GHz on Guest 2, then again on Guest 1 just in case but none worked (though it did find a printer). I also tried the iPad & Android on each, but to no avail.

If the JRemote is on one band and the NUC on another I get the same "Timed Out" error, though is still finds the correct internal ip address for the NUC. This still points to a firewall on the ports of some point, doesn't it? I don't see a comment in the log of a port being blocked, such as from Skynet, on the router.
 

L&LD

Part of the Furniture
What router are we talking about here?

Going from 384.19 to 386.4 requires a full reset to factory defaults. And not using any saved backup config file to configure the router afterward.
 

ColinTaylor

Part of the Furniture
If the JRemote is on one band and the NUC on another I get the same "Timed Out" error, though is still finds the correct internal ip address for the NUC. This still points to a firewall on the ports of some point, doesn't it? I don't see a comment in the log of a port being blocked, such as from Skynet, on the router.
It's unlikely to be a firewall issue as that would only effect traffic to and from the internet, not internally. But not knowing anything about how these devices communicate with each other I'm really just guessing in the dark.
 

anonimo

Occasional Visitor
RT-AC5300

The only addon I use is Skynet, pick specific WiFi channels for each band (to minimize possible interference I check periodically with an analyzer), and use quad9 as DNS, so no backup file needed.

Internally, the remote connects to the music server running JRiver on the same network using default port 52199. Still, if I open that specific port intentially (never had to before) or disable the firewall completely the remote, either on an iPad ro Android device, will not connect to the pc... well, pc's. By this point I've tried a few running Debian or Ubuntu. And I've tried another remote app with the same effect today (MO 4media).

Interesting, when I selected "Access Intranet" the NUC picked up a printer on a different WiFi band (internal vs guest network that the NUC used). That it still wouldn't connect to an iPad or Android on the same band is very odd.
 
Last edited:

ColinTaylor

Part of the Furniture
Can you try connecting two of the devices to the same primary (i.e. not guest) WiFi network and see if they can talk to each other. Apologies if you've already tried this.
 

anonimo

Occasional Visitor
Can you try connecting two of the devices to the same primary (i.e. not guest) WiFi network and see if they can talk to each other. Apologies if you've already tried this.

Just tried it on a primary band, but no luck.

Factory reset seems like the next step.
 

anonimo

Occasional Visitor
Finished performing a full factory reset and still not connecting between JRiver pc & JRemote iPad. Sigh.

No issues with any other items connecting (386.4 has been solid).

Open to any other suggestions. Please!

Going back to 384.19 isn't a favorable option.
 
Last edited:

anonimo

Occasional Visitor
It appears others may have similar issues with the 386 code base


Unfortunately I am not that network savvy. Would using YazFi work?
 

ColinTaylor

Part of the Furniture
It appears others may have similar issues with the 386 code base


Unfortunately I am not that network savvy. Would using YazFi work?
That is a different problem than you have. That's why I asked you to perform the test in post #9 to eliminate this as a possible cause.
 

anonimo

Occasional Visitor
That is a different problem than you have. That's why I asked you to perform the test in post #9 to eliminate this as a possible cause.

Yes, that makes sense. Thank you for the feedback.

If anyone thinks of anything else to try, please let me know.
 

L&LD

Part of the Furniture
@anonimo, after you performed the full reset to factory defaults (what method did you use?), how did you configure the router afterward?
 

anonimo

Occasional Visitor
@anonimo, after you performed the full reset to factory defaults (what method did you use?), how did you configure the router afterward?

I followed the factory reset method you documented. I also set the bands to specific channels and installed Skynet before trying again. (I did try with Skynet disabled after the factory reset too.) Trying to keep it simple.
 
Last edited:

L&LD

Part of the Furniture
Maybe try one more time without installing Skynet first?

Double checking that you did not use a saved backup config file after doing the reset too. :)
 

anonimo

Occasional Visitor
I don't use backup config files. To ensure firmware updates are "clean", I enter the [very few] changes manually.

If a factory reset has to be done 3 or 4 times for it to take doesn't that point to other issues? Like throw out the router and get another? That is a possible option, but hopefully 386.5 would be a more cost effective solution (assuming the router and/or firmware are the issue).
 

L&LD

Part of the Furniture
No, no need to throw out the router if a single reset doesn't work. There are many examples on these forums where it took more than one reset to be properly performed before the router is in a good/known state.

That is also the reason for the following link/post I made too.

Fully Reset Router and Network
 

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top