5 Replies Latest reply on May 27, 2015 2:42 AM by martin.lloyd

    MPS - failed to read tcp forward request

    binyan

      Hey everyone,

      We're trying to setup an AMT remote solution. We're successfully getting the connection from the AMT device, passing the certificate check but then we're stuck.

      The MPS server gives us the following error: "AMT_Tunnel_Supplier: failed to read tcp forward request".

      We're wondering if anyone here can give us a direction to were the problem comes from.

      The full MPS log is attached.

        • 1. Re: MPS - failed to read tcp forward request
          martin.lloyd

          Hello Evgeny,

           

          I recommend you review the excellent document "Intel vPro Technology Use Case Reference Design - CIRA Ref Architecture" which can be found here: Intel® Download Center

           

          Check stunnel, mps and apache config files according to this guide and the samples provided. From an MPS perspective it looks like the AMT Port Forwarding (APF) authorisation service (auth@amt.intel.com) and Intel AMT port forwarding requests (pfwd@amt.intel.com) are successful but if Stunnel log output doesn't look similar to section 9 "Troubleshooting" in the above document then you likely have issues with your SSL certificate and setting up the secure tunnel, which APF relies upon.

           

          Follow the guide to the letter and you will be successful! You may also find additional detail in the latest Intel® AMT SDK Documentation useful.

           

          Regards

           

          - Martin.

          • 2. Re: MPS - failed to read tcp forward request
            binyan

            Hi Martin,

            First of all, thank for the answer. You gave a really great reference, it's a shame I couldn't find it until now

            Now, regarding the certificate. As I've told, I'm pretty sure we pass the authentication. We get the following log in the stunnel:

             

            2015.05.06 11:09:37 LOG7[main]: Service [psudo-tcp] accepted (FD=548) from 84.228.118.88:16994

            2015.05.06 11:09:37 LOG7[main]: Creating a new thread

            2015.05.06 11:09:37 LOG7[main]: New thread created

            2015.05.06 11:09:37 LOG7[13]: Service [psudo-tcp] started

            2015.05.06 11:09:37 LOG5[13]: Service [psudo-tcp] accepted connection from 84.228.118.88:16994

            2015.05.06 11:09:37 LOG7[13]: SSL state (accept): before/accept initialization

            2015.05.06 11:09:37 LOG7[13]: SNI: no virtual services defined

            2015.05.06 11:09:37 LOG7[13]: SSL state (accept): SSLv3 read client hello A

            2015.05.06 11:09:37 LOG7[13]: SSL state (accept): SSLv3 write server hello A

            2015.05.06 11:09:37 LOG7[13]: SSL state (accept): SSLv3 write certificate A

            2015.05.06 11:09:37 LOG7[13]: SSL state (accept): SSLv3 write certificate request A

            2015.05.06 11:09:37 LOG7[13]: SSL state (accept): SSLv3 flush data

            2015.05.06 11:09:37 LOG7[13]: SSL state (accept): SSLv3 read client certificate A

            2015.05.06 11:09:37 LOG7[13]: SSL state (accept): SSLv3 read client key exchange A

            2015.05.06 11:09:37 LOG7[13]: SSL state (accept): SSLv3 read finished A

            2015.05.06 11:09:37 LOG7[13]: SSL state (accept): SSLv3 write change cipher spec A

            2015.05.06 11:09:37 LOG7[13]: SSL state (accept): SSLv3 write finished A

            2015.05.06 11:09:37 LOG7[13]: SSL state (accept): SSLv3 flush data

            2015.05.06 11:09:37 LOG7[13]:   14 server accept(s) requested

            2015.05.06 11:09:37 LOG7[13]:   14 server accept(s) succeeded

            2015.05.06 11:09:37 LOG7[13]:    0 server renegotiation(s) requested

            2015.05.06 11:09:37 LOG7[13]:    0 session reuse(s)

            2015.05.06 11:09:37 LOG7[13]:   13 internal session cache item(s)

            2015.05.06 11:09:37 LOG7[13]:    0 internal session cache fill-up(s)

            2015.05.06 11:09:37 LOG7[13]:    0 internal session cache miss(es)

            2015.05.06 11:09:37 LOG7[13]:    0 external session cache hit(s)

            2015.05.06 11:09:37 LOG7[13]:    0 expired session(s) retrieved

            2015.05.06 11:09:37 LOG6[13]: SSL accepted: new session negotiated

            2015.05.06 11:09:37 LOG6[13]: No peer certificate received

            2015.05.06 11:09:37 LOG6[13]: Negotiated TLSv1 ciphersuite AES128-SHA (128-bit encryption)

            2015.05.06 11:09:37 LOG7[13]: Compression: null, expansion: null

            2015.05.06 11:09:37 LOG6[13]: Failover strategy: round-robin

            2015.05.06 11:09:37 LOG6[13]: s_connect: connecting 127.0.0.1:1234

            2015.05.06 11:09:37 LOG7[13]: s_connect: s_poll_wait 127.0.0.1:1234: waiting 10 seconds

            2015.05.06 11:09:37 LOG5[13]: s_connect: connected 127.0.0.1:1234

            2015.05.06 11:09:37 LOG5[13]: Service [psudo-tcp] connected remote server from 127.0.0.1:54891

            2015.05.06 11:09:37 LOG7[13]: Remote socket (FD=444) initialized

            2015.05.06 11:09:38 LOG3[13]: readsocket: Connection reset by peer (WSAECONNRESET) (10054)

            2015.05.06 11:09:38 LOG5[13]: Connection reset: 140 byte(s) sent to SSL, 225 byte(s) sent to socket

            2015.05.06 11:09:38 LOG7[13]: Remote socket (FD=444) closed

            2015.05.06 11:09:38 LOG7[13]: Local socket (FD=548) closed

            2015.05.06 11:09:38 LOG7[13]: Service [psudo-tcp] finished (0 left)

             

            It's a bit different from the log in "Troubleshooting" section, but as far as I can understand from this log, we do manage to create a session and for some reason the client resets the connection.
            The only difference in our configuration is the port numbers, but I don't think this is the source of the problem.

            • 3. Re: MPS - failed to read tcp forward request
              binyan

              I'm still trying to identify the problem. So after going over the reference again I noticed one interesting thing.

              In section 4.3.3 the IP which is specified for Http, Socks and SOAP is 10.10.10.100. I'm wondering what does this IP represent? In the video tutorial the address is 192.168.1.1. In our configuration we set this address to 127.0.0.1 (because the proxy resides on the same machine). So, say we've got an Amazon server instance with IP 123.456.78.9. What shall we specify in the MPS configuration?

              • 4. Re: MPS - failed to read tcp forward request
                binyan

                Following the guide to the letter did the work. Thanks!

                • 5. Re: MPS - failed to read tcp forward request
                  martin.lloyd

                  Excellent, glad you found the guide useful!

                   

                  Regards

                   

                  - Martin.