We are trying to connect from a Linux HPC virtual environment in a different subnet with firewall to a Dstream box on a subnet box in our physical location. We can ping the box from the Linux env and I was also able to update the box firmware with the Debug Hardware Firmware Installer from the Linux env. However we cannot see the box using the browse function in the Debug Hardware Config IP. IT has assured us that the firewall is not blocking any communication to/from the Dstream box or the ARM DS-5 v5.25.0 eclipse environment.
My question is, should we be able to see and target this hardware from a different subnet? What specific requirements are there for communication to work (that aren't required for Firmware updates?)
Regards,Chris
Hi again, I did some internal investigation on this, and long story short, this is a 'chicken-and-egg' issue with the configure IP tool, and so connecting via USB is the best workaround. I note on newer versions of the documentation that the comment that you can use MAC address to locate device on other subnet has been removed.
Note this is only for the Configure IP feature - as you have found, the Firmware updater (and connecting to the unit as a debugger) can connect via an IP address (rather than MAC address). and so once the unit is set up, end users should not have any issues.
Hi Ronan,
Thanks for following up on this. So are you saying that I should use a USB connection to setup the box to a static IP and then we should be able to connect to it using a debug configuration, but not from the Configure IP window? Meaning we cannot use the identify function to verify connection across subnets? If so, this aligns with what we have been seeing so far.
Can you recommend the simplest way to confirm connection capability between our "other-subnet linux environment" and the dstream? As I mentioned before I started attempting to setup a new debug connection, but there appear to be a lot of variables and I've been told by our firmware that it is non-trivial to setup.
If not then I will continue working on getting a hardware debug target setup locally with Windows/USB and then once I have something working I'll attempt to replicate on the linux box via ethernet.
Thanks,
Chris
I just tried a "connect to target" from the linux environment to the dstream plugged into the ethernet port and got an "unable to connect" response. However pinging the dstream from the linux box appears to work fine. This still feels like an IT issue to me. I will contact them to confirm that this method is not being blocked by firewall rules. In the past we were looking at the Configure IP browse/identify functions.
Hi Chris... the latter (connecting via debug connection (or via the firmware update utility)) should definitely work across subnets... it is something I frequently do, connecting to development boards in remote offices. I generally am a Windows user... does the problem only arise with Linux setups? Can you confirm which Linux flavor you are running? Could it be some incompatibility with a newer Linux (again, the version of DS-5 you are running is quite (~5 years) old.
You have already done what I would suggest as the first pass, which would be to ensure you can 'ping' the box, so we know that the box is present on the network.
I found the below which lists the various ports DSTREAM uses, if this helps your investigation.https://community.arm.com/support-forums/f/armds-forum/45417/dstream-networking-ports
Sorry for your ongoing trouble,
Ronan
No worries and thanks again for your help with this.
Here's some of the contents from my os-release file:
NAME="Red Hat Enterprise Linux Server"VERSION="7.9 (Maipo)"ID="rhel"ID_LIKE="fedora"VARIANT="Server"VARIANT_ID="server"VERSION_ID="7.9"PRETTY_NAME="Red Hat Enterprise Linux Server 7.9 (Maipo)"
I am able to connect via the debug firmware installer from linux and read the firmware version from the box. I was unable to check in with IT yesterday to do some more port sniffing but this list should make it easier. I'll pass it along and see what they say.
Thanks,Chris
Thanks - that should be fine. From the 5.25 docs:https://developer.arm.com/documentation/dui0478/y/arm-ds-5-installation-and-system-requirements/system-requirements