none
Bitlocker Network Unlock / Timeout DHCP UEFI RRS feed

  • Question


  • Hello,

    During Bitlocker Network Unlock, my client has a problem getting the IP address from the DHCP server.

    Summary of the problem:
    "When the DHCP server processing time between DHCP DISCOVER and OFFER requests exceeds 1 second, the UEFI DHCP client goes into timeout and no longer continues the DHCP sequence (with a REQUEST packet)".

    => My question is: "Can we set this timeout value more than 1 second?"

    Here is the DISCOVER / OFFER delay and the result of obtaining the IP address or not:

    DISCOVER / OFFER delay
    NOK 1.000298
    0.000185 OK
    NOK 1.000793
    NOK 1,000,000
    0.000171 OK
    1.000302 NOK
    0.000191 OK
    1.000227 NOK
    0.000164 OK
    0.000272 OK
    0.000236 OK
    0.999670 NOK

    For information :
    - There is no timeout when getting an IP during the PXE boot or with the Windows DHCP client.
    - The WDS BitLocker Network Unlock server works perfectly: once the UEFI DHCP client obtains an IP address (step 1), the communication with the WDS server and the decryption of the station (step 2) works in 100% of cases.

    Thanks for your help,

    Regards,
    Wednesday, October 23, 2019 11:47 AM

Answers

  • Please refer to this similar case

    https://gitlab.isc.org/isc-projects/dhcp/issues/10

    The scenario is a problem with a UEFI DHCP process which appears to timeout around 600ms, due to a Bitlocker Network Unlock process. When the ping before allocate check is enabled on the DHCP server, the minimum timeout being 1 second, this results on the DHCP process on the client failing before the ping timeout is reached.

    For this situation, It would not be terribly difficult to add. The most likely approach would be to add a new field:

    ping-timeout-ms

    We have some choices here:

    If ping-timeout-ms is specified use it instead of ping-timeout

    Timeout duration becomes ping-timeout + ping-timeout-ms

    I think I prefer #1 (closed).

    Please Note: Since the website is not hosted by Microsoft, the link may change without notice. Microsoft does not guarantee the accuracy of this information.

    Regards


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Friday, October 25, 2019 7:23 AM
    Moderator
  • Hello !

    Thank you very much! Your answer was good about my problem!

    I explained the symptoms and the solution here: BitLocker Network Unlock - Linux DHCP Incompatibility

    Thanks again and have a nice day,

    Florent



    • Marked as answer by F Florent Wednesday, November 13, 2019 3:53 PM
    Wednesday, November 13, 2019 3:52 PM

All replies

  • Please refer to this similar case

    https://gitlab.isc.org/isc-projects/dhcp/issues/10

    The scenario is a problem with a UEFI DHCP process which appears to timeout around 600ms, due to a Bitlocker Network Unlock process. When the ping before allocate check is enabled on the DHCP server, the minimum timeout being 1 second, this results on the DHCP process on the client failing before the ping timeout is reached.

    For this situation, It would not be terribly difficult to add. The most likely approach would be to add a new field:

    ping-timeout-ms

    We have some choices here:

    If ping-timeout-ms is specified use it instead of ping-timeout

    Timeout duration becomes ping-timeout + ping-timeout-ms

    I think I prefer #1 (closed).

    Please Note: Since the website is not hosted by Microsoft, the link may change without notice. Microsoft does not guarantee the accuracy of this information.

    Regards


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Friday, October 25, 2019 7:23 AM
    Moderator
  • Hello !

    Thank you very much! Your answer was good about my problem!

    I explained the symptoms and the solution here: BitLocker Network Unlock - Linux DHCP Incompatibility

    Thanks again and have a nice day,

    Florent



    • Marked as answer by F Florent Wednesday, November 13, 2019 3:53 PM
    Wednesday, November 13, 2019 3:52 PM