You message says you have the same IP address on the linux server as on the vpro system. I assume it's a typo, but just to be sure, the IPs need to be different. Other than that, it looks like you're using imrcli correctly. The error means that imrcli can't connect to the redirection service running in AMT. This could happen for a number of reasons. Generally I'd start be ensuring you have network connectivity. Can you ping your vPro system? Can you get to AMT's WebUI? In case you don't know, AMT has it's own web service. If you're not using TLS you can reach it here: http://<AMT IP>:16992. If you are are using TLS it's here: https://<AMT IP>:16993. If you can not ping there's a basic network issue. If you can not get to the WebUI AMT may not be setup/configured or may have a different IP (or no IP) than the OS running on your vPro system.
If both of those work, then AMT is accessible and ready for use. However, its possible that Redirection is disabled or that there's a TLS cert issue. These are more complicated to advise on without more information. What AMT version are you using? How did you setup/configure AMT? Are you using static IP's or DHCP? Is there a firewall on or between these systems?
On thing to check: Be sure SOL, IDER, and the Redirection Listener (which is only listed in AMT 6's MEBx) are all enabled in MEBx.
We have a similar problem.
Manageability commander in windows is working fine, so AMT and addresses etc are set up correctly.
We use the same AMT SDK as the topic starter, and most tools work, for example remoteControl can remotely manage the machine and power up with IDE-Redirection ** when the image is mapped in the windows commander **.
However we'd like to use imrcli to handle the redirection. imrcli works fine with SOL and displays the bootup. With IDE redirection, it displays a lot of packets being received and sent, but the "data counter" is zero and the machine waits at the "Attempting remote IDE boot..." prompt.
We've tried strace'ing the process, enabling debugging etc but no avail. We've also updated AMT from 3.2.3 to 3.2.20 (dell optiplex 755, bios A17), but no difference. We have tried AMT SDK 5.1.1, but no difference.
And help would be greatly appreciated!
Ok, problem solved. It turns out that the [/dev/cdrom] cannot point directly to an iso-file. However, with a loop device redirection it works:
losetup -f disc.iso
mount /dev/loop0 /mnt/cdrom (the manual says it must be mounted)
and then /dev/loop0 is used as the cdrom device.
Thank you for sharing your solution...I just learned something!!!