Cannot connect to vPro 9 from MDTK 1.26

Cannot connect to vPro 9 from MDTK 1.26

Hi,

I found this forum from the Open Manageability Developer Tool Kit (MDTK) page.

I'm setting up a new Lenovo M93p running AMT 9.0.2-build 1345. This is for a small business, so it's all manual provisioning. I've turned on SOL, IDER, and KVM. I've set user consent to NONE.

I can access the machine via a web browser (port 16992) for power control, log viewing, etc. However when I try to Connect from MDTK 1.26, the connection times out. Same thing if I try to connect from UltraVNC.

If I run Wireshark while trying to connect with MDTK, I can see packets going back and forth between the management station and the M93p. (This is all on a local IPv4 LAN for now.) I don't know what the packets mean, but at leat there is bi-directional traffic. Just to be sure, I disabled the firewall on my Win7 management PC just in case that was a problem, but that didn't make a difference.

Is there something I'm missing to able to connect remotely to this machine using MDTK and VNC/KVM?

Thanks,

Mark

32 Beiträge / 0 neu
Letzter Beitrag
Nähere Informationen zur Compiler-Optimierung finden Sie in unserem Optimierungshinweis.

Are you in Admin Control mode, or Client Control mode?  There are limitations if you are in Admin control mode.  Check out this section in the Implementation and reference guide:  Setup and Configuration of Intel AMT > Setup and Configuration Methods > Host-Based Setup and Configuration > Functional Limitations of Client Control Mode

Follow me on Twitter: @GaelHof
Facebook: https://www.facebook.com/GaelHof

Hi Gael,

Thanks for your reply.

It looks like Client vs. Admin are only possible if you do a host-based setup. It sounds like that requires running some kind of program from inside the OS? I haven't booted this machine into the OS yet.

I did a manual setup:  I pressed Ctrl-P during boot and used DOS-like menus. It's similar to SMB mode, which I've used in years past.

P.S. I followed an approach similar to the one here (although it shows AMT 6):  http://www.howtogeek.com/56538/.

What version of AMT does your system have? Client Control mode is what you get if you configure from the MEBx menus for newer AMT Systems.

Are you sharing the IP address (Host OS and ME?)  Maybe you are trying to connect to the OS and not the ME?  Have you tried entering the actual IP address when connecting?  (sometimes FQDN is not resolved) 

KVM and IDER are enabled in the bios?  Are you having problems connecting to the device, in general, or just KVM?  If KVM, which ports are you trying to connect via?

Follow me on Twitter: @GaelHof
Facebook: https://www.facebook.com/GaelHof

Quote:

Gael Hofemeier (Intel) wrote:
What version of AMT does your system have? Client Control mode is what you get if you configure from the MEBx menus for newer AMT Systems.

AMT 9.0.2-build 1345. So I guess I'm in Client Control mode. I should still be able to do KVM, right?

Quote:

Gael Hofemeier (Intel) wrote:
Are you sharing the IP address (Host OS and ME?)  Maybe you are trying to connect to the OS and not the ME?  Have you tried entering the actual IP address when connecting?  (sometimes FQDN is not resolved)

Yes. I am sharing the IP address (I don't recall seeing the option NOT to share it--it just uses DHCP). I am connecting via IP address, not FQDN. The main OS is not booted. I was trying to connect while in the MEBx was on the screen, and then when a Hiren BootCD menu was on the screen, for example. I even tried connecting when the power is off.

Quote:

Gael Hofemeier (Intel) wrote:
KVM and IDER are enabled in the bios?  Are you having problems connecting to the device, in general, or just KVM?  If KVM, which ports are you trying to connect via?

KVM and IDER are enabled in MEBx, if that is what you mean? I cannot connect from the MDTK (this does a bunch of SOAP calls on ports 49191-49196) or from UltraVNC (port 5900). However I can connect fine by pointing a browser at http://192.168.x.x:16692.

You shouldn't be able to connect directly from UltraVNC, is that what you are trying to do?  If you can connect via the browser then your system should be set up just fine.  Can you send some screen shots of what the DTK is looking like when you try to connect?

Here is a blog that I wrote regarding KVM troubleshooting..

http://software.intel.com/en-us/blogs/2012/08/08/intel-kvm-port-requirements-and-troubleshooting-tips/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+IntelSoftwareNetworkBlog+%28Intel+Developer+Zone+Blog%29

Follow me on Twitter: @GaelHof
Facebook: https://www.facebook.com/GaelHof

I first tried to connect with MDTK. When I saw that it had an option for connecting with UltraVNC, but that the option wasn't available because MDTK wasn't connected, I tried UltraVNC directly.

Attached are a screen shot of MDTK (it says "Abort Connect" for 10 seconds, then times out), and part of the Wireshark packet sniff during the connection attempt.

I wonder if the time zone could make a difference? It look like the computer is still on GMT and I'm in PST.

I'll check out your blog post, thanks.

Anlagen: 

AnhangGröße
Herunterladen mdtk.png68.38 KB
Herunterladen wireshark.png69.66 KB

Ok - the UltraVNC is not a management console so it cannot connect to AMT - it is used with the KVM feature (which requires that you are already connected)  And UltraVNC requires a License if you want to use it's KVM feature.  The blog I sent covers that.

The image doesn't tell me a whole lot - have you tried connecting via the vPro Platform Solution Manager?  I like to try alternative methods to rule out there being a bug in the DTK. http://software.intel.com/en-us/blogs/2013/04/19/introducing-the-intel-vpro-platform-solution-manager

Sometimes Anti-virus software blocks the AMT messages from going back and forth.  When you access the WebUI are you on the local AMT Client, or are you doing it remotely accross the network?

Follow me on Twitter: @GaelHof
Facebook: https://www.facebook.com/GaelHof

Alright I was able to connect using PSM no problem using digest, non-TLS authentication. Maybe the DTK is requiring TLS even though it says it will automatically use it "if available." It also remembers the password even when you tell it not to.

I prefer not to buy RealVNC Plus for a function I will rarely use. So I was trying to use UltraVNC. "UltraVNC is Free and distributed under the terms of the GNU General Public License."

Let's see if I have this right:

I should be ale to use port 5900 with RFB if my password is 8 characters, which it is.

However the VNC server port must be changed programmatically--there's no MEBx setting for it.

DTK would let me change the port if I could connect, but I can't.

PSM only offers the option of using RealVNC Plus. Maybe if I buy (or trial) that, a screen would open that allows me access to the port settings. There is no general access to KVM server settings.

It doesn't seem like it should be this hard!

P.S. I found an option in the DTK to show Debug information. The attached screenshot shows the connection as it fails--read from the bottom up. There is no mention of 16994 or 16995 so it looks like it's not getting past the SOAP connection on 16992/16993.

Anlagen: 

AnhangGröße
Herunterladen mdtk-debug.png58.8 KB

You mentioned that the time on your computer wasn't set correctly?  That can certainly create issues of connectivity.  The KVM blog that I sent you has information of which VNC products can be used.  If you want to get rid of the splash screen, you have to buy a licence, but either way you should be able to do a kvm session.  PSM uses the redirection ports and the DTK allows both but you have to enable redirection in order for it to work using the KVM port.  Also for the PSM - I have instructions in that blog I sent you that describes what you have to do - it isn't all straight forward, unfortunately (which is why I wrote the blog.)    And the KVM password (if using the kvm ports must be strong - try P@ssw0rd - that works.)  

Follow me on Twitter: @GaelHof
Facebook: https://www.facebook.com/GaelHof

Gael,

Thanks for your reply.

This desktop has now been deployed with Windows 7 32-bit restored from the old system's image. I installed the AMT that came with the computer (screen shot). I can connect across a VPN using FQDN, using either the web interface or PSM.

I'm not clear where AMT gets its clock or what the time should be. Checking the web interface of a few systems:

  • An AMT 3.2.20 system shows the correct local time.
  • An AMT 5.2.40 system is ahead by one hour (daylight savings)?
  • The new AMT 9.0.2 system is ahead by 8 hours (meaning it is showing Greenwich Mean Time).

My understanding was that the splash screen only appears with RealVNC Standard, and you can avoid it by buying RealVNC Plus. But I'm not using RealVNC at all. I'm trying to use UltraVNC.

In fact the splash screen info may be out of date. The screen shot in your PSM blog shows a "KVM Remote Control" link. I can imagine that that used to launch the free version of RealVNC, with the splash screen. Now, they no longer give you that option:  the link is called "VNC Plus KVM Viewer", and the only option is to install a trial of VNCPlus (screen shot).

Meanwhile the AMT event log of the new machine has started showing messages like "Authentication failed 800 times. The system may be under attack." Since none of the AMT ports are open to the Internet, an attack seems unlikely. I guess that's a separate issue.

Anlagen: 

AnhangGröße
Herunterladen local-amt.png35.26 KB
Herunterladen psm-vnc.png64.73 KB

Hi. This is weird, MDTK not connecting to Intel AMT 9.x machine?? So, first, Intel AMT does not come with VNC port 5900 enabled by default. So it you try any VNC software the connection will go to the operating system. You need to get the MDTK connected then you will be able to enable hardware port 5900 and VNC connections will hit the hardware and the OS will see nothing.

Now, in Commander go in the HELP menu and select "Show Debug Information..." then try to connect and send back the text of screen shot of what you see there. I am lucky, I am moving to another lab at Intel that has plenty of Intel AMT 9.x machines, in the next few weeks I should be able to do lots more testing (time permitting). I have tested Commander with 9.x and it worked for me, hopefully the debug screen will show the problem.

Thanks,
Ylian

Oh, I want to point out a possible thing to check. MDTK may not connect because the password you type is not right, even if you think it's right. If you are using any special keyboard layouts that is not "US-English" in Windows, you risk a chance of running into this. Go back in MEBx try to change your computer name and type in your password in that box, look at what is actualy written. Because MEBx uses US-English and Windows uses a different keyboard layout, you may see the problem right away.

Ylian

Hi Ylian,

Thanks for your reply and help. I'm in the U.S. and the password only contains U.S. letters, numbers, and symbols. It's been working fine for years to connect to the web interface, and it works fine to connect to PSM. If you think it would matter, I can temporarily try a super-simple one just to be sure.

Yes, I thought that was the case, that I would need to use MDTK or some other program to adjust listening ports.

You'll find an MDTK debug screen shot attached to my November 1 post above.

Mark

Ha! I see the debug now in your previous post. Wow, with Intel AMT 9.x, I was expecting GetCoreVersion() to still exist as an older EOI call. But nop, the call seems to fail. I will try to find myself an Intel AMT 9.x machine with the same thing and change the code. Not sure when I will get to do this.

It's not clear the from the screenshot but the highlighted line is System.Net.WebException. That is what the stack trace in the bottom window is referring to when it says, "The operation has timed out."

BTW I just tested MDTK against an old AMT 3.x machine and it connected fine. That machine uses the same password as the AMT 9 machine.

P.S. Ylian, when you are poking around in the code, maybe you can check on the Remember Password behavior. It seems to remember it even when I uncheck the box.

mcbsys - I was wondering why there were soap calls (AMT 9 does not use SOAP) anymore.  Does your system have an older version of the MEI driver and LMS software?  Please verify that your MEI is version 9.x. and that your system is running the latest version of the LMS software.

Follow me on Twitter: @GaelHof
Facebook: https://www.facebook.com/GaelHof

Hi Gayle,

My cheap management laptop does not have AMT at all, so no drivers are installed. I noticed the outbound SOAP calls in a packet sniffer when MDTK, installed on this laptop, tries to connect to the AMT 9 machine. I guess maybe MDTK is trying various methods, since it supports various versions of AMT? I haven't used the packet sniffer while using the PSM, but the PSM connects no problem.

Mark Berry

This actually makes sense - the DTK does try alternate methods. Ylian would be able to comment better on that.  Your managment console does not need AMT at all.

Follow me on Twitter: @GaelHof
Facebook: https://www.facebook.com/GaelHof

Hi Ylian,

Any update on this? I'd still like to be able to use MDTK with vPro 9. I upgraded from 1.26 to 1.28 but I'm still getting the System.net.WebException when I try to connect.

Also, any chance you could add release dates to http://opentools.homeip.net/open-manageability? That would make it easier to tell if I have there has been an update since my last visit. Also maybe a note when a release is pulled, e.g. 1.26 disappeared.

Thanks,

Mark

Still trying to get this to work. Downloaded MDTK 1.31 but it cannot connect to a vPro 9 system. See new screenshot, attached.

What is the status of this issue?

Mark

Anlagen: 

AnhangGröße
Herunterladen MDTK error.png70.13 KB

There is a new version out there.  Please let us know if it is working for you:  https://downloadcenter.intel.com/Detail_Desc.aspx?DwnldID=22183

Follow me on Twitter: @GaelHof
Facebook: https://www.facebook.com/GaelHof

Oops did not mean to reply about PSM on this thread. This thread is about the MDTK issue, which is still my main concern. I've moved my PSM reply here:  https://software.intel.com/en-us/forums/topic/516500#comment-1792252.

Mark

Ok thanks.  Did you try the 32 bit as well?  I have reported this back to the developers.

Follow me on Twitter: @GaelHof
Facebook: https://www.facebook.com/GaelHof

Some good news on the MDTK issue:  it finally occurred to me to install it on the LAN where the actual vPro 9 machines are located, as opposed to working through a VPN tunnel. Voila! Instant connection to the vPro 9 machines, which allowed me to enable their VNC ports so I can use the free UltraVNC for remote control as described here.

So the new description of the issue:

  • MDTK 1.31 _cannot_ connect to any vPro machines across a VPN.
  • MTDK 1.31 _can_ connect to vPro machines, including vPro 9 machines, on the local LAN. However it cannot connect to the machine where it is installed either user localhost or the actual IP address.

Mark

Hi Mark. Sorry for the delay. With my work on Meshcentral, I had little time to work on the MDTK. This said, these are lots of requests for MDTK updates and starting getting some test machines at my desk. So, should start focusing on it a little more in the next few weeks.

I need a little help understanding the issue. For your VPN setup, are you running a VPN client on the Intel AMT machine, connecting to a network and trying to access Intel AMT back thru the VPN? Or is the machine on a corporate network and the machine running the MDTK is running the VPN client?

If your run the VPN client & the MDTK on the same machine and connect to a network and access Intel AMT, it should work fine. In this case, the VPN will get make the MDTK machine look like it's on the corporate network and connections should route ok.

If the VPN client is on the Intel AMT machine itself, this is a bit more tricky. Your basicaly accessing the Intel AMT machine like if Command was running in the Intel AMT machine's own OS. It's like installing Commander on the local machine and connecting to 127.0.0.1. It should work, but it's not going to give you the out-of-band features that Intel AMT offers. If the OS goes down, the VPN will also drop and you will not be able to remotely access Intel AMT. Still, accessing Intel AMT using a VPN (Where the VPN client software is on Intel AMT) should work.

Let me know what type of setup you have.
Ylian

Hi Ylian,

Thanks for the reply.

The VPN in this case is set up on the routers. Basically I have Tomato open-source firmware on my router and the client's router. The routers establish and maintain the VPN tunnel. All I have to do on the client is access the IP address on the remote network. This works fine for Remote Desktop, copying files back and forth via Windows Explorer, accessing an intranet site hosted on the client's network, etc. In fact, now that I was able to configure the target machines to accept VNC on 5900, those VNC connections work fine across the VPN as well. So far the only thing I haven't been able to do is get MDTK working across the VPN.

Now that I have VNC working, I probably won't need the MDTK very often and I've left an installation inside the client's network for when I do. So I wanted to report this status to you, but being able to run it successfully inside their network is okay as a workaround for me.

Regards,

Mark

Thanks for the report. I get it now. It's weird, your VPN setup should just forward everything like if you where on the local network. So, MDTK or any other application should just work. If you run into this problem and want to help, go in Commander's help mesh, hit "Show Debug Information...", try to connect and send us the debug log.

Also, if your are going to be managing lots of machines all over the Internet, check out Meshcentral.com. You can setup all your machines on the server and do web based hardware KVM, IDE-R and piles more for free. The entire site is open source, so you can setup your own instance of meshcentral. The main benefit over what you are doing is that you don't need a VPN. Machines can move all over the Internet and you still can manage them using a web site.

Ylian

Thanks Ylian. You can find my latest debug screen shot above in post #23. It's like a .Net call doesn't like the VPN, or maybe the VPN is okay but it doesn't like the attempt to connect outside the local subnet?

Meshcentral sounds very cool but is more than I need for now. If I ever need VNC access outside the firewall, I will definitely be looking for alternatives.

Mark

Quick update. I now have the Managebility Commander Tool 1.32 working across the Internet and VPN for KVM control using the free UltranVNC client. I documented the procedure (including certificate generation) here:

http://www.mcbsys.com/techblog/2014/12/set-up-intel-amt-for-remote-kvm/

I did have one problem today trying to connect to a new AMT 9 machine on the local LAN using an IP address. It kept timing out, even after I corrected the password. I deleted the machine and re-added it, this time specifying the correct password in the Add Intel AMT Computer dialog. This time it connected immediately. My hunch is that it wasn't using the password I typed in the main Connect & Control screen. Also, passwords seem to always be remembered even when you uncheck Remember. Ylian, perhaps you could review password handling sometime. Meanwhile, I'me pretty happy with the functionality I get from this tool!

Mark Berry
MCB Systems
 

Kommentar hinterlassen

Bitte anmelden, um einen Kommentar hinzuzufügen. Sie sind noch nicht Mitglied? Jetzt teilnehmen