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?)
I don't think it would be visible with Browse, though you should be able to connect by directly entering the IP address of the unit. Does that work?
I also note that you are using very old tools - the latest (and final) DS-5 release was 5.29(.2), though even that is 3 years obsolete, and has long been superseded by Arm Development Studio.
Thanks for the response! Yes the version is part of the Linux VM and HPC computing environment we have here. We are developing firmware test routines by piggy-backing on the final firmware development in a regulated industry so it is typical for us to remain in older versions of development environments/OS/etc as long as they keep working.
In theory, and according to the documentation, I should be able to use an IP to see the device, but it doesn't seem to agree. The instructions say to select Configure New and then to type in the ip. When I do this it complains about the hostname and the configure button is greyed out.
When I add a host name a new error is displayed indicating the the IP address is in the wrong format. Attempts to use the MAC address lead to the same error.
I should note that we were looking to get hardware response from the dstream before setting up any actual hardware debug targets. Like the identify function/flashing dstream lights to work from the remote Linux VM. I have recently started attempting to setup a debug configuration but am having similar issues as well as some pathing issues that I don't think are related.
In my earlier response I was thinking of the general use case of debugging, not specifically the ConfigureIP utility.
I was able to partially test this locally (I don't have a separate subnet). The MAC address is of the form xx:xx:xx:xx:xx:xx. There should be a sticker on the unit with this number (there is on newer units, but perhaps not on older ones?). When I enter this I am able to 'Identify' my DSTREAM. From there, set the IP address/hostname/etc in the lower right panel.
A potential workaround if either you do not know the MAC, or if this doesn't work over subnets, would be to connect to the unit via USB (or from the same subnet). and configure that way.
Hope that helps?
Yes it does have a MAC address sticker and we have tried connecting via that as well. I have the windows version of the DS5 v5.29.3 installed and have been able to connect to the box with USB to try to configure static IP and get the device to communicate with the remote Linux environment.
I have never been able to identify the device via ethernet on the local subnet(my laptop/windows) or from the remote linux environment. Only via USB. However the software does see the dstream via the firmware updater which is odd to me.
The reason we want to use the linux environment again is to be able to mimic exactly the environment of the firmware development group. I'm sure its possible for us to replicate everything locally for use in Windows, but seems like it would be fairly difficult task for beginners. I was hoping that we were just missing some trick or format issue or perhaps needed to just setup the debug configuration.
Looks to me like the software is not even allowing an attempt to locate via MAC because there is no host name?
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.
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.
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,
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 - 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