Connect By Name On Ohmni Dual NIC

Yes - what you’re describing sounds like a Windows routing/NIC selection issue, not a discovery issue in the EZB Connect By Name skill itself.

What’s happening

• Discovery works because the EZB broadcast is being received on the correct WiFi interface.
• Connect fails on the client networks because Windows is choosing the wrong outbound route/NIC for the actual TCP connection.
• The fact that disabling the USBEthernet interface makes it work is a strong indicator that ARC is fine, but Windows is binding the socket to the wrong adapter path.

Important limitation

At the moment, ARC does not provide a setting in the EZB Connect By Name skill to bind the outbound connection to a specific NIC or "use the same adapter that received the broadcast."

The skill’s job is to:

1. listen for broadcasts,
2. resolve the EZB name to an IP,
3. hand that IP to ARC’s connection stack.

It does not expose a per-adapter bind option.

Best workaround options

Option 1: Disable the conflicting NIC when using ARC

Since you already confirmed this works, it’s the most reliable fix.

If the USBEthernet interface is only needed for the Ohmni base and not for the EZ-B v4 link, you can:

• leave it enabled only when needed,
• or disable it automatically before launching ARC.

Option 2: Use a startup script to detect the resolved IP and connect manually

If you want to keep using the name skill for discovery, you can have it discover the EZB, then script a connection through the normal Connection skill.

Since you asked about exposing the resolved IP: the EZB Connect By Name skill already shows the IP in its log, but I don’t believe it currently exposes that resolved address as a documented ControlCommand output you can directly consume in a script.

A practical approach is:

1. Let EZB Connect By Name discover the board.
2. Use the Connection skill to connect by IP.
3. If needed, manage the connection flow with a script or startup sequence.

If you want to try a more targeted Windows fix

These are the Windows-side items most likely to help:

• Set the USBEthernet adapter metric higher than WiFi
• Confirm the EZ-B and the PC are not crossing into a route conflict
• Check route print and Get-NetIPInterface to confirm Windows prefers WiFi for that subnet
• If the USBEthernet adapter is on the same or overlapping subnet as the EZ-B network, Windows can absolutely misroute the TCP session

If you want, I can help you interpret the output of:

route print
ipconfig /all
Get-NetIPInterface

and tell you exactly which interface Windows is preferring.

A practical ARC workaround I’d recommend

For an Ohmni dual-NIC setup, the most stable pattern is usually:

• Ohmni base control via the Standalone Movement Panel
• EZ-B head controller on a network that does not conflict with the UpBoard’s other active NIC
• If route conflicts happen, disable the nonessential NIC before ARC starts

A couple of questions so I can narrow this down

1. What subnet is the USBEthernet interface using on those client networks?
2. What IP/subnet is the EZ-B receiving on the problem networks?
3. Is the EZ-B on the same subnet as the Ohmni base interface, or is Windows just choosing the wrong route?
4. Would you like a small PowerShell script to force the metric/disable the conflicting adapter before ARC launches?

If you share the adapter IPs from ipconfig /all, I can help you pinpoint the exact conflict and suggest the cleanest workaround.