vPro in details

vPro in details

Hi!
I'm experiencing problems in remote authorization on vPro platform over LAN. It happens rarely, but i still can't detect the problem's source.

I used ethereal in order to compare the details of both connections, successful and failed ones. At the beginning they were the same. The differences began after first unauthorized response from vPro platform:

Successful authorization

    ...
Source: 192.168.0.152 (192.168.0.152)
Destination: 192.168.0.14 (192.168.0.14)
Transmission Control Protocol, Src Port: 2243 (2243), Dst Port: 16992 (16992), Seq: 803, Ack: 954, Len: 0
Source port: 2243 (2243)
Destination port: 16992 (16992)
Sequence number: 803 (relative sequence number)
Acknowledgement number: 954 (relative ack number)
Header length: 20 bytes
Flags: 0x0014 (RST, ACK)
0... .... = Congestion Window Reduced (CWR): Not set
.0.. .... = ECN-Echo: Not set
..0. .... = Urgent: Not set
...1 .... = Acknowledgment: Set
.... 0... = Push: Not set
.... .1.. = Reset: Set
.... ..0. = Syn: Not set
.... ...0 = Fin: Not set

Authorization failure

    ...
Source: 192.168.0.152 (192.168.0.152)
Destination: 192.168.0.14 (192.168.0.14)
Transmission Control Protocol, Src Port: 2262 (2262), Dst Port: 16992 (16992), Seq: 803, Ack: 954, Len: 0
Source port: 2262 (2262)
Destination port: 16992 (16992)
Sequence number: 803 (relative sequence number)
Acknowledgement number: 954 (relative ack number)
Header length: 20 bytes
Flags: 0x0011 (FIN, ACK)
0... .... = Congestion Window Reduced (CWR): Not set
.0.. .... = ECN-Echo: Not set
..0. .... = Urgent: Not set
...1 .... = Acknowledgment: Set
.... 0... = Push: Not set
.... .0.. = Reset: Not set
.... ..0. = Syn: Not set
.... ...1 = Fin: Set

192.168.0.14 is vPro platform
192.168.0.152 is the one, which requested authorization.
Login and password are the same in both cases.

So by the logs it is clear, that in successful case the requesting host makes connection reset in order to sunc further, in failure case the requesting host closes the connection.

After debugging the .NET core it seemed to me that the requesting host just didn't get any response from vPro platform in a blocked send operation on a socket and treated this fact as HTTP 401 Unauthorized by WebException.

Is it any known issue that i missed?
And probably someone could tell me how can i review the details of the connection session setup on the vPro side?
Any other suggestions would help either.

4 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

I will not be of any help... the fact that it happens rarely indicates to me that everything works greatfor the most part... that is really good news! May I ask what application are you using to connect with? Is it the same appliaction that fails to connect each time or do various applications that you have fail to connect similarly in this manner occasionally? Do you attempt to connect immediatly after the failure with the failing application as well as trying to connect after the failure with other applicationslike IE? What are those results please? Can you correlate the failures with -anything- else in the environment that goes on over your network periodically? The next time it fails can you possibly be ready standing by to connect to that thing with every application you can find that will do the job... seriously.

This may be only of little comfort to you at this point... mine are rock solid and never fail to auth... I am confident that when you

find your problem, yours will do the same. I am sure your question will draw some interest... please keep us informed as to what you try next.

Ajith Illendula (Intel)'s picture

Hi,

Can you give some of the preliminary information about AMT, BIOS and OEM versions? How is AMT configured SMB vs Enterprise mode? Also I would like to know what is the power policy you have applied on the AMT enabled machine? Are you using WakeOnLan (WoL) power policies and if so what is the idle timeout configured as?

What is the application you are using to connect to AMT (IE, AMT Commander, Your application etc)? After your authorization fails, do you try to re-connect and what will happen in that scenario? We look forward to your response.

Thanks.

Yes, for the most part it works great and it's great indeed.
I'm using the same application. It's a kind of sample app., based on AMT SDK .NET samples. It works perfectly while it consists of .NET dll for RemoteControlService access and a simple UI exe, which uses dll.
But if i add a reference on a 3-rd party .NET dll from exe, it produces "unauthorized" exception, while i'm using not a single row of code from this dll and making no other changes in the solution except this reference. If i remove the reference, it works perfect again.

I tried to reconnect as you suggested, but it still failed. Thanks a lot for your response. Actually you gave me one idea and it was exactly what i came here for.
I'll try to debug this dll to see if it affects any .NET component during its loading and mapping into the process's address space.
Somewhere I read about such issue
-Title: Sending WS-Management packets encoded with an unsupported encoding
type returns error code 401 instead of 415.
-ID: b2438588
-Symptoms: When sending a WS-Management request which is encoded with an
unsupported encoding type (e.g. UTF-16), Intel AMT returns HTTP
error code 401 ("unauthorized") instead of 415 ("unsupported media
type").
From TCP stream it is clear that utf-8 is used. However, it is probably some yet unknown .NET issue, which would be useful to know about to avoid it in the future.
If you have any other ideas or suggestions to be checked, please let me know.

Login to leave a comment.