Re: [edk2] [Patch 2/3] NetworkPkg/TlsDxe: Handle the multiple TLS record messages encryption/decryption.
Reviewed-by: Karunakar p <karunak...@amiindia.co.in>
-Original Message-
From: Jiaxin Wu [mailto:jiaxin...@intel.com]
Sent: Tuesday, March 20, 2018 6:07 AM
To: edk2-devel@lists.01.org
Cc: Karunakar P; Fu Siyuan; Ye Ting
Subject: [Patch 2/3] NetworkPkg/TlsDxe: Handle the multiple TLS record messages
encryption/decryption.
Cc: Karunakar P <karunak...@amiindia.co.in>
Cc: Fu Siyuan <siyuan...@intel.com>
Cc: Ye Ting <ting...@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiaxin Wu <jiaxin...@intel.com>
---
NetworkPkg/TlsDxe/TlsImpl.c | 74 +++--
NetworkPkg/TlsDxe/TlsImpl.h | 6 +---
2 files changed, 52 insertions(+), 28 deletions(-)
diff --git a/NetworkPkg/TlsDxe/TlsImpl.c b/NetworkPkg/TlsDxe/TlsImpl.c index
8e1238216b..a026075f36 100644
--- a/NetworkPkg/TlsDxe/TlsImpl.c
+++ b/NetworkPkg/TlsDxe/TlsImpl.c
@@ -1,9 +1,9 @@
/** @file
The Miscellaneous Routines for TlsDxe driver.
-Copyright (c) 2016 - 2017, Intel Corporation. All rights reserved.
+Copyright (c) 2016 - 2018, Intel Corporation. All rights reserved.
This program and the accompanying materials are licensed and made available
under the terms and conditions of the BSD License which accompanies this
distribution. The full text of the license may be found at
http://opensource.org/licenses/bsd-license.php
@@ -48,10 +48,11 @@ TlsEncryptPacket (
UINT16 ThisPlainMessageSize;
TLS_RECORD_HEADER *TempRecordHeader;
UINT16 ThisMessageSize;
UINT32 BufferOutSize;
UINT8 *BufferOut;
+ UINT32 RecordCount;
INTNRet;
Status = EFI_SUCCESS;
BytesCopied = 0;
BufferInSize = 0;
@@ -59,10 +60,11 @@ TlsEncryptPacket (
BufferInPtr = NULL;
RecordHeaderIn = NULL;
TempRecordHeader = NULL;
BufferOutSize= 0;
BufferOut= NULL;
+ RecordCount = 0;
Ret = 0;
//
// Calculate the size according to the fragment table.
//
@@ -89,34 +91,46 @@ TlsEncryptPacket (
(*FragmentTable)[Index].FragmentLength
);
BytesCopied += (*FragmentTable)[Index].FragmentLength;
}
- BufferOut = AllocateZeroPool (MAX_BUFFER_SIZE);
+ //
+ // Count TLS record number.
+ //
+ BufferInPtr = BufferIn;
+ while ((UINTN) BufferInPtr < (UINTN) BufferIn + BufferInSize) {
+RecordHeaderIn = (TLS_RECORD_HEADER *) BufferInPtr;
+if (RecordHeaderIn->ContentType != TlsContentTypeApplicationData ||
RecordHeaderIn->Length > TLS_PLAINTEXT_RECORD_MAX_PAYLOAD_LENGTH) {
+ Status = EFI_INVALID_PARAMETER;
+ goto ERROR;
+}
+BufferInPtr += TLS_RECORD_HEADER_LENGTH + RecordHeaderIn->Length;
+RecordCount ++;
+ }
+
+ //
+ // Allocate enough buffer to hold TLS Ciphertext.
+ //
+ BufferOut = AllocateZeroPool (RecordCount * (TLS_RECORD_HEADER_LENGTH
+ + TLS_CIPHERTEXT_RECORD_MAX_PAYLOAD_LENGTH));
if (BufferOut == NULL) {
Status = EFI_OUT_OF_RESOURCES;
goto ERROR;
}
//
- // Parsing buffer.
+ // Parsing buffer. Received packet may have multiple TLS record messages.
//
BufferInPtr = BufferIn;
TempRecordHeader = (TLS_RECORD_HEADER *) BufferOut;
while ((UINTN) BufferInPtr < (UINTN) BufferIn + BufferInSize) {
RecordHeaderIn = (TLS_RECORD_HEADER *) BufferInPtr;
-if (RecordHeaderIn->ContentType != TlsContentTypeApplicationData) {
- Status = EFI_INVALID_PARAMETER;
- goto ERROR;
-}
-
ThisPlainMessageSize = RecordHeaderIn->Length;
TlsWrite (TlsInstance->TlsConn, (UINT8 *) (RecordHeaderIn + 1),
ThisPlainMessageSize);
-Ret = TlsCtrlTrafficOut (TlsInstance->TlsConn, (UINT8
*)(TempRecordHeader), MAX_BUFFER_SIZE - BufferOutSize);
+Ret = TlsCtrlTrafficOut (TlsInstance->TlsConn, (UINT8
+ *)(TempRecordHeader), TLS_RECORD_HEADER_LENGTH +
+ TLS_CIPHERTEXT_RECORD_MAX_PAYLOAD_LENGTH);
if (Ret > 0) {
ThisMessageSize = (UINT16) Ret;
} else {
//
@@ -127,11 +141,11 @@ TlsEncryptPacket (
ThisMessageSize = 0;
}
BufferOutSize += ThisMessageSize;
-BufferInPtr += RECORD_HEADER_LEN + ThisPlainMessageSize;
+BufferInPtr += TLS_RECORD_HEADER_LENGTH + ThisPlainMessageSize;
TempRecordHeader += ThisMessageSize;
}
FreePool (BufferIn);
BufferIn = NULL;
@@ -199,10 +213,11 @@ TlsDecryptPacket (
UINT16 ThisCipherMessageSize;
TLS_RECORD_HEADER *TempRecordHeader;
UINT16 ThisPlainMessageSize;
UINT8 *BufferOut;
UINT32 BufferOutSize;
+ UINT32 RecordCount;
INTNRet;
Status = EFI_SUCCESS;
BytesCopied = 0;
BufferIn = NULL;
@@ -210,10 +225,11 @@ TlsDecryptPacket (
BufferInPtr = NULL;
RecordHeaderIn = NULL;
TempRecordHeader = NULL;
BufferOut= NULL;
Buff
Re: [edk2] [Patch 1/3] MdePkg/Tls1.h: Add TLS record header length and max payload length.
Reviewed-by: Karunakar p <karunak...@amiindia.co.in>
-Original Message-
From: Jiaxin Wu [mailto:jiaxin...@intel.com]
Sent: Tuesday, March 20, 2018 6:07 AM
To: edk2-devel@lists.01.org
Cc: Karunakar P; Fu Siyuan; Ye Ting
Subject: [Patch 1/3] MdePkg/Tls1.h: Add TLS record header length and max
payload length.
Cc: Karunakar P <karunak...@amiindia.co.in>
Cc: Fu Siyuan <siyuan...@intel.com>
Cc: Ye Ting <ting...@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiaxin Wu <jiaxin...@intel.com>
---
MdePkg/Include/IndustryStandard/Tls1.h | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/MdePkg/Include/IndustryStandard/Tls1.h
b/MdePkg/Include/IndustryStandard/Tls1.h
index 9009291ee3..cccb6db7fb 100644
--- a/MdePkg/Include/IndustryStandard/Tls1.h
+++ b/MdePkg/Include/IndustryStandard/Tls1.h
@@ -1,11 +1,11 @@
/** @file
Transport Layer Security -- TLS 1.0/1.1/1.2 Standard definitions, from RFC
2246/4346/5246
This file contains common TLS 1.0/1.1/1.2 definitions from RFC 2246/4346/5246
- Copyright (c) 2016 - 2017, Intel Corporation. All rights reserved.
+ Copyright (c) 2016 - 2018, Intel Corporation. All rights reserved.
This program and the accompanying materials
are licensed and made available under the terms and conditions of the BSD
License
which accompanies this distribution. The full text of the license may be
found at
http://opensource.org/licenses/bsd-license.php
@@ -85,9 +85,23 @@ typedef struct {
UINT8 ContentType;
EFI_TLS_VERSION Version;
UINT16 Length;
} TLS_RECORD_HEADER;
+#define TLS_RECORD_HEADER_LENGTH 5
+
+//
+// The length (in bytes) of the TLSPlaintext records payload MUST NOT exceed
2^14.
+// Refers to section 6.2 of RFC5246.
+//
+#define TLS_PLAINTEXT_RECORD_MAX_PAYLOAD_LENGTH 16384
+
+//
+// The length (in bytes) of the TLSCiphertext records payload MUST NOT exceed
2^14 + 2048.
+// Refers to section 6.2 of RFC5246.
+//
+#define TLS_CIPHERTEXT_RECORD_MAX_PAYLOAD_LENGTH 18432
+
#pragma pack()
#endif
--
2.16.2.windows.1
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [Patch 3/3] NetworkPkg/HttpDxe: Handle the large data request via HTTPS channel.
Reviewed-by: Karunakar p <karunak...@amiindia.co.in>
-Original Message-
From: Jiaxin Wu [mailto:jiaxin...@intel.com]
Sent: Tuesday, March 20, 2018 6:07 AM
To: edk2-devel@lists.01.org
Cc: Karunakar P; Fu Siyuan; Ye Ting
Subject: [Patch 3/3] NetworkPkg/HttpDxe: Handle the large data request via
HTTPS channel.
Cc: Karunakar P <karunak...@amiindia.co.in>
Cc: Fu Siyuan <siyuan...@intel.com>
Cc: Ye Ting <ting...@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiaxin Wu <jiaxin...@intel.com>
---
NetworkPkg/HttpDxe/HttpProto.c| 121 +++---
NetworkPkg/HttpDxe/HttpsSupport.c | 17 +-
NetworkPkg/HttpDxe/HttpsSupport.h | 12 +++-
3 files changed, 111 insertions(+), 39 deletions(-)
diff --git a/NetworkPkg/HttpDxe/HttpProto.c b/NetworkPkg/HttpDxe/HttpProto.c
index d7fe271168..35c4a166c4 100644
--- a/NetworkPkg/HttpDxe/HttpProto.c
+++ b/NetworkPkg/HttpDxe/HttpProto.c
@@ -1,9 +1,9 @@
/** @file
Miscellaneous routines for HttpDxe driver.
-Copyright (c) 2015 - 2017, Intel Corporation. All rights reserved.
+Copyright (c) 2015 - 2018, Intel Corporation. All rights reserved.
(C) Copyright 2016 Hewlett Packard Enterprise Development LP This program
and the accompanying materials are licensed and made available under the terms
and conditions of the BSD License which accompanies this distribution. The
full text of the license may be found at
http://opensource.org/licenses/bsd-license.php
@@ -1474,64 +1474,101 @@ HttpTransmitTcp (
EFI_STATUSStatus;
EFI_TCP4_IO_TOKEN *Tx4Token;
EFI_TCP4_PROTOCOL *Tcp4;
EFI_TCP6_IO_TOKEN *Tx6Token;
EFI_TCP6_PROTOCOL *Tcp6;
- UINT8 *Buffer;
- UINTN BufferSize;
+ UINT8 *TlsRecord;
+ UINT16PayloadSize;
NET_FRAGMENT TempFragment;
+ NET_FRAGMENT Fragment;
+ UINTN RecordCount;
+ UINTN RemainingLen;
Status= EFI_SUCCESS;
- Buffer= NULL;
+ TlsRecord = NULL;
+ PayloadSize = 0;
TempFragment.Len = 0;
TempFragment.Bulk = NULL;
+ Fragment.Len = 0;
+ Fragment.Bulk = NULL;
+ RecordCount = 0;
+ RemainingLen = 0;
//
// Need to encrypt data.
//
if (HttpInstance->UseHttps) {
//
-// Build BufferOut data
+// Allocate enough buffer for each TLS plaintext records.
//
-BufferSize = sizeof (TLS_RECORD_HEADER) + TxStringLen;
-Buffer = AllocateZeroPool (BufferSize);
-if (Buffer == NULL) {
+TlsRecord = AllocateZeroPool (TLS_RECORD_HEADER_LENGTH +
TLS_PLAINTEXT_RECORD_MAX_PAYLOAD_LENGTH);
+if (TlsRecord == NULL) {
Status = EFI_OUT_OF_RESOURCES;
return Status;
}
-((TLS_RECORD_HEADER *) Buffer)->ContentType =
TlsContentTypeApplicationData;
-((TLS_RECORD_HEADER *) Buffer)->Version.Major =
HttpInstance->TlsConfigData.Version.Major;
-((TLS_RECORD_HEADER *) Buffer)->Version.Minor =
HttpInstance->TlsConfigData.Version.Minor;
-((TLS_RECORD_HEADER *) Buffer)->Length = (UINT16) (TxStringLen);
-CopyMem (Buffer + sizeof (TLS_RECORD_HEADER), TxString, TxStringLen);
-
+
//
-// Encrypt Packet.
+// Allocate enough buffer for all TLS ciphertext records.
//
-Status = TlsProcessMessage (
- HttpInstance,
- Buffer,
- BufferSize,
- EfiTlsEncrypt,
-
- );
-
-FreePool (Buffer);
+RecordCount = TxStringLen / TLS_PLAINTEXT_RECORD_MAX_PAYLOAD_LENGTH + 1;
+Fragment.Bulk = AllocateZeroPool (RecordCount * (TLS_RECORD_HEADER_LENGTH
+ TLS_CIPHERTEXT_RECORD_MAX_PAYLOAD_LENGTH));
+if (Fragment.Bulk == NULL) {
+ Status = EFI_OUT_OF_RESOURCES;
+ goto ON_ERROR;
+}
-if (EFI_ERROR (Status)) {
- return Status;
+//
+// Encrypt each TLS plaintext records.
+//
+RemainingLen = TxStringLen;
+while (RemainingLen != 0) {
+ PayloadSize = (UINT16) MIN
+ (TLS_PLAINTEXT_RECORD_MAX_PAYLOAD_LENGTH, RemainingLen);
+
+ ((TLS_RECORD_HEADER *) TlsRecord)->ContentType =
TlsContentTypeApplicationData;
+ ((TLS_RECORD_HEADER *) TlsRecord)->Version.Major =
HttpInstance->TlsConfigData.Version.Major;
+ ((TLS_RECORD_HEADER *) TlsRecord)->Version.Minor =
HttpInstance->TlsConfigData.Version.Minor;
+ ((TLS_RECORD_HEADER *) TlsRecord)->Length = PayloadSize;
+
+ CopyMem (TlsRecord + TLS_RECORD_HEADER_LENGTH, TxString +
+ (TxStringLen - RemainingLen), PayloadSize);
+
+ Status = TlsProcessMessage (
+ HttpInstance,
+ TlsRecord,
+ TLS
Re: [edk2] AsciiPrint() in HttpBootDxe Corrupting the Setup screen
Hi Jiaxin,
I've filled a bug in bugzilla and attached the changes, Please find the below
bug details
https://bugzilla.tianocore.org/show_bug.cgi?id=860
Thanks,
Karunakar
From: Wu, Jiaxin [mailto:jiaxin...@intel.com]
Sent: Monday, January 22, 2018 6:23 AM
To: Karunakar P; Ye, Ting; Fu, Siyuan; 'edk2-devel@lists.01.org'
Subject: RE: AsciiPrint() in HttpBootDxe Corrupting the Setup screen
Hi Karunakar,
Please also report the issue on Bugzilla.
Thanks,
Jiaxin
From: Wu, Jiaxin
Sent: Saturday, January 20, 2018 2:37 PM
To: Karunakar P <karunak...@amiindia.co.in<mailto:karunak...@amiindia.co.in>>;
Ye, Ting <ting...@intel.com<mailto:ting...@intel.com>>; Fu, Siyuan
<siyuan...@intel.com<mailto:siyuan...@intel.com>>; 'edk2-devel@lists.01.org'
<edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>>
Subject: RE: AsciiPrint() in HttpBootDxe Corrupting the Setup screen
Hi Karunakar,
You should sent out the attached patches for the review:).
Reviewed-by: Jiaxin Wu <jiaxin...@intel.com<mailto:jiaxin...@intel.com>>
Thanks,
Jiaxin
From: Karunakar P [mailto:karunak...@amiindia.co.in]
Sent: Wednesday, January 17, 2018 6:29 PM
To: Wu, Jiaxin <jiaxin...@intel.com<mailto:jiaxin...@intel.com>>; Ye, Ting
<ting...@intel.com<mailto:ting...@intel.com>>; Fu, Siyuan
<siyuan...@intel.com<mailto:siyuan...@intel.com>>; 'edk2-devel@lists.01.org'
<edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>>
Subject: RE: AsciiPrint() in HttpBootDxe Corrupting the Setup screen
[Patch] NetworkPkg\HttpBootDxe: AsciiPrint() in HttpBootDxe Corrupting the
Setup screen
NetworkPkg\HttpBootDxe\HttpBootSupport.c | 2
NetworkPkg\HttpBootDxe\HttpBootClient.c| 10
2 files changed, 10 insertions(+), 2 deletions(-)
NetworkPkg\HttpBootDxe\HttpBootSupport.c
NetworkPkg\HttpBootDxe\HttpBootClient.c
EFI_STATUS
HttpBootCheckUriScheme (
IN CHAR8 *Uri
)
{
UINTNIndex;
EFI_STATUS Status;.
.
.
//
// Return EFI_INVALID_PARAMETER if the URI is not HTTP or HTTPS.
//
if ((AsciiStrnCmp (Uri, "http://;, 7) != 0) && (AsciiStrnCmp (Uri,
"https://;, 8) != 0)) {
-AsciiPrint ("\n Error: Invalid URI address.\n");
DEBUG ((EFI_D_ERROR, "HttpBootCheckUriScheme: Invalid Uri.\n"));
return EFI_INVALID_PARAMETER;
}
//
// HTTP is disabled, return EFI_ACCESS_DENIED if the URI is HTTP.
//
if (!PcdGetBool (PcdAllowHttpConnections) && (AsciiStrnCmp (Uri, "http://;,
7) == 0)) {
-AsciiPrint ("\n Error: Access forbidden, only HTTPS connection is
allowed.\n");
DEBUG ((EFI_D_ERROR, "HttpBootCheckUriScheme: HTTP is disabled.\n"));
return EFI_ACCESS_DENIED;
}
.
.
.
}
EFI_STATUS
HttpBootDhcp4ExtractUriInfo (
IN HTTP_BOOT_PRIVATE_DATA *Private
)
{
HTTP_BOOT_DHCP4_PACKET_CACHE*SelectOffer;
HTTP_BOOT_DHCP4_PACKET_CACHE*HttpOffer;
UINT32 SelectIndex;.
.
.
.
//
// Check the URI scheme.
//
Status = HttpBootCheckUriScheme (Private->BootFileUri);
if (EFI_ERROR (Status)) {
DEBUG ((EFI_D_ERROR, "HttpBootDhcp4ExtractUriInfo: %r.\n", Status));
+if (Status == EFI_INVALID_PARAMETER) {
+AsciiPrint ("\n Error: Invalid URI address.\n");
+ } else if (Status == EFI_ACCESS_DENIED) {
+AsciiPrint ("\n Error: Access forbidden, only HTTPS connection is
allowed.\n");
+ }
return Status;
}
.
.
.
}
EFI_STATUS
HttpBootDhcp6ExtractUriInfo (
IN HTTP_BOOT_PRIVATE_DATA *Private
)
{
HTTP_BOOT_DHCP6_PACKET_CACHE*SelectOffer;
HTTP_BOOT_DHCP6_PACKET_CACHE*HttpOffer;
UINT32 SelectIndex;
.
.
.
Status = HttpBootCheckUriScheme (Private->BootFileUri);
if (EFI_ERROR (Status)) {
DEBUG ((EFI_D_ERROR, "HttpBootDhcp6ExtractUriInfo: %r.\n", Status));
+if (Status == EFI_INVALID_PARAMETER) {
+AsciiPrint ("\n Error: Invalid URI address.\n");
+ } else if (Status == EFI_ACCESS_DENIED) {
+ AsciiPrint ("\n Error: Access forbidden, only HTTPS connection is
allowed.\n");
+ }
return Status;
}
.
.
.
}
Please review the patch.
Thanks,
Karunakar
From: Karunakar P
Sent: Wednesday, January 17, 2018 2:44 PM
To: 'Wu, Jiaxin'; Ye, Ting; Fu, Siyuan; 'edk2-devel@lists.01.org'
Subject: RE: AsciiPrint() in HttpBootDxe Corrupting the Setup screen
Hi Jiaxin,
We'll send the formal patch for review and also could you please let me know if
you want to fill a bug in Bugzilla if needed.
Thank You,
Karunakar
From: Wu, Jiaxin [mailto:jiaxin...@intel.com]
Sent: Thursday, January 11, 2018 6:21 AM
To: Karunakar P; Ye, Ting; Fu, Siyuan
Subject: RE: AsciiPrint() in HttpBootDxe Corrupting the Setup screen
Hi Karunakar,
I agree the fix, can you send out the formal patch for the review or need us to
follow that?
Re: [edk2] AsciiPrint() in HttpBootDxe Corrupting the Setup screen
[Patch] NetworkPkg\HttpBootDxe: AsciiPrint() in HttpBootDxe Corrupting the
Setup screen
NetworkPkg\HttpBootDxe\HttpBootSupport.c | 2
NetworkPkg\HttpBootDxe\HttpBootClient.c| 10
2 files changed, 10 insertions(+), 2 deletions(-)
NetworkPkg\HttpBootDxe\HttpBootSupport.c
NetworkPkg\HttpBootDxe\HttpBootClient.c
EFI_STATUS
HttpBootCheckUriScheme (
IN CHAR8 *Uri
)
{
UINTNIndex;
EFI_STATUS Status;.
.
.
//
// Return EFI_INVALID_PARAMETER if the URI is not HTTP or HTTPS.
//
if ((AsciiStrnCmp (Uri, "http://;, 7) != 0) && (AsciiStrnCmp (Uri,
"https://;, 8) != 0)) {
-AsciiPrint ("\n Error: Invalid URI address.\n");
DEBUG ((EFI_D_ERROR, "HttpBootCheckUriScheme: Invalid Uri.\n"));
return EFI_INVALID_PARAMETER;
}
//
// HTTP is disabled, return EFI_ACCESS_DENIED if the URI is HTTP.
//
if (!PcdGetBool (PcdAllowHttpConnections) && (AsciiStrnCmp (Uri, "http://;,
7) == 0)) {
-AsciiPrint ("\n Error: Access forbidden, only HTTPS connection is
allowed.\n");
DEBUG ((EFI_D_ERROR, "HttpBootCheckUriScheme: HTTP is disabled.\n"));
return EFI_ACCESS_DENIED;
}
.
.
.
}
EFI_STATUS
HttpBootDhcp4ExtractUriInfo (
IN HTTP_BOOT_PRIVATE_DATA *Private
)
{
HTTP_BOOT_DHCP4_PACKET_CACHE*SelectOffer;
HTTP_BOOT_DHCP4_PACKET_CACHE*HttpOffer;
UINT32 SelectIndex;.
.
.
.
//
// Check the URI scheme.
//
Status = HttpBootCheckUriScheme (Private->BootFileUri);
if (EFI_ERROR (Status)) {
DEBUG ((EFI_D_ERROR, "HttpBootDhcp4ExtractUriInfo: %r.\n", Status));
+if (Status == EFI_INVALID_PARAMETER) {
+AsciiPrint ("\n Error: Invalid URI address.\n");
+ } else if (Status == EFI_ACCESS_DENIED) {
+AsciiPrint ("\n Error: Access forbidden, only HTTPS connection is
allowed.\n");
+ }
return Status;
}
.
.
.
}
EFI_STATUS
HttpBootDhcp6ExtractUriInfo (
IN HTTP_BOOT_PRIVATE_DATA *Private
)
{
HTTP_BOOT_DHCP6_PACKET_CACHE*SelectOffer;
HTTP_BOOT_DHCP6_PACKET_CACHE*HttpOffer;
UINT32 SelectIndex;
.
.
.
Status = HttpBootCheckUriScheme (Private->BootFileUri);
if (EFI_ERROR (Status)) {
DEBUG ((EFI_D_ERROR, "HttpBootDhcp6ExtractUriInfo: %r.\n", Status));
+if (Status == EFI_INVALID_PARAMETER) {
+AsciiPrint ("\n Error: Invalid URI address.\n");
+} else if (Status == EFI_ACCESS_DENIED) {
+ AsciiPrint ("\n Error: Access forbidden, only HTTPS connection is
allowed.\n");
+ }
return Status;
}
.
.
.
}
Please review the patch.
Thanks,
Karunakar
From: Karunakar P
Sent: Wednesday, January 17, 2018 2:44 PM
To: 'Wu, Jiaxin'; Ye, Ting; Fu, Siyuan; 'edk2-devel@lists.01.org'
Subject: RE: AsciiPrint() in HttpBootDxe Corrupting the Setup screen
Hi Jiaxin,
We'll send the formal patch for review and also could you please let me know if
you want to fill a bug in Bugzilla if needed.
Thank You,
Karunakar
From: Wu, Jiaxin [mailto:jiaxin...@intel.com]
Sent: Thursday, January 11, 2018 6:21 AM
To: Karunakar P; Ye, Ting; Fu, Siyuan
Subject: RE: AsciiPrint() in HttpBootDxe Corrupting the Setup screen
Hi Karunakar,
I agree the fix, can you send out the formal patch for the review or need us to
follow that?
Thanks,
Jiaxin
From: Karunakar P [mailto:karunak...@amiindia.co.in]
Sent: Wednesday, January 10, 2018 4:48 PM
To: Wu, Jiaxin <jiaxin...@intel.com<mailto:jiaxin...@intel.com>>; Ye, Ting
<ting...@intel.com<mailto:ting...@intel.com>>; Fu, Siyuan
<siyuan...@intel.com<mailto:siyuan...@intel.com>>
Subject: AsciiPrint() in HttpBootDxe Corrupting the Setup screen
Hello All,
[Issue]
1. On giving Invalid URI in Boot URI field in "HTTP Boot Configuration"
Page, doing AsciiPrint() in TSE corrupting the Screen.
AsciiPrint ("\n Error: Invalid URI address.\n");
2. When HTTP connection are disabled using "PcdAllowHttpConnections"
On giving http URI in Boot URI field in "HTTP Boot Configuration" Page, doing
AsciiPrint() in TSE corrupting the Screen.
AsciiPrint ("\n Error: Access forbidden, only HTTPS connection is allowed.\n");
[Fix]
1. I guess We've added this AsciiPrint() because HttpBootCheckUriScheme()
is common for both generic HTTP boot over IPv4/6 and "Http Boot Configuration"
page
2. In case of "Http Boot Configuration", AsciiPrint() may not be needed
in HttpBootCheckUriScheme because we're already using CreatePopUp() in case of
Error Status
CreatePopUp (
EFI_LIGHTGRAY | EFI_BACKGROUND_BLUE,
,
L"ERROR: Unsupported URI!",
L"Only supports HTTP and HTTPS",
NULL
);
(Or)
CreatePopUp (
EFI_LIGHTGRAY | EFI_BACK
[edk2] Syntax error in EFI iSCSI Initiator Name Protocol in UEFI2.7 Spec
Hello All,
There is a typing mistake in EFI_ISCSI_INITIATOR_NAME_PROTOCOL Get() and Set()
Prototypes
UEFI2.7 16.2 Page 921,922
EFI_ISCSI_INITIATOR_NAME_PROTOCOL. Get()
Summary
Retrieves the current set value of iSCSI Initiator Name.
Prototype
typedef EFI_STATUS
(EFIAPI *EFI_ISCSI_INITIATOR_NAME_GET) {
IN EFI_ISCSI_INITIATOR_NAME_PROTOCOL *This
IN OUT UINTN *BufferSize
OUT VOID *Buffer
}
EFI_ISCSI_INITIATOR_NAME_PROTOCOL.Set()
Summary
Sets the iSCSI Initiator Name.
Prototype
typedef EFI_STATUS
(EFIAPI *EFI_ISCSI_INITIATOR_NAME_SET) {
IN EFI_ISCSI_INITIATOR_NAME_PROTOCOL *This
IN OUT UINTN *BufferSize
IN VOID *Buffer
}
The Prototypes should be like below
typedef EFI_STATUS
(EFIAPI *EFI_ISCSI_INITIATOR_NAME_GET) (
IN EFI_ISCSI_INITIATOR_NAME_PROTOCOL *This
IN OUT UINTN *BufferSize
OUT VOID *Buffer
);
typedef EFI_STATUS
(EFIAPI *EFI_ISCSI_INITIATOR_NAME_SET) (
IN EFI_ISCSI_INITIATOR_NAME_PROTOCOL *This
IN OUT UINTN *BufferSize
IN VOID *Buffer
);
Thanks,
Karunakar
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] DHCP Process Starts Even there is NO Media Connected
Please review the patch
[Patch] MdeModulePkg/Universal/Network/Dhcp4Dxe: Implantation of handling
EFI_NO_MEDIA status code for DHCP4/6.Start()
NetworkPkg/Dhcp6Dxe : Implantation of handling EFI_NO_MEDIA status code for
DHCP4/6.Start()
MdeModulePkg/Universal/Network/Dhcp4Dxe/ Dhcp4Impl.c | 11
NetworkPkg/Dhcp6Dxe/ Dhcp6Impl.c | 11
2 files changed, 22 insertions(+)
a. MdeModulePkg/Universal/Network/Dhcp4Dxe/ Dhcp4Impl.c
b. NetworkPkg/Dhcp6Dxe/ Dhcp6Impl.c
a@ EfiDhcp4Start (
IN EFI_DHCP4_PROTOCOL *This,
IN EFI_EVENT CompletionEvent OPTIONAL
)
{
DHCP_PROTOCOL *Instance;
DHCP_SERVICE *DhcpSb;
EFI_STATUSStatus;
EFI_TPL OldTpl;
+ BOOLEAN MediaPresent;
.
.
.
OldTpl = gBS->RaiseTPL (TPL_CALLBACK);
DhcpSb = Instance->Service;
+ //
+ // Check media status before DHCP Start.
+ //
+ MediaPresent = TRUE;
+ NetLibDetectMedia (DhcpSb->Controller, );
+ if (!MediaPresent) {
+Status = EFI_NO_MEDIA;
+ DEBUG((DEBUG_ERROR,"\nIn EfiDhcp4Start MediaPresent Status =
%r\n",Status));
+goto ON_ERROR;
+ }
if (DhcpSb->DhcpState == Dhcp4Stopped) {
Status = EFI_NOT_STARTED;
goto ON_ERROR;
}
.
.
.
}
b @ EfiDhcp6Start (
IN EFI_DHCP6_PROTOCOL*This
)
{
EFI_STATUS Status;
EFI_TPL OldTpl;
DHCP6_INSTANCE *Instance;
DHCP6_SERVICE*Service;
+ BOOLEAN MediaPresent;
.
.
.
OldTpl = gBS->RaiseTPL (TPL_CALLBACK);
Instance->UdpSts = EFI_ALREADY_STARTED;
+ //
+ // Check media status before DHCP Start.
+ //
+ MediaPresent = TRUE;
+ NetLibDetectMedia (Service->Controller, );
+ if (!MediaPresent) {
+Status = EFI_NO_MEDIA;
+DEBUG((DEBUG_ERROR,"\nIn EfiDhcp6Start MediaPresent Status =
%r\n",Status));
+goto ON_ERROR;
+ }
//
// Send the solicit message to start S.A.R.R process.
//
Status = Dhcp6SendSolicitMsg (Instance);
.
.
.
}
Thanks,
Karunakar
-----Original Message-
From: Karunakar P
Sent: Friday, December 01, 2017 11:10 AM
To: 'Wu, Jiaxin'; Richardson, Brian; Fu, Siyuan; Ye, Ting;
'edk2-devel@lists.01.org'
Subject: RE: DHCP Process Starts Even there is NO Media Connected
Hi Jiaxin,
I've updated the patch changes for Dhcp6Dxe driver also and attached the same
for review.
Filed a tracker in TianoCore Bugzilla for this issue and attached the changes
for review,
https://bugzilla.tianocore.org/show_bug.cgi?id=804
Thanks,
Karunakar
-Original Message-
From: Wu, Jiaxin [mailto:jiaxin...@intel.com]
Sent: Friday, December 01, 2017 9:15 AM
To: Richardson, Brian; Karunakar P; Fu, Siyuan; Ye, Ting;
'edk2-devel@lists.01.org'
Subject: RE: DHCP Process Starts Even there is NO Media Connected
Hi Karunakar,
Per your question #3.c, I think it's *unreasonable* to check Media Status for
EFI_IP4_CONFIG2_SET_DATA.
Even there is no media connected, we still need to set the data instead of
return directly. If the EFI_IP4_CONFIG2_SET_DATA.SetData() is to set the DHCP
policy, the SetData() interface will try to do the DHCP process to get one
valid default address, but if there is any failure happen in DHCP process (e.g.
no media connected), we should continue change the policy to DHCP and return
EFI_SUCCESS, which align with static policy. So, I don't prefer to check the
Media Status in EFI_IP4_CONFIG2_SET_DATA.SetData().
I have reviewed your patch, the Dhcp4Dxe update is good to me. Can you send out
the formal patch to the EDK2 community for the review or need us do to that?
Note: don't forget to update the Dhcp6Dxe driver.
Also thanks Brain's reminder, please file a tracker in TianoCore Bugzilla for
this issue.
Thanks,
Jiaxin
> -Original Message-
> From: Richardson, Brian
> Sent: Thursday, November 30, 2017 11:02 PM
> To: Karunakar P <karunak...@amiindia.co.in>; Wu, Jiaxin
> <jiaxin...@intel.com>; Fu, Siyuan <siyuan...@intel.com>; Ye, Ting
> <ting...@intel.com>; 'edk2-devel@lists.01.org'
> <edk2-devel@lists.01.org>
> Subject: RE: DHCP Process Starts Even there is NO Media Connected
>
> We saw some problems running Linux UEFI Validation (LUV) at the last
> UEFI Plugfest that are probably related to this issue. At the time we
> asked the LUV team to investigate it as a test issue, but it may
> actually be a stack problem based on this information.
>
> Have you filed a tracker in TianoCore Bugzilla for this issue?
>
> Thanks ... br
> ---
> Brian Richardson, Senior Technical Marketing Engineer, Intel Software
> brian.richard...@intel.com -- @intel_brian (Twitter & WeChat)
> https://software.intel.com/en-us/meet-the-developers/evangelists/team/
> brian-
> richardson
>
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On B
Re: [edk2] DHCP Process Starts Even there is NO Media Connected
Hi Jiaxin, I've updated the patch changes for Dhcp6Dxe driver also and attached the same for review. Filed a tracker in TianoCore Bugzilla for this issue and attached the changes for review, https://bugzilla.tianocore.org/show_bug.cgi?id=804 Thanks, Karunakar -Original Message- From: Wu, Jiaxin [mailto:jiaxin...@intel.com] Sent: Friday, December 01, 2017 9:15 AM To: Richardson, Brian; Karunakar P; Fu, Siyuan; Ye, Ting; 'edk2-devel@lists.01.org' Subject: RE: DHCP Process Starts Even there is NO Media Connected Hi Karunakar, Per your question #3.c, I think it's *unreasonable* to check Media Status for EFI_IP4_CONFIG2_SET_DATA. Even there is no media connected, we still need to set the data instead of return directly. If the EFI_IP4_CONFIG2_SET_DATA.SetData() is to set the DHCP policy, the SetData() interface will try to do the DHCP process to get one valid default address, but if there is any failure happen in DHCP process (e.g. no media connected), we should continue change the policy to DHCP and return EFI_SUCCESS, which align with static policy. So, I don't prefer to check the Media Status in EFI_IP4_CONFIG2_SET_DATA.SetData(). I have reviewed your patch, the Dhcp4Dxe update is good to me. Can you send out the formal patch to the EDK2 community for the review or need us do to that? Note: don't forget to update the Dhcp6Dxe driver. Also thanks Brain's reminder, please file a tracker in TianoCore Bugzilla for this issue. Thanks, Jiaxin > -Original Message- > From: Richardson, Brian > Sent: Thursday, November 30, 2017 11:02 PM > To: Karunakar P <karunak...@amiindia.co.in>; Wu, Jiaxin > <jiaxin...@intel.com>; Fu, Siyuan <siyuan...@intel.com>; Ye, Ting > <ting...@intel.com>; 'edk2-devel@lists.01.org' > <edk2-devel@lists.01.org> > Subject: RE: DHCP Process Starts Even there is NO Media Connected > > We saw some problems running Linux UEFI Validation (LUV) at the last > UEFI Plugfest that are probably related to this issue. At the time we > asked the LUV team to investigate it as a test issue, but it may > actually be a stack problem based on this information. > > Have you filed a tracker in TianoCore Bugzilla for this issue? > > Thanks ... br > --- > Brian Richardson, Senior Technical Marketing Engineer, Intel Software > brian.richard...@intel.com -- @intel_brian (Twitter & WeChat) > https://software.intel.com/en-us/meet-the-developers/evangelists/team/ > brian- > richardson > > -----Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Karunakar P > Sent: Thursday, November 30, 2017 3:59 AM > To: Wu, Jiaxin <jiaxin...@intel.com>; Fu, Siyuan > <siyuan...@intel.com>; Ye, Ting <ting...@intel.com>; > 'edk2-devel@lists.01.org' <edk2-devel@lists.01.org> > Subject: Re: [edk2] DHCP Process Starts Even there is NO Media > Connected > > Hi Jiaxin, > > Please find my below comments/suggestions. > > > 1. Yes, Current DHCP4/6 Start() implementation doesn't check for Media > Status. It will be better to implement it in order to sync with UEFI spec. > > 2. DHCP process may be initiated by HTTP/PXE/ISCSI or Assigning IP > (SetData) from Shell or using BIOS setup page. > > HTTP,PXE and ISCSI is already Checking Media Presence before DHCP > Start, So it will have NO effect if we do implementation in DHCP4/6 Start(). > > 3. Current implementation of EFI_IP4_CONFIG2_SET_DATA, also NOT > handling checking Media Status. > > a. UEFI Spec NOT defines EFI_NO_MEDIA status code for > EFI_IP4_CONFIG2_SET_DATA, I'm NOT sure what's reason behind it or > might be missing. > > b. UEFI Spec defines EFI_DEVICE_ERROR status code for > EFI_IP4_CONFIG2_SET_DATA, If we can use the same status for Media > presence then no issues. > > c. When there is No Media connected and if we try to assign IP over > DHCP(SetData), I guess there is no need to proceed further in > EfiIp4Config2SetData and we can return with EFI_DEVICE_ERROR. > > Based on above points(1 & 3.c ), I've updated the suggested changes > and attached the same (CheckMediaStatus_V2.rar) > > Could you please review and provide your comments. > Please correct if anything wrong. > > Thank You, > Karunakar > > From: Wu, Jiaxin [mailto:jiaxin...@intel.com] > Sent: Wednesday, November 29, 2017 11:57 AM > To: Karunakar P; Fu, Siyuan; Ye, Ting > Subject: RE: DHCP Process Starts Even there is NO Media Connected > > Hi Karunakar, > > After talk with Siyuan, we agree it's reasonable to check the Media > status before starting DHCP process, but we'd better check it in DHCP > layer since the UEFI spec defines EFI_NO_MEDIA status code
Re: [edk2] DHCP Process Starts Even there is NO Media Connected
Hi Jiaxin, Please find my below comments/suggestions. 1. Yes, Current DHCP4/6 Start() implementation doesn't check for Media Status. It will be better to implement it in order to sync with UEFI spec. 2. DHCP process may be initiated by HTTP/PXE/ISCSI or Assigning IP (SetData) from Shell or using BIOS setup page. HTTP,PXE and ISCSI is already Checking Media Presence before DHCP Start, So it will have NO effect if we do implementation in DHCP4/6 Start(). 3. Current implementation of EFI_IP4_CONFIG2_SET_DATA, also NOT handling checking Media Status. a. UEFI Spec NOT defines EFI_NO_MEDIA status code for EFI_IP4_CONFIG2_SET_DATA, I'm NOT sure what's reason behind it or might be missing. b. UEFI Spec defines EFI_DEVICE_ERROR status code for EFI_IP4_CONFIG2_SET_DATA, If we can use the same status for Media presence then no issues. c. When there is No Media connected and if we try to assign IP over DHCP(SetData), I guess there is no need to proceed further in EfiIp4Config2SetData and we can return with EFI_DEVICE_ERROR. Based on above points(1 & 3.c ), I've updated the suggested changes and attached the same (CheckMediaStatus_V2.rar) Could you please review and provide your comments. Please correct if anything wrong. Thank You, Karunakar From: Wu, Jiaxin [mailto:jiaxin...@intel.com] Sent: Wednesday, November 29, 2017 11:57 AM To: Karunakar P; Fu, Siyuan; Ye, Ting Subject: RE: DHCP Process Starts Even there is NO Media Connected Hi Karunakar, After talk with Siyuan, we agree it's reasonable to check the Media status before starting DHCP process, but we'd better check it in DHCP layer since the UEFI spec defines EFI_NO_MEDIA status code for DHCP4/6.Start(), but our current implementation doesn't check it. What do you think? Thanks, Jiaxin From: Karunakar P [mailto:karunak...@amiindia.co.in] Sent: Tuesday, November 28, 2017 11:18 PM To: Wu, Jiaxin <jiaxin...@intel.com<mailto:jiaxin...@intel.com>>; Fu, Siyuan <siyuan...@intel.com<mailto:siyuan...@intel.com>>; Ye, Ting <ting...@intel.com<mailto:ting...@intel.com>> Subject: RE: DHCP Process Starts Even there is NO Media Connected Could you please review the attachment changes for this support. Thanks, Karunakar From: Karunakar P Sent: Monday, November 27, 2017 12:53 PM To: 'Wu, Jiaxin'; 'Fu, Siyuan'; 'Ye, Ting' Subject: RE: DHCP Process Starts Even there is NO Media Connected Could you please provide your comments... Thank You, Karunakar From: Karunakar P Sent: Thursday, November 23, 2017 2:05 PM To: 'Wu, Jiaxin'; Fu, Siyuan; Ye, Ting Subject: DHCP Process Starts Even there is NO Media Connected Hello All, When we try to Assign IP to SUT using ifconfig command from Shell or IPv4 Network Configuration BIOS setup page DHCP process start even there is no LAN cable connected to specific port. Can we add a Media presence condition check before starting DHCP service? Could you please correct if anything is wrong. Thanks, Karunakar ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] SCT Test crashes After HTTPS boot success.
Hi Jiaxin, It happens in DEBUG MODE Thanks, Karunakar From: Wu, Jiaxin [mailto:jiaxin...@intel.com] Sent: Friday, November 17, 2017 12:05 PM To: Karunakar P; 'edk2-devel@lists.01.org' Cc: Fu, Siyuan; Ye, Ting Subject: RE: SCT Test crashes After HTTPS boot success. I will try to reproduce the issue with EDK2 trunk code, then feedback to you. Thanks the report. Jiaxin From: Karunakar P [mailto:karunak...@amiindia.co.in] Sent: Friday, November 17, 2017 2:32 PM To: Wu, Jiaxin <jiaxin...@intel.com<mailto:jiaxin...@intel.com>>; 'edk2-devel@lists.01.org' <edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>> Cc: Fu, Siyuan <siyuan...@intel.com<mailto:siyuan...@intel.com>>; Ye, Ting <ting...@intel.com<mailto:ting...@intel.com>> Subject: RE: SCT Test crashes After HTTPS boot success. Hi Jiaxin, Below are the detailed steps for SCT test [Steps to reproduce] . 5. Run SCT test a. Execute the following commands to run SCT test on SUT sct -r sct -u b. In Test Case Management page, Enable GenericTest c. Press F9 to run the selected test case [Observation] synchronous exception occurred in SCT ,Attached the Log for reference. Thanks, Karunakar From: Wu, Jiaxin [mailto:jiaxin...@intel.com] Sent: Friday, November 17, 2017 6:01 AM To: Karunakar P; 'edk2-devel@lists.01.org' Cc: Fu, Siyuan; Ye, Ting Subject: RE: SCT Test crashes After HTTPS boot success. Hi Karunakar, Can you provide more detailed info for the SCT test steps? The crash can happen after "Sct.efi -u" or need run any specific test case? Thanks, Jiaxin From: Karunakar P [mailto:karunak...@amiindia.co.in] Sent: Thursday, November 16, 2017 4:48 PM To: 'edk2-devel@lists.01.org' <edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>> Cc: Wu, Jiaxin <jiaxin...@intel.com<mailto:jiaxin...@intel.com>>; Fu, Siyuan <siyuan...@intel.com<mailto:siyuan...@intel.com>>; Ye, Ting <ting...@intel.com<mailto:ting...@intel.com>> Subject: SCT Test crashes After HTTPS boot success. Hello All, When I do SCT test, get the below failure GenericTest\EFICompliantTest 0 0 CB6F7B77-0B15-43F7-A95B-8C7F9FD70B21 FAIL UEFI Compliant - TLS support is required The reason for the failure is that the platform doesn't have TLS related protocols installed. ->if the platform supports TLS feature then, EFI_TLS_PROTOCOL, EFI_TLS_SERVICE_BINDING_PROTOCOL, EFI_TLS_CONFIGURATION_PROTOCOL must be existed. -> According UEFI2.7 Spec - 28.10 EFI TLS Protocols(page-1787) The TLS consumer need locate EFI_TLS_SERVICE_BINDING_PROTOCOL and call CreateChild() to create a new child of EFI_TLS_PROTOCOL instance. Then use EFI_TLS_PROTOCOL to start TLS session. After use, the TLS consumer need call DestroyChild() to destroy it. -> Network Stack follows same in HTTPS boot. While doing IPv4/6 HTTPS boot , will locate gEfiTlsServiceBindingProtocolGuid and call TlsServiceBindingCreateChild, So that EFI_TLS_PROTOCOL and EFI_TLS_CONFIGURATION_PROTOCOL will be installed. So once HTTPS boot is success then TLS supported protocols exist. And if we do SCT test after HTTPS boot is success, Then TLS related failures should NOT happen in SCT. I've tried SCT test after HTTPS boot success, But SCT test Crashes. [Steps to reproduce] 1. Configure the HTTPS Server with EFI Shell as NBP file. 2. Connect test machine and HTTPS server with LAN cable. 3. Perform HTTPS boot in test machine 4. Once HTTPS boot is success, It will launch Shell. 5. Run SCT test [Observations] 1. SCT test was crashed and unable to continue the test. Could you please provide your comments/Suggestion on this? Thanks, Karunakar ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] SCT Test crashes After HTTPS boot success.
Hi Jiaxin, Below are the detailed steps for SCT test [Steps to reproduce] . 5. Run SCT test a. Execute the following commands to run SCT test on SUT sct -r sct -u b. In Test Case Management page, Enable GenericTest c. Press F9 to run the selected test case [Observation] synchronous exception occurred in SCT ,Attached the Log for reference. Thanks, Karunakar From: Wu, Jiaxin [mailto:jiaxin...@intel.com] Sent: Friday, November 17, 2017 6:01 AM To: Karunakar P; 'edk2-devel@lists.01.org' Cc: Fu, Siyuan; Ye, Ting Subject: RE: SCT Test crashes After HTTPS boot success. Hi Karunakar, Can you provide more detailed info for the SCT test steps? The crash can happen after "Sct.efi -u" or need run any specific test case? Thanks, Jiaxin From: Karunakar P [mailto:karunak...@amiindia.co.in] Sent: Thursday, November 16, 2017 4:48 PM To: 'edk2-devel@lists.01.org' <edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>> Cc: Wu, Jiaxin <jiaxin...@intel.com<mailto:jiaxin...@intel.com>>; Fu, Siyuan <siyuan...@intel.com<mailto:siyuan...@intel.com>>; Ye, Ting <ting...@intel.com<mailto:ting...@intel.com>> Subject: SCT Test crashes After HTTPS boot success. Hello All, When I do SCT test, get the below failure GenericTest\EFICompliantTest 0 0 CB6F7B77-0B15-43F7-A95B-8C7F9FD70B21 FAIL UEFI Compliant - TLS support is required The reason for the failure is that the platform doesn't have TLS related protocols installed. ->if the platform supports TLS feature then, EFI_TLS_PROTOCOL, EFI_TLS_SERVICE_BINDING_PROTOCOL, EFI_TLS_CONFIGURATION_PROTOCOL must be existed. -> According UEFI2.7 Spec - 28.10 EFI TLS Protocols(page-1787) The TLS consumer need locate EFI_TLS_SERVICE_BINDING_PROTOCOL and call CreateChild() to create a new child of EFI_TLS_PROTOCOL instance. Then use EFI_TLS_PROTOCOL to start TLS session. After use, the TLS consumer need call DestroyChild() to destroy it. -> Network Stack follows same in HTTPS boot. While doing IPv4/6 HTTPS boot , will locate gEfiTlsServiceBindingProtocolGuid and call TlsServiceBindingCreateChild, So that EFI_TLS_PROTOCOL and EFI_TLS_CONFIGURATION_PROTOCOL will be installed. So once HTTPS boot is success then TLS supported protocols exist. And if we do SCT test after HTTPS boot is success, Then TLS related failures should NOT happen in SCT. I've tried SCT test after HTTPS boot success, But SCT test Crashes. [Steps to reproduce] 1. Configure the HTTPS Server with EFI Shell as NBP file. 2. Connect test machine and HTTPS server with LAN cable. 3. Perform HTTPS boot in test machine 4. Once HTTPS boot is success, It will launch Shell. 5. Run SCT test [Observations] 1. SCT test was crashed and unable to continue the test. Could you please provide your comments/Suggestion on this? Thanks, Karunakar *RECOVERY* System hangs or stops abnormally. -- FAILURE DE687A18-0BBD-4396-8509-498FF23234F1 /home/supven01/upstream_edk2/edk2/SctPkg/TestInfrastructure/SCT/Framework/Execute/Execute.c:2104 Returned Status Code: Unsupported PlatformSpecificElements: [FAILED] Passes... 18 Warnings. 0 Errors... 8 UEFI 2.6 Revision 0x00010001 Test Entry Point GUID: A0A8BED3-3D6F-4AD8-907A-84D52EE1543B Logfile: "\UEFISCT_2.6\UEFISCT\SctPackageAARCH64\AARCH64\Log\GenericTest\EFICompliantTest0\PlatformSpecificElements_0_0_A0A8BED3-3D6F-4AD8-907A-84D52EE1543B.log" Test Finished: 09/28/80 12:41p Elapsed Time: 00 Days 00:00:02 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] SCT Test crashes After HTTPS boot success.
Hello All, When I do SCT test, get the below failure GenericTest\EFICompliantTest 0 0 CB6F7B77-0B15-43F7-A95B-8C7F9FD70B21 FAIL UEFI Compliant - TLS support is required The reason for the failure is that the platform doesn't have TLS related protocols installed. ->if the platform supports TLS feature then, EFI_TLS_PROTOCOL, EFI_TLS_SERVICE_BINDING_PROTOCOL, EFI_TLS_CONFIGURATION_PROTOCOL must be existed. -> According UEFI2.7 Spec - 28.10 EFI TLS Protocols(page-1787) The TLS consumer need locate EFI_TLS_SERVICE_BINDING_PROTOCOL and call CreateChild() to create a new child of EFI_TLS_PROTOCOL instance. Then use EFI_TLS_PROTOCOL to start TLS session. After use, the TLS consumer need call DestroyChild() to destroy it. -> Network Stack follows same in HTTPS boot. While doing IPv4/6 HTTPS boot , will locate gEfiTlsServiceBindingProtocolGuid and call TlsServiceBindingCreateChild, So that EFI_TLS_PROTOCOL and EFI_TLS_CONFIGURATION_PROTOCOL will be installed. So once HTTPS boot is success then TLS supported protocols exist. And if we do SCT test after HTTPS boot is success, Then TLS related failures should NOT happen in SCT. I've tried SCT test after HTTPS boot success, But SCT test Crashes. [Steps to reproduce] 1. Configure the HTTPS Server with EFI Shell as NBP file. 2. Connect test machine and HTTPS server with LAN cable. 3. Perform HTTPS boot in test machine 4. Once HTTPS boot is success, It will launch Shell. 5. Run SCT test [Observations] 1. SCT test was crashed and unable to continue the test. Could you please provide your comments/Suggestion on this? Thanks, Karunakar ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] Build error in StdLib with VS 2015 compiler
It works Fine. Are you going to check in this changes, could you please let us know the plan? -Original Message- From: Gao, Liming [mailto:liming@intel.com] Sent: Monday, November 06, 2017 6:59 PM To: Karunakar P; 'Tim Lewis'; 'edk2-devel@lists.01.org' Cc: Ye, Ting; Fu, Siyuan; Wu, Jiaxin Subject: RE: [edk2] Build error in StdLib with VS 2015 compiler For VS2015, don't define it. The change is like below. #ifndef __STDC_HOSTED__ #if !defined(_MSC_VER) || _MSC_VER != 1900 #define __STDC_HOSTED__ 1 #endif #endif > -Original Message- > From: Karunakar P [mailto:karunak...@amiindia.co.in] > Sent: Monday, November 6, 2017 5:32 PM > To: Gao, Liming <liming@intel.com>; 'Tim Lewis' > <tim.le...@insyde.com>; 'edk2-devel@lists.01.org' > <edk2-devel@lists.01.org> > Cc: Ye, Ting <ting...@intel.com>; Fu, Siyuan <siyuan...@intel.com>; > Wu, Jiaxin <jiaxin...@intel.com> > Subject: RE: [edk2] Build error in StdLib with VS 2015 compiler > > What do you say... > > > Thanks, > Karunakar > > -Original Message- > From: Karunakar P > Sent: Thursday, November 02, 2017 8:17 PM > To: 'Gao, Liming'; 'Tim Lewis'; edk2-devel@lists.01.org > Cc: Ye, Ting; Fu, Siyuan; Wu, Jiaxin > Subject: RE: [edk2] Build error in StdLib with VS 2015 compiler > > Then it works fine. > But the problem is it may miss the backward compatibility with other > compilers. > > I guess better to define as mentioned previously. > > Thank You, > Karunakar > > -----Original Message- > From: Gao, Liming [mailto:liming@intel.com] > Sent: Thursday, November 02, 2017 7:33 PM > To: Karunakar P; 'Tim Lewis'; edk2-devel@lists.01.org > Cc: Ye, Ting; Fu, Siyuan; Wu, Jiaxin > Subject: RE: [edk2] Build error in StdLib with VS 2015 compiler > > Could you remove them, and build again? > > > -Original Message- > > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf > > Of Karunakar P > > Sent: Thursday, November 2, 2017 8:32 PM > > To: 'Tim Lewis' <tim.le...@insyde.com>; edk2-devel@lists.01.org > > Cc: Ye, Ting <ting...@intel.com>; Fu, Siyuan <siyuan...@intel.com>; > > Wu, Jiaxin <jiaxin...@intel.com> > > Subject: Re: [edk2] Build error in StdLib with VS 2015 compiler > > > > It is C only. > > > > -Karunakar > > > > -Original Message- > > From: Tim Lewis [mailto:tim.le...@insyde.com] > > Sent: Thursday, November 02, 2017 8:59 AM > > To: Karunakar P; edk2-devel@lists.01.org > > Cc: 'Ye, Ting'; 'Fu, Siyuan'; 'Wu, Jiaxin' > > Subject: RE: [edk2] Build error in StdLib with VS 2015 compiler > > > > Are you building C++ (.cpp)? Tim > > > > -Original Message- > > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf > > Of Karunakar P > > Sent: Wednesday, November 1, 2017 8:27 PM > > To: 'edk2-devel@lists.01.org' <edk2-devel@lists.01.org> > > Cc: 'Ye, Ting' <ting...@intel.com>; 'Fu, Siyuan' > > <siyuan...@intel.com>; 'Wu, Jiaxin' <jiaxin...@intel.com> > > Subject: Re: [edk2] Build error in StdLib with VS 2015 compiler > > > > Any comment on this? > > > > From: Karunakar P > > Sent: Tuesday, October 31, 2017 3:18 PM > > To: 'edk2-devel@lists.01.org' > > Cc: 'Wu, Jiaxin'; 'Fu, Siyuan'; 'Ye, Ting' > > Subject: Build error in StdLib with VS 2015 compiler > > > > Hello All, > > > > Facing an build error with Stdlib module when built with VS 2015 compiler. > > > > e:\test\StdLib\Include\sys/EfiCdefs.h(357): error C2220: warning > > treated as error - no 'object' file generated > > e:\test\StdLib\Include\sys/EfiCdefs.h(357): warning C4117: macro > > name '__STDC_HOSTED__' is reserved, '#define' ignored > > > > below change resolving this error. Would you please review and provide > > comments. > > > > #ifndef __STDC_HOSTED__ > > #define __STDC_HOSTED__ 1 > > #endif > > > > > > Thank You, > > Karunakar > > ___ > > edk2-devel mailing list > > edk2-devel@lists.01.org > > https://lists.01.org/mailman/listinfo/edk2-devel > > > > ___ > > edk2-devel mailing list > > edk2-devel@lists.01.org > > https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] Build error in StdLib with VS 2015 compiler
What do you say... Thanks, Karunakar -Original Message- From: Karunakar P Sent: Thursday, November 02, 2017 8:17 PM To: 'Gao, Liming'; 'Tim Lewis'; edk2-devel@lists.01.org Cc: Ye, Ting; Fu, Siyuan; Wu, Jiaxin Subject: RE: [edk2] Build error in StdLib with VS 2015 compiler Then it works fine. But the problem is it may miss the backward compatibility with other compilers. I guess better to define as mentioned previously. Thank You, Karunakar -Original Message- From: Gao, Liming [mailto:liming@intel.com] Sent: Thursday, November 02, 2017 7:33 PM To: Karunakar P; 'Tim Lewis'; edk2-devel@lists.01.org Cc: Ye, Ting; Fu, Siyuan; Wu, Jiaxin Subject: RE: [edk2] Build error in StdLib with VS 2015 compiler Could you remove them, and build again? > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Karunakar P > Sent: Thursday, November 2, 2017 8:32 PM > To: 'Tim Lewis' <tim.le...@insyde.com>; edk2-devel@lists.01.org > Cc: Ye, Ting <ting...@intel.com>; Fu, Siyuan <siyuan...@intel.com>; Wu, > Jiaxin <jiaxin...@intel.com> > Subject: Re: [edk2] Build error in StdLib with VS 2015 compiler > > It is C only. > > -Karunakar > > -Original Message- > From: Tim Lewis [mailto:tim.le...@insyde.com] > Sent: Thursday, November 02, 2017 8:59 AM > To: Karunakar P; edk2-devel@lists.01.org > Cc: 'Ye, Ting'; 'Fu, Siyuan'; 'Wu, Jiaxin' > Subject: RE: [edk2] Build error in StdLib with VS 2015 compiler > > Are you building C++ (.cpp)? Tim > > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Karunakar P > Sent: Wednesday, November 1, 2017 8:27 PM > To: 'edk2-devel@lists.01.org' <edk2-devel@lists.01.org> > Cc: 'Ye, Ting' <ting...@intel.com>; 'Fu, Siyuan' <siyuan...@intel.com>; 'Wu, > Jiaxin' <jiaxin...@intel.com> > Subject: Re: [edk2] Build error in StdLib with VS 2015 compiler > > Any comment on this? > > From: Karunakar P > Sent: Tuesday, October 31, 2017 3:18 PM > To: 'edk2-devel@lists.01.org' > Cc: 'Wu, Jiaxin'; 'Fu, Siyuan'; 'Ye, Ting' > Subject: Build error in StdLib with VS 2015 compiler > > Hello All, > > Facing an build error with Stdlib module when built with VS 2015 compiler. > > e:\test\StdLib\Include\sys/EfiCdefs.h(357): error C2220: warning treated as > error - no 'object' file generated > e:\test\StdLib\Include\sys/EfiCdefs.h(357): warning C4117: macro name > '__STDC_HOSTED__' is reserved, '#define' ignored > > below change resolving this error. Would you please review and provide > comments. > > #ifndef __STDC_HOSTED__ > #define __STDC_HOSTED__ 1 > #endif > > > Thank You, > Karunakar > ___ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel > > ___ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] Build error in StdLib with VS 2015 compiler
Then it works fine. But the problem is it may miss the backward compatibility with other compilers. I guess better to define as mentioned previously. Thank You, Karunakar -Original Message- From: Gao, Liming [mailto:liming@intel.com] Sent: Thursday, November 02, 2017 7:33 PM To: Karunakar P; 'Tim Lewis'; edk2-devel@lists.01.org Cc: Ye, Ting; Fu, Siyuan; Wu, Jiaxin Subject: RE: [edk2] Build error in StdLib with VS 2015 compiler Could you remove them, and build again? > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Karunakar P > Sent: Thursday, November 2, 2017 8:32 PM > To: 'Tim Lewis' <tim.le...@insyde.com>; edk2-devel@lists.01.org > Cc: Ye, Ting <ting...@intel.com>; Fu, Siyuan <siyuan...@intel.com>; Wu, > Jiaxin <jiaxin...@intel.com> > Subject: Re: [edk2] Build error in StdLib with VS 2015 compiler > > It is C only. > > -Karunakar > > -Original Message- > From: Tim Lewis [mailto:tim.le...@insyde.com] > Sent: Thursday, November 02, 2017 8:59 AM > To: Karunakar P; edk2-devel@lists.01.org > Cc: 'Ye, Ting'; 'Fu, Siyuan'; 'Wu, Jiaxin' > Subject: RE: [edk2] Build error in StdLib with VS 2015 compiler > > Are you building C++ (.cpp)? Tim > > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Karunakar P > Sent: Wednesday, November 1, 2017 8:27 PM > To: 'edk2-devel@lists.01.org' <edk2-devel@lists.01.org> > Cc: 'Ye, Ting' <ting...@intel.com>; 'Fu, Siyuan' <siyuan...@intel.com>; 'Wu, > Jiaxin' <jiaxin...@intel.com> > Subject: Re: [edk2] Build error in StdLib with VS 2015 compiler > > Any comment on this? > > From: Karunakar P > Sent: Tuesday, October 31, 2017 3:18 PM > To: 'edk2-devel@lists.01.org' > Cc: 'Wu, Jiaxin'; 'Fu, Siyuan'; 'Ye, Ting' > Subject: Build error in StdLib with VS 2015 compiler > > Hello All, > > Facing an build error with Stdlib module when built with VS 2015 compiler. > > e:\test\StdLib\Include\sys/EfiCdefs.h(357): error C2220: warning treated as > error - no 'object' file generated > e:\test\StdLib\Include\sys/EfiCdefs.h(357): warning C4117: macro name > '__STDC_HOSTED__' is reserved, '#define' ignored > > below change resolving this error. Would you please review and provide > comments. > > #ifndef __STDC_HOSTED__ > #define __STDC_HOSTED__ 1 > #endif > > > Thank You, > Karunakar > ___ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel > > ___ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] Build error in StdLib with VS 2015 compiler
It is C only. -Karunakar -Original Message- From: Tim Lewis [mailto:tim.le...@insyde.com] Sent: Thursday, November 02, 2017 8:59 AM To: Karunakar P; edk2-devel@lists.01.org Cc: 'Ye, Ting'; 'Fu, Siyuan'; 'Wu, Jiaxin' Subject: RE: [edk2] Build error in StdLib with VS 2015 compiler Are you building C++ (.cpp)? Tim -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Karunakar P Sent: Wednesday, November 1, 2017 8:27 PM To: 'edk2-devel@lists.01.org' <edk2-devel@lists.01.org> Cc: 'Ye, Ting' <ting...@intel.com>; 'Fu, Siyuan' <siyuan...@intel.com>; 'Wu, Jiaxin' <jiaxin...@intel.com> Subject: Re: [edk2] Build error in StdLib with VS 2015 compiler Any comment on this? From: Karunakar P Sent: Tuesday, October 31, 2017 3:18 PM To: 'edk2-devel@lists.01.org' Cc: 'Wu, Jiaxin'; 'Fu, Siyuan'; 'Ye, Ting' Subject: Build error in StdLib with VS 2015 compiler Hello All, Facing an build error with Stdlib module when built with VS 2015 compiler. e:\test\StdLib\Include\sys/EfiCdefs.h(357): error C2220: warning treated as error - no 'object' file generated e:\test\StdLib\Include\sys/EfiCdefs.h(357): warning C4117: macro name '__STDC_HOSTED__' is reserved, '#define' ignored below change resolving this error. Would you please review and provide comments. #ifndef __STDC_HOSTED__ #define __STDC_HOSTED__ 1 #endif Thank You, Karunakar ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] Build error in StdLib with VS 2015 compiler
Any comment on this? From: Karunakar P Sent: Tuesday, October 31, 2017 3:18 PM To: 'edk2-devel@lists.01.org' Cc: 'Wu, Jiaxin'; 'Fu, Siyuan'; 'Ye, Ting' Subject: Build error in StdLib with VS 2015 compiler Hello All, Facing an build error with Stdlib module when built with VS 2015 compiler. e:\test\StdLib\Include\sys/EfiCdefs.h(357): error C2220: warning treated as error - no 'object' file generated e:\test\StdLib\Include\sys/EfiCdefs.h(357): warning C4117: macro name '__STDC_HOSTED__' is reserved, '#define' ignored below change resolving this error. Would you please review and provide comments. #ifndef __STDC_HOSTED__ #define __STDC_HOSTED__ 1 #endif Thank You, Karunakar ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] Build error in StdLib with VS 2015 compiler
Hello All, Facing an build error with Stdlib module when built with VS 2015 compiler. e:\test\StdLib\Include\sys/EfiCdefs.h(357): error C2220: warning treated as error - no 'object' file generated e:\test\StdLib\Include\sys/EfiCdefs.h(357): warning C4117: macro name '__STDC_HOSTED__' is reserved, '#define' ignored below change resolving this error. Would you please review and provide comments. #ifndef __STDC_HOSTED__ #define __STDC_HOSTED__ 1 #endif Thank You, Karunakar ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] Adding VLAN changing Boot order to default
Could you please provide your comments. Thank You, Karunakar From: Karunakar P Sent: Monday, October 23, 2017 8:38 PM To: 'edk2-devel@lists.01.org' Cc: Wu, Jiaxin; 'Fu, Siyuan'; Ye, Ting Subject: RE: Adding VLAN changing Boot order to default Hello All, Boot order is changing to default if we add VLAN, below are the steps followed. [Steps] 1. Change default boot order to some other, Then Commit changes and Exit. (In my case first boot option Is UEFI Internal Shell, then I changed PXEv4 as first boot option) 2. Add a VLAN Network Device List -> MAC -> VLAN Configuration -> Create new VLAN and Add VLAN 3. Now check the Boot order Observation:- The boot order was changed to default(In my case, UEFI Internal shell becomes first boot option) Could you please provide your comments on this? Thanks, Karunakar ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [Patch] NetworkPkg/IScsiDxe: Clear the old IFR TargetIp to avoid sharing it with other attempts.
Hi Jiaxin,
It can resolve the issue.
Thanks,
Karunakar
-Original Message-
From: Jiaxin Wu [mailto:jiaxin...@intel.com]
Sent: Thursday, October 26, 2017 1:57 PM
To: edk2-devel@lists.01.org
Cc: Karunakar P; Ye Ting; Fu Siyuan; Wu Jiaxin
Subject: [Patch] NetworkPkg/IScsiDxe: Clear the old IFR TargetIp to avoid
sharing it with other attempts.
Cc: Karunakar P <karunak...@amiindia.co.in>
Cc: Ye Ting <ting...@intel.com>
Cc: Fu Siyuan <siyuan...@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Wu Jiaxin <jiaxin...@intel.com>
---
NetworkPkg/IScsiDxe/IScsiConfig.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/NetworkPkg/IScsiDxe/IScsiConfig.c
b/NetworkPkg/IScsiDxe/IScsiConfig.c
index 3ce37c5..3382982 100644
--- a/NetworkPkg/IScsiDxe/IScsiConfig.c
+++ b/NetworkPkg/IScsiDxe/IScsiConfig.c
@@ -539,10 +539,11 @@ IScsiConvertAttemptConfigDataToIfrNvData (
IScsiIpToStr (, FALSE, IfrNvData->LocalIp);
CopyMem (, >SubnetMask, sizeof
(EFI_IPv4_ADDRESS));
IScsiIpToStr (, FALSE, IfrNvData->SubnetMask);
CopyMem (, >Gateway, sizeof (EFI_IPv4_ADDRESS));
IScsiIpToStr (, FALSE, IfrNvData->Gateway);
+ZeroMem (IfrNvData->TargetIp, sizeof (IfrNvData->TargetIp));
if (SessionConfigData->TargetIp.v4.Addr[0] != '\0') {
CopyMem (, >TargetIp, sizeof
(EFI_IPv4_ADDRESS));
IScsiIpToStr (, FALSE, IfrNvData->TargetIp);
}
--
1.9.5.msysgit.1
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [Patch 0/2] Add IPv6 support condition check for HTTP/ISCSI.
Reviewed-by: Karunakar p <karunak...@amiindia.co.in> Thanks, Karunakar -Original Message- From: Wu, Jiaxin [mailto:jiaxin...@intel.com] Sent: Tuesday, October 24, 2017 12:50 PM To: Karunakar P; edk2-devel@lists.01.org Cc: Ye, Ting; Fu, Siyuan Subject: RE: [edk2] [Patch 0/2] Add IPv6 support condition check for HTTP/ISCSI. Hi Karunakar, If you have no more comments, can you reply the below series patches with Reviewed-by/Tested-By tags, then I can go on the commit process? [Patch v3 0/3] NetworkPkg/IScsiDxe: Display InitiatorInfo correctly. NetworkPkg/IScsiDxe: Fix the incorrect/needless DHCP process. NetworkPkg/IScsiDxe: Clean the previous ConfigData when switching the IP mode. /// This one is to fix the issue A. NetworkPkg/IScsiDxe: Display InitiatorInfo in attempt page even DHCP enabled. [Patch v2 0/2] Add IPv6 support condition check. NetworkPkg/HttpBootDxe: Add IPv6 support condition check. /// B && C have been fixed in version 2. NetworkPkg/IScsiDxe: Add IPv6 support condition check. Thanks, Jiaxin > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Karunakar P > Sent: Tuesday, October 24, 2017 3:13 PM > To: Wu, Jiaxin <jiaxin...@intel.com>; edk2-devel@lists.01.org > Cc: Ye, Ting <ting...@intel.com>; Fu, Siyuan <siyuan...@intel.com> > Subject: Re: [edk2] [Patch 0/2] Add IPv6 support condition check for > HTTP/ISCSI. > > Hi Jiaxin, > > Yes, I believe this issue(#) is not the regression for previous issues > we have fixed. > > I created a new bug For #3 and below are the details > https://bugzilla.tianocore.org/show_bug.cgi?id=743 > > Could you please let me know the scheduled check in date for > previously reported issue/Features > > Thank You, > Karunakar > > -Original Message- > From: Wu, Jiaxin [mailto:jiaxin...@intel.com] > Sent: Tuesday, October 24, 2017 8:45 AM > To: Karunakar P; edk2-devel@lists.01.org > Cc: Ye, Ting; Fu, Siyuan > Subject: RE: [edk2] [Patch 0/2] Add IPv6 support condition check for > HTTP/ISCSI. > > Hi Karunakar, > > For #3, it's the non-regression issue that will cause the target IP is > invalid if it's the same with previous one. And I'd like to fix it by > another patch since it's not related to the InitiatorInfo display. > > Can you please report another Bugzilla for the ISCSI target address issue? > > Thanks, > Jiaxin > > > -Original Message- > > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf > > Of Karunakar P > > Sent: Tuesday, October 24, 2017 12:41 AM > > To: Wu, Jiaxin <jiaxin...@intel.com>; edk2-devel@lists.01.org > > Cc: Ye, Ting <ting...@intel.com>; Fu, Siyuan <siyuan...@intel.com> > > Subject: Re: [edk2] [Patch 0/2] Add IPv6 support condition check for > > HTTP/ISCSI. > > > > Hi Jiaxin, > > > > 1. I've verified, IPv6 support condition check for HTTP/ISCSI, It > > works fine and the ASSERT issue also resolved. > > 2. Regards Display Initiator IP, It resolves the issues the issues > > which I've mentioned previously. > > 3. I found some other issue in ISCSI, Below are the details A. Add > > Attempt1 with Target Info via Static and provide Target Name & > > Target IP, Save changes. > > B. If we are trying to add another attempt , It is taking Target IP > > as default IP which is same Target IP given in Attempt1. > > > > Could you please check at your end provide your comments on 3rd one. > > > > Thank You, > > Karunakar > > > > -Original Message- > > From: Wu, Jiaxin [mailto:jiaxin...@intel.com] > > Sent: Wednesday, October 18, 2017 2:30 PM > > To: Karunakar P; edk2-devel@lists.01.org > > Cc: Ye, Ting; Fu, Siyuan > > Subject: RE: [edk2] [Patch 0/2] Add IPv6 support condition check for > > HTTP/ISCSI. > > > > Hi Karunakar, > > > > Actually, in my part, I didn't meet the ASSERT no matter the "Ipv6Available" > > returned from HttpBootCheckIpv6Support is true or false. According > > your ASSERT case that happened in Ip4DxeDriverBindingStart, which is > > caused by the FreePool of Private in Ip6DxeDriverBindingStart, so I > > guess the Ip6DxeDriverBindingStart may be involved ahead of > > Ip4DxeDriverBindingStart, then something wrong happened in > > Ip6DxeDriverBindingStart and goto the ON_ERROR (Private is freed > > here!). so, you can add the breakpoint within > > Ip6DxeDriverBindingStart/Ip4DxeDriverBindingStart to check it. > > > > Per my analysis above, it does the issue that may trigger th
Re: [edk2] [Patch 0/2] Add IPv6 support condition check for HTTP/ISCSI.
Hi Jiaxin, Yes, I believe this issue(#) is not the regression for previous issues we have fixed. I created a new bug For #3 and below are the details https://bugzilla.tianocore.org/show_bug.cgi?id=743 Could you please let me know the scheduled check in date for previously reported issue/Features Thank You, Karunakar -Original Message- From: Wu, Jiaxin [mailto:jiaxin...@intel.com] Sent: Tuesday, October 24, 2017 8:45 AM To: Karunakar P; edk2-devel@lists.01.org Cc: Ye, Ting; Fu, Siyuan Subject: RE: [edk2] [Patch 0/2] Add IPv6 support condition check for HTTP/ISCSI. Hi Karunakar, For #3, it's the non-regression issue that will cause the target IP is invalid if it's the same with previous one. And I'd like to fix it by another patch since it's not related to the InitiatorInfo display. Can you please report another Bugzilla for the ISCSI target address issue? Thanks, Jiaxin > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Karunakar P > Sent: Tuesday, October 24, 2017 12:41 AM > To: Wu, Jiaxin <jiaxin...@intel.com>; edk2-devel@lists.01.org > Cc: Ye, Ting <ting...@intel.com>; Fu, Siyuan <siyuan...@intel.com> > Subject: Re: [edk2] [Patch 0/2] Add IPv6 support condition check for > HTTP/ISCSI. > > Hi Jiaxin, > > 1. I've verified, IPv6 support condition check for HTTP/ISCSI, It > works fine and the ASSERT issue also resolved. > 2. Regards Display Initiator IP, It resolves the issues the issues > which I've mentioned previously. > 3. I found some other issue in ISCSI, Below are the details A. Add > Attempt1 with Target Info via Static and provide Target Name & Target > IP, Save changes. > B. If we are trying to add another attempt , It is taking Target IP as > default IP which is same Target IP given in Attempt1. > > Could you please check at your end provide your comments on 3rd one. > > Thank You, > Karunakar > > -Original Message- > From: Wu, Jiaxin [mailto:jiaxin...@intel.com] > Sent: Wednesday, October 18, 2017 2:30 PM > To: Karunakar P; edk2-devel@lists.01.org > Cc: Ye, Ting; Fu, Siyuan > Subject: RE: [edk2] [Patch 0/2] Add IPv6 support condition check for > HTTP/ISCSI. > > Hi Karunakar, > > Actually, in my part, I didn't meet the ASSERT no matter the "Ipv6Available" > returned from HttpBootCheckIpv6Support is true or false. According > your ASSERT case that happened in Ip4DxeDriverBindingStart, which is > caused by the FreePool of Private in Ip6DxeDriverBindingStart, so I > guess the Ip6DxeDriverBindingStart may be involved ahead of > Ip4DxeDriverBindingStart, then something wrong happened in > Ip6DxeDriverBindingStart and goto the ON_ERROR (Private is freed > here!). so, you can add the breakpoint within > Ip6DxeDriverBindingStart/Ip4DxeDriverBindingStart to check it. > > Per my analysis above, it does the issue that may trigger the potential > ASSERT. > So, I refined the patch as version2. The principle of patch v2 is that > IPv6 and > IPv4 should not affect each other even any failure happen, but the > original code doesn't follow that:). > > > Thanks, > Jiaxin > > > > -Original Message- > > From: Karunakar P [mailto:karunak...@amiindia.co.in] > > Sent: Wednesday, October 18, 2017 4:06 PM > > To: Wu, Jiaxin <jiaxin...@intel.com>; edk2-devel@lists.01.org > > Cc: Ye, Ting <ting...@intel.com>; Fu, Siyuan <siyuan...@intel.com> > > Subject: RE: [edk2] [Patch 0/2] Add IPv6 support condition check for > > HTTP/ISCSI. > > > > Hi Jiaxin, > > > > 1. Cleaning the ConfigData when switching the mode will resolve the > > Issue > A. > > 2. Will also verify the ASSERT issue and update you. > > > > Could you please help in clarifying the below items, 1. Could you > > please let us know why the ASSERT happens? > > 2. I've not faced any ASSERT with the changes attached in Bugzilla, > > Did you find any issues/drawbacks with that? > > -> In HttpBootCheckIpv6Support () definition Instead of getting > > -> Ipv6Support > > from Private->Nii->Ipv6Supported if we open the protocol there > > itself, Then there will not be issues in Destroying Children or > > FreePool(Private) > right. > > Because we're going to check HttpBootCheckIpv6Support() before > > opening any instances in HttpBootIp6DxeDriverBindingStart(). > > > > Thanks for your great support. > > > > Thank You, > > Karunakar > > > > From: Wu, Jiaxin [jiaxin...@intel.com] > > Sent: 18 October 2017 12:35 > > To: Karunakar P; edk2-devel@lists.01.org > > C
Re: [edk2] [Patch 0/2] Add IPv6 support condition check for HTTP/ISCSI.
Hi Jiaxin, 1. I've verified, IPv6 support condition check for HTTP/ISCSI, It works fine and the ASSERT issue also resolved. 2. Regards Display Initiator IP, It resolves the issues the issues which I've mentioned previously. 3. I found some other issue in ISCSI, Below are the details A. Add Attempt1 with Target Info via Static and provide Target Name & Target IP, Save changes. B. If we are trying to add another attempt , It is taking Target IP as default IP which is same Target IP given in Attempt1. Could you please check at your end provide your comments on 3rd one. Thank You, Karunakar -Original Message- From: Wu, Jiaxin [mailto:jiaxin...@intel.com] Sent: Wednesday, October 18, 2017 2:30 PM To: Karunakar P; edk2-devel@lists.01.org Cc: Ye, Ting; Fu, Siyuan Subject: RE: [edk2] [Patch 0/2] Add IPv6 support condition check for HTTP/ISCSI. Hi Karunakar, Actually, in my part, I didn't meet the ASSERT no matter the "Ipv6Available" returned from HttpBootCheckIpv6Support is true or false. According your ASSERT case that happened in Ip4DxeDriverBindingStart, which is caused by the FreePool of Private in Ip6DxeDriverBindingStart, so I guess the Ip6DxeDriverBindingStart may be involved ahead of Ip4DxeDriverBindingStart, then something wrong happened in Ip6DxeDriverBindingStart and goto the ON_ERROR (Private is freed here!). so, you can add the breakpoint within Ip6DxeDriverBindingStart/Ip4DxeDriverBindingStart to check it. Per my analysis above, it does the issue that may trigger the potential ASSERT. So, I refined the patch as version2. The principle of patch v2 is that IPv6 and IPv4 should not affect each other even any failure happen, but the original code doesn't follow that:). Thanks, Jiaxin > -Original Message- > From: Karunakar P [mailto:karunak...@amiindia.co.in] > Sent: Wednesday, October 18, 2017 4:06 PM > To: Wu, Jiaxin <jiaxin...@intel.com>; edk2-devel@lists.01.org > Cc: Ye, Ting <ting...@intel.com>; Fu, Siyuan <siyuan...@intel.com> > Subject: RE: [edk2] [Patch 0/2] Add IPv6 support condition check for > HTTP/ISCSI. > > Hi Jiaxin, > > 1. Cleaning the ConfigData when switching the mode will resolve the Issue A. > 2. Will also verify the ASSERT issue and update you. > > Could you please help in clarifying the below items, 1. Could you > please let us know why the ASSERT happens? > 2. I've not faced any ASSERT with the changes attached in Bugzilla, > Did you find any issues/drawbacks with that? > -> In HttpBootCheckIpv6Support () definition Instead of getting > -> Ipv6Support > from Private->Nii->Ipv6Supported if we open the protocol there itself, > Then there will not be issues in Destroying Children or FreePool(Private) > right. > Because we're going to check HttpBootCheckIpv6Support() before > opening any instances in HttpBootIp6DxeDriverBindingStart(). > > Thanks for your great support. > > Thank You, > Karunakar > > From: Wu, Jiaxin [jiaxin...@intel.com] > Sent: 18 October 2017 12:35 > To: Karunakar P; edk2-devel@lists.01.org > Cc: Ye, Ting; Fu, Siyuan > Subject: RE: [edk2] [Patch 0/2] Add IPv6 support condition check for > HTTP/ISCSI. > > Hi Karunakar, > > Thanks your verification. Base on your comments, I refined the series > patches as below to fix the issues: > > [Patch v3 0/3] NetworkPkg/IScsiDxe: Display InitiatorInfo correctly. > NetworkPkg/IScsiDxe: Fix the incorrect/needless DHCP process. > NetworkPkg/IScsiDxe: Clean the previous ConfigData when > switching the IP mode. /// This one is to fix the issue A. > NetworkPkg/IScsiDxe: Display InitiatorInfo in attempt page > even DHCP enabled. > > [Patch v2 0/2] Add IPv6 support condition check. > NetworkPkg/HttpBootDxe: Add IPv6 support condition check. > /// B && C have been fixed in version 2. > NetworkPkg/IScsiDxe: Add IPv6 support condition check. > > Please help to verify them. > > Best Regards, > Jiaxin > > > > -Original Message- > > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf > > Of Karunakar P > > Sent: Tuesday, October 17, 2017 6:13 PM > > To: Wu, Jiaxin <jiaxin...@intel.com>; edk2-devel@lists.01.org > > Cc: Ye, Ting <ting...@intel.com>; Fu, Siyuan <siyuan...@intel.com> > > Subject: Re: [edk2] [Patch 0/2] Add IPv6 support condition check for > > HTTP/ISCSI. > > > > Hi Jiaxin, > > > > I Reviewed the changes for 3 features/Bugs and verified the same, > > Please find my below comments and issues faced > > > > A. Display InitiatorInfo in attempt page even DHCP enabled > > ---
Re: [edk2] Adding VLAN changing Boot order to default
Hello All, Boot order is changing to default if we add VLAN, below are the steps followed. [Steps] 1. Change default boot order to some other, Then Commit changes and Exit. (In my case first boot option Is UEFI Internal Shell, then I changed PXEv4 as first boot option) 2. Add a VLAN Network Device List -> MAC -> VLAN Configuration -> Create new VLAN and Add VLAN 3. Now check the Boot order Observation:- The boot order was changed to default(In my case, UEFI Internal shell becomes first boot option) Could you please provide your comments on this? Thanks, Karunakar ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [Patch 0/2] Add IPv6 support condition check for HTTP/ISCSI.
Hi Jixian, Thanks for your Detailed explanation. Will review/Verify the changes and update you on Friday. Thank You, Karunakar From: Wu, Jiaxin [jiaxin...@intel.com] Sent: 18 October 2017 14:30 To: Karunakar P; edk2-devel@lists.01.org Cc: Ye, Ting; Fu, Siyuan Subject: RE: [edk2] [Patch 0/2] Add IPv6 support condition check for HTTP/ISCSI. Hi Karunakar, Actually, in my part, I didn't meet the ASSERT no matter the "Ipv6Available" returned from HttpBootCheckIpv6Support is true or false. According your ASSERT case that happened in Ip4DxeDriverBindingStart, which is caused by the FreePool of Private in Ip6DxeDriverBindingStart, so I guess the Ip6DxeDriverBindingStart may be involved ahead of Ip4DxeDriverBindingStart, then something wrong happened in Ip6DxeDriverBindingStart and goto the ON_ERROR (Private is freed here!). so, you can add the breakpoint within Ip6DxeDriverBindingStart/Ip4DxeDriverBindingStart to check it. Per my analysis above, it does the issue that may trigger the potential ASSERT. So, I refined the patch as version2. The principle of patch v2 is that IPv6 and IPv4 should not affect each other even any failure happen, but the original code doesn't follow that:). Thanks, Jiaxin > -Original Message- > From: Karunakar P [mailto:karunak...@amiindia.co.in] > Sent: Wednesday, October 18, 2017 4:06 PM > To: Wu, Jiaxin <jiaxin...@intel.com>; edk2-devel@lists.01.org > Cc: Ye, Ting <ting...@intel.com>; Fu, Siyuan <siyuan...@intel.com> > Subject: RE: [edk2] [Patch 0/2] Add IPv6 support condition check for > HTTP/ISCSI. > > Hi Jiaxin, > > 1. Cleaning the ConfigData when switching the mode will resolve the Issue A. > 2. Will also verify the ASSERT issue and update you. > > Could you please help in clarifying the below items, > 1. Could you please let us know why the ASSERT happens? > 2. I've not faced any ASSERT with the changes attached in Bugzilla, Did you > find any issues/drawbacks with that? > -> In HttpBootCheckIpv6Support () definition Instead of getting Ipv6Support > from Private->Nii->Ipv6Supported if we open the protocol there itself, Then > there will not be issues in Destroying Children or FreePool(Private) right. > Because we're going to check HttpBootCheckIpv6Support() before opening > any instances in HttpBootIp6DxeDriverBindingStart(). > > Thanks for your great support. > > Thank You, > Karunakar > ____ > From: Wu, Jiaxin [jiaxin...@intel.com] > Sent: 18 October 2017 12:35 > To: Karunakar P; edk2-devel@lists.01.org > Cc: Ye, Ting; Fu, Siyuan > Subject: RE: [edk2] [Patch 0/2] Add IPv6 support condition check for > HTTP/ISCSI. > > Hi Karunakar, > > Thanks your verification. Base on your comments, I refined the series > patches as below to fix the issues: > > [Patch v3 0/3] NetworkPkg/IScsiDxe: Display InitiatorInfo correctly. > NetworkPkg/IScsiDxe: Fix the incorrect/needless DHCP process. > NetworkPkg/IScsiDxe: Clean the previous ConfigData when switching > the IP mode. /// This one is to fix the issue A. > NetworkPkg/IScsiDxe: Display InitiatorInfo in attempt page even > DHCP > enabled. > > [Patch v2 0/2] Add IPv6 support condition check. > NetworkPkg/HttpBootDxe: Add IPv6 support condition check. /// B > && C have been fixed in version 2. > NetworkPkg/IScsiDxe: Add IPv6 support condition check. > > Please help to verify them. > > Best Regards, > Jiaxin > > > > -Original Message- > > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > > Karunakar P > > Sent: Tuesday, October 17, 2017 6:13 PM > > To: Wu, Jiaxin <jiaxin...@intel.com>; edk2-devel@lists.01.org > > Cc: Ye, Ting <ting...@intel.com>; Fu, Siyuan <siyuan...@intel.com> > > Subject: Re: [edk2] [Patch 0/2] Add IPv6 support condition check for > > HTTP/ISCSI. > > > > Hi Jiaxin, > > > > I Reviewed the changes for 3 features/Bugs and verified the same, Please > > find my below comments and issues faced > > > > A. Display InitiatorInfo in attempt page even DHCP enabled > > --- > --- > > > > 1. I applied IScsiConfigVfr.vfr changes and as well IScsiMisc.c changes > > 2. It displays initiator info properly when it's Enabled for DHCP > > 3. But, I found some different behavior in below case > > a. Add an Attempt (Attempt1 -> Initiator Info Enabled for DHCP) > > b. On reboot iSCSI attempt was success and Initiator Details shown > >
Re: [edk2] [Patch 0/2] Add IPv6 support condition check for HTTP/ISCSI.
Not sure that previous mail was delivered, Hence resending the same Mail.
Thanks,
Karunakar
-Original Message-
From: Karunakar P
Sent: Tuesday, October 17, 2017 3:43 PM
To: 'Wu, Jiaxin'; edk2-devel@lists.01.org
Cc: Ye, Ting; Fu, Siyuan
Subject: RE: [edk2] [Patch 0/2] Add IPv6 support condition check for HTTP/ISCSI.
Hi Jiaxin,
I Reviewed the changes for 3 features/Bugs and verified the same, Please find
my below comments and issues faced
A. Display InitiatorInfo in attempt page even DHCP enabled
--
1. I applied IScsiConfigVfr.vfr changes and as well IScsiMisc.c changes 2. It
displays initiator info properly when it's Enabled for DHCP 3. But, I found
some different behavior in below case
a. Add an Attempt (Attempt1 -> Initiator Info Enabled for DHCP)
b. On reboot iSCSI attempt was success and Initiator Details shown
properly ==> This is as expected
c. Edit the same Attempt1 details to IP6 and save changes and reset
d. Now Iscsi connection with IP6 ==> This is as Expected
e. Now if we again Change the Attempt1 to IP4, It is Displaying Subnet Mask
==> I guess we are not clearing It
I guess we need to do ZeroMem for initiator details before.
B. [Patch 2/2] NetworkPkg/IScsiDxe: Add IPv6 support condition check.
-
-> This changes looks similar whatever I attached in Bugzilla, and
-> verified the same with off board card witch doesn't support IP6 It works
fine, I didn't find any issues on it.
C. [Patch 1/2] NetworkPkg/HttpBootDxe: Add IPv6 support condition check.
--
I found some issues in this changes, please find my below comments 1.
HttpBootCheckIpv6Support() function definition and function call parameter
differs , To correct this I've done 1 insertion(+), 1 deletion(-) like below ...
+HttpBootCheckIpv6Support (
+ IN EFI_HANDLE ControllerHandle,
+ IN HTTP_BOOT_PRIVATE_DATA *Private,
+ OUT BOOLEAN *Ipv6Support
+ )
...
+ // Set IPv6 available flag.
+ //
+ Status = HttpBootCheckIpv6Support (ControllerHandle,
-This->DriverBindingHandle, );
+Private, );
...
2. With the above changes I've verified with Off board card which doesn't
support IP6, But I'm facing below ASSERT
(324): CR has Bad Signature
EFI_STATUS
EFIAPI
HttpBootIp4DxeDriverBindingStart (
IN EFI_DRIVER_BINDING_PROTOCOL *This,
IN EFI_HANDLE ControllerHandle,
IN EFI_DEVICE_PATH_PROTOCOL *RemainingDevicePath OPTIONAL
)
{
...
if (!EFI_ERROR (Status)) {
Private = HTTP_BOOT_PRIVATE_DATA_FROM_ID(Id); // ASSERTs here
} else {
.
3. I would like add some points and info about the this ASSERT, which I've
found The ASSERT is happening because of FreePool (Private), mentioned exact
line no below
EFI_STATUS
EFIAPI
HttpBootIp6DxeDriverBindingStart (
IN EFI_DRIVER_BINDING_PROTOCOL *This,
IN EFI_HANDLE ControllerHandle,
IN EFI_DEVICE_PATH_PROTOCOL *RemainingDevicePath OPTIONAL
)
{
...
Status = gBS->InstallProtocolInterface (
,
,
EFI_NATIVE_INTERFACE,
>Id
);
if (EFI_ERROR (Status)) {
goto ON_ERROR;
}
}
+
+ //
+ // Set IPv6 available flag.
+ //
+ Status = HttpBootCheckIpv6Support (ControllerHandle,
-This->DriverBindingHandle, );
+Private, );
+ if (EFI_ERROR (Status)) {
+//
+// Fail to get the data whether UNDI supports IPv6.
+ // Set default value to TRUE.
+//
+Ipv6Available = TRUE;
+ }
+
+ if (!Ipv6Available) {
+return EFI_UNSUPPORTED;
+ }
if (Private->Ip6Nic != NULL) {
//
...
ON_ERROR:
HttpBootDestroyIp6Children(This, Private);
HttpBootConfigFormUnload (Private);
FreePool (Private);
// If I comment this line ASSERT is not happening
return Status;
}
4. At your end could you please verify this IP6 Condition check for HTTP
Please correct if anything is wrong, Thanks for your support
Thank You,
Karunakar
-Original Message-
From: Wu, Jiaxin [mailto:jiaxin...@intel.com]
Sent: Tuesday, October 17, 2017 7:32 AM
To: Wu, Jiaxin; edk2-devel@lists.01.org
Cc: Karunakar P; Ye, Ting; Fu, Siyuan
Subject: RE: [edk2] [Patch 0/2] Add IPv6 support condition check for HTTP/ISCSI.
Hello Karunakar,
Base on your original changes attached in Bugzilla 701
(https://bugzilla.tianocore.org/show_bug.cgi?id=710), I created the formal
series patches to support the IP
Re: [edk2] [Patch 0/2] Add IPv6 support condition check for HTTP/ISCSI.
Hi Jiaxin,
I Reviewed the changes for 3 features/Bugs and verified the same, Please find
my below comments and issues faced
A. Display InitiatorInfo in attempt page even DHCP enabled
--
1. I applied IScsiConfigVfr.vfr changes and as well IScsiMisc.c changes
2. It displays initiator info properly when it's Enabled for DHCP
3. But, I found some different behavior in below case
a. Add an Attempt (Attempt1 -> Initiator Info Enabled for DHCP)
b. On reboot iSCSI attempt was success and Initiator Details shown
properly ==> This is as expected
c. Edit the same Attempt1 details to IP6 and save changes and reset
d. Now Iscsi connection with IP6 ==> This is as Expected
e. Now if we again Change the Attempt1 to IP4, It is Displaying Subnet Mask
==> I guess we are not clearing It
I guess we need to do ZeroMem for initiator details before.
B. [Patch 2/2] NetworkPkg/IScsiDxe: Add IPv6 support condition check.
-
-> This changes looks similar whatever I attached in Bugzilla, and verified the
same with off board card witch doesn't support IP6
-> It works fine, I didn't find any issues on it.
C. [Patch 1/2] NetworkPkg/HttpBootDxe: Add IPv6 support condition check.
--
I found some issues in this changes, please find my below comments
1. HttpBootCheckIpv6Support() function definition and function call parameter
differs , To correct this I've done 1 insertion(+), 1 deletion(-) like below
...
+HttpBootCheckIpv6Support (
+ IN EFI_HANDLE ControllerHandle,
+ IN HTTP_BOOT_PRIVATE_DATA *Private,
+ OUT BOOLEAN *Ipv6Support
+ )
...
+ // Set IPv6 available flag.
+ //
+ Status = HttpBootCheckIpv6Support (ControllerHandle,
-This->DriverBindingHandle, );
+Private, );
...
2. With the above changes I've verified with Off board card which doesn't
support IP6, But I'm facing below ASSERT
(324): CR has Bad Signature
EFI_STATUS
EFIAPI
HttpBootIp4DxeDriverBindingStart (
IN EFI_DRIVER_BINDING_PROTOCOL *This,
IN EFI_HANDLE ControllerHandle,
IN EFI_DEVICE_PATH_PROTOCOL *RemainingDevicePath OPTIONAL
)
{
...
if (!EFI_ERROR (Status)) {
Private = HTTP_BOOT_PRIVATE_DATA_FROM_ID(Id); // ASSERTs here
} else {
.
3. I would like add some points and info about the this ASSERT, which I've found
The ASSERT is happening because of FreePool (Private), mentioned exact line no
below
EFI_STATUS
EFIAPI
HttpBootIp6DxeDriverBindingStart (
IN EFI_DRIVER_BINDING_PROTOCOL *This,
IN EFI_HANDLE ControllerHandle,
IN EFI_DEVICE_PATH_PROTOCOL *RemainingDevicePath OPTIONAL
)
{
...
Status = gBS->InstallProtocolInterface (
,
,
EFI_NATIVE_INTERFACE,
>Id
);
if (EFI_ERROR (Status)) {
goto ON_ERROR;
}
}
+
+ //
+ // Set IPv6 available flag.
+ //
+ Status = HttpBootCheckIpv6Support (ControllerHandle,
-This->DriverBindingHandle, );
+Private, );
+ if (EFI_ERROR (Status)) {
+//
+// Fail to get the data whether UNDI supports IPv6.
+ // Set default value to TRUE.
+//
+Ipv6Available = TRUE;
+ }
+
+ if (!Ipv6Available) {
+return EFI_UNSUPPORTED;
+ }
if (Private->Ip6Nic != NULL) {
//
...
ON_ERROR:
HttpBootDestroyIp6Children(This, Private);
HttpBootConfigFormUnload (Private);
FreePool (Private);
// If I comment this line ASSERT is not happening
return Status;
}
4. At your end could you please verify this IP6 Condition check for HTTP
Please correct if anything is wrong, Thanks for your support
Thank You,
Karunakar
-Original Message-
From: Wu, Jiaxin [mailto:jiaxin...@intel.com]
Sent: Tuesday, October 17, 2017 7:32 AM
To: Wu, Jiaxin; edk2-devel@lists.01.org
Cc: Karunakar P; Ye, Ting; Fu, Siyuan
Subject: RE: [edk2] [Patch 0/2] Add IPv6 support condition check for HTTP/ISCSI.
Hello Karunakar,
Base on your original changes attached in Bugzilla 701
(https://bugzilla.tianocore.org/show_bug.cgi?id=710), I created the formal
series patches to support the IPv6 condition check for HTTP/ISCSI.
Please help to review/verify it.
BTW, To review the ISCSI part, please apply the "[Patch v2 0/2]
NetworkPkg/IScsiDxe: Display InitiatorInfo correctly" first to avoid any patch
conflict.
Thanks,
Jiaxin
> -Original Message-
> From: edk2-devel [mailto:edk2-deve
Re: [edk2] Linux CentOS 7.3 can get DHCP IPv4 IP address with configuring DHCP server as per RFC3021
Hi Siyuan,
Could you please update the status on this.
Thanks,
Karunakar
From: Karunakar P
Sent: Wednesday, September 27, 2017 3:06 PM
To: 'Fu, Siyuan'; 'edk2-devel@lists.01.org'
Cc: Wu, Jiaxin; Ye, Ting
Subject: RE: Linux CentOS 7.3 can get DHCP IPv4 IP address with configuring
DHCP server as per RFC3021
Hi Siyuan,
I've filled a New Bug in Bugzilla and following are the details.
https://bugzilla.tianocore.org/show_bug.cgi?id=722
Thanks,
Karunakar
From: Fu, Siyuan [mailto:siyuan...@intel.com]
Sent: Wednesday, September 27, 2017 1:46 PM
To: Karunakar P; 'edk2-devel@lists.01.org'
Cc: Wu, Jiaxin; Ye, Ting
Subject: RE: Linux CentOS 7.3 can get DHCP IPv4 IP address with configuring
DHCP server as per RFC3021
Hi, Karunakar
We haven't received requirement for this feature before so we don't have plan
now. I think you can submit a Bugzilla ticket for this feature request, we will
follow up to investigate it.
BestRegards
Fu Siyuan
From: Karunakar P [mailto:karunak...@amiindia.co.in]
Sent: Monday, September 25, 2017 4:54 PM
To: Fu, Siyuan <siyuan...@intel.com<mailto:siyuan...@intel.com>>;
'edk2-devel@lists.01.org'
<edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>>
Cc: Wu, Jiaxin <jiaxin...@intel.com<mailto:jiaxin...@intel.com>>; Ye, Ting
<ting...@intel.com<mailto:ting...@intel.com>>
Subject: RE: Linux CentOS 7.3 can get DHCP IPv4 IP address with configuring
DHCP server as per RFC3021
Hi Fu Siyuan,
Thanks for your conformation.
We would like to use /31s to save IPv4 addresses.
When it's a point-to-point link (server to router), the extra network address
and broadcast address is wasted.
RFC 3021 solves the problem by using a broadcast address of 255.255.255.255 on
such subnets.
We have a requirement to support this, do you have any plan to support RFC3021
? Given the requirement time consuming how hard to implement this ?
Thanks,
karunakar
From: Fu, Siyuan [mailto:siyuan...@intel.com]
Sent: Monday, September 25, 2017 1:28 PM
To: Karunakar P; 'edk2-devel@lists.01.org'
Cc: Wu, Jiaxin; Ye, Ting
Subject: RE: Linux CentOS 7.3 can get DHCP IPv4 IP address with configuring
DHCP server as per RFC3021
Hi, Karunakar
May I know that whether you have a real requirement that must use the
point-2-point link in your environment, or you just found this problem in your
test?
BestRegards
Fu Siyuan
From: Fu, Siyuan
Sent: Monday, September 25, 2017 3:50 PM
To: Karunakar P <karunak...@amiindia.co.in<mailto:karunak...@amiindia.co.in>>;
'edk2-devel@lists.01.org'
<edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>>
Cc: Wu, Jiaxin <jiaxin...@intel.com<mailto:jiaxin...@intel.com>>; Ye, Ting
<ting...@intel.com<mailto:ting...@intel.com>>
Subject: RE: Linux CentOS 7.3 can get DHCP IPv4 IP address with configuring
DHCP server as per RFC3021
Hi, Karunakar
You are correct that EDK2 doesn't support rfc3201.
The most obvious problem that come to my mind is the NetIp4IsUnicast() function
in NetLib, which has the assumption that the host address part should not be
all zero or all one (or to say, -1 in the rfc3201). I think that's why the PXE
failed, but Cent OS could use IP address from the same DHCP server.
This is just an example, there may be some other places in edk2 network stack
which have the same assumption, I'm not sure about this. Anyway, we never
considered the point-2-point link in edk2.
BestRegards
Fu Siyuan
From: Karunakar P [mailto:karunak...@amiindia.co.in]
Sent: Monday, September 25, 2017 3:02 PM
To: 'edk2-devel@lists.01.org'
<edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>>
Cc: Wu, Jiaxin <jiaxin...@intel.com<mailto:jiaxin...@intel.com>>; Fu, Siyuan
<siyuan...@intel.com<mailto:siyuan...@intel.com>>; Ye, Ting
<ting...@intel.com<mailto:ting...@intel.com>>
Subject: Re: Linux CentOS 7.3 can get DHCP IPv4 IP address with configuring
DHCP server as per RFC3021
Hello All,
It is known that current EDKII doesn't support RFC3021, We could see the
following behavior which is PXE boot fails whereas Cent OS can get IP address
from the same BIOS.
[Configuration Used]
DHCP server setting under Ubuntu:
1. /etc/dhcp/dhcpd.conf
# RFC3021-Using 31-bit perfixes on IPv4 Point-to-Point Links
subnet 192.168.1.0 netmask 255.255.255.254 {
range 192.168.1.1 192.168.1.1;
next-server 192.168.1.0;
filename "EFI/BOOT/BOOTAA64.EFI";
option subnet-mask 255.255.255.254;
option routers 192.168.1.0;
}
2. /etc/network/interfaces
auto eth0
iface eth0 inet static
address 192.168.1.0
netmask 255.255.255.254
network 192.168.1.0
If the DHCP server and network interface are set up above configuration. Below
are my test results and questions
1. CentOS 7.3 (pre-installed) was able to retrieve IP through DHCP when
they connect HDD to the SUT where PXE is failing.
2. Could you please suggest what could be the reason beh
Re: [edk2] [Patch] NetworkPkg/IScsiDxe: Display InitiatorInfo in attempt page even DHCP enabled.
Hi Jiaxin/Siyuan, I've verified Initiator details with this changes. I found an issue like Initiator Details are shown for Connection less NIC Please find below details for more details [Issue details and steps to reproduce] 1. SUT have 2 LAN ports MAC XX:XX:XX:XX:XX:AA -> LAN Cable NOT connected to this port, i.e. Link Status is Disconnected MAC XX:XX:XX:XX:XX:BB -> LAN Cable Connected to this port, i.e. Link Status is Connected 2. I've added two attempts a. Attempt1 added to connection less NIC (MAC XX:XX:XX:XX:XX:AA ) b. Attempt2 added to connected NIC (MAC XX:XX:XX:XX:XX:BB ) [Observations] 1. Initiator IP Address and Subnet Mask displayed for both Attempt1 and Attempt2 Could you please comment on this observation? Thanks, Karunakar -Original Message- From: Fu, Siyuan [mailto:siyuan...@intel.com] Sent: Friday, October 13, 2017 11:54 AM To: Wu, Jiaxin; edk2-devel@lists.01.org Cc: Karunakar P; Ye, Ting Subject: RE: [Patch] NetworkPkg/IScsiDxe: Display InitiatorInfo in attempt page even DHCP enabled. Reviewed-by: Fu Siyuan <siyuan...@intel.com> -Original Message- From: Wu, Jiaxin Sent: Friday, October 13, 2017 2:01 PM To: edk2-devel@lists.01.org Cc: Karunakar P <karunak...@amiindia.co.in>; Ye, Ting <ting...@intel.com>; Fu, Siyuan <siyuan...@intel.com>; Wu, Jiaxin <jiaxin...@intel.com> Subject: [Patch] NetworkPkg/IScsiDxe: Display InitiatorInfo in attempt page even DHCP enabled. Cc: Karunakar P <karunak...@amiindia.co.in> Cc: Ye Ting <ting...@intel.com> Cc: Fu Siyuan <siyuan...@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Wu Jiaxin <jiaxin...@intel.com> --- NetworkPkg/IScsiDxe/IScsiConfigVfr.vfr | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/NetworkPkg/IScsiDxe/IScsiConfigVfr.vfr b/NetworkPkg/IScsiDxe/IScsiConfigVfr.vfr index d401419..35e8f9a 100644 --- a/NetworkPkg/IScsiDxe/IScsiConfigVfr.vfr +++ b/NetworkPkg/IScsiDxe/IScsiConfigVfr.vfr @@ -189,13 +189,14 @@ formset flags = INTERACTIVE, key= KEY_DHCP_ENABLE, endcheckbox; endif; -suppressif ideqval ISCSI_CONFIG_IFR_NVDATA.InitiatorInfoFromDhcp == 0x01 OR - ideqval ISCSI_CONFIG_IFR_NVDATA.IpMode == IP_MODE_IP6 OR +suppressif ideqval ISCSI_CONFIG_IFR_NVDATA.IpMode == IP_MODE_IP6 OR ideqval ISCSI_CONFIG_IFR_NVDATA.IpMode == IP_MODE_AUTOCONFIG; + +grayoutif ideqval ISCSI_CONFIG_IFR_NVDATA.InitiatorInfoFromDhcp == 0x01; string varid = ISCSI_CONFIG_IFR_NVDATA.LocalIp, prompt = STRING_TOKEN(STR_ISCSI_LOCAL_IP_ADDRESS), help= STRING_TOKEN(STR_ISCSI_IP_ADDRESS_HELP), flags = INTERACTIVE, key = KEY_LOCAL_IP, @@ -218,10 +219,11 @@ formset flags = INTERACTIVE, key = KEY_GATE_WAY, minsize = IP4_MIN_SIZE, maxsize = IP4_MAX_SIZE, endstring; +endif; endif; suppressif ideqval ISCSI_CONFIG_IFR_NVDATA.IpMode == IP_MODE_AUTOCONFIG; subtitle text = STRING_TOKEN(STR_NULL); -- 1.9.5.msysgit.1 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] Request to display Initiator IP in ISCSI Attempt Page
Hi Jiaxin, Thanks for your support. I've created a ticket in Bugzilla, and below are the details https://bugzilla.tianocore.org/show_bug.cgi?id=732 Yeah we should grayout the Initiator info to indicate it's un-configurable. In case of IPv6 1. Before trying for ISCSI connection(with IPv6 attempt), we'll configure the IP manually. 2. While trying for ISCSI Connection(with IPv6 attempt), It may use the above Configured IP or link local address. 3. Can we display the whatever IP used for ISCSI connection(with IPv6 attempt) as Initiator IP In IP6 attempt Page? , So that we can know what Initiator IP used for ISCSI connection. Could you please let me know if anything is wrong. Thanks, Karunakar From: Wu, Jiaxin [mailto:jiaxin...@intel.com] Sent: Tuesday, October 10, 2017 8:07 AM To: Karunakar P; 'edk2-devel@lists.01.org' Cc: Fu, Siyuan; Ye, Ting Subject: RE: Request to display Initiator IP in ISCSI Attempt Page Hi Karunakar, We agree to add this feature for the Initiator info of IPv4 when DHCP enabled. Can you report it on Bugzilla first? To achieve that, we can grayout the Initiator IP/Subnet/Gateway if Initiator DHCP enabled to indicate it's un-configurable. For IPv6, since iSCSI only request the target info from DHCP server, so, it's unnecessary to display the info as IPv4. Thanks, Jiaxin From: Karunakar P [mailto:karunak...@amiindia.co.in] Sent: Friday, October 6, 2017 5:28 PM To: 'edk2-devel@lists.01.org' <edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>> Cc: Fu, Siyuan <siyuan...@intel.com<mailto:siyuan...@intel.com>>; Wu, Jiaxin <jiaxin...@intel.com<mailto:jiaxin...@intel.com>>; Ye, Ting <ting...@intel.com<mailto:ting...@intel.com>> Subject: RE: Request to display Initiator IP in ISCSI Attempt Page Hello All, We have a requirement to display Initiator IP in ISCSI Configuration Page when Initiator info is enabled for DHCP, find detailed description below. 1. Add an Attempt with Initiator info Enabled for DHCP 2. Save changes 3. On next reboot, Previously added ISCSI attempt will be tried and ISCSI DHCP server will assign an IP to the client (Initiator IP). 4. It is better to display Initiator IP in same attempt Page like below Ex:- Initiator IP : 192.168.0.5 // DHCP Process was success Initiator IP : 0.0.0.0 // DHCP process failed Could you please provide your comments to support this feature? Thanks, Karunakar ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] Different ISCSI behavior when 2 attempts are added
Will try with Updating to "Enabled for MPIO". Thanks for your great support, Karunakar From: Ye, Ting [mailto:ting...@intel.com] Sent: Tuesday, October 10, 2017 8:39 AM To: Wu, Jiaxin; Karunakar P; 'edk2-devel@lists.01.org' Cc: Fu, Siyuan Subject: RE: Different ISCSI behavior when 2 attempts are added Yes, I agree that it is the implementation's choice. If you need Attempt 1 in Case 2&4, try to update "Enabled" to "Enabled for MPIO". Thanks, Ting Ye From: Wu, Jiaxin Sent: Tuesday, October 10, 2017 11:01 AM To: Karunakar P <karunak...@amiindia.co.in<mailto:karunak...@amiindia.co.in>>; 'edk2-devel@lists.01.org' <edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>> Cc: Ye, Ting <ting...@intel.com<mailto:ting...@intel.com>>; Fu, Siyuan <siyuan...@intel.com<mailto:siyuan...@intel.com>> Subject: RE: Different ISCSI behavior when 2 attempts are added Hi Karunakar, I think it's not the bug according the current iSCSI implementation that the first login session will be selected while others are aborted directly. Here, IP4 is the first login session. I didn't find any state that the first attempt should be connected. Ting and Siyuan, If anything wrong, please correct me. Thanks, Jiaxin From: Karunakar P [mailto:karunak...@amiindia.co.in] Sent: Monday, October 9, 2017 10:52 PM To: 'edk2-devel@lists.01.org' <edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>> Cc: Wu, Jiaxin <jiaxin...@intel.com<mailto:jiaxin...@intel.com>>; Ye, Ting <ting...@intel.com<mailto:ting...@intel.com>>; Fu, Siyuan <siyuan...@intel.com<mailto:siyuan...@intel.com>> Subject: Re: Different ISCSI behavior when 2 attempts are added Hello All, Found the below behavior when I try for ISCSI connection with 2 Valid attempts. Case 1: Attempt 1---Enabled(ISCSI Mode)---IP4Enabled(Initiator DHCP)---Disabled(Target DHCP)--->Valid Attempt Attempt 2---Enabled(ISCSI Mode)---IP6Enabled(Initiator DHCP)---Disabled(Target DHCP)--->Valid Attempt EDK2 RESULT:- Attempt1(IP4) connected and shown in shell ,Attempt2 tried but session does not exist Case 2: Attempt 1---Enabled(ISCSI Mode)---IP6Enabled(Initiator DHCP)---Disabled(Target DHCP)--->Valid Attempt Attempt 2---Enabled(ISCSI Mode)---IP4Enabled(Initiator DHCP)---Disabled(Target DHCP)--->Valid Attempt EDK2 RESULT:- Attempt2(IP4) connected and shown in shell ,Attempt1 tried but session does not exist Case 3: Attempt 1---Enabled(ISCSI Mode)---Autoconfigure --->Valid Attempt Attempt 2---Enabled(ISCSI Mode)---IP6Enabled(Initiator DHCP)---Disabled(Target DHCP)--->Valid Attempt EDK2 RESULT:- Attempt1(IP4) connected and shown in shell ,Attempt2 tried but session does not exist Case 4: Attempt 1---Enabled(ISCSI Mode)---IP6--->Valid Attempt Attempt 2---Enabled(ISCSI Mode)---Autoconfigure Enabled(Initiator DHCP)---Disabled(Target DHCP)--->Valid Attempt EDK2 RESULT:- Attempt2(IP4) connected and shown in shell ,Attempt1 tried but session does not exist 1. Case1 & Case3 looks fine as 1st valid attempt connected 2. But Case2 & Case4 looks bit different, 1St attempt was valid but connection success with 2nd attempt 3. As we found that IScsiIp4 Driver Binding Start is getting call first and processing the IP4 attempt first even though it is 2nd attempt Could you please comment on this whether this is a bug or Not? Thanks, Karunakar ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] Different ISCSI behavior when 2 attempts are added
Hello All, Found the below behavior when I try for ISCSI connection with 2 Valid attempts. Case 1: Attempt 1---Enabled(ISCSI Mode)---IP4Enabled(Initiator DHCP)---Disabled(Target DHCP)--->Valid Attempt Attempt 2---Enabled(ISCSI Mode)---IP6Enabled(Initiator DHCP)---Disabled(Target DHCP)--->Valid Attempt EDK2 RESULT:- Attempt1(IP4) connected and shown in shell ,Attempt2 tried but session does not exist Case 2: Attempt 1---Enabled(ISCSI Mode)---IP6Enabled(Initiator DHCP)---Disabled(Target DHCP)--->Valid Attempt Attempt 2---Enabled(ISCSI Mode)---IP4Enabled(Initiator DHCP)---Disabled(Target DHCP)--->Valid Attempt EDK2 RESULT:- Attempt2(IP4) connected and shown in shell ,Attempt1 tried but session does not exist Case 3: Attempt 1---Enabled(ISCSI Mode)---Autoconfigure --->Valid Attempt Attempt 2---Enabled(ISCSI Mode)---IP6Enabled(Initiator DHCP)---Disabled(Target DHCP)--->Valid Attempt EDK2 RESULT:- Attempt1(IP4) connected and shown in shell ,Attempt2 tried but session does not exist Case 4: Attempt 1---Enabled(ISCSI Mode)---IP6--->Valid Attempt Attempt 2---Enabled(ISCSI Mode)---Autoconfigure Enabled(Initiator DHCP)---Disabled(Target DHCP)--->Valid Attempt EDK2 RESULT:- Attempt2(IP4) connected and shown in shell ,Attempt1 tried but session does not exist 1. Case1 & Case3 looks fine as 1st valid attempt connected 2. But Case2 & Case4 looks bit different, 1St attempt was valid but connection success with 2nd attempt 3. As we found that IScsiIp4 Driver Binding Start is getting call first and processing the IP4 attempt first even though it is 2nd attempt Could you please comment on this whether this is a bug or Not? Thanks, Karunakar ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] Request to display Initiator IP in ISCSI Attempt Page
Hello All, We have a requirement to display Initiator IP in ISCSI Configuration Page when Initiator info is enabled for DHCP, find detailed description below. 1. Add an Attempt with Initiator info Enabled for DHCP 2. Save changes 3. On next reboot, Previously added ISCSI attempt will be tried and ISCSI DHCP server will assign an IP to the client (Initiator IP). 4. It is better to display Initiator IP in same attempt Page like below Ex:- Initiator IP : 192.168.0.5 // DHCP Process was success Initiator IP : 0.0.0.0 // DHCP process failed Could you please provide your comments to support this feature? Thanks, Karunakar ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] Linux CentOS 7.3 can get DHCP IPv4 IP address with configuring DHCP server as per RFC3021
Hi Siyuan,
I've filled a New Bug in Bugzilla and following are the details.
https://bugzilla.tianocore.org/show_bug.cgi?id=722
Thanks,
Karunakar
From: Fu, Siyuan [mailto:siyuan...@intel.com]
Sent: Wednesday, September 27, 2017 1:46 PM
To: Karunakar P; 'edk2-devel@lists.01.org'
Cc: Wu, Jiaxin; Ye, Ting
Subject: RE: Linux CentOS 7.3 can get DHCP IPv4 IP address with configuring
DHCP server as per RFC3021
Hi, Karunakar
We haven't received requirement for this feature before so we don't have plan
now. I think you can submit a Bugzilla ticket for this feature request, we will
follow up to investigate it.
BestRegards
Fu Siyuan
From: Karunakar P [mailto:karunak...@amiindia.co.in]
Sent: Monday, September 25, 2017 4:54 PM
To: Fu, Siyuan <siyuan...@intel.com<mailto:siyuan...@intel.com>>;
'edk2-devel@lists.01.org'
<edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>>
Cc: Wu, Jiaxin <jiaxin...@intel.com<mailto:jiaxin...@intel.com>>; Ye, Ting
<ting...@intel.com<mailto:ting...@intel.com>>
Subject: RE: Linux CentOS 7.3 can get DHCP IPv4 IP address with configuring
DHCP server as per RFC3021
Hi Fu Siyuan,
Thanks for your conformation.
We would like to use /31s to save IPv4 addresses.
When it's a point-to-point link (server to router), the extra network address
and broadcast address is wasted.
RFC 3021 solves the problem by using a broadcast address of 255.255.255.255 on
such subnets.
We have a requirement to support this, do you have any plan to support RFC3021
? Given the requirement time consuming how hard to implement this ?
Thanks,
karunakar
From: Fu, Siyuan [mailto:siyuan...@intel.com]
Sent: Monday, September 25, 2017 1:28 PM
To: Karunakar P; 'edk2-devel@lists.01.org'
Cc: Wu, Jiaxin; Ye, Ting
Subject: RE: Linux CentOS 7.3 can get DHCP IPv4 IP address with configuring
DHCP server as per RFC3021
Hi, Karunakar
May I know that whether you have a real requirement that must use the
point-2-point link in your environment, or you just found this problem in your
test?
BestRegards
Fu Siyuan
From: Fu, Siyuan
Sent: Monday, September 25, 2017 3:50 PM
To: Karunakar P <karunak...@amiindia.co.in<mailto:karunak...@amiindia.co.in>>;
'edk2-devel@lists.01.org'
<edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>>
Cc: Wu, Jiaxin <jiaxin...@intel.com<mailto:jiaxin...@intel.com>>; Ye, Ting
<ting...@intel.com<mailto:ting...@intel.com>>
Subject: RE: Linux CentOS 7.3 can get DHCP IPv4 IP address with configuring
DHCP server as per RFC3021
Hi, Karunakar
You are correct that EDK2 doesn't support rfc3201.
The most obvious problem that come to my mind is the NetIp4IsUnicast() function
in NetLib, which has the assumption that the host address part should not be
all zero or all one (or to say, -1 in the rfc3201). I think that's why the PXE
failed, but Cent OS could use IP address from the same DHCP server.
This is just an example, there may be some other places in edk2 network stack
which have the same assumption, I'm not sure about this. Anyway, we never
considered the point-2-point link in edk2.
BestRegards
Fu Siyuan
From: Karunakar P [mailto:karunak...@amiindia.co.in]
Sent: Monday, September 25, 2017 3:02 PM
To: 'edk2-devel@lists.01.org'
<edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>>
Cc: Wu, Jiaxin <jiaxin...@intel.com<mailto:jiaxin...@intel.com>>; Fu, Siyuan
<siyuan...@intel.com<mailto:siyuan...@intel.com>>; Ye, Ting
<ting...@intel.com<mailto:ting...@intel.com>>
Subject: Re: Linux CentOS 7.3 can get DHCP IPv4 IP address with configuring
DHCP server as per RFC3021
Hello All,
It is known that current EDKII doesn't support RFC3021, We could see the
following behavior which is PXE boot fails whereas Cent OS can get IP address
from the same BIOS.
[Configuration Used]
DHCP server setting under Ubuntu:
1. /etc/dhcp/dhcpd.conf
# RFC3021-Using 31-bit perfixes on IPv4 Point-to-Point Links
subnet 192.168.1.0 netmask 255.255.255.254 {
range 192.168.1.1 192.168.1.1;
next-server 192.168.1.0;
filename "EFI/BOOT/BOOTAA64.EFI";
option subnet-mask 255.255.255.254;
option routers 192.168.1.0;
}
2. /etc/network/interfaces
auto eth0
iface eth0 inet static
address 192.168.1.0
netmask 255.255.255.254
network 192.168.1.0
If the DHCP server and network interface are set up above configuration. Below
are my test results and questions
1. CentOS 7.3 (pre-installed) was able to retrieve IP through DHCP when
they connect HDD to the SUT where PXE is failing.
2. Could you please suggest what could be the reason behind this?
Thanks,
karunakar
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] Linux CentOS 7.3 can get DHCP IPv4 IP address with configuring DHCP server as per RFC3021
Hi Fu Siyuan,
Thanks for your conformation.
We would like to use /31s to save IPv4 addresses.
When it's a point-to-point link (server to router), the extra network address
and broadcast address is wasted.
RFC 3021 solves the problem by using a broadcast address of 255.255.255.255 on
such subnets.
We have a requirement to support this, do you have any plan to support RFC3021
? Given the requirement time consuming how hard to implement this ?
Thanks,
karunakar
From: Fu, Siyuan [mailto:siyuan...@intel.com]
Sent: Monday, September 25, 2017 1:28 PM
To: Karunakar P; 'edk2-devel@lists.01.org'
Cc: Wu, Jiaxin; Ye, Ting
Subject: RE: Linux CentOS 7.3 can get DHCP IPv4 IP address with configuring
DHCP server as per RFC3021
Hi, Karunakar
May I know that whether you have a real requirement that must use the
point-2-point link in your environment, or you just found this problem in your
test?
BestRegards
Fu Siyuan
From: Fu, Siyuan
Sent: Monday, September 25, 2017 3:50 PM
To: Karunakar P <karunak...@amiindia.co.in<mailto:karunak...@amiindia.co.in>>;
'edk2-devel@lists.01.org'
<edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>>
Cc: Wu, Jiaxin <jiaxin...@intel.com<mailto:jiaxin...@intel.com>>; Ye, Ting
<ting...@intel.com<mailto:ting...@intel.com>>
Subject: RE: Linux CentOS 7.3 can get DHCP IPv4 IP address with configuring
DHCP server as per RFC3021
Hi, Karunakar
You are correct that EDK2 doesn't support rfc3201.
The most obvious problem that come to my mind is the NetIp4IsUnicast() function
in NetLib, which has the assumption that the host address part should not be
all zero or all one (or to say, -1 in the rfc3201). I think that's why the PXE
failed, but Cent OS could use IP address from the same DHCP server.
This is just an example, there may be some other places in edk2 network stack
which have the same assumption, I'm not sure about this. Anyway, we never
considered the point-2-point link in edk2.
BestRegards
Fu Siyuan
From: Karunakar P [mailto:karunak...@amiindia.co.in]
Sent: Monday, September 25, 2017 3:02 PM
To: 'edk2-devel@lists.01.org'
<edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>>
Cc: Wu, Jiaxin <jiaxin...@intel.com<mailto:jiaxin...@intel.com>>; Fu, Siyuan
<siyuan...@intel.com<mailto:siyuan...@intel.com>>; Ye, Ting
<ting...@intel.com<mailto:ting...@intel.com>>
Subject: Re: Linux CentOS 7.3 can get DHCP IPv4 IP address with configuring
DHCP server as per RFC3021
Hello All,
It is known that current EDKII doesn't support RFC3021, We could see the
following behavior which is PXE boot fails whereas Cent OS can get IP address
from the same BIOS.
[Configuration Used]
DHCP server setting under Ubuntu:
1. /etc/dhcp/dhcpd.conf
# RFC3021-Using 31-bit perfixes on IPv4 Point-to-Point Links
subnet 192.168.1.0 netmask 255.255.255.254 {
range 192.168.1.1 192.168.1.1;
next-server 192.168.1.0;
filename "EFI/BOOT/BOOTAA64.EFI";
option subnet-mask 255.255.255.254;
option routers 192.168.1.0;
}
2. /etc/network/interfaces
auto eth0
iface eth0 inet static
address 192.168.1.0
netmask 255.255.255.254
network 192.168.1.0
If the DHCP server and network interface are set up above configuration. Below
are my test results and questions
1. CentOS 7.3 (pre-installed) was able to retrieve IP through DHCP when
they connect HDD to the SUT where PXE is failing.
2. Could you please suggest what could be the reason behind this?
Thanks,
karunakar
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] Linux CentOS 7.3 can get DHCP IPv4 IP address with configuring DHCP server as per RFC3021
Hello All,
It is known that current EDKII doesn't support RFC3021, We could see the
following behavior which is PXE boot fails whereas Cent OS can get IP address
from the same BIOS.
[Configuration Used]
DHCP server setting under Ubuntu:
1. /etc/dhcp/dhcpd.conf
# RFC3021-Using 31-bit perfixes on IPv4 Point-to-Point Links
subnet 192.168.1.0 netmask 255.255.255.254 {
range 192.168.1.1 192.168.1.1;
next-server 192.168.1.0;
filename "EFI/BOOT/BOOTAA64.EFI";
option subnet-mask 255.255.255.254;
option routers 192.168.1.0;
}
2. /etc/network/interfaces
auto eth0
iface eth0 inet static
address 192.168.1.0
netmask 255.255.255.254
network 192.168.1.0
If the DHCP server and network interface are set up above configuration. Below
are my test results and questions
1. CentOS 7.3 (pre-installed) was able to retrieve IP through DHCP when
they connect HDD to the SUT where PXE is failing.
2. Could you please suggest what could be the reason behind this?
Thanks,
karunakar
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] Failed to clear configuration in Ip4Config2 Protocol
Hi Jiaxin,
Many thanks for your help.
After the successful HTTP boot DNS parsing, I can see the DNS Node, But it have
bit difference form UEFI2.7 spec
//../MAC(D8CB8ADEBBAA,0x0)/IPv4(0.0.0.0)/Dns(192.168.184.1)/Uri(https://www.cloudboot.com:443/EFI/Shell.efi)
//../MAC(D8CB8ADEBBAA,0x0)/IPv6(2001:0DB8::0001::::0001)/Dns(2001:0DB8::0001::::0001)/Uri(https://www.cloudbootip6.com:443/EFI/Shell.efi)
I can see Only DNS Server IP address in DNS Node i.e. Dns(192.168.184.1)
But UEFI2.7 spec says(24.7.3.1 Device Path, page 1329) like below
Dns(192.168.22.100, 192.168.22.101) for IPv4
Dns(2016::100, 2016::101 for IPv6, DNS node have DNS Server IP and some
other IP address too.
Why I'm getting this difference, is there anything wrong or I'm I missing
anything?
Thanks,
Karunakar
-Original Message-
From: Wu, Jiaxin [mailto:jiaxin...@intel.com]
Sent: Monday, September 18, 2017 10:28 AM
To: Karunakar P; 'edk2-devel@lists.01.org'; Ye, Ting
Subject: RE: [edk2] Failed to clear configuration in Ip4Config2 Protocol
Hi karunakar,
You can verify the DNS device path with HTTP boot feature. After the successful
HTTP boot DNS parsing, the device path should be like:
//../Mac(...)[/Vlan(...)][/Wi-Fi(...)]/IPv4(...)[/Dns(...)]/Uri(...).
That is recommend way for the verification.
Besides, you can also draft the App to call the DevPathFromTextDns and
DevPathToTextDns libraries for the more verification.
Thanks,
Jiaxin
> -Original Message-
> From: Karunakar P [mailto:karunak...@amiindia.co.in]
> Sent: Monday, September 18, 2017 12:22 PM
> To: Wu, Jiaxin <jiaxin...@intel.com>; 'edk2-devel@lists.01.org' de...@lists.01.org>; Ye, Ting <ting...@intel.com>
> Subject: RE: [edk2] Failed to clear configuration in Ip4Config2
> Protocol
>
> Hi Jiaxin,
>
> Thank you very much for your info, Yes it works fine for manual configuration.
>
> And also could you please provide steps to verify "Add DNS device path
> node" feature.
>
> Thanks,
> karunakar
>
> -Original Message-
> From: Wu, Jiaxin [mailto:jiaxin...@intel.com]
> Sent: Monday, September 18, 2017 7:46 AM
> To: Karunakar P; 'edk2-devel@lists.01.org'; Ye, Ting
> Subject: RE: [edk2] Failed to clear configuration in Ip4Config2
> Protocol
>
> Hi Karunakar,
>
> According the UEFI Spec, the Ip4Config2DataTypeManualAddress,
> Ip4Config2DataTypeGateway and Ip4Config2DataTypeDnsServer
> configuration data are not allowed to set via SetData() if the policy is DHCP.
> So, the clear feature is only for the manual configuration. This is
> our design purpose and also the reason why the feature is not apply to
> the Ip4Config2DataTypeInterfaceInfo/Ip4Config2DataTypePolicy.
>
> Thanks,
> Jiaxin
>
>
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf
> > Of Karunakar P
> > Sent: Friday, September 15, 2017 5:41 PM
> > To: 'edk2-devel@lists.01.org' <edk2-devel@lists.01.org>
> > Subject: Re: [edk2] Failed to clear configuration in Ip4Config2
> > Protocol
> >
> > Hello All,
> >
> > Could you please anyone provide comment on this?
> >
> > Thank you,
> > karunakar
> >
> > From: Karunakar P
> > Sent: Wednesday, September 13, 2017 7:04 PM
> > To: 'edk2-devel@lists.01.org'
> > Subject: RE: RE: Failed to clear configuration in Ip4Config2
> > Protocol
> >
> > Hello All,
> >
> > I was trying to verify the feature "Allow SetData to clear
> > configuration in Ip4Config2/Ip6Config Protocol" , But SetData
> > returns with Write Protected Error Status
> >
> > [Steps followed]
> >
> > 1. I've taken the above feature changes.
> >
> > 2. I've a UEFI test Application which call to SetData with DataSize
> > is 0 and
> > Data is NULL
> >
> > Status = Ip4Cfg2->SetData (
> >
> > Ip4Cfg2,
> >
> > Ip4Config2DataTypeManualAddress,
> >
> > 0,
> >
> > 0
> >
> > );
> >
> > 3. But SetData returns with Write Protected Error Status//
> > Status =
> > Write Protected
> >
> > 4.Faced the same error for setting Gateway & DnsServer
> >
> > Guess the return is happening from
> > Ip4Config2SetManualAddress() ->
> > ...
> > if (Instance->Policy != Ip4Config2PolicyStatic) {
> > return EFI_WRITE_PROTECTED;
> > }
> > ...
> >
> > Could you please help on this whether am I missing any
Re: [edk2] Failed to clear configuration in Ip4Config2 Protocol
Hi Jiaxin,
Thank you very much for your info, Yes it works fine for manual configuration.
And also could you please provide steps to verify "Add DNS device path node"
feature.
Thanks,
karunakar
-Original Message-
From: Wu, Jiaxin [mailto:jiaxin...@intel.com]
Sent: Monday, September 18, 2017 7:46 AM
To: Karunakar P; 'edk2-devel@lists.01.org'; Ye, Ting
Subject: RE: [edk2] Failed to clear configuration in Ip4Config2 Protocol
Hi Karunakar,
According the UEFI Spec, the Ip4Config2DataTypeManualAddress,
Ip4Config2DataTypeGateway and Ip4Config2DataTypeDnsServer configuration data
are not allowed to set via SetData() if the policy is DHCP. So, the clear
feature is only for the manual configuration. This is our design purpose and
also the reason why the feature is not apply to the
Ip4Config2DataTypeInterfaceInfo/Ip4Config2DataTypePolicy.
Thanks,
Jiaxin
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Karunakar P
> Sent: Friday, September 15, 2017 5:41 PM
> To: 'edk2-devel@lists.01.org' <edk2-devel@lists.01.org>
> Subject: Re: [edk2] Failed to clear configuration in Ip4Config2
> Protocol
>
> Hello All,
>
> Could you please anyone provide comment on this?
>
> Thank you,
> karunakar
>
> From: Karunakar P
> Sent: Wednesday, September 13, 2017 7:04 PM
> To: 'edk2-devel@lists.01.org'
> Subject: RE: RE: Failed to clear configuration in Ip4Config2 Protocol
>
> Hello All,
>
> I was trying to verify the feature "Allow SetData to clear
> configuration in Ip4Config2/Ip6Config Protocol" , But SetData returns
> with Write Protected Error Status
>
> [Steps followed]
>
> 1. I've taken the above feature changes.
>
> 2. I've a UEFI test Application which call to SetData with DataSize is
> 0 and
> Data is NULL
>
> Status = Ip4Cfg2->SetData (
>
> Ip4Cfg2,
>
> Ip4Config2DataTypeManualAddress,
>
> 0,
>
> 0
>
> );
>
> 3. But SetData returns with Write Protected Error Status//
> Status =
> Write Protected
>
> 4.Faced the same error for setting Gateway & DnsServer
>
> Guess the return is happening from
> Ip4Config2SetManualAddress() ->
> ...
> if (Instance->Policy != Ip4Config2PolicyStatic) {
> return EFI_WRITE_PROTECTED;
> }
> ...
>
> Could you please help on this whether am I missing anything or
> anything else need to be done to resolve this?
>
> Thanks,
> karunakar
>
>
> From: Karunakar P
> Sent: Wednesday, September 13, 2017 7:00 PM
> To: edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> Subject: RE: Failed to clear configuration in Ip4Config2 Protocol
>
> Hello All,
>
> I was trying to verify the feature "Allow SetData to clear
> configuration in Ip4Config2/Ip6Config Protocol" , But SetData returns
> with Write Protected Error Status
>
> [Steps followed]
>
> 1. I've taken the above feature changes.
>
> 2. I've a UEFI test Application which call to SetData with DataSize is
> 0 and
> Data is NULL
>
> Status = Ip4Cfg2->SetData (
>
> Ip4Cfg2,
>
> Ip4Config2DataTypeManualAddress,
>
> 0,
>
> 0
>
> );
>
> 3. But SetData returns with Write Protected Error Status//
> Status =
> Write Protected
>
> 4.Faced the same error for setting Gateway
>
> Guess the error is happening from
>
>
> Thanks,
> karunakar
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] Check Ipv6 Support for ISCSI attempt page
Hi Ting Ye, Thanks for your reply. [Here the bug details] Bug 710 - IPv6 support condition check for HTTP and ISCSI https://bugzilla.tianocore.org/show_bug.cgi?id=710 Thanks, karunakar -Original Message- From: Ye, Ting [mailto:ting...@intel.com] Sent: Monday, September 18, 2017 8:23 AM To: Karunakar P; 'edk2-devel@lists.01.org' Subject: RE: [edk2] Check Ipv6 Support for ISCSI attempt page Hi Karunakar, Thanks for capturing this. We agree that it's reasonable to add similar check to HTTP and ISCSI. Could you please help to file a bugzilla tracker for this? Thanks, Ting Ye -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Karunakar P Sent: Friday, September 15, 2017 5:37 PM To: 'edk2-devel@lists.01.org' <edk2-devel@lists.01.org> Subject: Re: [edk2] Check Ipv6 Support for ISCSI attempt page Hello all, We have a Broadcom NIC card which doesn't support IPv6 (Ipv6Supported flag is 0). 1) But the HTTPv6 boot options are shown. Unlike in PXE (PxeBcCheckIpv6Support()), the HTTP drivers in edk2 do not have a condition check whether the card supports IPv6 or not. 2) If the card doesn't support IPv6, then for ISCSI attempt page also, Internet Protocol should suppress IPv6 Could you please provide your comments on this? Thank you Karunakar ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] Failed to clear configuration in Ip4Config2 Protocol
Hello All,
Could you please anyone provide comment on this?
Thank you,
karunakar
From: Karunakar P
Sent: Wednesday, September 13, 2017 7:04 PM
To: 'edk2-devel@lists.01.org'
Subject: RE: RE: Failed to clear configuration in Ip4Config2 Protocol
Hello All,
I was trying to verify the feature "Allow SetData to clear configuration in
Ip4Config2/Ip6Config Protocol" , But SetData returns with Write Protected Error
Status
[Steps followed]
1. I've taken the above feature changes.
2. I've a UEFI test Application which call to SetData with DataSize is 0
and Data is NULL
Status = Ip4Cfg2->SetData (
Ip4Cfg2,
Ip4Config2DataTypeManualAddress,
0,
0
);
3. But SetData returns with Write Protected Error Status// Status
= Write Protected
4.Faced the same error for setting Gateway & DnsServer
Guess the return is happening from
Ip4Config2SetManualAddress() ->
...
if (Instance->Policy != Ip4Config2PolicyStatic) {
return EFI_WRITE_PROTECTED;
}
...
Could you please help on this whether am I missing anything or anything else
need to be done to resolve this?
Thanks,
karunakar
From: Karunakar P
Sent: Wednesday, September 13, 2017 7:00 PM
To: edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
Subject: RE: Failed to clear configuration in Ip4Config2 Protocol
Hello All,
I was trying to verify the feature "Allow SetData to clear configuration in
Ip4Config2/Ip6Config Protocol" , But SetData returns with Write Protected Error
Status
[Steps followed]
1. I've taken the above feature changes.
2. I've a UEFI test Application which call to SetData with DataSize is 0
and Data is NULL
Status = Ip4Cfg2->SetData (
Ip4Cfg2,
Ip4Config2DataTypeManualAddress,
0,
0
);
3. But SetData returns with Write Protected Error Status// Status
= Write Protected
4.Faced the same error for setting Gateway
Guess the error is happening from
Thanks,
karunakar
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] Check Ipv6 Support for ISCSI attempt page
Hello all, We have a Broadcom NIC card which doesn't support IPv6 (Ipv6Supported flag is 0). 1) But the HTTPv6 boot options are shown. Unlike in PXE (PxeBcCheckIpv6Support()), the HTTP drivers in edk2 do not have a condition check whether the card supports IPv6 or not. 2) If the card doesn't support IPv6, then for ISCSI attempt page also, Internet Protocol should suppress IPv6 Could you please provide your comments on this? Thank you Karunakar ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] Failed to clear configuration in Ip4Config2 Protocol
Hello All,
I was trying to verify the feature "Allow SetData to clear configuration in
Ip4Config2/Ip6Config Protocol" , But SetData returns with Write Protected Error
Status
[Steps followed]
1. I've taken the above feature changes.
2. I've a UEFI test Application which call to SetData with DataSize is 0
and Data is NULL
Status = Ip4Cfg2->SetData (
Ip4Cfg2,
Ip4Config2DataTypeManualAddress,
0,
0
);
3. But SetData returns with Write Protected Error Status// Status
= Write Protected
4.Faced the same error for setting Gateway & DnsServer
Guess the return is happening from
Ip4Config2SetManualAddress() ->
...
if (Instance->Policy != Ip4Config2PolicyStatic) {
return EFI_WRITE_PROTECTED;
}
...
Could you please help on this whether am I missing anything or anything else
need to be done to resolve this?
Thanks,
karunakar
From: Karunakar P
Sent: Wednesday, September 13, 2017 7:00 PM
To: edk2-devel@lists.01.org
Subject: RE: Failed to clear configuration in Ip4Config2 Protocol
Hello All,
I was trying to verify the feature "Allow SetData to clear configuration in
Ip4Config2/Ip6Config Protocol" , But SetData returns with Write Protected Error
Status
[Steps followed]
1. I've taken the above feature changes.
2. I've a UEFI test Application which call to SetData with DataSize is 0
and Data is NULL
Status = Ip4Cfg2->SetData (
Ip4Cfg2,
Ip4Config2DataTypeManualAddress,
0,
0
);
3. But SetData returns with Write Protected Error Status// Status
= Write Protected
4.Faced the same error for setting Gateway
Guess the error is happening from
Thanks,
karunakar
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] Failed to clear configuration in Ip4Config2 Protocol
Hello All, I was trying to verify the feature "Allow SetData to clear configuration in Ip4Config2/Ip6Config Protocol" , But SetData returns with Write Protected Error Status [Steps followed] 1. I've taken the above feature changes. 2. I've a UEFI test Application which call to SetData with DataSize is 0 and Data is NULL Status = Ip4Cfg2->SetData ( Ip4Cfg2, Ip4Config2DataTypeManualAddress, 0, 0 ); 3. But SetData returns with Write Protected Error Status// Status = Write Protected 4.Faced the same error for setting Gateway Guess the error is happening from Thanks, karunakar ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] Question on Iscsi Behavior
Hi Ting Ye, Thank you very much for your info. Thanks, karunakar -Original Message- From: Ye, Ting [mailto:ting...@intel.com] Sent: Tuesday, September 12, 2017 1:49 PM To: Karunakar P; edk2-devel@lists.01.org Subject: RE: [edk2] Question on Iscsi Behavior Hi Karunakar, In "Enabled" mode, only connected attempts will be recorded in iBFT while in "Enabled for MPIO", all configured attempts will be recorded in iBFT. In "Enabled for MPIO" mode, the first configured attempt (according to attempt order displayed) is preferred. If the first attempt is valid it will not connect other attempts. While in "Enabled" mode, all configured attempts will be tried. Thanks, Ting Ye -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Karunakar P Sent: Monday, September 11, 2017 6:38 PM To: edk2-devel@lists.01.org Subject: Re: [edk2] Question on Iscsi Behavior Hello All, Could you please help in clarifying below question on ISCSI behavior. 2 ISCSI Attempts are added with different configuration Case 1: Attempt 1--Enabled(ISCSI Mode)--IP4-DHCP ---> In Valid Attempt (In Valid Target Details) Attempt 2--Enabled(ISCSI Mode)--IP4-DHCP ---> Valid Attempt Result:- -> Initiator IP Assigned for Attempt1 and Attempt2(2 times DHCP process ->done) ISCSI connection success with Attempt2 and same Details was ->found in Shell Case 2: Attempt 1--Enabled for MPIO(ISCSI Mode)--IP4-DHCP ---> In Valid Attempt (In Valid Target Details) Attempt 2--Enabled for MPIO(ISCSI Mode)--IP4-DHCP ---> Valid Attempt Result:- -> Initiator IP Assigned for Attempt1 and Attempt2(2 times DHCP process ->done) ISCSI connection success with Attempt2 and same Details was ->found in Shell Note: Same behavior seen with adding attempts for 2 different MAC addresses 1.What is the difference between ISCSI Mode Enable & Enabled for MPIO ? Because irrespective of ISCSI Mode, Attempt2 will be processed if Attempt1 is In Valid Thanks, karunakar ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] Question on Iscsi Behavior
Hello All, Could you please help in clarifying below question on ISCSI behavior. 2 ISCSI Attempts are added with different configuration Case 1: Attempt 1--Enabled(ISCSI Mode)--IP4-DHCP ---> In Valid Attempt (In Valid Target Details) Attempt 2--Enabled(ISCSI Mode)--IP4-DHCP ---> Valid Attempt Result:- -> Initiator IP Assigned for Attempt1 and Attempt2(2 times DHCP process done) ->ISCSI connection success with Attempt2 and same Details was found in Shell Case 2: Attempt 1--Enabled for MPIO(ISCSI Mode)--IP4-DHCP ---> In Valid Attempt (In Valid Target Details) Attempt 2--Enabled for MPIO(ISCSI Mode)--IP4-DHCP ---> Valid Attempt Result:- -> Initiator IP Assigned for Attempt1 and Attempt2(2 times DHCP process done) ->ISCSI connection success with Attempt2 and same Details was found in Shell Note: Same behavior seen with adding attempts for 2 different MAC addresses 1.What is the difference between ISCSI Mode Enable & Enabled for MPIO ? Because irrespective of ISCSI Mode, Attempt2 will be processed if Attempt1 is In Valid Thanks, karunakar ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] Iscsi Specification Document
Hello All, Do we have any specific Document for Iscsi? Any document that describes the standard iscsi behavior. Thanks, karunakar ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] SCT Test failed
Hi All, SCT GenericTest failed NetworkPkg. SCT version used:- UEFI2.5A_SCT_II_Release\UEFISCT\SctPackageX64 [Following are the test results] GenericTest\EFICompliantTest 5.22.1.2.5 0 0 98551AE7-5020-4DDD-861A-CFFFB4D60382 FAIL EFI Compliant - PXE_BC protocols and one of UNDI/SNP/MNP must be implemented if a platform supports to boot from a network device. x:\uefi-sct\SctPkg\TestCase\UEFI\EFI\Generic\EfiCompliant\BlackBoxTest\EfiCompliantBBTestPlatform_uefi.c:1428:SetupMode equal zero - No 0x00010001 A0A8BED3-3D6F-4AD8-907A-84D52EE1543B No device path PlatformSpecificElements_0_0_A0A8BED3-3D6F-4AD8-907A-84D52EE1543B.log GenericTest\EFICompliantTest 5.22.1.2.23 0 0 CB6F7B77-0B15-43F7-A95B-8C7F9FD70B21 FAILUEFI-Compliant - EFI_TLS_PROTOCOL, EFI_TLS_SERVICE_BINDING_PROTOCOL, EFI_TLS_CONFIGURATION_PROTOCOL must be existed if the platform supports TLS feature. x:\uefi-sct\SctPkg\TestCase\UEFI\EFI\Generic\EfiCompliant\BlackBoxTest\EfiCompliantBBTestPlatform_uefi.c:3261:TLSSB-Y, TLSConfig-N 0x00010001 A0A8BED3-3D6F-4AD8-907A-84D52EE1543B No device path PlatformSpecificElements_0_0_A0A8BED3-3D6F-4AD8-907A-84D52EE1543B.log Note: Along with above two failures some other failures also present. Please let us know the details if fix is already present for this failures. Please look into it and provide your comments/suggestions. Thanks, karunakar ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] HTTP Boot failed to download NBP file if it is .iso type
Hi All, Verified that BDS has been updated to support HTTP RAM disk boot. And able to download SUSE iso (>3 GB) from the HTTP server. But the install stops in middle. I've checked SUSE iso image could support RAM disk boot or NOT with below steps 1. Go to "RAM Disk Configuration" form setup browser. 2. Change the disk memory type to "Reserved" 3. Choose "Create from file" and select the SUSE iso image from a local USB disk. 4. After the RAM disk is created, go back to the boot manager, select the new created RAM disk device to boot from it. When I tries to boot from it, installation stops in middle. Note: Tried with SLE-12-SP2-Server-DVD-x86_64-GM-DVD1.iso If there anything else I've missed please let me know. Could you please help which ISO images supports this RAM Disk boot? Have you verified HTTP boot with any iso image? Thanks, karunakar -Original Message- From: Fu, Siyuan [mailto:siyuan...@intel.com] Sent: Wednesday, June 14, 2017 11:34 AM To: Santhapur Naveen; Karunakar P; edk2-devel@lists.01.org Subject: RE: HTTP Boot failed to download NBP file if it is .iso type Hi, Naveen First let's kick out the HTTP and check whether your SUSE iso image could support RAM disk boot: 1. Go to "RAM Disk Configuration" form in your setup browser. 2. Change the disk memory type to "Reserved" 3. Choose "Create from file" and select the SUSE iso image from a local harddisk or USB disk. 4. After the RAM disk is created, go back to the boot manager, select the new created RAM disk device to boot from it. If your SUSE iso image could boot in above way, please check whether your BDS has been updated to support HTTP RAM disk boot. Best Regards, Siyuan > -Original Message- > From: Santhapur Naveen [mailto:nave...@amiindia.co.in] > Sent: Tuesday, June 13, 2017 5:32 PM > To: Fu, Siyuan <siyuan...@intel.com>; Karunakar P > <karunak...@amiindia.co.in>; edk2-devel@lists.01.org > Subject: RE: HTTP Boot failed to download NBP file if it is .iso type > > Hi Siyuan, > > Thank you for your reply. > And regarding the OS installation, we are able to download SUSE iso > (>3 GB) from the HTTP server. But the install didn't happen. > May I ask you what could be possible reason? Is there anything else > I've had missed, please let me know. > > Regards, > Naveen > > -----Original Message- > From: Fu, Siyuan [mailto:siyuan...@intel.com] > Sent: Tuesday, June 13, 2017 8:17 AM > To: Santhapur Naveen; Karunakar P; edk2-devel@lists.01.org > Subject: RE: HTTP Boot failed to download NBP file if it is .iso type > > Hi, Karunakar and Naveen > > Status 0023 is EFI_HTTP_ERROR, which means the HTTP server replied > an HTTP error. The HTTP error code is placed in > HttpIo->RspToken.Message- > >Data.Response->StatusCode, and will be displayed in > HttpBootPrintErrorMessage() function. > > If a downloaded NBP is a RAM disk image, the BDS will try to find a > boot file inside it according UEFI 2.7 section 3.5.1 "Boot via the > Simple File Protocol". > > Best Regards, > Siyuan > > > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Santhapur Naveen > Sent: Saturday, June 10, 2017 1:49 AM > To: Karunakar P; edk2-devel@lists.01.org > Subject: Re: [edk2] HTTP Boot failed to download NBP file if it is > .iso type > > Even if we are able to download an ISO file successfully, how will > EFI_RAM_DISK_PROTOCOL comes to know what is the efi that needs to be used? > > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Karunakar P > Sent: Friday, June 09, 2017 9:04 PM > To: edk2-devel@lists.01.org > Subject: [edk2] HTTP Boot failed to download NBP file if it is .iso > type > > Hi All, > > We have facing an issue with HTTP boot. > > [Issue] > HTTP Boot failed to download NBP file if it is an .iso type > > [Reproduction Steps] > > 1. Configure HTTP Server in Ubuntu environment. > > 2. Place any iso image as NBP file. > > 3. Perform UEFI HTTPv4 boot. > > [Result] > DHCP process was success, But Failed to download NBP file. > > [Observations] > > 1. As per UEFI spec "23.7.1 Boot from URL" (UEFI 2.6, page 1222). > > Here is what the section says about binary image returned by HTTP server: > > "...the binary image [..] is a UEFI-formatted executable[...], or it > could be mounted as a RAM disk which contains a UEFI-compliant file > system (see Section 12.3)." > > We're interested in exploring second scenario, when downloaded image > is
[edk2] HTTP Boot failed to download NBP file if it is .iso type
Hi All,
We have facing an issue with HTTP boot.
[Issue]
HTTP Boot failed to download NBP file if it is an .iso type
[Reproduction Steps]
1. Configure HTTP Server in Ubuntu environment.
2. Place any iso image as NBP file.
3. Perform UEFI HTTPv4 boot.
[Result]
DHCP process was success, But Failed to download NBP file.
[Observations]
1. As per UEFI spec "23.7.1 Boot from URL" (UEFI 2.6, page 1222).
Here is what the section says about binary image returned by HTTP server:
"...the binary image [..] is a UEFI-formatted executable[...], or it could be
mounted as a RAM disk which contains a UEFI-compliant file system (see Section
12.3)."
We're interested in exploring second scenario, when downloaded image is a
UEFI-compliant file system.
Section "23.7.3.1 Device Path" on page 1226 provides examples of image URL:
http://192.168.1.100/boot.iso
The specification also says that "the HTTP Boot driver will register RAM disk
with the downloaded NBP, by appending a RamDisk device node to the device path
above, like...".
HttpBootDxe is doing this.But NBP file itself failing to download in the case
of iso image.
2. HTTP boot fails in the following function
HttpBootGetBootFile() ->
EFI_STATUS
HttpBootGetBootFile (
IN HTTP_BOOT_PRIVATE_DATA *Private,
IN BOOLEAN HeaderOnly,
IN OUT UINTN*BufferSize,
OUT UINT8*Buffer,
OUT HTTP_BOOT_IMAGE_TYPE *ImageType
)
{
.
.
.
Status = HttpIoRecvResponse (
>HttpIo,
TRUE,
ResponseData
);
// Here the Status value is Success and ResponseData->Status = 0023
if (EFI_ERROR (Status) || EFI_ERROR (ResponseData->Status)) {
if (EFI_ERROR (ResponseData->Status)) {
StatusCode = HttpIo->RspToken.Message->Data.Response->StatusCode;
HttpBootPrintErrorMessage (StatusCode);
Status = ResponseData->Status;
// Here Status = 0023
}
goto ERROR_5;// goto ERROR_5
}
.
.
.
}
Note:
We have HTTP server configured in Ubuntu Environment.
Could you please look into it.
Thanks,
karunakar
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] Pressing ESC from "PXE windows Boot manager" causes ASSERT
Hi Jiaxin, Please find below details regards Server Configuration I have configured DHCP and WDS server on same machine (Windows Server 2012 R2) Server IP: 192.168.0.1 1. Configured Active Directory Domain Services, DHCP , WDS services 2. DHCPv4 Configuration Address Pool :- 192.168.0.2 - 192.168.0.50 Scope Options:- Option Name Value - 006 DNS server 192.168.0.1 060 PXE Client PXEClient 3. WDS Configuration DHCP Properties Check both of the following check boxes 1. Do not listen on DHCP ports 2. Configure DHCP options to indicate that this is also a PXE Server In WDS Server, added boot.wim and install.wim images of same server. As you know, Once we configure WDS and added boot.wim and install.wim images to WDS server, bootmgfw.efi and wdsmgfw.efi files will be added to C:\RemoteInstall\Boot\x64 I also tried with PXE server configured in Windows Server 2008 R2. ASSERT happens at the same place Following are the debug messages // DEBUG message printed before StartImage() // StartImage() called wdsmgfw.Entry(10001000) Press ENTER for network boot service. ConvertPages: Incompatible memory types bootmgfw.Entry(8510C000) Windows Boot Manager (Server IP: 192.168.000.001) Choose an operating system to start: (Use the arrow keys to highlight your choice, then press ENTER.) WinServer2008_boot.wim To specify an advanced option for this choice, press F8. ENTER=Choose ESC=Exit WinServer2008_boot.wim> To specify an advanced option for this choice, press F8. ASSERT d:\ProjectPath\MdeModulePkg\Core\Dxe\Mem\Pool.c(561): CR has Bad Signature Yeah you are correct with above debug messages, It seems that issue is happening inside bootmgfw Thanks, karunakar -Original Message- From: Wu, Jiaxin [mailto:jiaxin...@intel.com] Sent: Thursday, May 25, 2017 4:07 PM To: Karunakar P; af...@apple.com; edk2-devel@lists.01.org Cc: Ye, Ting; Fu, Siyuan Subject: RE: [edk2] Pressing ESC from "PXE windows Boot manager" causes ASSERT Karunakar, Can you share us the detailed DHCP and WDS configuration? E.g. DHCP options / WDS Properties (DHCP). As you know, the different DHCP/WDS configuration may lead to the different PXE download process/behavior. We would like to reproduce the issue first. >From your below debug messages, the issue seems to be triggered by >bootmgfw.Entry. Thanks, Jiaxin > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Karunakar P > Sent: Thursday, May 25, 2017 2:38 PM > To: af...@apple.com; edk2-devel@lists.01.org > Cc: Ye, Ting <ting...@intel.com> > Subject: Re: [edk2] Pressing ESC from "PXE windows Boot manager" > causes ASSERT > > Hello All, > > I've added some traces to narrow down the issue. > > Once the NBP file downloaded, control will be given to it. > I've added some traces before StartImage() and after StartImage() call. > > Following are the debug messages > > // DEBUG message printed before StartImage() // StartImage() called > wdsmgfw.Entry(100061C0) > WDS Boot Manager version 0800 > Client IP: 192.168.0.6 > Server IP: 192.168.0.1 > Server Name: WIN-8PL637590SS > Press ENTER for network boot service. > Windows Deployment Services (Server IP: 192.168.0.1) Contacting Server > (192.168.0.1): > ESC=Exit -ConvertPages: Incompatible memory types > bootmgfw.Entry(849FE1C0) > ASSERT d:\PathtoProject\MdeModulePkg\Core\Dxe\Mem\Pool.c(561): CR has > Bad Signature > > It might be Boot Loader Issue, As control is NOT coming back. > > Could you please help on this. > > Thanks, > karunakar > > -Original Message- > From: af...@apple.com [mailto:af...@apple.com] > Sent: Wednesday, May 24, 2017 8:39 PM > To: Karunakar P > Cc: Ye, Ting; edk2-devel@lists.01.org > Subject: Re: [edk2] Pressing ESC from "PXE windows Boot manager" > causes ASSERT > > Karunakar, > > Every Pool allocation has a header and a tail data structure that is > outside of the user visible data. Both these structures have > signatures. The ASSERT you are seeing is a bad signature in the header so > that looks like a buffer underflow. > It could also be a use after free bug. > > Head: > POOL_HEAD > Buffer: > User Data > Tail: > POOL_TAIL > > Given the checks only happen on Free it is possible it could be a > buffer overflow on a buffer that has not yet been freed that runs into this > buffer. > > If you have a debugger dumping the memory before and after the buffer > can some times be useful. The pattern might give you some clues. > > Thanks, > > Andrew Fish > > > O
Re: [edk2] Pressing ESC from "PXE windows Boot manager" causes ASSERT
Hello All,
I've added some traces to narrow down the issue.
Once the NBP file downloaded, control will be given to it.
I've added some traces before StartImage() and after StartImage() call.
Following are the debug messages
// DEBUG message printed before StartImage()
// StartImage() called
wdsmgfw.Entry(100061C0)
WDS Boot Manager version 0800
Client IP: 192.168.0.6
Server IP: 192.168.0.1
Server Name: WIN-8PL637590SS
Press ENTER for network boot service.
Windows Deployment Services (Server IP: 192.168.0.1)
Contacting Server (192.168.0.1):
ESC=Exit -ConvertPages: Incompatible memory types
bootmgfw.Entry(849FE1C0)
ASSERT d:\PathtoProject\MdeModulePkg\Core\Dxe\Mem\Pool.c(561): CR has Bad
Signature
It might be Boot Loader Issue, As control is NOT coming back.
Could you please help on this.
Thanks,
karunakar
-Original Message-
From: af...@apple.com [mailto:af...@apple.com]
Sent: Wednesday, May 24, 2017 8:39 PM
To: Karunakar P
Cc: Ye, Ting; edk2-devel@lists.01.org
Subject: Re: [edk2] Pressing ESC from "PXE windows Boot manager" causes ASSERT
Karunakar,
Every Pool allocation has a header and a tail data structure that is outside of
the user visible data. Both these structures have signatures. The ASSERT you
are seeing is a bad signature in the header so that looks like a buffer
underflow. It could also be a use after free bug.
Head:
POOL_HEAD
Buffer:
User Data
Tail:
POOL_TAIL
Given the checks only happen on Free it is possible it could be a buffer
overflow on a buffer that has not yet been freed that runs into this buffer.
If you have a debugger dumping the memory before and after the buffer can some
times be useful. The pattern might give you some clues.
Thanks,
Andrew Fish
> On May 23, 2017, at 10:16 PM, Karunakar P <karunak...@amiindia.co.in> wrote:
>
> Hello All,
>
> The ASSERT happens in the following function
>
> /**
> Internal function to free a pool entry.
> Caller must have the memory lock held
>
> @param Buffer The allocated pool entry to free
> @param PoolType Pointer to pool type
>
> @retval EFI_INVALID_PARAMETER Buffer not valid
> @retval EFI_SUCCESSBuffer successfully freed.
>
> **/
> EFI_STATUS
> CoreFreePoolI (
> IN VOID *Buffer,
> OUT EFI_MEMORY_TYPE *PoolType OPTIONAL
> )
> {
> .
> .
> ASSERT(Buffer != NULL);
> //
> // Get the head & tail of the pool entry //
> Head = CR (Buffer, POOL_HEAD, Data, POOL_HEAD_SIGNATURE);// ASSERT
> happens here
> ASSERT(Head != NULL);
> .
> .
> }
>
> We are using NetworkPkg: SHA- ef810bc807188224a752ffbcf5e7f4b651291cee
>
> I think here I'm unable attach the files.
> You can find the attached screenshots in the following Bug571
> https://bugzilla.tianocore.org/show_bug.cgi?id=571
>
> Thanks,
> Karunakar
>
>
> -Original Message-
> From: Ye, Ting [mailto:ting...@intel.com]
> Sent: Wednesday, May 24, 2017 10:29 AM
> To: Karunakar P; edk2-devel@lists.01.org
> Subject: RE: Pressing ESC from "PXE windows Boot manager" causes
> ASSERT
>
> Hi Karunakar,
>
> Sorry I did not find your attached files. Would you please send them again?
> Besides that, do you mind telling us which code base are you using for PXE
> boot? Are you using some revision of EDKII main trunk or UDK release?
>
> Thanks,
> Ting
>
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Karunakar P
> Sent: Wednesday, May 24, 2017 12:20 PM
> To: edk2-devel@lists.01.org
> Subject: [edk2] Pressing ESC from "PXE windows Boot manager" causes
> ASSERT
>
> Hi All,
>
> We have facing an issue with PXE boot.
> [Issue]
> When ESC is pressed from Windows Boot manager during PXE boot (IPv4 or
> IPv6) system Hangs with following ASSERT
>
> ASSERT [DxeCore] \MdeModulePkg\Core\Dxe\Mem\Pool.c : CR has Bad
> Signature
>
> [Reproduction Steps]
> 1. Perform UEFI PXEv4 or UEFI PXEv6 boot 2. It will start PXE boot over
> IPv4/6 and Downloads NBP file successfully.
> Attached the Screenshot for the same(ScreenShot1.jpg)
>
> It will Displays the info like "Press ENTER for network boot service"
> Attached Screensho(ScreenShot2.jpg)
>
> 3. Press ENTER and then press ESC immediately to see the Windows Boot Manager
> Menu
> It will list the available Operating Systems
> Attached the screenshot(ScreenShot3.png)
>
> 4. Press ESC to come back to Setup or next Boot option
>
> [Result]
> System hangs with ASSERT
>
> [Expected Result]
> On pressing ESC from Windows Boot Manager, it should come back to
> setup/Next boot option in boot order
>
> Note:
> We have PXE server con
Re: [edk2] Pressing ESC from "PXE windows Boot manager" causes ASSERT
Hello All,
The ASSERT happens in the following function
/**
Internal function to free a pool entry.
Caller must have the memory lock held
@param Buffer The allocated pool entry to free
@param PoolType Pointer to pool type
@retval EFI_INVALID_PARAMETER Buffer not valid
@retval EFI_SUCCESSBuffer successfully freed.
**/
EFI_STATUS
CoreFreePoolI (
IN VOID *Buffer,
OUT EFI_MEMORY_TYPE *PoolType OPTIONAL
)
{
.
.
ASSERT(Buffer != NULL);
//
// Get the head & tail of the pool entry
//
Head = CR (Buffer, POOL_HEAD, Data, POOL_HEAD_SIGNATURE); // ASSERT
happens here
ASSERT(Head != NULL);
.
.
}
We are using NetworkPkg: SHA- ef810bc807188224a752ffbcf5e7f4b651291cee
I think here I'm unable attach the files.
You can find the attached screenshots in the following Bug571
https://bugzilla.tianocore.org/show_bug.cgi?id=571
Thanks,
Karunakar
-Original Message-
From: Ye, Ting [mailto:ting...@intel.com]
Sent: Wednesday, May 24, 2017 10:29 AM
To: Karunakar P; edk2-devel@lists.01.org
Subject: RE: Pressing ESC from "PXE windows Boot manager" causes ASSERT
Hi Karunakar,
Sorry I did not find your attached files. Would you please send them again?
Besides that, do you mind telling us which code base are you using for PXE
boot? Are you using some revision of EDKII main trunk or UDK release?
Thanks,
Ting
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
Karunakar P
Sent: Wednesday, May 24, 2017 12:20 PM
To: edk2-devel@lists.01.org
Subject: [edk2] Pressing ESC from "PXE windows Boot manager" causes ASSERT
Hi All,
We have facing an issue with PXE boot.
[Issue]
When ESC is pressed from Windows Boot manager during PXE boot (IPv4 or IPv6)
system Hangs with following ASSERT
ASSERT [DxeCore] \MdeModulePkg\Core\Dxe\Mem\Pool.c : CR has Bad Signature
[Reproduction Steps]
1. Perform UEFI PXEv4 or UEFI PXEv6 boot 2. It will start PXE boot over IPv4/6
and Downloads NBP file successfully.
Attached the Screenshot for the same(ScreenShot1.jpg)
It will Displays the info like "Press ENTER for network boot service"
Attached Screensho(ScreenShot2.jpg)
3. Press ENTER and then press ESC immediately to see the Windows Boot Manager
Menu
It will list the available Operating Systems
Attached the screenshot(ScreenShot3.png)
4. Press ESC to come back to Setup or next Boot option
[Result]
System hangs with ASSERT
[Expected Result]
On pressing ESC from Windows Boot Manager, it should come back to setup/Next
boot option in boot order
Note:
We have PXE server configured in Windows Server 2012 R2.
Please look into it.
Thanks,
karunakar
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] Pressing ESC from "PXE windows Boot manager" causes ASSERT
Hi All, We have facing an issue with PXE boot. [Issue] When ESC is pressed from Windows Boot manager during PXE boot (IPv4 or IPv6) system Hangs with following ASSERT ASSERT [DxeCore] \MdeModulePkg\Core\Dxe\Mem\Pool.c : CR has Bad Signature [Reproduction Steps] 1. Perform UEFI PXEv4 or UEFI PXEv6 boot 2. It will start PXE boot over IPv4/6 and Downloads NBP file successfully. Attached the Screenshot for the same(ScreenShot1.jpg) It will Displays the info like "Press ENTER for network boot service" Attached Screensho(ScreenShot2.jpg) 3. Press ENTER and then press ESC immediately to see the Windows Boot Manager Menu It will list the available Operating Systems Attached the screenshot(ScreenShot3.png) 4. Press ESC to come back to Setup or next Boot option [Result] System hangs with ASSERT [Expected Result] On pressing ESC from Windows Boot Manager, it should come back to setup/Next boot option in boot order Note: We have PXE server configured in Windows Server 2012 R2. Please look into it. Thanks, karunakar ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] HTTPBoot server setup in Home Environment
Hello all,
I have a question on verifying the HTTPBoot in Home Environment which is "Do I
need to have a DHCP server configured to serve HTTPClient?"
My typical dhcp configuration for HTTPBoot is as follows
default-lease-time 600;
max-lease-time 7200;
allow booting;
option domain-name " MyBootSource.com ";
option domain-name-servers 192.168.x.y;
option vendor-class-identifier "HTTPClient";
option bootfile-name
"http://www.MyBootSource.com/SourceFolder/FileName.ext;;
subnet 192.168.x.0 netmask 255.255.255.0 {
range 192.168.x.yy 192.168.x.zz;
}
With the above configuration, the HTTPBoot works in a normal environment.
Also I have tried commenting the "option bootfile-name ..." and I see that the
Discover and Offer packets are exchanged but the Request is not coming from
client.
If I want to make the HTTPBoot work in home environment, then what changes
should I make to my dhcp configuration ?
Thanks,
Karunakar
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] Does edk2 supports RFC standards 3132?
Hi all, Does edk2 supports RFC 3132? I can find DHCP RFCs supported info in Dhcp4Impl.h, it doesn't have RFC 3132. Does it mean edk2 don't support it yet? Do edk2 have plans to support it? /** @file EFI DHCP protocol implementation. RFCs supported are: RFC 2131: Dynamic Host Configuration Protocol RFC 2132: DHCP Options and BOOTP Vendor Extensions RFC 1534: Interoperation Between DHCP and BOOTP RFC 3396: Encoding Long Options in DHCP. Copyright (c) 2006 - 2016, Intel Corporation. All rights reserved. This program and the accompanying materials are licensed and made available under the terms and conditions of the BSD License which accompanies this distribution. The full text of the license may be found at http://opensource.org/licenses/bsd-license.php THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS, WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED. **/ Thanks, karunakar ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] The network interface configuration is taking some delay to update in DHCP case
Hi Jiaxin,
In the case of Ip4FormExtractConfig() we are using
'IpSb->DefaultInterface->Configured' ,which is updated in
Ip4Config2OnDhcp4Complete().
So if we call Extractconfig before this event getting Configured value as 0 and
in setup Configured is disabled which is false.
Thanks,
karunakar
-Original Message-
From: Wu, Jiaxin [mailto:jiaxin...@intel.com]
Sent: Wednesday, April 19, 2017 2:20 PM
To: Karunakar P; edk2-devel@lists.01.org
Subject: RE: [edk2] The network interface configuration is taking some delay to
update in DHCP case
Hi Karunakar,
May I ask why you want to signal dhcp event before ExtractConfig? In my
opinion, it doesn't matter to call ExtractConfig even dhcp is not finished.
You know the dhcp MAY be failure, then event will never be called.
Thanks,
Jiaxin
> -Original Message-
> From: Karunakar P [mailto:karunak...@amiindia.co.in]
> Sent: Wednesday, April 19, 2017 12:36 PM
> To: Wu, Jiaxin <jiaxin...@intel.com>; edk2-devel@lists.01.org
> Subject: RE: [edk2] The network interface configuration is taking some
> delay to update in DHCP case
>
> Hi Jiaxin,
>
> I've found something related to this.
>
> Ip4Config2OnDhcp4Complete()
> Callback function when DHCP process finished. It will save the
> retrieved IP configure parameter from DHCP to the NVRam. Set the
> station address, subnetmask and gateway address for the default interface.
> And this function is taking some delay to Set the Address. If we add
> some delay by that time Ip4Config2OnDhcp4Complete() was done and
> printing the values are correct. If print the values before this function we
> are getting as 0.
>
> Could you please suggest anything that we can overcome this delay or
> we can Signal this event before ExtractConfig called.
>
> Thanks,
> Karunakar.
>
> -Original Message-
> From: Karunakar P
> Sent: Tuesday, April 18, 2017 2:22 PM
> To: 'Wu, Jiaxin'
> Subject: RE: [edk2] The network interface configuration is taking some
> delay to update in DHCP case
>
> Hi Jiaxin,
>
> Thank you very much for your instant reply. I changed the print statements.
>
> EFI_STATUS
> Ip4Config2ConvertConfigNvDataToIfrNvData (
> IN IP4_CONFIG2_INSTANCE *Instance,
> IN OUT IP4_CONFIG2_IFR_NVDATA *IfrNvData
> )
> {
> ...
> IpSb = IP4_SERVICE_FROM_IP4_CONFIG2_INSTANCE (Instance);
>
> +Print value of IpSb->DefaultInterface->Configured (Printed value is
> +IpSb->DefaultInterface->Configured = 0)
>
> if (IpSb->DefaultInterface->Configured) {
> IfrNvData->Configure = 1;
> } else {
> IfrNvData->Configure = 0;
> goto Exit;
> }
> + Print value of IpSb->DefaultInterface->Configured (Printed value is
> + IpSb->DefaultInterface->Configured = 0)
>
> ...
> Exit:
> +Print value of IpSb->DefaultInterface->Configured (Printed value is
> +IpSb->DefaultInterface->Configured = 0)
> }
>
> [Observation]
> 1. IpSb->DefaultInterface->Configured itself getting as 0.
> 2. If add some delay before print, then it is printing as 1
> EFI_STATUS Ip4Config2ConvertConfigNvDataToIfrNvData (
> IN IP4_CONFIG2_INSTANCE *Instance,
> IN OUT IP4_CONFIG2_IFR_NVDATA *IfrNvData
> )
> {
> ...
> IpSb = IP4_SERVICE_FROM_IP4_CONFIG2_INSTANCE (Instance);
>
> + Add some delay
> +Print value of IpSb->DefaultInterface->Configured (Printed value is
> +IpSb->DefaultInterface->Configured = 1)
>
> if (IpSb->DefaultInterface->Configured) {
> IfrNvData->Configure = 1;
> } else {
> IfrNvData->Configure = 0;
> goto Exit;
> }
> + Print value of IpSb->DefaultInterface->Configured (Printed value is
> + IpSb->DefaultInterface->Configured = 1)
>
> ...
> Exit:
> +Print value of IpSb->DefaultInterface->Configured (Printed value is
> +IpSb->DefaultInterface->Configured = 1)
> }
>
> > Could you please help in where it is taking time to update the values.
>
> Thanks,
> Karunakar.
>
> -Original Message-
> From: Wu, Jiaxin [mailto:jiaxin...@intel.com]
> Sent: Tuesday, April 18, 2017 1:44 PM
> To: Karunakar P; edk2-devel@lists.01.org
> Subject: RE: [edk2] The network interface configuration is taking some
> delay to update in DHCP case
>
> Hi Karunakar,
>
> With your reproduction Step 2, DHCP process will be triggered. Ip and
> SubnetMask in IP service default interface will also be updated once
> the DHCP process finished. For detailed, you can check the
> Ip4Config2OnDhcp4Complete -> Ip4Config2SetDefaultIf ->
> Ip4Config2SetDefaultAddr -> Ip4SetAddress.
>
> So, before DHCP finished, Ip and SubnetMask sh
Re: [edk2] The network interface configuration is taking some delay to update in DHCP case
Hi Jiaxin,
I've found something related to this.
Ip4Config2OnDhcp4Complete()
Callback function when DHCP process finished. It will save the retrieved IP
configure parameter from DHCP to the NVRam. Set the station address, subnetmask
and gateway address for the default interface.
And this function is taking some delay to Set the Address. If we add some delay
by that time Ip4Config2OnDhcp4Complete() was done and printing the values are
correct. If print the values before this function we are getting as 0.
Could you please suggest anything that we can overcome this delay or we can
Signal this event before ExtractConfig called.
Thanks,
Karunakar.
-Original Message-
From: Karunakar P
Sent: Tuesday, April 18, 2017 2:22 PM
To: 'Wu, Jiaxin'
Subject: RE: [edk2] The network interface configuration is taking some delay to
update in DHCP case
Hi Jiaxin,
Thank you very much for your instant reply. I changed the print statements.
EFI_STATUS
Ip4Config2ConvertConfigNvDataToIfrNvData (
IN IP4_CONFIG2_INSTANCE *Instance,
IN OUT IP4_CONFIG2_IFR_NVDATA *IfrNvData
)
{
...
IpSb = IP4_SERVICE_FROM_IP4_CONFIG2_INSTANCE (Instance);
+Print value of IpSb->DefaultInterface->Configured (Printed value is
+IpSb->DefaultInterface->Configured = 0)
if (IpSb->DefaultInterface->Configured) {
IfrNvData->Configure = 1;
} else {
IfrNvData->Configure = 0;
goto Exit;
}
+ Print value of IpSb->DefaultInterface->Configured (Printed value is
+ IpSb->DefaultInterface->Configured = 0)
...
Exit:
+Print value of IpSb->DefaultInterface->Configured (Printed value is
+IpSb->DefaultInterface->Configured = 0)
}
[Observation]
1. IpSb->DefaultInterface->Configured itself getting as 0.
2. If add some delay before print, then it is printing as 1 EFI_STATUS
Ip4Config2ConvertConfigNvDataToIfrNvData (
IN IP4_CONFIG2_INSTANCE *Instance,
IN OUT IP4_CONFIG2_IFR_NVDATA *IfrNvData
)
{
...
IpSb = IP4_SERVICE_FROM_IP4_CONFIG2_INSTANCE (Instance);
+ Add some delay
+Print value of IpSb->DefaultInterface->Configured (Printed value is
+IpSb->DefaultInterface->Configured = 1)
if (IpSb->DefaultInterface->Configured) {
IfrNvData->Configure = 1;
} else {
IfrNvData->Configure = 0;
goto Exit;
}
+ Print value of IpSb->DefaultInterface->Configured (Printed value is
+ IpSb->DefaultInterface->Configured = 1)
...
Exit:
+Print value of IpSb->DefaultInterface->Configured (Printed value is
+IpSb->DefaultInterface->Configured = 1)
}
> Could you please help in where it is taking time to update the values.
Thanks,
Karunakar.
-Original Message-
From: Wu, Jiaxin [mailto:jiaxin...@intel.com]
Sent: Tuesday, April 18, 2017 1:44 PM
To: Karunakar P; edk2-devel@lists.01.org
Subject: RE: [edk2] The network interface configuration is taking some delay to
update in DHCP case
Hi Karunakar,
With your reproduction Step 2, DHCP process will be triggered. Ip and
SubnetMask in IP service default interface will also be updated once the DHCP
process finished. For detailed, you can check the Ip4Config2OnDhcp4Complete ->
Ip4Config2SetDefaultIf -> Ip4Config2SetDefaultAddr -> Ip4SetAddress.
So, before DHCP finished, Ip and SubnetMask should be always zero. Your
observed value may be printed during DHCP process.
I suggest you change your print code as below:
EFI_STATUS
Ip4Config2ConvertConfigNvDataToIfrNvData (
IN IP4_CONFIG2_INSTANCE *Instance,
IN OUT IP4_CONFIG2_IFR_NVDATA *IfrNvData
)
{
...
IpSb = IP4_SERVICE_FROM_IP4_CONFIG2_INSTANCE (Instance);
if (IpSb->DefaultInterface->Configured) {
IfrNvData->Configure = 1;
} else {
IfrNvData->Configure = 0;
goto Exit;
}
+ Print value of IpSb->DefaultInterface->Ip Print value of
+ IpSb->DefaultInterface->SubnetMask
...
}
Above print can ensure the Ip and SubnetMask is printed after DHCP finished.
Thanks,
Jiaxin
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Karunakar P
> Sent: Tuesday, April 18, 2017 3:04 PM
> To: edk2-devel@lists.01.org
> Subject: [edk2] The network interface configuration is taking some
> delay to update in DHCP case
>
> Hi All,
>
> I've been facing an issue with IP4 SERVICE Default interface value.
>
>
>
> [Reproduction Steps]
> 1.Add trace messages to print the values of ip and SubnetMask in
> Ip4FormExtractConfig() -> Ip4Config2ConvertConfigNvDataToIfrNvData()
>
> EFI_STATUS
> Ip4Config2ConvertConfigNvDataToIfrNvData (
> IN IP4_CONFIG2_INSTANCE *Instance,
> IN OUT IP4_CONFIG2_IFR_NVDATA *IfrNvData
> )
> {
> ...
> IpSb = IP4_SERVICE_FROM_IP4_CONFIG2_INSTANCE (Instance);
>
> + Print value of IpSb->DefaultInterface->Ip Print value of
> + IpSb->DefaultInterfa
[edk2] The network interface configuration is taking some delay to update in DHCP case
Hi All,
I've been facing an issue with IP4 SERVICE Default interface value.
[Reproduction Steps]
1.Add trace messages to print the values of ip and SubnetMask in
Ip4FormExtractConfig() -> Ip4Config2ConvertConfigNvDataToIfrNvData()
EFI_STATUS
Ip4Config2ConvertConfigNvDataToIfrNvData (
IN IP4_CONFIG2_INSTANCE *Instance,
IN OUT IP4_CONFIG2_IFR_NVDATA *IfrNvData
)
{
...
IpSb = IP4_SERVICE_FROM_IP4_CONFIG2_INSTANCE (Instance);
+ Print value of IpSb->DefaultInterface->Ip
+ Print value of IpSb->DefaultInterface->SubnetMask
...
}
2. Assign ip to SUT using IPv4 Network Configuration page.
( Enable Configured and Enable DHCP and Save Changes and Exit )
3. reset the SUT once IP assigns
[Observation]
1. On restart, Ip4FormExtractConfig() gets call and prints Ip and
SubnetMask values are 0.
2. If add some delay before printing those values , then getting the
proper values
+ add Delay some delay
+ Print value of IpSb->DefaultInterface->Ip
+ Print value of IpSb->DefaultInterface->SubnetMask
3. In the case of Static Ip , printing proper values without giving any
delay.
Could you please help in where it is taking time to update the values in DHCP
case.
Thanks,
Karunakar.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
