Need to change the Maximum Transmission Unit (MTU) size for vPro packets

[idata]

Hi!

I am trying to configure vPro workstations to be managed by a Landesk server. I am able to get a workstation through the "provisioning" process successfully, however, I am not able to perform any of the remote management functions (from the Landesk server) after it has gone through the provisioning process. What I did discover is that I am able to access the workstation's AMT web page from any workstation/server on the same subnet. However, when trying to access it from a workstation/server on a different subnet, the web page fails to load.

In order to troubleshoot the issue further, I ran a Wireshark capture of the traffic while trying to access the workstation's AMT web page from the Landesk server. I found that the "don't fragment" flag is set on the packets before the traffic dies out. After talking with our network team, I found that the MTU size accross our WAN is set to 1400. We did test allowing the traffic from the vPro workstation to the Landesk server to transmit packets above the 1400 limit and the vPro management works great.

So, long story short, I need to be able to set the MTU size to be less than 1400 bytes in order to keep the packets from fragmenting. This appears to be the only way to get the vPro communication to work across our WAN link.

Any ideas?

[Alireza_M_Intel]

Hi,

Do you have to change the default MTU size of Windows TCP stack from1500 to lower than 1400 in your environment in order to optimize packet sizes for each medium too?

Is it possible to attach a copy of the wireshark capture when managing AMT?

Also what is the version of AMT and manufacture and model of the vPro system?

Was system provisioned with use of Provisioning Certificate, PID/PPS, or simply in non-secure manner?

As far as available configuration settings, AMT FW only provides a limited set of tcp/ip configuration options, from the top of my head:

Dhcp on/off, ping replies on/off,..

With knowing more information about your environment and studying the wireshark capture, we may duplicate the issue in lab and get more detail.

Regards,

Ali

[idata]

Do you have to change the default MTU size of Windows TCP stack from1500 to lower than 1400 in your environment in order to optimize packet sizes for each medium too?

We do not modify the Windows stack. We have, however, modified the MTU size to be below 1400 in order to optimize some file replication we are doing.

Is it possible to attach a copy of the wireshark capture when managing AMT?

I will have to clear it through our security team, but possibly. I will get back to you.

Also what is the version of AMT and manufacture and model of the vPro system?

We are on firmware version 5.0.1.1111 as supplied by Dell for the Optiplex 960.

Was system provisioned with use of Provisioning Certificate, PID/PPS, or simply in non-secure manner?

PID/PPS

[Alireza_M_Intel]

Hi Jason,

When you provisioned the system, did you choose the option "Do not respond to ping" or "Ping Disabled" as part of the vPro provisioning profile? If so that is more likely the root cause of your problem. Currently any version of AMT below 5.1, does not support PMTU (Path discovery MTU) when the Ping to vPro option is disabled. PMTU relies on ICMP to negotiate the right MTU size between two network devices and disabling Ping, blocks ICMP traffic. This issue does not impact the provisioning of vPro system as "Ping Disabled" option comes to play after provisioning completed. If you systems are all AMT 5.x, the best is to work with Dell to get AMT 5.1.x firmware update and upgrade all systems. Alternative is to keep the Ping to vPro option enabled. If you have any system with AMT version 4.x or lower and you do not wish to keep the Ping to vPro option as enabled, let us know so we look into a better solution.

Regards,

Ali

[idata]

Ali,

I do not have the option "Do not respond to ping" or Ping Disabled" set. I double checked that the option was not enabled on one of my test systems by browsing to the HTTPS page and verifying that "Respond to Ping" is selected in the "Network Settings" section.

I will go ahead and get the 5.1.x firmware update and let you know if that makes any difference. If you have any other suggestions, let me know.

Thanks,

Jason

[Alireza_M_Intel]

Jason,

Then it seems like AMT firmware below 5.1 version does not support Path Discovery MTU (PMTU) regardless of the ping option settings in the firmware. Please update your system with 5.1 firmware version and let me know the result to follow up with developers.

Thanks

[Alireza_M_Intel]

Hi Jason,

I confirmed with team that ICMP is filtered as long as host OS is up and running for all AMT versions below 5.1. Therefore PMTU that relies on ICMP will fail. This issue is fixed in AMT 5.1 version. Would it be possible to test the AMT use cases on a system that host OS is not running? It's easier to boot the system to a non-bootable CD or simply disconnect the hard drive cable. We expect to see different result as ICMP is no longer filtered in this scenario. Let me know what you will find.

Thanks,

Ali

[idata]

I am testing with the 5.1 firmware upgrade today. I will also run the test without the OS loaded to see how it behaves.

What about 4.0 versions and below? Will there or is there a firmware update available to include the fix for PMTU filtering? I have quite a few AMT 3.0 PC's out there as well.

[Alireza_M_Intel]

Thanks Jason. Let me know what you will find. At this point there is no plan to address this issue for legacy firmware versions but if we can justify the effort, team will lookinto it. I will communicate your requirement to team for the follow up.

Regards,

Ali

[Alireza_M_Intel]

Hi Jason,

Did you try 5.1 firmware and/or AMT OOB use cases on a system with no OS?

Regards,

Ali

[idata]

Ali,

Sorry for the delay in response. Here are the tests I ran. The workstations were already provisioned prior to the test.

FirmwareOS LoadedvPro Functioning5.0OS loaded

No

5.0No OS loaded (powered off or in BIOS config)No ??5.1OS loadedYes3.0OS loadedNo3.0No OS loaded (powered off or in BIOS config)Yes

So, it would appear that the new firmware (5.1) is working in our environment!! I didn't, however, get the same results between a 5.0 and 3.0 firmware when the OS wasn't loaded. 3.0 worked but 5.0 didn't. Not sure what that was about. Maybe I did something wrong...I didn't spend too much time troubleshooting.

We would definitely be very appreciative if the issue could be addressed in legacy firmware as well (specifically 3.0 for us). We have a couple hundred AMT 3.0 PC's already in use (vPro currently disabled) as well as some already purchased that have not yet been deployed. It would be great to be able to get vPro working on them as well.

Thanks again for your help!

[Alireza_M_Intel]

Jason,

Glad to see 5.1 firmware update resolved your outstanding issue with PMTU. I shared your input with Engineering team and informed them about your requirement for a patch on AMT 3.x version to support PMTU.

Best Regards,

Ali

[idata]

Ali,

Is there a more formal process I can go through to officially request the PMTU issue be resolved in the 3.0 firmware version? It would be very helpful in our environment if we could get the 3.0 working.

Thanks!

[Alireza_M_Intel]

Hi Jason,

I forwarded your request the same day you posted your message to follow up but unfortunately have not heard back from anyone. I see due to the complexity of changes on legacy firmware, the effort may require serious business justification. Sorry that I have been much of help here. If you feel you need to pursue the issue, please explore the official channels.

Regards,

ali