I’m trying to use the onyx remote on my phone (iphone 14 Pro), and I’m getting some networking behavior I can’t quite wrap my head around:
I have an isolated wifi setup for my console. Since this wifi does NOT provide outside access, my default inclination is to NOT set a default gateway on it. I am reasonably confident this network is working properly, since my “ping” app can get a response from the console in this configuration. However, the onyx app cannot reach the console. It just does “looking for device…” for a while, then gives me “can’t find the device on the network”.
If I set a default gateway from the dhcp server (even though it doesn’t actually route anywhere), then the Onyx app immediately starts working properly
Also, if I turn off my cellular data (regardless of the default gateway config) then the Onyx app immediately starts working.
Of course, both of these solutions are sub-optimal, since they effectively disconnect my phone from the world when I’m on the wifi.
Can anybody suggest just what is even happening? And maybe help me get to a state where cellular data and onyx app can coexist properly?
Software Version: 4.10.1271
NX Console Type or PC OS Version: NX1
Addendum. I think I’ve more or less figured out what’s happening, but I’m not sure it gets me any closer to a fix…
It appears that the app uses a multicast discovery to find consoles on the network, and it appears that multicast traffic isn’t ending up on the wireless in the failure scenarios. (I assume it’s going out the cellular? I can’t really think how to test that)
If you are using a DHCP server, it is best practice to leave the Default Gateway configured, even if there’s a router on the network that is not connected to the Internet.
In the iOS Settings app, go to Apps > Onyx, and make sure “Local Network” is enabled.
On my iOS Device in addition to making sure the “Local Network” is enabled I also have the “Cellular Data” disabled for this app.
See if that combination allows you to have your overall cellular data on for other apps while still being able to connect to your private wifi for remote focus / control.
@Edward - since on the topic, I have also noticed that if an iOS device (iPad - no cellular - dedicated VLAN) is running the app, I can remote focus no problem. However, if the iPad “times out” and goes to sleep, when I re-open the app, it drops the network connection. I have to go back to the console and “toggle” the remote focus / network connection off and back on for it to re-connect. As a work around, I usually set the iPad to not sleep until I’m done. This has been a change since 4.8, but not big enough to stop my operation. And I usually forget to report this.
I’ve not been able to replicate this. I’m using an iPad Pro running iPadOS 18.1. If the iPad goes to sleep whilst using the ONYX Remote app, upon waking the iPad, the Remote connection is dropped. This is expected, as it will timeout. However, I can then click on my ONYX system again in the list, and reconnect without having to change settings on the console.
What iPad are you using, and what iPadOS version is it running?
Could you expand on that? In my experience, false default gateways generally lead to worse results, not better. (phones trying to use the fake default gateway,for things they should really continue using cellular, primarily)
Unfortunately, for whatever reason, those settings don’t seem to have much effect for me. My impression (which may be completely false) is that the multicast discovery process somehow doesn’t care what you have set for the app specific data settings.
If your Wi-Fi network does not have Internet access, but your cellular connection does, apps will automatically use cellular, providing they are granted Cellular access in your iOS settings.
Even if a DHCP server has provided the phone with the IP address of your router (default gateway address), the phone should still use cellular for apps that are trying to connect to the Internet, if the router is not connected to the Internet.
I’m afraid that’s entirely contrary to my experience. In my experience, when there’s a (bogus) default gateway, iphones will prefer that, and cellular data service mostly stops working.
edit: further experimentation, I see the difference: if the bogus gateway exists but isn’t actually routing traffic to anywhere useful, everything breaks. if the bogus gateway doesn’t exist, iOS seems to figure out not to use it. So okay, I’ve learned something useful.
None of it seems to impact the failed discovery functionality though, and I’m still unclear on why a bogus gateway is BETTER than no gateway.
Is your DHCP Server also the router, or do you have a separate DHCP Server and Router on your network?
If a device is set to DHCP, it will expect to be assigned IP, Subnet, Default Gateway/Router, DNS address. If iOS doesn’t receive a Default Gateway when set to DHCP, I’m not sure whether it tries to function without one, or whether it essentially treats this as an invalid DHCP configuration. I’ll need to do some research on that.
it’s the same device, though there are differences in behavior when I have the dhcp server identify the default route as itself, vs another IP (that no device is actually there).
I disagree completely with your asessment that dhcp with no default route is invalid though. That’s a completely noraml and acceptable configuration for a network which only provides local access
I feel like we’re getting side tracked from my actual issue though: This is a single purpose network. I’ll set the default routes (and everything else) however you recommend…but NO configuration I’ve yet tried gets this to work properly !
I’ve done some further investigation and experimentation into this. When the ONYX app attempts to establish a console connection, it seems that the connection is blocked by iOS, if iOS is actively using cellular data alongside Wi-Fi (Wi-Fi Assist). If Cellular data is not currently in use, the Wi-Fi connection will work, but of course iOS will then be disconnected from the Internet. This seems to be unrelated to configured Default Gateways. I have logged this on our software tracking system (reference ONYX-1118), to allow us to investigate this further.